パターンのアイデア - 室長のひとりごち

積ん読になったままになっていたFearless Changeを少し前に読んだあと、ネットを検索してなんとなくわかった気になったがやっぱり腹落ちしていなくて、どう書けばいいのかと彷徨っているところで思考の軌跡を知り、読みたい章だけ拾い読みする。

消化不良のままパターンの外周を徘徊していたが、なんとなく形にできそうと思い書いてみたがそれがパターンっぽく書けているかどうかはわからない。

その昔、全く業務と関係ないのにJavaのデザインパターンの本（記憶にないけどこれかな…Javaとピザとデザインパターン）を読んだ気がする。内容は記憶に残っていないのでわかっていなかったのだろう。

パターンの使い方を以前書き物か誰かから聞いたのは、コードを『このパターンで書いている』とか『この処理はこっちのパターンで書こう』的な文脈で使う、というような記憶がある。これを勝手にインタフェースとして使うのだな、と解釈したまま放置した。

職種がプロマネやマネージャに変わってくると扱うのはリスクになる。いかにリスクを識別するかに全力を注ぐ。小さな変化を見逃すとあとあと何十倍にも利子がつく。利子がついて嬉しいのは預金か貯金の利子だけだ。あとは迷惑でしかないし、利子がつくような借り物はしたくない。

このリスクを識別するのがからっきしダメなメンバやプロマネがときどき目の前に現れる。

組織にプロジェクトマネジメントを導入し始めたり、プロジェクト計画書のテンプレートを用意したり、プロジェクト型のビジネスをしているSIerなどではQMS自体をプロジェクト計画書と整合性を取るようになる。業務自体にプロジェクトマネジメントが急速に導入されるが、それはプロジェクトマネジメントを導入した一部の関係者かQMSをプロジェクト計画と整合性をとったPMO的な役割を担った担当者だけが理解している。

のちにプロジェクトマネージャになる中堅や若手エンジニアはそうした経緯を知らず、いきなりそうしたテンプレートを使わなければならない環境に置かれる。

そういった若手のプロマネ層でもプロマネそのものの前提知識を旺盛に吸収しようとするエンジニアは一部（1割くらい）でしかなく、多く（6-7割くらい）は必要に迫ったとき、つまりプロジェクト計画書を書かなければならないときに初見でガイドなり過去のプロジェクト計画書を書き写す。残りは自己流に書くか借金取りのように迫られるまで放置する。

物事は計画が8割だ、9割だと言われているにも関わらず、ほとんどのプロジェクトマネージャはプロジェクトマネジメントの基礎的な教養を学ばない。結果、リスクをリスクと識別できず、当たり前にやっておけば回避できたリスクをみすみす抱え込む。

組織によっては過去のプロジェクト計画書（更新完了版）を保存しているケースもあるようだが、何分にもwordなどの文書ファイルのままファイルサーバの奥底に保存されているのでひのめを見ない。読み解くことが可能であればリスクに対する知見（多くはトラブル事例）を得られるはずだが、たどり着くことができないこととそれに割くリソースを割り当てないから知見は空のままである。

本来、そうした状況下であっても事例を収集するのは過去の同じ過ちを犯さないための再発防止策であったはずだがそれも生かされることはない。

そこでプロジェクトのリスクをパターン表記したらどうかと思案する。プロジェクトのリポジトリを学習させ、パターンに一致するものをインフォメーションとしてステークホルダ全てにサジェストする。

パターンを実用的に使うのはこうしたところで活かせるような気がしないでもない。