読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ソフトウェア開発と設計書の関係

Info-Qの記事「アジャイルにおけるドキュメント:いつどれくらい書くべきか」を読みながら考えたこと。ソフトウェア開発と設計書の関係については、本ブログでも何回か取り上げている。

アジャイルソフトウェア開発マニフェストは「包括的なドキュメントよりも動くソフトウェア」に価値を置いている。そうだとすると、どんな種類のドキュメントが、いつどれだけ必要なのだろうか?
アジャイルにおけるドキュメント:いつどれくらい書くべきか

発掘的な設計と、創発的な設計

ドキュメントを作るべきかどうかは、ソフトウェア開発プロセスアジャイルかどうかとは無関係だと考えている。開発対象となるソフトウェアの設計が「発掘的」に行われるのか、「創発的」に行われるのかでドキュメント化の戦略が変わってくるのではないだろうか。

発掘的な設計

  • 答えは過去にある。それを適切、的確にとらえて明確化することのがポイント
    • 既存のマニュアル、ルール、ドキュメント
    • 現在の現場担当者が持つ暗黙知
    • 現行システム
  • As-Is 重要
  • 設計の正しさは、有識者(SME:Subject Matter Expert)によって確認される。有識者レビュー重要
  • 正解はある (部分最適であったとしても)

発掘的な設計の場合は、品質をおさえる主たる方法がレビューになる。設計の正しさ(良さとは違う)は既存の知識(文書とは限らない。有識者を含む)と照らし合わせて判断される。だから『想定する最終仕様』をコンパクトに落として点検することが重要となる。

創発的な設計

  • 答えはない(または、答えは未来にならないとわからない)。
  • To-Be重要 (というか、As-Isは無価値)
  • 仮説志向
  • 設計の正しさは、実現によってのみ確認される。出来るだけ早く仮説検証を行い、誤りがあれば訂正する
  • 進化的設計
  • 正解はない

創発的な設計の場合は、完成するまでプロダクトの良し悪しはわからない(いわんや、設計をや)。ということでドキュメント化の目的が発掘的な設計とはまったく異なる。設計の過程や、意思決定の根拠を形式知として共有することが重要だと思う。また、開発をするソフトウェアの規模が小さかったり、Wikiや構成管理ツールなどで情報共有できるのであれば、ドキュメント化を行わなくても問題ないだろう。

創発的な設計が必要とされるプロジェクトだと、アジャイル開発プロセスが適用される場合が多い(逆の関係ではない点に注意)。しかし、ドキュメントの要否と開発プロセスには直接的な関係があるわけではない。アジャイル開発プロセスを適用したとしても、発掘的な設計が必要とされるのであれば、それ相応にドキュメント化を行ったほうが良いのではないかと考える。

未来への道は、きれいな直線ではなく、まがりくねった道なのだ。その道はジグザクで、でこぼこで、穴だらけで、思いがけない行き止まりがある。ガードレールは壊れかけている。あなたを導く道しるべもほとんどない。その行程すべてを、地図なしで進まなければならない。偉大な経営学者である故ピーター・ドラッカーの言葉を借りれば、現在の延長線上に未来を予測することは、夜に後ろを見ながら車を運転するようなものだ。
シナリオ・プランニング――未来を描き、創造する

シナリオ・プランニング――未来を描き、創造する

シナリオ・プランニング――未来を描き、創造する

蛇足

本記事を書きながら色々調べていたら、仕様発掘(Specification Mining)という研究分野(?)があることがわかった。ただし計算機科学的な内容っぽい。思ってたんと違う。

世の中、いろいろあるなぁ。