株式会社ラフティ | Time Craft Consulting
Chapter 4 設計・開発
人ではなく、 タスクでプロジェクトを回す
設計・開発フェーズは、
ITプロジェクトの中で 最も人間関係が壊れやすい工程です。
なぜなら、
-
期限が迫る
-
タスクが増える
-
想定外が発生する
このすべてが同時に起きるからです。
この章では、
人を管理しない設計・開発の進め方を解説します。
4-0. 設計・開発フェーズで起きる典型的な破綻
設計・開発が破綻するプロジェクトには、
ほぼ共通した兆候があります。
-
「あの人が忙しい」が理由になる
-
感情や不満が進捗会議に持ち込まれる
-
問題が個人の責任にすり替わる
-
判断が先送りされる
これらは、
技術の問題ではありません。
構造の問題です。
4-1. 設計と開発を分けてはいけない理由
設計と開発を完全に分けると、
次の問題が必ず起きます。
-
設計は「理想論」になる
-
開発は「現実対応」になる
-
両者の間に責任の空白が生まれる
設計とは、
開発で壊れることを前提に作るものです。
そのため、
-
設計者は開発を知る必要があり
-
開発者は設計の背景を知る必要がある
完全分業は、
設計・開発フェーズでは破綻します。
4-2. 人に寄り添わず、タスクに寄り添う
設計・開発フェーズで
最もやってはいけないことは、人に寄り添うことです。
ここで言う「寄り添う」とは、
-
忙しそうだから任せない
-
大変そうだから期限を緩める
-
感情を考慮して判断を変える
という行為です。
これは一見、チームに優しい判断に見えます。
しかし結果として、
-
不公平感が生まれ
-
属人化が進み
-
プロジェクト全体が止まります。
4-3. 役割と責任でチームを安定させる
安定した設計・開発では、
人ではなく 役割 が主語になります。
-
誰がやるかではなく
-
どの役割が判断するか
役割と責任を明確にすると、
-
判断は個人攻撃にならず
-
問題は構造として扱え
-
感情が排除されます。
-
これは冷たい管理ではありません。
人を守るための構造です。
4-4. 進捗管理は感情を排除する
進捗管理で見るべきものは、
次の2つだけです。
-
タスクが終わっているか
-
期限に間に合うか
それ以外は、基本的に不要です。
-
忙しさ
-
苦労
-
努力
これらは、評価や労務の話であり、進捗管理の話ではありません。
進捗会議が感情の共有の場になると、
プロジェクトは必ず停滞します。
4-5. 「できない」を早く出せる設計
良い設計・開発では、
「できない」が早く出てきます。
-
技術的に難しい
-
期限的に無理
-
前提が崩れている
これを言えない環境は、必ず後で爆発します。
「できない」と言えないのは、個人の問題ではありません。
構造の問題です。
4-5-1. タスクが難しいのではなく、情報が足りないだけ
設計・開発フェーズで
「このタスクは難しい」と言われる場合、
その原因の多くは 技術力不足ではありません。
ほとんどの場合、
-
前提情報が足りない
-
判断基準が共有されていない
-
どこまでやれば良いか分からない
といった、
情報不足が「難しさ」に変換されているだけです。
この場合、やるべきことはシンプルです。
-
チームに聞く
-
タスク管理・コミュニケーションツールで名指しで聞く
-
判断者に即エスカレーションする
人に我慢させる必要はありません。
タスクは、情報が揃えば前に進むものです。
4-6. 設計・開発フェーズのまとめ
設計・開発フェーズで最も大切なことは、
-
人を信じることでも
-
頑張らせることでもありません。
構造を信じることです。
-
タスクで進める
-
役割で判断する
-
感情を排除する
これができたプロジェクトは、驚くほど静かに進みます。
設計・開発フェーズが静かに進んでいるプロジェクトは、
-
誰かが我慢しているのではなく
-
誰かが頑張りすぎているのでもありません。
正しい構造が機能しているだけです。