ドキュメンテーションに対する危機感
様々な問題の真因を
『コミュニケーション』
と定義した時、ＩＴ業界において大きな障壁となるのが、エンジニアの
『ドキュメンテーションスキルの低さ』
です。こればかりはここ10年ほどで痛切に感じます。
こういうと、アジャイル開発モデルを採用していて、その手法をモノにしているグループや企業は「？」と思うかもしれません。
そもそもアジャイルはドキュメント化をあまり重要視しません（まったくではありませんが）し、重要視しなくても時間経過によって引き起こされる記憶欠落による「情報劣化」や「認識齟齬」が起きる前に
合意形成 → プロダクト化 → 検証
が成立する程度の小サイクルを繰り返すようにし、仮に多少の劣化や齟齬が起きても次のイテレーションで対応が可能となるような仕組みとすることで、最低限のドキュメント化のみで進められるようになっているからです。
だからアジャイルで開発することを中心としているエンジニアや企業にとっては、「ドキュメンテーションスキル」が優先度の高いプロセスとなっていないのは仕方ありません。それで成立する開発モデルですから。
とはいえ、「プロジェクトのライフサイクル」だけを見れば非常に有効で、ウォーターフォールと比べても非常に成功率が高いアジャイル開発モデルですが、ドキュメント化する量を圧倒的に減らす（その分をコミュニケーションでカバーする）…という特性上、「システムのライフサイクル」や「顧客ビジネスのライフサイクル」を見据えた時にリスクが残るのは否めません。
ドキュメントは「情報の永続化」という点においてとても重要な役割を果たします。アジャイルを含め、ドキュメント化する量を圧倒的に減らすと言うことは、システムリリース後に当時の決定事項や検討事項、経緯などを記録に残さないということでもあります。その場でのモノづくりはそれで良くても何か月、何年と経過した後、保守・運用や保守開発、システムリプレースなどの際に、開発当時の情報を引き出すことは非常に困難となってしまいます。開発モデルの選定時にはこの点に注意してください（特に利用者）。
ですが、世の中のＩＴ企業がすべてアジャイル開発モデルとなっているわけではありませんし、場合によってはアジャイルとは相性の悪いプロジェクト…というのも未だに存在しています（特に日本（民法）の定める契約類型と上手くマッチングするものがあまりない…（顧客に都合がよすぎたり、あるいはベンダーにあまりに都合がよすぎたり））。
特に億を超える大規模なシステム開発となると、まだまだウォーターフォールの方が圧倒的に多いのではないでしょうか。
多重下請け構造がまだまだ多いこの業界では、大手ＩＴベンダーの下で２次請け、３次請けをしている中小企業も多いと思います。そういったところでは、容易に「自分たちだけアジャイルで…」と言えない背景もあるのでしょう。
ですが、アジャイルを採用するしないに関わらず、エンジニアの多くは「ドキュメンテーション」業務を嫌います。
中途半端にプライムで請けていて、しかもアジャイルを採用していない…ような企業などはエンジニアないしプロジェクトマネージャーに「開発の進め方に対する決定権がある」と勘違いしがちです。
結果、ウォーターフォールであっても、なんとなーく過去の事例に基づいて仕様書や設計書は作るのですが
本当に必要かどうか検討していない
インプットとアウトプットの関係性を紐解いていない
ドキュメントの中に記載するべき情報群の整理がなされていない
状態で、思考を停止したまま「過去踏襲」が行われます。
気持ちはわかります。
そうした方が「見積り」する際に過去の経験則が活きますし、もしも過去のプロジェクトではそれで上手くいっていた（ように感じる）のであれば、同じことをすれば同じ結果になると思ってしまいますから。
ですが本来、プロジェクトには独自性が伴うものであって、不確実性をコントロールするものだと理解していれば、思考停止した過去踏襲ほど怖いものは無いはずです。
…そのことを正しく教えてくれる上司…ひいては企業というのがなかなか存在しないんですよね。むしろ、なんでもかんでも「経験則を信じる」という上司の方が多いのではないでしょうか。
決定されたプロセスに対する作業見積りやその根拠については、経験則も良いと思います。型が決まってしまっているわけですから。ですが、型の選定（プロセスの決定）時にはそれで正しいかどうかを見極めるのに、過去の経験則ではやや不安が残ります。通常は「過去は過去、現在は現在」として正しく検討する必要があるからです。
結果、そうした検討がなされないまま過去踏襲という形で、同様のドキュメントが採用されます。
このように「ドキュメント」が非常に重要なコミュニケーションツールであることを忘れ、ただただ「めんどくさい」作業と認識してしまったエンジニアはどんどんドキュメンテーション活動から遠ざかっていきます。
ひいては
「文書化しない」
↓
「論理的ではなくなる」
↓
「言語化すらしない」
↓
「ＫＫＤ（勘・経験・度胸）に頼ることが一般化する」
↓
「業務の一つひとつが属人的になる」
といった変遷をたどっていくことになります。
こうなってしまうとまともな育成や教育は実現できません。なにせ個々人のＫＫＤに100%頼ってしまうわけですから、ドキュメンテーションスキルだけでなく様々な方針や活動に対して、組織内で統一することが困難となってしまいます。仮にドキュメントフォーマットだけ決めようとしても、それぞれがそれぞれの"やりやすさ"を主張し、収拾がつかなくなって、必要最低限の記載内容以外はフリーフォーマットに近い様式となっていることが多いのではないでしょうか。
そう。
こうなってしまうと烏合の衆の完成です。
当然、組織の中で優秀な人材なんてのは一握りしかいません。
個々人の自由となる領域が増えれば増えた分だけ、優秀な人にとっては水を得た魚のようにスイスイと泳ぎ回れることでしょう。一人ひとりが自由に泳ぎ、集団としての体裁は無くなってしまうかもしれませんが、居心地よく感じるはずです。
そして、その弊害として残った凡庸な人たちは何かしらの負債を抱え、まともな評価を受けることも難しくなり、苦しむことになります。そんな状況でも属人的であることを強要され、まともにドキュメント化する機会もスキルも奪われてしまい、十分なコミュニケーション（情報の伝達・共有）すらしてもらえず、ますます苦しくなっていきます。
その結果、残るのは「苦手意識」です。
ただでさえ一部の決定権を持った優秀な人たちのせいで、ドキュメンテーションを軽視しつつあるなかで、さらに苦手意識まで植え付けられていきます。ますますドキュメント化することから遠ざかりたいと思うのは当然の心理ではないでしょうか。
このように、文書化することを嫌う（嫌いにさせられる）エンジニアが多い中、本当に必要な情報を本当に必要な分だけ、本当に必要なドキュメントに記録し、次タスク以降のインプットとして再利用する…その機会がどんどん減っていくことで、デザインセンス的な力量もそうですけど、なにより
「コミュニケーションの本質」
を果たせないドキュメントで自己満足するプロジェクトがどんどん増えているという事態が既に現実のものとなってしまっています。
具体的には
ドキュメント一つひとつの目的や用途がハッキリしていない
ドキュメントをインプットとしたプロセスがハッキリしていない
というものです。事実、ドキュメントを開いて見てみれば必要な情報を記載する箇所が無かったり、記載すべき箇所があっても記載されていない…ということはよくあります。そして、そのせいでトラブルプロジェクトにまで発展するという例は決して少なくありません。
そのたびに
「このドキュメントは何のために作ったの？」
「このドキュメントの目的は？」
「このドキュメントは次工程以降にいったいどう使われているの？」
と聞かなければならないことが多々あります。
かれこれ20年以上、ＩＴ業界ではお客さまからの短納期化／低コスト化を要求する煽りもあって、ますますエンジニアにとっては
ドキュメンテーションを削る
ことを免罪符とするようになってしまいました。結果、時系列につながった情報・認識共有に支障をきたすプロジェクトが後を絶ちません。
こうした課題は本来エンジニアリング以前のもので、人の本質的な弱点（記憶や認識を維持し続けられない）を補い、ビジネスで支障を起こさないための取り組みであるべきなのですが、エンジニアはアンジニアリングだけしか見ようとせず、そうしたエンジニアリングを長年続けてきたなかで選抜されたプロジェクトマネージャーはこうした課題リスクがあることに気づかないまま次の世代のエンジニアを巻き込み、またその風土を根付かせていくことになります。
その結果、いざドキュメンテーションが必要になると
とにかくパフォーマンスが悪い
とにかく質が悪い
とにかく可読性が低い
とにかく一つひとつの成果物の効果・価値が低い
という問題を引き起こします。質が悪かったり、可読性が低かったりすると、そのドキュメントをインプットにした次のプロセスは自ずと質が低いものとなっていきますから、むしろ作れば作るほど不良在庫となってプロジェクトの成功を脅かしかねません。
そしてそのことをエンジニア達も自覚しているのでしょう。
テスト工程にもなると計画書はおろか、設計書や仕様書などに目もくれず、テストケースを洗い出そうとするエンジニアも出てきます。なかにはそれでも質の高いテスト内容となっているケースもあるのでしょうが、もう完全に属人化してしまっていて組織に対する信用の土台は構築できませんし、当然ながら次プロジェクト以降における再現性も保証できません。ＫＫＤ任せになんてしていると、同じ優秀な人に実施させても、同じ優秀な結果になるとは限らないんです。
さらに、個人がどんなに優れていても、それは所詮組織の中のごく一部。しかも当人の優秀さと人を育成する能力は全く別物。エンジニアやプロジェクトマネージャーとしては優秀だったが、上司になった瞬間組織はボロボロになっていった…なんて話は枚挙にいとまがありません。
そうして組織の偏差値としては、信用に値しないようになっていってしまいます。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。