フレームワーク説明会が「手戻り騒ぎ」に!? ――プロジェクト進捗とタイミングのリアル

フレームワーク理解はなぜ難しいのか

うわっ、説明しただけなのに会議室がざわついた！

その日、私は少し不思議な立場で会議に参加していた。
Javaでシステム開発を進めるためのフレームワークを作ってきたチームとして、その適用支援という名目でプロジェクトをサポートしていたのだ。

今回のプロジェクトは、私の同期がリードしている大型案件。
各ベンダーのリーダーが集まり、プロジェクトの設計はすでにかなり進んでいた。

会議室には、ベンダー各社の責任者が並んでいる。
その中心でプロジェクトをまとめているのは、同期のプロジェクトリーダーだ。

同期が率いるプロジェクト

同期はしっかりとリードしていた。
ベンダーの意見を聞きながら、議論を前に進めている。

そして、会議の途中で私の出番が来た。
フレームワークの説明だ。

Javaシステム開発では、フレームワークの理解が非常に重要になる。
設計方針、モジュール構造、実装ルール。
それらを共有することで、開発の品質やスピードが大きく変わる。

私は資料を開きながら説明を始めた。

しかし。

進んでしまった設計

説明が進むにつれて、会議室の空気が少しずつ変わっていった。

「それだと、今の設計は変わるのでは？」

誰かがそう言った。

すると別のベンダーが言う。
「ということは、手戻りですか？」

会議室がざわついた。

そう。
設計がすでに進んでいる中でのフレームワーク説明だったのだ。

プロジェクトには、
“適切なタイミング”
というものがある。

フレームワークの説明は、本来もっと早いタイミングで行われるべきだった。

タイミングを逸した説明会。
当然、手戻りの議論が始まる。

プロジェクトリーダーの色

こういう時、プロジェクトリーダーの色が出る。

あるリーダーはこう言う。
「あるべき設計に合わせるべきです」

理路整然と正論で押していくタイプだ。

別のリーダーは言う。
「影響範囲を整理して別チームで吸収できませんか」

サポート体制を考えるタイプ。

さらに別の人は言う。
「進捗に影響しない作業を先に進めましょう」

並行作業を考えるタイプだ。

それぞれの色がある。

一方、同期のリーダーは少し困っていた。
強く押すタイプではない。

さて、この会議はどうなるのだろう。

私は少し様子を見ていた。

優しいベンダーたち

すると、面白いことが起きた。

各ベンダーのリーダーが、
それぞれ解決策を出し始めたのだ。

「この部分なら後ろで吸収できます」
「ここは設計変更なしで対応できます」
「ここは開発後半で修正できます」

それぞれが、自分の領域の責任を守りながら提案をしてくれる。

みんな、優しい。

そして気づいた。

同期のリーダーのやり方は、
「みんなで解決策を考える」
というスタイルだったのだ。

押し切るリーダーもいる。
論理で進めるリーダーもいる。
サポート体制を作るリーダーもいる。

私はどちらかというと、
並行作業や進捗調整を考えるタイプだ。

成功の形は一つじゃない

プロジェクトリーダーの成功の形は一つではない。

強く押すリーダー。
論理で整理するリーダー。
チームに考えさせるリーダー。

それぞれの色がある。

大事なのは、
プロジェクトがうまく進むこと。

そのために、
チーム全員で頭を使うことだ。

あの会議のあと、私は思った。

プロジェクトとは、
技術だけで動くものではない。

人が動き、
考え、
助け合うことで進んでいく。

だからこそ面白い。

私ならできる！明日から踏み出す