2018年振り返り

今年も楽しいことが多かった年です。

Keep

仕事以外の楽しいことも増えた1年でした。
・折り畳み自転車を買った。電車で出かけてポタリングが楽しかった。
Amazon VIDEOでいっぱい映画を見た。家族からはディスられているがアニメはお気に入りだ。
ソーシャルレンディングは良いリターンだった。
・今年はSwift, Python, React Naitiveでの開発がいい感じにできた。
・自分のスタートアップは?だけど、デザイン指向、リーンスタートアップスクラム関連の仕事ができたのは大きい

Problem

スタートアップ関連については一度リセットして再度考えを無しが必要かな
・作りたいものを作っている感じで、スケールアウトするような感じはない。
・顧客の課題を深堀しないといけないのに、すぐにソリューションを考えてプロダクトを作ってしまった
・昨年に引き続き、Amazon プライムでビデオを見すぎて夜の睡眠の質が落ちてしまった。
・FinTech関連はIT関連の株下落の直撃を受けてしまった。前半は絶好調で強欲になっていたことが問題。

Try

・スタートアップ関連はギアを落としてチャンスを待つ。課題を深堀、デザイン指向など勝率を上げる方法を学ぶ
・FinTechは安全な運用をできるようにオプションを取り入れる
・あと健康のためにもう少し痩せるように医者に言われたので、60を切るようにする

来年も皆様にとっても良いお年になるように

ソフトウエア開発は発見的な作業だよね

DevOpsとは何か? そのツールと組織文化、アジャイルとの違いにあるようにDevOpsでたまにバリューストリームマッピングの話が出てくる、ソフトウエア開発を決まった作業の繰り返しに見ているような例で説明されるが、本当にそうなの。
僕はこのメタファは多くの場合間違っていると思っている。やって見ないとわからないような開発、不確実性に対応するためにアジャイルを導入している場合は。

バリューストリームマッピングはソフトウェア開発でも有効か?

リーンスタートアップ とスクラム

リーンスタートアップ では素早く起業するためどのように進めれば良いかを唱えている。そのため方向転換とかできるようにアジャイル的な開発が適している。ここまでは納得できる。なので、スクラムアジャイル開発プロセスの一つなので、リーンスタートアップ にあっているという論理もわかる。

でも本当にリーンスタートアップの開発をスクラムでやったほうがいいの?
一人の天才の下にサポーターを集めた外科医型でやるほうが開発は早いじゃないかな。少なくともMVPを作るまでは、
チームをスケールさせるにはもちろんスクラムのようなプロセスは役に立つと思うが

ウォータースクラムフォール

組織のアジャイル・DevOps度をアセスメントする質問に

Q 主要な開発方法論は何ですか?
 1.ウォーターホール
 2.ウォータースクラムフォール
 3.アジャイル

とあった。

ウォータースクラムフォール(Water-Scrum-Fall)ってはじめて聞いたので調べてみると

実用主義者が勝ったのか?Water-Scrum-Fallが一般的に

Water – 多くの場合はITとビジネスの間に行われる、前倒しのプロジェクト計画プロセスの定義
Scrum – 「Water」段階で最初に定められた計画全体を達成するための反復・進化型のアプローチ
Fall – 組織方針やインフラの制約によって定められる、制御された、頻繁でない本番リリースサイクル

日本だとエンタープライズアジャイルとか言っているに似ているような。

エンタープライズの領域は、いろいろ制約があるので、どこでもこうなるのかなと思った。

WebAPIのCSRF対策

Cookieベースの認証とかの場合にX-Requested-Withをつけるようなアイデアがあったのですが、
認証して利用するAPIだったらAuthorizationヘッダーをつけるようにすればそれでOKだよね。
Microsoft Graphもこのタイプ。

https://leastprivilege.com/2015/04/01/implicit-vs-explicit-authentication-in-browser-based-applications/

アジャイル=スクラムで良かったんでしたっけ?

企業向けの開発でも最近アジャイルという言葉が良く出る。その際のキーワードの多くにスクラムが出ている。
スクラムマスター何人いるの?みたいな話もあり。アジャイル開発=スクラム開発みたいになっている。
で実際にスクラムをやっているところもそれなりにあるみたいだけど、あまり上手くいっていない匂いがする。
理由はいろいろあるが、プロダクトオーナーが機能していないはかなり多いような気がする。あと、開発チームが受け身すぎ、責任とりたくないみたいな場合も多い。

アジャイルの反対の位置にはウォーターフォール(WF)があるので、WFからアジャイルへみたいな話が多いのだが、その間にはUPのような繰り返し開発がある。規模が大きく・作るものがきまっているような場合、こっちのほうが良いんじゃないかな

アジャイルは今はビジネス用語になって一人歩きしているので、アジャイルでやってと言われるケースがあるけど、やり方はスクラム一択ではないですよね。

くそストアドプロシージャ

ビジネスロジックを全てSQL Serverのストアドプロシージャで書いていてパフォーマンスがでなくて困っている話を聞いた。
どうも数千行のストアドで内容的にも分からないので、なかなか前に進まないらしい。
性能向上の第一歩は計測なのですが、その影響で性能が落ちるのが怖くて、本番計測も簡単ではないようです。

個人的にはストアドでビジネスロジックを書くこと自体受け入れ難い話なのですが、このような状況で対処するならどんな方法にするかなと

ここでの課題を並べると

・性能の計測が本番に適用できない
・パフォーマンスが出ない処理の特定方法が分からない
・でかいストアドに対する対処

性能の計測が本番に適用できない

これは性能測定をした場合の影響が小さければいいわけですが、どのくらいの影響がでるかが分からないレベルなんでしょうね
SQLプロファイラ(GUI)とかだと遅そうですが、その他にも選択肢はあります。以下の記事で様々な方法の比較があって、拡張イベントであれば10%程度遅くなりますが許容範囲のように見えます。

Measuring “Observer Overhead” of SQL Trace vs. Extended Events

トレースファイル:約20% 影響(遅くなる)
SQLプロファイル:約80%影響(遅くなる)
拡張イベント  :約10% 影響(遅くなる)

パフォーマンスが出ない処理の特定方法が分からない

計測ができていてもその解析方法が分からないと前に進みません。特定のSQLであれば実行プランなどを見て改善できますが、問題になるSQL文やプロシージャを特定する必要があります。これらの絞り込みはSQL実行時間やCPUコスト、IOコスト、実行回数を調査することになります。

第4回 サーバートレースの解析方法

でかいストアドに対する対処

問題がわかってもストアドが複雑で単純には手を付けれない場合は、その複雑度を下げることを考えます。
リファクタリングが思いつきますが、ストアドのリファクタリングツールを探してみるといくつかあるようです。

SQL Enlightをみるとストアードプロシージャや関数としてT-SQLスクリプトカプセル化するようなこともできるので、大きなストアドを機械的に分割しながら構造化して扱い易くします。


最後に

くそストアドプロシージャとの戦いはこれらの作業を繰り返して改善していくんでしょうね。
あと、データ分割して並列実行のアプローチ(ミニバッチ化)や、それをさらに小さくしてストリーム処理にしてしまうアイデアもありですね。

一番いいのは、くそストアドプロシージャに出逢わないことなんでしょうが