脱出! 暗闇プロジェクト第1-4回を読んで

日経コンピュータの「脱出! 暗闇プロジェクト」の第1-4回を読んだ。
教科書通には対処出来ない場合についての話があり、とても共感出来る内容が多かった。

[優先順位は理屈ではなく「声の大きさ」で]
理屈の通じない相手もいる。
理屈は論理バイアスで偏っている場合も多々ある。
目的が共有出来ていれば「声の大きさ」もそれなりに妥当性がある。

[矛盾する要求は解決せず「先送り」で]
[合意形成が難しい場合は「曖昧なまま」で]
その場ではお互いムキになって感情的に合意出来ない場合も多い。
可能性やそもそも論や理想論を言っているだけで、今回のプロジェクトでは妥協出来る部分も多い。
プロジェクト上諦めなくてはならないタイミングが来ると自然と妥協出来る場合も多い。

[半年前の合意は「期限切れ」]
古い合意は反故にされやすいので、定期的に確認してリフレッシュする必要あり。

[重要な会議は事前に根回しして「儀式」に]
会議では各部門の代表として建前を言う必要がある場合が多い。
事前にキーパーソンから個別に妥協点に関して根回しで同意と取っておく。

[理不尽さをあえて受け入れる]
上手く行っていないのだから理想とかけ離れているのは当たり前。
理想(べき論)とのギャップを呑み込めるのかが重要。
他人の考えを変えるより自分が折れる方が容易。

[KKD(勘、経験、度胸)]
これが重要だと言うのも共感出来る内容。
プロセス(方法論)もプロジェクト運営のツールとしては重要ではある。
PSPでも「データが実務者の感覚と合っている事」を重要視している。。
データは勘を修正、補完するために重要だが、勘と経験を上回ることは無さそう。

[不安は解消せずに上手く付き合う]
リスク管理は難しい。特にリスクを受容すると言う事に関しては。
リスクを受容の合意が形成出来ない場合は誰かが腹を括る必要があるかもしれない。

[モジュール分割を人間関係で決める]
仲の悪い人同士が共同作業しなくて良いようにモジュールを分割すると言う事。
モジュール分割は常識的には開発対象によって最適に分割すると言う事になっている。
実際はある程度に正しい分割は複数考えられるのでそこからメンバの特性に合ったものを選べば良いと思う。
作った人が違えば別のものになると言うのは、文章作成と一緒で当たり前の事。

[課題解決に劇薬は避ける]
問題メンバーがいてもなだめすかしながら穏便に進める方が無難な場合が多い。
そのメンバーを交代させても別の問題が発生する場合が多い。
大切なのは原因を取り除く事よりも問題のある状態を捌ける様になること。

[全メンバーで全情報を共有する]
[メンバー管理は放置プレーで]
担当者レベルが自律的に判断して動けるようにする。個々人に任せる。

[辻褄が合いすぎる報告書は信用しない]
辻褄を合わせるために改竄されている可能性を疑う。

[苦手なメンバーをチームに入れる]
メンバーを多様性を持たせてクロスチェックを有効に働くようにする。