黒柴的パンセ　#9

とりあえず「３つの思考法」を身につけよう　その3

パンセ#7で取り上げた3つの思考法のうち、その3では「抽象化思考力」を掘り下げていきたいと思う

1. 「結論から考える」仮説思考力

2. 「全体から考える」フレームワーク思考力

3. 「単純に考える」抽象化思考力

実は、この「抽象化思考力」は、「地頭力を鍛える」を読んだ当初は、ほとんど理解できなかった
そのため、「仮定的思考法（仮説思考力）」、「俯瞰的思考法（フレームワーク思考力）」は、仕事上の課題を整理する上でも活用できていたが、「抽象化思考力」についてはまったく活用できていなかった

本書では、「抽象化する」ということについて、「単純化する」、「モデル化する」としており、より「単純にする」ことにより、そのものの本質をとらえることができるとしている
しかし、具体的な例が載っておらず、それこそ「抽象的な」説明がされていたので、今一つ頭の中には入ってこなかった

そんな状態の中で、「これって、もしかしたら抽象化ってことかな？」と、後で思い返してみると、モデル化することにより、事象の分析をうまく行うことができた事例があった
以下は、黒柴がトラブルプロジェクトの内容調査を行った際に、問題を「単純化」することで、問題の分析がうまく行えた事例となる
これが、正しいのか否かは、著者の細谷先生に確認してもらう必要があるが、これを行ったことにより、黒柴の中では「単純化」ということを腹落ちさせたので、参考として記述する

そのトラブルプロジェクトは、開始当初から自社のメンバー数名がSIerに常駐して要件定義・基本設計のサポート（主幹はSIerでその指示のもとでの作業）を行っていた
この作業は、派遣契約で実施していた
その後、基本設計工程が完了し、そのアウトプットを元に見積もりを行って、詳細設計以降から結合テストまでを自社の一括請負として契約した
請負開発に伴い、開発メンバーについても、自社が調達したビジネスパートナーを追加して体制を整えたが、作業場所についてはコンプライアンスの関係からSIerが情報の持ち出しを嫌がったため、引き続きSIerの社屋内となった

SIer社内での作業となり、SIerの入門証を持っていない自社社員が頻繁に立ち入ることができなかったため、自社側でのプロジェクトの状況確認が遅れてしまった
気が付いたときにはかなりの遅れが発生しており、その対策としてメンバーを追加したことにより、プロジェクトはオーバー工数となった

このトラブルの原因や、そのとき現場で何が行われていたかを調査することになった
しかし、プロジェクトリーダーやメンバーを招集して、ヒアリングを行っても、全く要因が整理できない
ヒアリングから課題が一つ検出されて、その課題を分析すると別の課題が見えてきて、それをまた分析すると・・・の繰り返しで、最初の調査では課題が発散する方向でしか分析できなかった

そのため、個別のヒアリングや、その場での課題の分析を一旦中止し、改めて関係者を集めて休日出勤し、雑音の入らない中で全体での調査会を実施することとした
当然のことだが、同じ手法（課題を見つけて分析する）では、調査が発散することが目に見えていたので、少しやり方を変えてみることとにした
（この件は長くなるので、次回へ続く）