黒柴的パンセ　#10

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

やり方は、トラブルを抽象化したモデルを作成し、そのモデルに従って課題を洗い出すことにした
※ここで、抽象化、モデル化ということが出てくる

モデル化の手順は、以下のように考えた

今回のトラブルの事象というのは、「オーバー工数」である
オーバー工数というのは、
計画された工数　＜　実際にかかった工数
という状態のことである
では、「計画された工数」とは何か？
計画された工数は、
製造予定の規模　／　予想している生産性　＝　計画された工数
となる
つまり、計画された工数が実施した結果として大きくなったということは、

• 製造規模が、計画した時点より大きくなった

• 生産性が、予想している値よりも低くかった

• そして、その両方

ということになる
この抽象化された要因を元に、そのような事象が発生していないか、また発生した場合にどのような対応をおこなったか、ということをヒアリングした
また、ヒアリングで抽出された新たな課題は、課題として記録することとして、それ以上は分析しないこととした

ヒアリングの結果、規模の増加については、

• 開発着手後に追加になった開発項目は複数あった

• いくつかの項目は、明確な仕様追加としてSIerに費用を請求している

• ただ、要員が追加できるほどの規模がなかったので、既存メンバーでの対応とした

• しかし、スケジュールへの反映を怠っていたため、マスタスケジュールからの遅れにつながった

• いくつかの項目は、見積もりの母体とした基本設計からは漏れていた

• 理由は、設計工程での見落としと考えられたが、設計工程時に派遣契約で参画していたことがあったため、自分たちの作業ミスと考えて、強く仕様追加と言えなかった

ということが分かった

生産性の低下については、

• 全体的には、当初予定から大きく落ちているとは考えられない

• ただ、当然だが作業者間での生産性・品質のばらつきは発生した

• また、そのばらつきを是正するような事前の取り組みはできていなかった

• SIer側でライセンスを持っている独自フレームワークを使うため、SIer提供のアーキテクチャ資料のみで十分と考え、システムアーキテクチャとしての標準資料は作成していなかった

ということが分かった

だいぶ、問題がはっきりしたところで、後はこの問題にメンバーがどのように関係し、どのようにアクションしたかを整理するだけとなったが、休日出勤の時間切れとなったため、それは後日とした
ただ、黒柴自身としては最初に実施した何も用意しないままのヒアリングとは異なり、モデルを用意したことにより、実のある調査ができたと思った

以下は余談となる
この調査会は、人事考課のためのネタ集めとして実施しており、このトラブルプロジェクトに対する個々のメンバーのアクションを加点・減点で整理することが目的だった

上記調査会の結果を、中間報告として人事担当の役員に報告した
この人事担当役員の反応は、「問題の個別分析が全くできておらず、こんなの調査でも何でもない。お前らには任せておけないから、自分が調査する」として、この中間報告を無視して、自分でヒアリングを開始した
そして、黒柴たちが最初にやったように、問題を抽出するごとに分析するというアクションを繰り返して、分析の沼に嵌まっていった

最終的に、「お前らの人事考課の結果ってどうなった？」と、件のプロジェクトリーダーに尋ねたら、「結局、考課のための分析が終わらず、今期は考課なしとして、社内ランクは前年のまま」となったとのことだった
やはり、思考方法をきちんと身に着けていないとダメなんだな、と思った次第である