1週間デプロイと週次報告の親和性

エンジニアになってしばらくした頃、某プロジェクトで年配のエンジニアの仕事ぶりを見ていて「こりゃやばいな」と思ったことがある。トラブルが起きると1週間なんてあっという間に過ぎるのだが、もちろん、トラブルの当事者の年配のエンジニアのその期間に計画していた進捗なんてゼロだ。

当たり前のことなのだが、こうしたトラブったときに予定していた作業の遅延を気にしていないエンジニアが多い。

初めてプロマネになったとき、顧客とのミーティングは1週間に一度に設定した。要は週次で進捗ミーティングを会議体として設定したわけだ。

この会議体では、SIerと顧客のそれぞれの進捗の他、課題管理が主な議題だったので1時間程度(だったはず)で、あとは別の会議体を設け、ほぼそちらに使っていた。別の会議体とは、いわゆる局面ごとのテーマを検討する場で、ほにゃらら検討会的な名前をつけていた。

上流の設計工程では、要件から仕様決めやデータ項目設計の項目や導出条件などをセッション形式で片付けていく。この片付けていくという言葉そのものだったのは、WBSに成果物のドキュメントと章立てを決めておき、セッションのコマを割り当て、ほにゃらら検討会で合意していくとWBSが完了するような仕組みを取っていたためだ。

これのどこが1週間デプロイかというと、翌週の会議体に合わせて検討するための資料を用意しなければならない。そのサイクルが1週間なのである。さらに言えば、工程の納期(=完了時期)を設けていたので、局面内で合意が得られるようにカレンダを睨みながら、どのテーマが延べで時間が必要かの当たりをつけて組み替えなければならない。

そんな工夫をして毎週のセッションに資料をデプロイし、宿題が必要であれば種担当を決め、調査が必要であれば担当をアサイメントする。宿題も調査のどちらもSIerも顧客になることもある。

下工程になると局面と後に作成単位ごと、つまりWBSごとの進捗を確認することになるので単工程の進捗でしかないが、1週間ごとに成果を確認する。

ちょっと、今考えると、仕様決めまで進めたら、1週間単位で動くシステムを部分的にリリースすることができたのだろうあ。

機能のパラメータ設定、ワークフローの設定、アドオンの開発、ハウスキーピングなどの運用ツール、外部インタフェースの開発、プロビジョニングのカスタマイズなどがあったがなんとなくできそうな気がするし、当時それに近いところはあったような気がする。多分、アドオン開発や外部インタフェース周りだろう。

1週間デプロイと週次は一見全く無関係と思ったり、並べて関係があるなんて発想をしないと思うが、作業のリズムで考えるとエンジニアに影響を与える同質の部分が多いのである。

まあ、仕様に落とし込むところで1週間デプロイできるように準備をするのも、まるで週次ミーティングでセッション資料をまとめ、仕様決めするのと同じなのだ。そこのサイクルができれ上がれば1週間デプロイもレディなのだ。

あとはやってみればいい。やってない、できないは食わず嫌いなだけだ。