先日までこういう状態だったので、思わず膝を打ったのがこのくだり。
プロジェクトに参加した大多数の人間は，「漠然」とした不安と安心を持っているだろう。全く何も感じない人間はいないはずである。しかし，各個人の性格的な問題，人間関係，業務上での上司の評価，さらに利害関係などが複雑に絡み，その結果，そのような不安や安心を言葉として口にされることは稀である。つまり，プロジェクトメンバーのほとんどは，悶々とした気持ちで開発を行っている。
この状態は，最もいけない状態である。
不安が人間系により表立ったものとして顕在化せず、「やっぱり破綻した」といったような事を第三者に言われてしまう虚無さといったら…。
不安はまず認知して、その不安を無くさなければならないのだということをプロジェクトが認識して、適切な対応策をとらなければならない。単なる杞憂に終わればそれはそれで問題なし。
不安事項を「言いやすいヒト」っていうのもあると思う。不都合な情報を伝えても良い意味でサバサバしていて、変に怒らないヒトがそうだろう。世の中不安と思ってることを指摘すると恐怖感から怒り出してしまう管理者もいたりするしねぇ…。そういうキャパの狭いヒトはあかん。
また、こういった組閣もコスト面やラインが渋い顔をすることがしばしばある。
テスト部隊は実装部隊とは全く別の人間で組閣し，何が正しいのか，そしてそれをどう検証するかを並行で考えてもらうことが必要だろう。実装の早い段階からテストを適用し，全てを網羅するテストシナリオを何度も何度も繰り返し行ってもらうことで，実装コードの現状をメンバー全員で共有する。
天使やカイザーと呼ばれて〜不安を認識することの重要性
この組閣を行うとテスト部隊のコストを実装フェーズから組閣しなければならないし、実装を他社に投げた場合どうするかという問題も出てくる。地力のあるアーキテクトがテスト部隊が行えるタスクをカバーしてコストを最低限に抑えるとか、他社の開発手法についてキッチリ「このやり方で実装して下さい」というメソトロジーを共有できるなら、また話が変わってくるのではないかと。
実際の所は小規模案件ではプロマネが仕様理解できればいいじゃん、大規模案件ではチームリーダーが仕様理解してればいいじゃん、という形でうやむやになってしまっていると思う。
弊社でもJUnitを検収に使える標準化方法を模索しる、という裏タスクが動き始めているようだ。ビルドできないJavaアプリとか普通に納品されたことがあるとかあるとか。
個々人の不安ということから見えることは、やはり「神は細部に宿る」ということ。細部の象徴である不安⇔安心のゆりかごをPDCAできるチームを、プロジェクト遂行のために作らねばならない。
