睡眠

今月に入ってからは、ほぼ毎日18～19時に退社し、
22時にはハニーと一緒に寝て、
朝5時30分くらいに起きる毎日だな。

健康的だお。(´・ω・`)

新年度

遂に2015年度が開始されてしもうたか。(´・ω・`)

しかし最近、何だか体の調子が……。
ちゃんと寝ているはずなのに体が重い。

デスマ終了間もないから調子が戻ってないのかな。(´・ω・`)

平穏

ふう。(´・ω・`)

少々の残タスクはあるが、デスマプロジェクトは無事に納品を迎えたようだ。

まあ、デスマの代わりにかなり利益は出たようだ。
4～5人でやるべき作業を2～3人で3ヶ月も貫徹した結果、4人月分くらいが丸っと浮いたのだな。

2～3人のうち、1人は0.2しかパワーが無いヘタレだったにも関わらず貫徹したのは大したものだろう。

頑張った甲斐があって良かったぜ。

最近は僕もただ作るだけのプログラマーから脱却してプロジェクトの利益も考慮出来るようにならねばならんと思っていたところだから、良い実績を作ることが出来たな。

しかし、この少人数にムチ打ってプロジェクトを押し進める戦術は、黒字プロジェクトの為の一つの成功事例になり得ると思うが、代わりにかなりキツかったな。

こんなやり方を連発していたら脱落者が出かねん。

それに、プロジェクト本体は成功でも、代わりに社内改善活動や情報処理試験の勉強が完全壊滅した。
目立たない所で犠牲が出ているのも事実。

人材の消耗品戦術と言っても過言ではなかろう。

このやり方はここぞという時の必殺技として温存し、普段は使わないようにしなければ。(；´・ω・`)

進捗管理の現実

今回のプロジェクトは僕が進捗管理を行ったが、理論と現実の狭間で大変悩んだな。

まず、進捗管理というのは「開始日」「終了日」を目標として掲げて、それを目指してプロジェクトを進めていくことが趣旨と言えよう。

この時、開始日から終了日までの期間。つまり、その作業にどれだけの日数を要するのかを正確に見積もることが進捗管理担当者の腕の見せ所である。

やり方はこうだ。

まず、作業工数は案件を受注した際の金額の見積もりをベースにする。

例えば、案件受注の段階で3人日として見積もってお金を貰って、それを一人で進行する場合、
その作業の予定期間は3日である。

これを基本とするが、しかし、作業の効率というのは個人差があるから、出来る人には2日でやって貰い、出来ない人には5日を割り当てる。
こうやって現実を鑑みて配分を調整しながらプロジェクトを進めていくのが進捗管理だ。

しかし、ここで問題が発生する。
作業者の効率が想定を遙かに下回る場合だ。

今回の場合、協力会社さんの作業効率は0.2。通常の5倍の時間を要する。
となると、本来3日で終わる仕事に15日、つまり3週間をを割り当てなければならない。

こんなのが許されるのか？ということだ。

現実重視で線を引くと、以下のようになる。



上司「何でこの作業に15日も掛かるの？3日で十分でしょ？」
(´･ω･`)「い、いえ、それが、あの人だとこれくらい必要で……」



理論を重視して3日で線を引くと、当然スケジュールは守れないから以下のようになる。



上司「この作業、いつまで遅延してるの？　3日で終わるはずだったんでしょ？」
(´･ω･`)「い、いえ、それが、予定より苦戦しているようでして。15日くらいは必要かも……」


こんなの、どっちもありえんだろ！！
明らかにカドが立っちまうからな！！

真実を明らかにすると間違いなくカドが立っちまってプロジェクトの雰囲気が悪くなる。
だから僕は今回、そこを誤魔化し戦術で曖昧にしてやりくりした。

僕の頭の中では期限は明確だが、外から見た時には現実が見えないようにドキュメントを書いた。
まあ、明らかに作業効率悪いのはバレバレなんだけど、それでも明確な数字、形として出なければ、幾分雰囲気は和らぐでしょ？
とりあえずその点では僕の配慮は上手く回ったと思う。
和やかな雰囲気のままプロジェクトを終わらせられそうだ。

しかし、これはこれで別の意味で問題アリだよなぁ……。
何の為に進捗管理やってんのって言う……。

全く、何事も思い通りに進まぬものよ。(´･ω･`)

リカバリー

おーし。

アイドルマスターと艦これの視聴をリカバリーしたぞ。

これで時代の最先端や。(｀・ω・´)

フィボナッチ数

最近、フィボナッチ数という良い概念を学んだ。

簡単に言えば「黄金比」の話で、自然界には以下の比例式が成立しているケースが多いという話だ。

・1
・2
・3
・5
・8
・13

カタツムリの貝殻の螺旋が一定パターンを描いているというアレだな。

そして、この黄金比はITの作業見積もりや、組織の人員にも適応出来るという概念があるらしい。

請負案件の見積もりの場合、以下の比例で開発工数の重さを定義する。

・1人日：超簡単な機能
・2人日：ちょっと簡単な機能
・3人日：標準的な機能
・5人日：ちょいムズな機能
・8人日：かなり大変な機能
・13人日：激烈に大変な機能

基本的に「1画面3日で作る」のがIT開発の標準だ。

ここで説明すると、上記の数字に「4」は無いだろ。
見積もりの段階で「4」は定義しないのよ。

「4日で作れると思うなら5日見積もっておけ。それが結果的には正しい」

という法則があるってのが、このフィボナッチ数という意味だからな。

そして、この法則はそのまま人員の能力にも適応出来る。

・1生産：バカタレ
・2生産：Ｂ級社員
・3生産：普通社員
・5生産：ベテラン
・8生産：エース
・13生産：カリスマ

「3生産：普通社員」が標準だから、それぞれの数字を3で割る。すると、以下の解釈に達する。

・どんなバカでも1/3＝0.3人分は働いて貰わねば困る。
・どんな天才でも13/3=4人分が限度である。

この範囲を逸脱する野郎はイレギュラーな存在だ。

つまり、

・その会社における普通社員の1/3にも達しないバカタレはやっていけないから速攻でクビにするべき。
・その会社における普通社員の4倍以上の働きをするヤツは特別な地位に就けなければ割が合わん。

こういうわけだな。

翻って、今の僕の参加しているプロジェクトで考えてみると、

・僕：2.8生産　⇒　8.4人力(エース級)
・協力会社さん：0.2生産　⇒　0.6人力(脱落)

う～ん。
協力会社さんの生産性は最低基準の1に届いてないか……。
つまり、プロジェクト管理のセオリーから逸脱した低生産性メンバーという計算になってしまう。

しかし、比例計算で考えると、「2.8:0.2=14:1」か。

13:1が限度で、現実は14:1というわけだが、これくらいなら誤差の範囲で何とかなるか……。

もうちょっと頑張ろう……。

激務

最近、業務が忙しすぎてやりたいことが全然出来ないぞ……。

3人で行うのが妥当な仕事なんだが、それを2人で行っている。
1人がボクで1人が協力会社。
その協力会社の生産性が……。
僕が2.8人、協力会社さんが0.2人くらいの比率で作業している。

しかも、協力会社さんは「プログラミングが苦手なだけでテスターとしてなら1.0の生産性がある」と期待していたんだけど、
実際はテスターとして見ても、やはり0.2人。
プログラマーとしても0.2、テスターとしても0.2なら、恐らく何をやっても0.2だろう。

僕の見立てだと、たぶん作業のルーチン化が出来ていない。

仕事って基本、同じ事の繰り返しだ。
今日の仕事は昨日の仕事のマイナーチェンジでしかなく、大部分は同じ事を繰り返している。
協力会社さんはこの「何が同じで何が違うのか」という見分けが出来ておらず、
同じロジックを何度も再生産したり、同じテスト観点を違うテストのように読み取ったりする。

常に『初見』に戻って作業しており、経験が消え去ってしまう。
だから何をやっても0.2なのだろう。

サポートしたいが僕も余裕が無さ過ぎる。
僕1人が2.8人分の仕事をするのを回して1ヶ月経過したが、そろそろキツくなってきたぜ。