もういくつ寝ると...今年もあとわずかとなりましたね。
研修も年内は残すところ1週間となり、最後の追い込み中です！
最終課題は、いつもどおりWebシステム開発演習。
グループ開発では個人の力量はもちろん、チームワーク（意思疎通、情報共有）も試されます。
中の人が思うシステム開発の最も効率的なやり方は『すべて一人でやる』です。
そうすれば、ドキュメント（要件定義書、仕様書、設計⇒開発など工程ごとの設計書や取扱説明書の類）は必要ないし、問題が発生した場合の影響把握も簡単になります。
全ては開発者(＝自分)の頭の中にあるわけですから。
．．．こう書くといろいろなところから突っ込まれそうです。*1
引継ぎはどうする？ドキュメントがないと運用ができないでしょう？お客さまとの合意はちゃんと取れているのか？……etc
なら自分で運用もやればいいし、引き継がない方法を考えればいい。お客さまへの説明だって、やりようはあるはず。最悪、引継ぎやもしもの事態への対応を考えたときに、ドキュメントを作成すればいいと思います。
とこんなことを書きましたが、中の人は必ずドキュメントを書きます。
なぜか。
そもそもシステム自体一人で完結できる規模じゃなかったり、プロジェクトの細かい部分を忘れてしまうリスクがあったりします。また、後からプロジェクト増員した時に、スムーズに参加してもらえるというメリットもあります。
なので、ドキュメント類は開発時に書いておきます。*2
世の中には、軽視される作業や、なぜやるかわからないとされて無視される手順なんかがあります。そうみなされた結果、要らないものとして削られてしまい、本来の効果を期待できなくなるものが数多くあります。
以前参加したプロジェクトで、
予算削減のためドキュメントがない
なんていう非常に危険な仕事をしたことがありました。
ドキュメントを作らないという判断をした人がどう考えたかはわかりません。なぜその工程を行うのか、なぜそれを作るのかを考えておらず、正しく判断できなかったのかと思います。もしくは、なんらかの理由で削らざるを得なかったのか。。（ココはヒエラルキーに属するサラリーマンの辛いところかもしれません...）
今思い返しても、ぞっとします。
ちょっと長くなりましたが、ドキュメントは、お客様に提出する成果物という側面だけでなく、プロジェクトの概要や進行を客観的に見ることができるものでもあるべきだと考えます。
これがあれば、チーム全体が取るべき方針、優先順位、残タスク等々いろいろなことがわかります。納期や開発に追われているときは、ただただ時間を取られる邪魔くさいものに感じてしまいがちですが、あとから効果が出るものなんです。
自分の頭の中だけにある考えでモノを作る、という所から一歩進み、全体を俯瞰して考えを整理し、それをチームで共有・協働するためにもドキュメントを起こしてみてはいかがでしょうか。
今回、どうしてこういう話を書いたかというと...
最終課題であるWebシステムの開発では、成果物として「(ある程度)動くシステム」を作ることに加えて、いくつかドキュメント類を作成・提出することも指示されているのです。
課題に費やせる期間は短く、それに反して実装する内容は山盛りです。そのうえ、研修の課題として誰に何のために必要なのかわからないドキュメントまで書かないといけないの？！と思うかもしれません。
でもここまで読んでいただいた人はもう、ドキュメントの本当の大切さ、わかりますよね。