ある製造業の企業様の、ERP刷新のお手伝いをしている。
大規模な刷新なので、インフラや基盤もチームが編成されてサブプロジェクト化されている。私はそこにメンバの一人として末席に置いてもらっている。
2018年9月現在、いよいよ要件定義、という段階に来ているが、業務担当やアプリケーション担当から、基盤に対する要求が一向に降りてこない。したがって、見切りである程度の準備を始めるより仕方ない。
大抵の大規模プロジェクトはうまくいかない（うまくいったように見せているプロジェクトが大半である）。
このあたりは、経営層、コンサル、ＳＩベンダ、エンドユーザなど、いろんな人の思惑の食い違いや、例えば組織などの構造的な問題があったり、参画する背景の違う様々な利害関係者（そしてそれぞれが特有の文化やプロトコルを当たり前のように押し付け合う）が集まって混沌とするために、そもそもコミュニケーションが成り立たなかったり、そのことによって多大なコストと時間を浪費するなど、原因を挙げればきりがない。この件については日を改めて整理したいと思う。
今回テーマとしたいのは、文書やその内容の体系化（管理）の問題だ。
以前、データセンターの仮想基盤構築のプロジェクトで、PMOの一員として参画したことがあった。途中までは、利害調整が仕事の大半を占めていたと記憶している。
基盤チームの単体テストの品質があまりにも酷かったため、「テストチームのリーダーをやってください。」と、プロジェクトマネージャから依頼を受けた。とっ散らかすだけとっ散らかして、時間もカネも無い状態でのパスである。
その時点で、単体テストは100％終了していることになっていた。後からよくよく調査すると、構築チームのリーダーが、単体テストフェーズでやるべきことを結合テストフェーズに先送りしていたから、そのように見えていた、というカラクリであった。まあそんなこはどのプロジェクトでもよくある話しで、プライドが高く、かつ心の弱い担当は大抵こういうことをしでかす（そいつの上司が「叱責」以外に管理の手段を持たないからだ）。
もっと問題なのは、現場のメンバがテストフェーズにおいて、「思いついたテストを全部やったから満点。」みたいな曖昧な話しで終わっている場合が、あまりにも多いことだ。
テストのフェーズになると、「どれだけ機能が実現できていて、どれだけ品質が担保されているか」、という目的で、要件定義書が読み返されることは、まずほとんどない。
これで何が起こるかというと、サービスリリース前になって、要件に対する品質保証が丸っぽ抜け落ちていたり、酷い場合には、機能が実装されていない（設計書がない）などという、あまりにもお粗末な話しになる。大抵なる。
私は、１週間ほどかけて、要件定義書の記載内容を構造化してコード化し、基本設計書の記載内容にもコードを振り、Excelで紐付けを行なった。
さすがにテスト項目までは手が回らなかったので、ここは現場のメンバーに依頼して、基本設計書の記述内容とテスト項目とのマッピングをやってもらった。
この結果、要件に対してテスト項目の全てが紐づくようになり（m:nの関係で非常に複雑なものにはなるのだが）、要件毎の進捗や品質保証のカバー率が可視化できるようになった。
最初は構築メンバーの負担を増やすことになり、「いきなり来た奴が仕事を増やしやがって。」みたいな感じで随分嫌われたが、途中から私がやりたかったことを理解してくれたようで、態度も随分やわらかくなった。
※というよりは全量と進捗が見えて、「あとどれだけやれば終わり」、ということが認識できるようになった段階で、他人に接する態度にも余裕が出たのかもしれない。
マネジメント側からは、建て直し結果そのものは評価されたが、取り組んだ内容や手法に関する評価は一切なかった（そもそも手法には興味がなかったようである）。
その後、これらをシステム化したりルール化したり手順化したり、ということについては、その他の業務に追いまくられてタイムアップで挫折した（余暇でやるほどのモチベーションも湧いてこなかった）。
現在のプロジェクトでは、インフラ構築を担当される方が、最初からそういった紐付けのスキーム（管理粒度は最小ではないが）を持っていらっしゃったようなので割と安心している。
苦い経験を多少なりともスキームやツールに落とし込んでいるあたりは、さすが大手、という感じである。
私はもう少し細かい管理が必要なのではないかと感じたのだが、ご担当曰く、「パラメータの一つ一つまで紐づけると時間とコストがかかる。」とのことで、これも尤もな話しであろう。
プロジェクトが火の車になってしまったのでそれを立て直す、というフェーズであれば、ある程度は整理にコストをかけることも黙認されるのであろうが、まあこの手の話しにはバランス感覚は必要だわな、、、。