オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

稟議書でアジャイル開発と技術的負債を説明するのに適していそうな講演資料 - IEEE Computer Society, IEEE Software主催のイベントから

»

IEEE Computer Society, IEEE SoftwareによるSoftware Expert Summit 2012というイベントが2012年6月26日にロンドンで開催されました。基調講演、講演、パネルディスカッションというオーソドックスな構成です。プログラムの詳細は、こちらで公開されています。

当日の資料の一部が最近公開されたようで、興味があったものの参加できなかったので資料を眺めていました。私が気になったのはアジャイル開発と技術的負債を説明する2つの講演資料でした。アジャイル開発のほうは不確定な状況への対応を中心に紹介されています。技術的負債のほうは負債によるコスト増と負債を解消するための対応コストの双方を示しながら、技術的負債とうまくつきあっていく方法を提案しています。客観的に書かれているので、稟議書等での引用でも使えそうな感じです。

  • アジャイル開発(講演資料はこちら): The Value Proposition for Agility
    序盤でアジャイル開発の柔軟性がもたらす価値をたとえ話で説明しています。アジャイル開発を柔軟な開発プラクティスと位置づけた上で、次のようなたとえ話をしています。(おそらく遊びに行くための)航空券のチケットA(300ドルでキャンセルによる返金不可(キャンセルは300ドル))とチケットB(600ドルでキャンセル時の返金は550ドル(キャンセルは50ドル)があり、2つのシナリオを提示しながら、飛行機に乗れた場合の費用と都合がつかずキャンセルした場合の費用を比較しています。シナリオ1(飛行機に乗る日に絶対にジャマは入らない)、シナリオ2(飛行機に乗る日に60%の確率で上司が仕事をするようにいうかもしれない)が示され、不確定要素の大きい状況(シナリオ2)ではチケットBの価値が大きくなることを説明しています。不確定な状況では柔軟性のあるアジャイル開発のほうが価値が大きいことを説明しています。
  • 技術的負債(講演資料はこちら): Accruing Technical Debt
    前半に技術的負債の事例としてネットスケープが紹介されています。また、17ページに「うまく対応できていれば、全ての技術的負債が悪というわけではない」という記述があり、対応の方法が紹介されています。29ページには、技術的負債に対応するコストを最適化することによって価値を最大化できるとする模式的なグラフがあります。スケジュールを優先して場当たり的な修正を繰り返した後のソースコード等、見えないうちにマイナスの影響を与えるものを技術的負債と呼んでいます。この講演資料では、技術的負債を具体例で示しつつ、負債を把握しコスト対効果が最大となるよう対応していくべきという考え方を示しています。

両方の話とも日本にも識者が多く、勉強会、講演等で聞くことができる内容ですが、上2つの講演資料は排他的な部分が少なく客観的な説明ができているように感じました。「こういう失敗を繰り返してはいけない」という熱意や現場での苦労が問題を解決する上では大切なのですが、熱い思いが込められすぎていると、稟議書等には適していないこともあるように思います。

上の2つの資料では、アジャイル開発は不確定要素が多い場合に特に有効、技術的負債は持つべきではないがどうしても発生してしまうのでコストとのバランスをとりながらうまくコントロールするという点で比較的客観的な解説になっています。アジャイルや技術的負債にあまり親しくない方がみても心理的抵抗が少ない状態で理解できるように思いました。

なんとなくPublickeyで日本語の紹介記事が公開されそうな内容にも見えます。英語版で全部を読む時間がないという方はのを待つのも一つの手かもしれません。Publickeyでは、これまで多くの英語版の長い記事をわかりやすく簡潔に和訳されています。

Comment(0)