パイロット開発にAgile開発のアイデアを適用した事例～実験的アプローチ #JaSST_Kansai

先週開催されたJaSST'13 Kansaiで、細谷さんが発表された実験的アプローチの話がとても興味深かった。
理解できたことをメモ書き。
間違っていたら後で直す。

【参考】
JaSSTソフトウェアテストシンポジウム-JaSST'13 Kansai

JaSSTソフトウェアテストシンポジウム-JaSSTレポート

JaSST関西2013私的まとめ - Togetter

[#Agile] 組織的改善から現場改善へ #JaSST_Kansai: ソフトウェアさかば

フィードバックループ構築の最初の一歩：メトリクスの重要性 | "Lean Startup Japan"

【1】新しい技術を適用する場合の問題点

ソフトウェア開発案件では、特に新規開発では、必ず新しい技術を使って開発するのが普通。
例えば、Java＋Scalaを使おう、とか、RailsとNode.jsを使おうとか、バッチにCobolではなくAsakusaフレームワークのHadoopを使う、など。
理由は、その時代の最新のフレームワークやライブラリ、ハードウェアを使うことで、システムが運用できる期間を長く維持するためだ。

細谷さんの事例では、原因結果グラフやドキュメント生成ツールなど、特定の課題や特定の工程に対して、新しい技術を適用しようとしている。

しかし、新しい技術を使う場合、リスクは結構ある。
一番のリスクは、開発案件や自分たちのチームのコンテキスト(状況)にその技術がうまく当てはまるか、ということだろう。
本では、こうすればうまくいく、と書かれていても、プロジェクトやチームのメンバーのスキル、開発環境は様々であるがゆえに、制約条件も多い。
その制約条件と技術がマッチしない場合は、失敗プロジェクトになる。

また、新しい技術は実際に使ってみたら、想定した効果が出なかった、あるいは、別の悪影響が現れた、というリスクもある。
例えば、最新のフレームワークを採用したのに、開発者が慣れるのに手間取り、開発やテストが長引き、品質も良くなかった。
あるいは、せっかく出来上がったシステムでは、大量のトランザクション処理で性能要件を満たさず、別の解決策を選択せざるを得なかった、など。

だから、経験のあるプロマネは、要件定義をしている期間中に、アーキテクチャの実現可能性調査というパイロット開発を裏で並行作業している時が多い。
早めに実現可能性調査(フィージビリティスタディ)のフィードバックを受けて、うまくいかないならば、別の手段を調査するように、手を打つわけだ。

でも、細谷さんの説明のように、新技術を適用するための検証時間が長かったり、適用した投資コストが大きすぎるために撤退しづらいという問題点がある。
開発がズルズル進んで、結合テスト工程で技術上のリスクが判明したら、その時点で新技術を捨て去ることは普通は困難だ。

細谷さんの事例「実験的アプローチ」は、そんなパイロット開発をメタプロセス化した事例のように思えた。

【2】実験的アプローチのプロセス

実験的アプローチによれば、下記のような流れになる。
ポイントはいくつかある。

JaSST2013 Kansai～「実験的アプローチによる現場改善」(細谷泰夫氏) from akipii Oga

【2-1】手段(細谷さんのコンテキストでは、適用したい新しい技術)の情報収集は、SNSや書籍、コミュニティなどで行う点が面白い。
　うまくいった事例だけでなく、発信者その人も知っているならば、どんなコンテキストで成功したのか、をよく理解できる。
　最近は、FacebookやTwitterですぐにコミュニケーションが取れるし、コミュニティのイベントがとても多いので、感度の高い情報を収集しやすくなったと思う。

【2-2】課題の発見→課題と手段をマッピング→手段の試行

この辺りのプロセスがとても重要。
まずは、繰り返し現れる課題を特定する。
アジャイル開発ならば各イテレーションだろうし、WF型開発ならば過去の複数のプロジェクトが抽出の対象になるだろう。
なぜなら、再現性の高い課題は、新しい技術(手段)で解決できることで大きな効果を得やすくなるからだ。

次に、課題と手段をマッピングする。
普通は、課題と手段の関係は多対多なので、複雑だ。
だから、課題のスコープをできるだけ小さくして、より具体的な課題にすることで、手段を絞り込む。
普通は、1つの課題に対して、複数の手段を取る時が多いだろう。
それゆえに、複数の手段を並行して実施する場合もある。

ここで、手段の試行のゴール(終了条件)は、手段の実践を開始できる状況であること、という説明がある。
この意味は、採用した手段を使えば課題を解決できる可能性が高くなると決断した状況であると理解している。

この辺りのプロセスが重要と思うのは、現場のトラブル(問題・AsIs)から課題(ToBe)を特定して、有効な手段を選定しているからだ。
細谷さんの説明では、原因結果グラフを使うためにCEGTestを使ったりした事例でその辺りの事情を詳しく話してくれて、なるほどと理解できた。

【2-3】結果の評価

手段を実践後、できるだけ早く結果を得て評価する。
評価の基準は、採用した手段が自分たちのコンテキストにうまくハマっているかどうか。
プロジェクトやメンバーの制約条件の元で、その技術で課題を解決できたのか。

失敗したらなば、すぐに撤退すればいい。
そのために早めにフィードバックを受けたわけだから。

成功すればそれでよいだろうが、なぜうまく成功したのか、という必然性をリーダーもメンバーも認識しているとは限らない。
だから、成功した必然性をコンテキストと比較して、そのノウハウを形式知ないし実践知として言語化することが重要。

この辺りはとてもなるほどと思う。
個人的には、実験的アプローチで得られた実践知は、パターン言語でまとめることが有効だろうと思っている。
成功したノウハウは、コンテキスト依存が大きいために、どのプロジェクトでも、どのチームでも適用できるとは限らない。
だから、どんな状況でどんな問題に対して有効であるのか、というパターンで形式化してネーミングすれば、流通しやすくなるだろうと思う。

【2-4】実験的アプローチはパイロット開発の成功率を高めるための一手法

実験的アプローチの原則は、細谷さんに後で聞いたら、リーンスタートアップの手法にヒントを得たと聞いた。
確かに、最低限の機能の製品(MVP)を早く作って、少しずつ改善していくリーンスタートアップの手法と、アーキテクチャ検証などのパイロット開発はとてもよく似ている。

コンテキストと新技術が合致するかどうか、手探りしながら、早く結果を得て、新技術が適用できる範囲を特定していく。
コンテキスト探索手法と言ってもいいのかもしれない。

上記のアプローチは、RedmineやJenkinsなどの新しいツールを導入する場合にも使える。
ツールが全てを解決してくれるとは限らない。
どのコンテキストでうまくいくのか、逆に想定しない副次的な悪影響があるのか、を特定して、ブラッシュアップしていくのが大事。

もちろん、ERPのようなパッケージ製品を導入する場合にも、そのアイデアを流用することはできるだろう。
色々考えてみる。