エンジニアリング・プリフライトブリーフィング手法

概要

パイロットのプリフライトブリーフィングをエンジニアリングプロジェクトに応用し、見積もりやマイルストーン時の意識統一を図る手法

何をイメージしているのか

プロジェクト開発を進めるにあたり困る
①これって私がしてもいいの？これって◯◯さんしなくていいの？
②もっと全体を考えてと言われるがそんな時間もらったことない

についてほかの業種ではどうしているのだろうかと気になった。
パイロットの方はメンタルもかなり大事な仕事なのだから、いかに平静でいるために色々なことがすでに決定されていて想定ずみなのではないのか・・・と思い参考にさせてもらった

皆さんも一つ考えて欲しい
「それって決まってたらすぐ終わるのに」なんてことが気になってなんか仕事が手につかない時はないでしょうか？
なら、先にみんなの頭の中でプロジェクトを開発しましょう。
きっと、「あ！あのツールのアカウント足りない」なんてこともたくさん出てくる気がしています。

実施方針

「時間をかけてでも徹底的に行う」

• プロジェクトの複雑さ・重要度に応じた時間配分
• 手戻りコスト削減を優先し、事前検証に十分な時間を投資

実施手順

1. 事前準備

• V字モデルの各工程を基準とした進行計画
• ブロック化による分割（ドメイン単位・機能単位）
• 参加者のロール明確化

2. シミュレーション実行

各工程で以下を順次確認：

• PLが工程概要と目標を説明
• 各担当者が自分の作業内容を発言
• 不明な点は「分からない」として課題登録

3. 検証ポイント

① 明確性の確認

• 誰が何をするのか
• 何を持って工程完了とするのか
• 次工程への引き渡し条件

② 整合性の検証

• 行動間の矛盾はないか
• 矛盾がある場合の理由と対策

4. ブロック化戦略

• 機能ブロック例： 認証、データ処理、UI、API
• ドメインブロック例： 業務領域別の分割
• ブロック内シミュレーション → ブロック間連携確認

期待効果

• 工程間の依存関係の事前把握
• 潜在的問題の早期発見
• チーム全体の共通理解形成
• 技術制約・リソース制約の洗い出し
• 後工程での認識齟齬防止

重要な考え方

「漏れがあることは想定済み」

• 完璧を求めず、現状で分かる範囲での最善を尽くす
• 不明点は隠さずオープンにし、課題として管理
• 小規模プロジェクトでの実験から開始し、手法を改善

終わりに

今回の投稿では目的などの抽象的な部分にだけをまとめました。

次の投稿にて例を挙げながら進め方についてまとめました。
ぜひ、そちらも見ていただけたらと思います。