プロジェクトの現場では、日々さまざまな問題が起きる。
仕様が決まらない。
設計が進まない。
障害が発生する。
関係者の認識が合わない。
顧客判断が遅れる。
課題が増え続ける。
こうした状況で重要なのは、個別のテクニックだけではない。
もちろん、課題管理表を作る、会議体を整える、共同編集する、完了条件を決める、といった現場テクニックは重要である。
しかし、それ以前に必要なのは、物事をどう捉えるかという「思考法」だと思う。
私が現場で特に意識している思考法は、以下の7つである。
- 目的ベース思考
- 問題分解思考
- 抽象化・具体化思考
- 全体像思考
- 正論・現実解思考
- 仮説構築思考
- シンプル思考
どれも一見すると当たり前のことに見える。
しかし、現場ではこの当たり前が簡単に崩れる。
忙しいと目的を忘れる。
細部に入ると全体像を失う。
問題が大きすぎると打ち手が見えない。
正論だけでは動かず、現実だけでは単なる妥協になる。
分からないことを分からないまま置き続けると、プロジェクトは前に進まない。
複雑な資料やルールは、いつの間にか現場の生産性を下げる。
だからこそ、思考法として言語化しておく意味がある。
1. 目的ベース思考
目的ベース思考とは、何をやるかではなく、何のためにやるかから考えることである。
現場では、手段が目的化しやすい。
「会議をやります」
「設計書を作ります」
「レビューします」
「課題管理表を更新します」
これらはすべて手段であり、目的ではない。
本来考えるべきなのは、次のような問いである。
「この会議は何を決めるためのものか」
「この設計書は誰が何に使うのか」
「このレビューでは何を確認すべきなのか」
「この報告によって、相手に何を判断してほしいのか」
たとえば、設計書を作る場合でも、目的によって書くべき内容は変わる。
開発者が実装するための設計書なのか。
テスターがテストケースを作るための設計書なのか。
顧客と仕様合意するための設計書なのか。
運用担当者が保守するための設計書なのか。
目的が曖昧なまま作業を始めると、成果物は作ったものの、誰の役にも立たないということが起きる。
また、目的ベース思考では、whyをしっかり把握しておくことが重要である。
現場では、「お客様から言われたので、この仕様にしています」という説明を聞くことがある。
しかし、それだけでは不十分である。
大事なのは、なぜお客様がその仕様を求めているのかである。
なぜその項目が必要なのか。
なぜそのタイミングで処理する必要があるのか。
なぜその運用にしたいのか。
なぜその制約があるのか。
このwhyを把握していないと、目的が分からない。
目的が分からなければ、目的ベース思考はできない。
逆に、whyを把握していれば、ある仕様の実現が難しくなった場合でも、別の手段を検討できる。
たとえば、顧客がある仕様を求めていたとしても、その目的が「作業ミスを減らすこと」なのか、「処理時間を短縮すること」なのか、「監査証跡を残すこと」なのかによって、代替案は変わる。
もし目的が作業ミスの削減であれば、必ずしも当初の仕様そのものでなくても、入力チェック、確認画面、アラート、運用手順の見直しなどで目的を達成できるかもしれない。
もし目的が監査証跡を残すことであれば、画面表示よりもログ出力や履歴管理の方が本質的な対応になるかもしれない。
このように、whyを理解していれば、仕様そのものに固執せず、目的を達成するための別案を考えられる。
もちろん、すべての仕様について深くwhyを確認する時間があるわけではない。
時間やコストとの兼ね合いはある。
しかし、重要な仕様、後工程に大きく影響する仕様、実現難易度が高い仕様、顧客業務上の意味が大きい仕様については、whyを把握する姿勢が必要である。
目的ベース思考とは、単に「何のためか」と口で言うことではない。
仕様や作業の背景にあるwhyを理解し、目的に照らして最適な手段を選ぶ思考である。
また、目的は最初に一度決めたら終わりではない。
プロジェクトの状況が変われば、目的自体も見直す必要がある。
たとえば、DBが停止した場合、最初は「障害原因を特定し、再発防止すること」が目的になる。
しかし、調査の結果、それが製品の瑕疵ではなく、基盤の正常挙動によるものであると分かった場合、目的は変わる。
その場合は、「障害原因の追及」ではなく、「正常挙動ではあるが、同様事象が業務影響につながらないよう、容量監視を強化し、予兆検知できる仕組みを作ること」が目的になる。
このように、目的ベース思考では、単に最初の目的を確認するだけでなく、状況変化に応じて目的そのものを見直す。
目的ベース思考とは、常に「それは何のためか」に戻る思考である。
2. 問題分解思考
問題分解思考とは、大きな問題を扱える単位に分けることである。
現場では、問題が大きな言葉で語られがちである。
「品質が悪い」
「進捗が遅れている」
「仕様が決まらない」
「顧客の要求が曖昧」
「設計が弱い」
しかし、このままでは打ち手が見えない。
たとえば「品質が悪い」と言っても、その中身はいろいろある。
誤字脱字が多いのか。
仕様不整合が多いのか。
異常系の考慮が不足しているのか。
レビュー観点が曖昧なのか。
作成者が業務を理解していないのか。
顧客確認が不足しているのか。
分解すれば、対策も変わる。
誤字脱字ならチェック方法を変える。
仕様不整合なら整合表を作る。
異常系不足なら異常系パターンを洗い出す。
業務理解不足なら業務フローから説明する。
顧客確認不足なら確認会を設定する。
大きな問題を大きなまま扱うと、精神論になりやすい。
「もっと頑張りましょう」
「品質を上げましょう」
「早く決めましょう」
これでは現場は動かない。
問題分解思考とは、大きな問題を小さく分け、実際に手を打てる単位に変換する思考である。
ただし、分解すればするほどよいわけではない。
分解しすぎると、課題管理が複雑になり、管理のための管理が増える。
分解の基準は、担当・期限・判断・打ち手が変わるかどうかである。
それらが変わらないのであれば、無理に細かく分ける必要はない。
3. 抽象化・具体化思考
抽象化・具体化思考とは、具体的な事象から本質を掴み、その後で再び具体に戻って確認する思考である。
現場では、細かい情報が大量に入ってくる。
「この画面でエラーが出ました」
「このバッチが失敗しました」
「このIFでステータスが合いません」
「このログにエラーが出ています」
こうした具体情報をそのまま追いかけ続けると、細部に埋もれる。
そこで一度、抽象化する。
「要するに何が問題なのか」
「これは個別機能の問題なのか」
「共通部品の問題なのか」
「設計思想の問題なのか」
「運用ルールの問題なのか」
「ステータス管理全体の問題なのか」
たとえば、複数の機能でステータス不整合が起きている場合、それは個別機能のバグではなく、ステータス管理設計そのものが曖昧である可能性がある。
ただし、抽象化だけで終わってはいけない。
「ステータス管理が弱いですね」
「設計思想の問題ですね」
これだけでは空中戦になる。
再び具体に戻る必要がある。
「どのステータスが不整合なのか」
「どのタイミングで更新されるのか」
「どのAPIが返しているのか」
「異常時にどの状態に戻すのか」
「どのテストケースで再現するのか」
つまり、具体から抽象へ上がり、抽象で本質を掴み、また具体に戻って確認する。
具体だけでは泥沼になる。
抽象だけでは空中戦になる。
現場では、この往復が重要である。
4. 全体像思考
全体像思考とは、いきなり詳細に入らず、まず全体構造を掴んでから詳細を見る思考である。
システム開発でも、障害対応でも、プロジェクト管理でも、詳細だけを見ていると判断を誤ることがある。
たとえば、あるAPIの項目定義を見る前に、本来は次のことを確認すべきである。
そのAPIは業務全体のどこで使われるのか。
どのシステムから呼ばれるのか。
どのシステムへ結果を返すのか。
今回のScopeはどこまでか。
Scope外だが依存しているものは何か。
変更するとどこに影響するのか。
誰が責任を持つ領域なのか。
工場システムで言えば、まず工場全体の業務がある。
その中で、今回システムを入れる部分がある。
さらに、そのシステムは上位システム、搬送装置、運用担当、テスト環境などと依存関係を持つ。
この全体像を見ずに、いきなり個別仕様だけを見ると、局所的には正しくても、全体としてはズレた判断をする可能性がある。
全体像思考で見るべきものは、単なる概要ではない。
業務全体。
システム全体。
プロジェクト全体。
Scope。
Scope外。
境界線。
依存関係。
影響範囲。
制約条件。
責任分界。
これらを含めて全体像である。
詳細は重要である。
しかし、詳細は全体の中で意味を持つ。
だからこそ、まず全体像を掴み、その後で詳細に入ることが重要である。
5. 正論・現実解思考
正論・現実解思考とは、まずあるべき姿を置き、そのうえで現実制約を踏まえて最適な着地点を出す思考である。
現場では、いきなり現実から入ってしまうことが多い。
「時間がないから仕方ない」
「人が足りないから無理」
「顧客が決めてくれないから進まない」
「前からこうだから変えられない」
もちろん、現実制約は重要である。
しかし、最初から現実だけを見ると、単なる妥協になる。
一方で、正論だけでも現場は動かない。
「本来は全部決めるべきです」
「設計工程で完全に固めるべきです」
「異常系もすべて定義すべきです」
これは正しいかもしれないが、現場では時間、体制、顧客判断、契約、予算などの制約がある。
だから順番が重要である。
まず正論を置く。
次に現実制約を見る。
最後に現実解を出す。
たとえば、異常系仕様が未確定の場合で考える。
正論としては、異常系仕様は設計工程で確定しておくべきである。
しかし現実には、顧客側の運用が未確定で、すべての異常パターンを今すぐ決めることが難しい場合がある。
その場合の現実解は、すべてを諦めることではない。
量産運用に致命的なパターンを先に決める。
搬送停止、在庫不整合、二重指示など、影響が大きいものを優先する。
残りは暫定仕様として課題管理する。
確定期限を置く。
後続工程への影響を明示する。
このように、正論を軸として持ちながら、現実に合わせて着地点を作る。
正論だけでは机上の空論になる。
現実だけでは妥協になる。
正論と現実解を分けて考えることが重要である。
6. 仮説構築思考
仮説構築思考とは、分からないことをそのまま放置せず、現時点の情報から「こうなっているはずだ」という仮定を置き、それを相手にぶつけることで、仮定を事実・差分・未決事項に変換していく思考である。
一般的に仮説思考というと、「仮説を立てて検証する」という説明になりがちである。
しかし、システム開発の現場では、もっと具体的に使える。
特に業務ヒアリングや要件定義では、最初から業務の全体を完全に理解できることは少ない。
顧客もすべてを言語化できているわけではないし、現場によって運用が違うこともある。
資料に書かれていない例外運用や、暗黙知になっている判断も多い。
このとき、分からない部分を単に、
「ここは不明です」
「確認が必要です」
として管理するだけでも悪くはない。
しかし、それだけだと会話が進みにくい。
もう一歩踏み込むなら、
「おそらくこう運用しているはずだ」
「この場合は、こう判断しているはずだ」
「このデータは、このタイミングで更新されているはずだ」
という仮定を置く。
そして、その仮定を顧客や業務担当者にぶつける。
「こちらでは、この業務はこのように流れていると想定しています。合っていますか？」
こう聞くと、相手は答えやすくなる。
たとえば、搬送業務のヒアリングで、次のことが分かったとする。
上位システムから搬送指示が出る。
搬送システムが搬送装置に指示する。
搬送装置が対象物を搬送する。
完了したら上位システムに結果を返す。
しかし、不明点も残る。
失敗時に誰が判断するのか。
在庫ステータスはいつ変わるのか。
手動復旧した場合、システム状態をどう戻すのか。
ここで、単に「分かりません」とするのではなく、仮定を置く。
「搬送失敗時は、搬送装置からエラー通知を受け、搬送システム側でエラー状態にし、業務担当者が現物確認後に再実行またはキャンセルを判断すると想定する」
これを顧客にぶつける。
「この想定で合っていますか？」
顧客が、
「通常は合っています。ただし、特定の搬送物の場合は、現場責任者の承認が必要です」
と答えたとする。
この瞬間、隠れていた業務ルールが見える。
仮説を置かなければ、この例外は出てこなかったかもしれない。
仮説構築思考の流れは以下である。
仮定を置く。
相手にぶつける。
Yesなら事実に昇格する。
Noなら差分を確認する。
未決なら課題化する。
「何でも分かりません」と聞くのと、「こう想定していますが合っていますか」と聞くのでは、話の進み方が大きく異なる。
前者は相手にゼロから説明を求める。
後者は相手に差分確認を求める。
差分確認の方が、相手は答えやすい。
また、認識齟齬も早く見つかる。
ただし、注意点もある。
仮説を事実として扱ってはいけない。
仮説はあくまで仮説として管理する必要がある。
設計書に書く場合も、「現時点の想定」「要確認」「顧客確認待ち」などの状態を明確にする。
また、誘導尋問にも注意が必要である。
こちらの仮説を強く出しすぎると、相手が深く考えずにYesと言ってしまうことがある。
そのため、
「この理解で合っていますか」
「例外はありますか」
「実際の運用と違う部分はありますか」
と確認することが重要である。
仮説構築思考は、業務理解を高速化する。
不透明な部分を不透明なまま置かず、仮定を置いて相手にぶつけることで、業務の解像度を上げていく。
これは、要件定義、業務ヒアリング、設計レビュー、障害調査で特に有効な思考法である。
7. シンプル思考
シンプル思考とは、不要な複雑さを疑い、本質に集中する思考である。
複雑な設計。
複雑な資料。
複雑な会議体。
複雑な承認フロー。
複雑な課題管理表。
現場には、さまざまな複雑さがある。
もちろん、必要な複雑さはある。
業務やシステムが複雑である以上、それを正しく表現するために、ある程度複雑になることは避けられない。
しかし、必要性のない複雑さは、現場の生産性を下げる。
複雑な資料は読まれない。
複雑なルールは守られない。
複雑な会議体は形骸化する。
複雑な課題管理表は更新されなくなる。
複雑な設計は保守できなくなる。
シンプルであることには多くのメリットがある。
理解しやすい。
説明しやすい。
間違いにくい。
レビューしやすい。
引き継ぎやすい。
保守しやすい。
判断が速くなる。
現場では、常にこう問うべきである。
「これはもっと単純にできないか」
「この資料は本当に必要か」
「この会議体は本当に必要か」
「このルールは現場が守れるか」
「この表は複雑すぎないか」
「この管理項目は本当に使うのか」
シンプル思考は、目的ベース思考ともつながっている。
目的が明確であれば、不要なものを削れる。
逆に、目的が曖昧だと、念のための資料、念のための会議、念のための管理項目が増えていく。
ただし、シンプルにすることは、雑にすることではない。
必要な情報まで削ってはいけない。
必要な複雑さと不要な複雑さを分けることが重要である。
シンプル思考とは、単に短くすることではない。
本質に集中することである。
まとめ
現場で使える思考法として、私は以下の7つを意識している。
- 目的ベース思考
- 問題分解思考
- 抽象化・具体化思考
- 全体像思考
- 正論・現実解思考
- 仮説構築思考
- シンプル思考
これらは、どれも新しい理論ではない。
むしろ、当たり前のことに近い。
しかし、現場ではその当たり前が簡単に崩れる。
目的を忘れて作業に追われる。
全体像を見ずに詳細だけを見る。
大きな問題を大きなまま扱う。
抽象論だけで終わる。
逆に具体論だけに埋もれる。
正論を言うだけで現場が動かない。
現実に寄せすぎて、単なる妥協になる。
分からないことを不明点のまま放置する。
複雑な資料や管理表を作り、現場の負担を増やす。
だからこそ、思考法として言語化しておく意味がある。
特にシステム開発やプロジェクト推進では、曖昧な状況を整理し、関係者の認識を合わせ、実行可能な形に落とす力が求められる。
そのためには、テクニックだけでは足りない。
物事をどう見るか、どう分けるか、どう確認するか、どう現実に落とすかという思考法が必要である。
この7つは、現場で迷ったときに自分の思考を整えるための基本姿勢である。
コメント