ITプロジェクトでなぜドキュメントを書くのか？
ITプロジェクトでの発注者と受注者の関係は以下である。
【発注者はお金を払って物を作ってもらう人、受注者はお金をもらって物を開発する人】
その場合、発注者の意図を正しく理解でき、製造物が正しく動作するとした場合ドキュメントは不要となるはずである。
フリーランスが受注するケースなどはこれに該当すると思う。
ところが、開発の規模が大きくなったり、システム化する業務が複雑であったりする場合、口頭だけでやりたい事を伝えるのは困難となってくる。
また、口頭のみでやり取りした場合、発注者が伝えた通りの物ができているのかを確認する方法もなくなってしまう。
そこで、契約から納品までを円滑に進めるために合意形成をするため、合意形成をした証拠品としてドキュメントを作成することになったと考える。
合意形成
ITプロジェクトのドキュメンテーションについては、IPAによる機能要件の合意形成ガイドというガイドラインが存在するが、2010年のもので少々古く読まれている方も少ないと思う。
また、手に馴染んでない細かいルールは実践できない事が多く、結局のところは属人的なルールが蔓延し、実際には会社に存在する過去のドキュメントをベースにプロジェクト毎で、およそ以下のドキュメントを作成することにしていると思う。
- 要件定義書
- 外部設計書
- 詳細設計書
- 試験項目書
※話を簡単にするためインフラや運用等は除外している
詳細設計書を省略
合意形成とその証拠品としてのドキュメントとした場合、外部設計を行う人間とプログラム製造を行う人間が同一人物の場合「詳細設計書」は不要となる。同一人物であれば合意形成は不要だからだ。
低予算、短納期の案件に対応するためには大幅なコストダウンを余儀なくされるため「外部設計と実装を出来る人間」がその様な案件に対応し、低予算で案件を受注する事が常態化してくる。
実は、自分が担当する工程以外の工程を学ぶ教育的側面として大きな役割を担っていたが、その点については考慮されず、コモンズの悲劇が発生してしまったと考察する。
上級SEとPG
ウォーターフォール開発と呼ばれていた頃には、上級SEが設計を行い、PGが実装を行っていた。
しかし、上記の様に詳細設計の工程を飛ばすと、PGができる仕事がない状態となる。
それまでは顧客の案件予算内でエンジニアの育成をできていたが、それができない状態となる。
予算が増えない限り、工程の数は増やせない。
むしろ予算は減る事はあっても増えることはない。
さて、どうするべきだろう？
A1. オフショア
製造工程を安価に抑えて、詳細設計の工程を復活させる。
上級SEを多く抱えている企業であれば、直近は可能であろう。
新たな上級SEをどの様に育成するかが次の課題となると推察する。
A2. ポイントを記載したドキュメント / レビュー
詳細に記載した詳細設計書をメンテナンスするのはコストにしかならない。
『設計者がポイントを記載、実装者が理解を記載するドキュメント』ならどうだろうか？
レビューして指摘することで設計手法を伝える事はできないだろうか？
まとめ
抜けもれない手順書を与えると、与えられた側の人間は思考を停止する。思考する必要がないからだ。
設計ができる上級SEは、プログラムが上手いプログラマーではなく、問題を解決できる開発者だと思う。
思考して問題を解決できた事を確認できるドキュメント、すなわち 上級SE、問題解決できる開発者を育成するためのドキュメントを作成するのがITプロジェクトのドキュメントではないかと考える。