エンジニアの１日は8時間というトリックがコスト増を招く

作業工数の見積もりをする際にどのように工数を見積もっているでしょうか。工数は人月を単位として見積もる場合の流れをポストイットに書き出してみてください。

さて、書けましたか。

作業見積もり

作業を見積もるのですからこれから作業する将来の作業時間を見積もります。見積もりには様々な見積もり手法があります。FP法、COCOMOIIなどありますから見積もり対象が見積れる手法を選択して見積もります。わざわざ見積れる手法でと書いているはインフラの作業見積もりにはFP法は向かない場合もあるからです。

何れにしても、ある程度の精度で見積もりできる手法を選ばならないのは変わりません。

人月単位

お題は見積もり単位を人月で答える、というものです。さて人月は月あたりに占める人的リソースの使用量ですから、人月を１とした場合の人的リソースを誰もが共通的に同じ解釈をできる単位で交換する必要があります。

その単位は通常は時間です。時間を対価と交換するわけです。

月あたりの時間を単純化するために次ように定義します。

8時間/日にち

お題は単位が月間ですから、これを月の単位に変換したいところですがひと月あたり何日働くのかを決めなければなりません。労働基準法32条では1週間について40時間を上限にしていますから１週間では40時間です。

月の日にちが30日であれば４週間と2日になります。便宜上、１ヶ月を４週間とするとひと月当たりの作業時間は次のように求められます。

40時間＊4週間＝160時間

ひと月160時間が1人月。

160時間の意味

人月の単位は定義できましたし、作業工数も精度のある手法で求められたので、人月当たりの作業見積もりが導き出せますね。

含まれるものは何か

ところで、作業見積もりに含まれる作業は何が含まれいるのでしょうか。それを書き出してください。コーディングならコード書いて、デバッグして、でしょうか。仕様書なら執筆してレビューして、でしょうか。

その他には含まれていない、のでしょうか。

含まれないものは何か

では次のものは含まれているのでしょうか。

・上司との打ち合わせ
・休暇、病欠
・カンファレンス出席
・研修

1日8時間のワナ
通常これらの活動は160時間の中には含まれていません。そうなんですね。知っているよ、わかっているよという方がほとんどだと思うのですが、工数を見積もって人月に観山する際に１人月を160時間働けることを無意識に前提としていませんか。

そう、これがワナなんですね。そして160時間で見積もっているからそのぶん、含まれない活動や休暇が割り込んでくるとその分外にはみ出てしまうのです。

何が問題か

これを考慮せずに定常的に見積もりをしているとどうなるかを考えてみましょう。

含まれない活動や休暇は日中帯に割り込んできます。割り込まれた分だけ残業としてはみ出ます。残業は法的に25％増しですから割り込んで押し出された本来日中帯に作業をする工数は、25％増しでコストが増えるということなのです。

稼働率にもワナがある

こうした対策として稼働率を設け、割り込んでくる工数見積もりに含まれない活動や休暇を差し引いて100％稼働の100％を例えば80％や70％に下げて人月を計算する方法もあります。

まあやりすぎると間接費が増えて利益率が下がるのですけど。

 何を含めるかを共通にしておく

 見積もる工数に何を含め、何を含めないかの線引きを緩くてもしておかないと思わぬコスト増がおきてしまいます。

ルールに縛られて必要ないものまで作ってしまったら本末転倒ですから

「アジャイルで開発を始めてしばらく経つんですが、色々と問題があって」
「そうなんですか。どんな」
「開発期間が決まっているじゃないですか」
「同じリズム、サイクルでスプリントを回すのですね」
「そうです。それでそのサイクルにいつもぴったり開発テーマがあうわけじゃないのでどうしたらいいかとか」
「バッグログリストを作って、必須の開発項目はここまでで、あとはベストエフォートでできるところまででいいんじゃないですか」
「そうなんですが」
「いつも期間にぴったりあう開発テーマにならないから詰め込んだスケジュールになったり、間延びしたスケジュールになったりして困っているということですか」
「そうなんです！」

「ところで、チームの中で開発のルールは決まっているのですよね」
「ええ」
「ところでなんでアジャイルの開発手法を選んでいるのでしたっけ」
「リリースを早くするため、です」
「そうですよね。だったら」
「はい」
「それが一番大切ですかね。チームとしては」
「それが要求されているので」
「じゃあ、バックログでスプリントの長さを調整してしまえばいいじゃないですか」

「いいんですか」
「一つだけ約束があって、今のスプリントの長さがリリースしたいサイクルにあっているならですが」
「はい、合っています」
「それをリミット、上限にします」
「上限に」
「そう、それ以上は延ばさない。上限。それで、あとはバックログの必須開発項目はいつも通りやって、ベストエフォート分は上限以内で収まる分だけ」
「それってぴったり期間にハマらなくても埋めないってことですか」
「そうですよ。埋めようとすると弊害も出ますから」
「でもそうすると空いた時間も開発テーマの期間を延ばして使ってしまいそうです」
「見積もりで開発日数はチームで見積もりを取るのでしょう。それはルールだから変えない。隙間時間ができたら、それは別のことに使えば。例えば、改善に当てるとか技術的なテーマに当てるとか。休みにしてもいいじゃないですか」

「いいんですか」
「だってリリースしたいテーマはそのスプリントでリリースできるんでしょう」
「そういうことになりますけど」
「じゃあいいじゃないですか。あと、上限としているのだからスプリントを短くしてもいいんじゃないですか」
「あ、だから上限なんですね」
「スプリントの期間に縛られるのもなんかおかしい話でしょう。期間に縛られると作らなくてもいいテーマを『期間に合うから』と選んでしまいますよ。実際、それをしてしまっているのでは。だから違和感を感じているのでしょう」

「それですね…なんかおかしい、問題じゃないかっていう感覚は」
「チームに合わせないと意味がなくなっちゃうというか、おかしくなってしまいますよ。開発のプラクティスはチームに合わせてカスタマイズしないと。ただ、プラクティスの本質を見失わないようにさえすればいいと思いますよ」
「ちょっとスッキリしました。なるほど」
「じゃあ」
「あ、このあと今日はお仕事おしまいですか。だったらちょっとだけ行きませんか。もう少し相談させてください」
「えっと、じゃあ少しだけ行きましょうか」

よなよな 地ビール 飲み比べセット 350ml×4種 各6本 ( よなよなエール インドの青鬼 燦々オーガニック 東京ブラック )

中堅エンジニアに求められるリーダの資質とビジネスの資質

中堅のエンジニアになるとプロジェクトチームでの役割もブロックリーダやアーキテクト、プロジェクトマネージャのサブ的な位置付けなど現場での期待が広く、重くのしかかってくるようになります。

一方、経営、つまりマネジメントサイドからの期待も徐々に増えてくる頃でもあります。早い組織では若手の頃から経営が次々世代のリーダ候補として選抜している場合もありますが、中堅のエンジニアゾーンに入ってくると確実に候補者にマークをしているものです。

リーダの資質

中堅のエンジニアは次世代のマネジメント、組織のリーダとして期待されるゾーンです。リーダとはあるところで聞いた（気がする）話では300通りの定義があってこれという定まった言葉の定義がないらしいですが、ワタシの持っている知識の限りでは、

「ビジョンを作り、伝え、自ら切り開く人」

ではないかと思うのです。

エンジニアの集団の組織であれば、エンジニアの組織の進む経営ビジョンを描き、組織のメンバに共有して、ビジョンを実現するために先頭に立って進む人と表現できるでしょう。

営利組織ですから経営ビジョンは商売が実現でき、継続的経営が成り立つものである必要があります。

ビジョンが技術全面であっても、その技術を介して利益を得る構造になっているものです。

ビジネスを支えるのは現場です。いくら組織の本社機能がビジョンを行動プランとして描いてもそれを実現する役割が機能しなければ技術の対価を得ることはできません。

経営者が描くビジョンを現実化するのが現場のリーダであり、中堅エンジニアはその役割を期待されています。中堅エンジニアには経営者が描くビジョンを推進するリーダのスキルが求められるのです。

でも、リーダの定義は300もあるのであるということは、実は

「誰とでも共有できるリーダ像はない」

ということでもあります。だから組織ごとに求められるリーダをその時々の要請に基づく言葉で表現されるのです。よって300を超えるリーダの定義に結びつくのではないかと思うのです。

こうなってしまうと、つまり、リーダという一つの言葉で微妙に違う意味が氾濫している状況ではリーダに求められる資質はあってないようなものだと捉えることもできます。

そういった背景はマネージャが変わるとリーダシップが違う自称からもその理由が理解できると思うのです。

言い換えると

「決まったリーダ像がないので教育のしようがない」

ということの裏返しなのです。が、中堅エンジニアにはリーダになることを求められるという不条理があるのです。

ビジネスの資質

エンジニアは技術を介して技術を利用するエンドユーザの便利を提供し、対価を得ることが仕事です。

中堅エンジニアに至っては、経営サイドに一歩近づくことを期待されているので、ビジネスを介して利益をいかに得るか、組織の一員としての役割を期待されるようになるのです。

経営者はビジョンを語ります。それを実現するのがリーダです。ビジョンは組織存続の将来像であり、リーダにはそれの実践が求められているのは確実です。

であればこそ、中堅エンジニアにはビジネスをビジョンから現実のビジネスに、技術を貨幣価値に変換することが求められているということです。

これは、中堅エンジニアのゾーンに入ると技術をお金に変えることを考え、実践することを求められるということです。

これを実践できる可能性が高いエンジニアを選抜しているのです。だって、少なくとも事業責任を担う管理職候補にするのですから。

ここのところを逃げ回っているとキャリアパスを一つ失うことになります。 

当事者として変えたいと真剣に思っていなければいくら事例を聞いても変えられない

キャリアパスを考えるようになってから、組織内の興味を惹かれない研修であっても時間に見合いそうな

「何かひとつ」

でも良いからお土産を持って帰ろうと思うようになったのです。まあ、最初からそのつもりで研修を受けろよ、っていう事案ではありますが。

時間の価値

背景には、キャリアパスを考えるようになって、他のエンジニアの足元にも及ばないけれど、仕事でアウトプットを気にするようになったので自分の仕事の中でアウトプットをする時間をどれだけ確保するかが気になっていたからかもしれません。

例えば、呼ばれて出た会議で実は必要なかった、とかが続くと自分の作業時間が削られるわけで、残作業のボリュームが削られて残った時間の中でやり切れるかがきになるのです。

同じように、研修に行くことになってもその時間を作業に割り当てれればと思う自分と新しい（かもしれない）ことを学び知識面での価値を少しでも充填しておかないと知識の燃料切れになってしまうという焦燥感の間での行動指針が

「何か一つでもお土産を持ち帰る」

なのです。

これが時間の価値を学ぶ一つの経験だったのでした。

何かを持ち変えられるか

そういった行動指針のスイッチをする前までは、研修やセミナーで事例を聞いても「そうなんだー」くらいで終わってしまうことが多かったのではないかと思うのです。今は違ってしまっているのでそうだったんだろうと。

スイッチ後は、この時間の対価を価値を得ようと思って聴くのでお土産を探すことが聴講している間のタスクになります。研修やセミナーで講師や講演をしてみるとわかるのですが、スライドに全てを書き切ってそれを読み上げるような進行はしないものです。

スライドを図と少ない文字で構成することで、初見の聴講者に対して注目と情報を一度に伝えきるように工夫しますから自然と口頭での補足説明が入ります。

書いてあること以外で何を話すか、何を聞き取るかが鍵なのです。それを聞き逃さないようにした上で、自分の関心事に刺さるキーワードを見つける行為が

「お土産を持って帰る」

なのです。

変えたいことがある

自分の関心事に刺さるキーワードを見つけられるかどうかは、現状の課題を持っていて、それを当事者として変えたいと思っているかどうか、これに尽きます。

当事者であれば現状の運用でデメリットを感じたり実際に影響を受けているのです。だから「変えたい」と真剣に思いその行動の一つが事例を聴くにつながっているのです。

変えたいと思っていても「うちの組織では無理だろう」と１ミリでも思っていたら、いくらセミナーや研修に出てもそれは実現しないです。だって、最初から諦めているのですから。それこそ、聴講するだけ時間の無駄です。変えられないオペレーションをどうぞ続けてください。

変えようと意思決定する人だけが持っている関心事に変えるための光るキーワードは刺さるのです。

10年前の自分に「マネージャを選んだのは良い判断だった」と伝えたい

10年のところは各自置き換えていただいて結構です。

エンジニア→プロジェクトマネージャ→マネージャと、やってみたいことを自分で選択してきたけれど、今振り返ってみると今の活動の源泉になっているのでひとまずはマネージャを選んだことは良い判断だった、と。

正解とは言わない

拘りがあるわけではないけれど、選んだ結果が正解とは言わないです。正解がないからね。あるのはやる前に妄想していたこと、つまりマネージャになって実現したかったことを実践したことで人材の育成に影響を与えることができたことが何より自分の期待に対する結果として得られたので概ね良いのではないかと思うわけです。

全部が期待する結果でもない

現実は冷淡で10年前にマネージャを選んだのは良い判断だと今の自分が言えるけれど、あったことが全て期待する良い結果をもたらしたわけでもないです。

10年もあれば様々な仕事があるわけで、こりゃひどいと思っていたこともあるのです。まあ、ひどいときってものは一時的なのです。

そんなことがあっても見てくれている人はいるもので、陰日向になって応援してくれるのはとてもありがたいです。

だから同じようにするのですけれど。

やりたいことを実現するように動いている？

新しい技術を覚えたいとか、アジャイルのスクラムで開発したいとか、何かしらちょっと試してみたいことがあるのではないか、と思うのです。

もしかしたら、もっと上手に、早くコードを書きたいとか、バグの少ないコードを書きたいとか、誰それさんのようにプロジェクトを仕切りたい、とかかもしれませんね。

自分の技量によるものでは実現できないことは、そうしたことの裁量を持っている人になるか、働きかけて実行責任者を請け負えるポジションにつくことが近道なのです。

それを実現するために、今の行動を判断することが大切です。単なる一時的な感情で判断をしていると実現したいことから離れてしまうことがあるので。そうした回り道も無駄にはならないし、得るものはあると思いますけれど。

10年後の自分の活躍を具体的に妄想しよう

昭和であればあと10年もせずにリタイヤをしているはずでした。世の中が変わったこともあるし、自分で歩けるうちは自分で稼ぐ手段を持っていたいと思うようになりました。もちろん、エンジニアとして関わりたいのです。

例えばこんな風に。

リタイアまであと数年だけれど、ブログは書き続けている。もう6000以上のエントリがある。まあ、読者は相変わらず少ないしPVもニッチサイトの代表みたいなものだ。それでも10年前と変わらず、同じようなテーマを車輪の再発明をして、でも切り口はその時々により変えて。プロジェクトマネージャになる人は毎年いるし、振り返りたいプロマネもいるし。現場にはPMのメンターやアドバイザーとしてプログラムマネジメントをしている。社外での講演も相変わらずポツポツあって…。

さて、それを実現するためにアレをしなければ。

小さな失敗を許容するチームは、結果を求めずに何を得れば良いのだろう

これまで、プロジェクトなどの仕事の中で

「小さな失敗をしよう」

と何度か書いてきました。仕事で失敗をするなんて、と思うかもしれないけれど、失敗することを嫌っていたら、今の確実に仕事を捌ける確立された仕事の手順でしか成果を出せない、ということになります。

これ、とてもエンジニアとしては危険なシグナルを自ら発していると気づいて欲しいです。

確立された手順は楽チンだけど

仕事を進める上で、確立された手順があるということはとても楽です。同じ環境構築をするにしても、構成情報だけが違うのであれば単なるパラメータ違いでしかありませんから、既存の手順にインプットするパラメータだけ確認しながら作業すればいだけです。

楽ということはそこに学びがありません。楽ばかりしていると技術スキルは陳腐化し、技術価値は低下します。これも毎度言っていることですけど。手順化できるということは、機械化で置き換えられる可能性がとても高いです。置き換えられるということはより低価格の人的リソースに置き換えが発生するかもしれませんし、そのまま機械化され易い部分であるということです。

小さな失敗の「小さな」

小さな失敗とは担当するタスクの中で、プロセスや技術的な変更を試みる行為です。

なぜ、小さな失敗と「小さな」とつけているかと言えば、プールしている工数の中で失敗をしてもリカバリできる範囲で検証すると歯止めを掛けるためです。

小さな失敗の意義

小さな失敗は小さな失敗をするために行為をするわけではありません。仕事やプロジェクトの中で現状に課題があり、解決するための手段や期待する効果を得られるかを検証するために行うものです。

その検証結果では解決できないことがわかったり、期待したほど効果が得られなかったりした場合が「小さな失敗」なのです。

つまり、

「小さな失敗とは変えるための事前検証的な活動に対する結果についてはリターンで求めない」

という意義があるのです。

では、変えるための事前検証的な活動に対して結果を求めずに何を得られることを期待するのでしょうか。

それは、その活動により得られる経験知に価値を見出すのです。確実にできる手順を形式知として知っていることも必要ですが、このやり方は上手くいかないと知っていることも必要です。

同調ばかりのメンバとは働く価値がない

チームを編成するにはメンバが必要で、チームとして必要とするスキルとレベルを充足するスキルとスキルレベルを持つメンバがいて初めてチームとしてのスタートラインに立つことができるのです。

チームとしてのスキルとレベルで成立するように考えるのでそれを満たすメンバ一人ひとりのスキルとレベルは個々の経験によりバラツキが生じるものですし、人生、一人ひとり違うのだから生じることが当たり前です。同じスキルとレベルのメンバが複数人いる方が胡散臭いくらいです。

意見が最初から一致していたら

前提から違う経験が当たり前としているので、チームとして同じテーマの課題や問題を抱えたとき、違う考え方、違う解釈、違うアプローチになって当然です。

というか、最初に意見をいったメンバに他のメンバが同調していたらこれは危ない兆候です。

だって、違って当たり前なんだから。そこには専門家としてのミッションを果たすというエンジニアのイズムより同調することでことを進めようとする間違った判断があるかもしれないと思った方が良いのです。

同調は考えていない

他のメンバの意見にすぐに同調するメンバがいたら、自分の言葉、考え方で話すようにうながしてみよう。他のメンバの意見にすぐさま同調するなんて、まるで下手なレポータのグルメ番組のようなものです。口に入れて直ぐに美味しいなんて味わっていないのと一緒に、理解せずに合わせているだけなんです。

考え方、導き方を共有する

チームの中であるテーマについて検討が必要なとき、そのテーマをどう考えたか、結論をどう導き出したかをそれぞれ出し合い、共有し合うことが必要です。

間違っても人の意見を批判することを求めているわけではないし、自分の意見をごり押しすることでもないのです。

チームの存在目的を達成するための一つの活動として考え方を共有するのです。