数学の不得意なエンジニアが数字に抵抗感を持たなくなるまで

エンジニアをやっていれば計算する処理なんていくらでもあるし、普段のexcelを使う方が簡単な計算式を思っている以上に使っている。

仕事のロールがエンジニアからプロジェクトマネージャ、マネージャに変わると更に計算することが多く頻度は格段に増える。

小学校の頃はなんとか理解できていた算数も中学に上がって数学になった途端、躓いた。さっぱりわからない。2年くらいの年次で部活の先生が数学の担当で、あるタイミングでわかっていないことがバレた。そのとき、公式の使い方レベルで教えてくれて、ああ、そうやって使えばいいのかとやっと理解できたことがあった。多分、そこでもう少し聞くことができればもうちょっと数学にコンプレックスを持つことはなかったのかもしれない。

担当エンジニアの頃は色々あったけれど、プロジェクトマネージャをするのならコスト計算をしなければならない。プロジェクトのお財布を管理するのはプロジェクトの成功の要因の一つにコストがあるからだ。

学生の時代になんの因果か簿記を取っていたのでP/LやB/Sは（そのときは）作れていたし、（単位を取った程度で）理解もできていた。

割とそうした取り敢えずこれはできたと言う体験があるとプロマネとしてコスト管理に必要な数字の計算に対する心理的なハードルは押し下げる方向に向かう。なんでもそうなんだけれど、成功体験は支えになる。

プロジェクトのコスト計算を毎月するとして、そうした計算した結果がプロマネとマネージャで見方が違うこともまたやってみるとわかると言うか、やってみないと気づかない。

プロマネがプロジェクトの月次の収支を計算するのはプロジェクトの収益の観点での健全性を確認するためが1つ、プロジェクトが終了した時点での収支の見通しを確かめるのが2つ目の目的になる。

それは当然で、プロマネはプロジェクトのaccountablityがあるからだ。これがマネージャになるとプロマネが計算した数字を違う見方をする。

プロジェクトのコストのほとんどは、エンジニアの人件費だ。HWをサービスとして使ったり、SWもOSSや自作をすればその他費用が下がるから更に人件費の割合は高まる。

その人件費を人件費としてまるっと見がちなのはプロマネである。まあ、進捗やら成果物の観点はそれぞれの管理エリアで直接みているからそれで良いのだ。

では、マネージャはどこを見るか。それは人件費をバラして人単位での時間を見る。それで何を見るかと言うと、労務時間である。

ところで、プロジェクトのコストはやった時間全て計上しなければいけない。間違っても他のプロジェクトに計上したり、ねぐったり忖度して過少申告してはいけない。これはコンプラよりもプロジェクトコストの実績をあるがままに記録しなければ次の見積もりで使えなくなってしまうからだ。

やった分は必ず計上する。それをみて、労務時間に異常値があるかどうかをみて、プロジェクトのメンバごとの負荷状況を推測したり、プロマネのアサイメントを見たり、メンバの健康状態の観点で見たりする。

マネージャともなるとべったりとプロジェクトに入ることはできないから、そうした客観的な数字でプロジェクトの状況（月次であればひと月遅れになるが）とリスクを識別する。

数字もこういった使い方なら割と親しみが持てる。目的があって、その道具になっているからかもしれない。

大人のための数学勉強法 ― どんな問題も解ける10のアプローチ