補充

 いつも小指から穴が空くんだよねぇ。

「蒸れません！」本物シルクの自転車用５本指靴下！-ドクターシルク「くつしたの下」紳士用２足組

受け身のエンジニアとアサイメントの関係

新人や中堅のエンジニアが成長しない、積極的でない、受け身で困っていると相談を受けることが度々あるのですが、そういった相談をする方々は多分、ご自分のエリアのプロジェクトの人的リソースのアサインメントについて実情をご存知ないのだと思うのです。

なぜ、担当するプロジェクトや組織の人的リソースのアサイメントの方法が新人や中堅エンジニアの育成に影響するかは、どこで困っている対象の人的リソースの層が働いているかを調べたらわかると思うのですが。

調べ方

受け身で困っている新人や中堅エンジニアのマネージャであれば目標管理でどのようなアサイメントかを知る機会がこれまであったはずですし、今年もあるでしょう。

あなたがプロジェクトマネージャであればチームのロールにアサインしているのはプロジェクトマネージャ自身ですからご存知のはず。

何を調べるか

役割（ロール）と工程の範囲をお尋ねください。

前提

一般的なウォーターフォール型のプロジェクトでは、要件定義から総合試験の各工程の工数と適用技術を拠り所にメンバをアサインします。

工程がいわゆる下流工程の詳細設計から結合試験の期間に工数のビークが立ちます。逆に上流工程や総合試験では少ない人数で対応します。

前提は工程に応じてエンジニアの増減がある、というものです。要件定義から総合試験まで一定のワークロードで工期を設定している場合やアジャイル開発などでチームのメンバの増減を前提にしない場合は当てはまりません。

当てはまらないケースで新人や中堅エンジニアが育たない場合は、また別の原因があるのでしょう。

ロールと工程の経験数

調べた調査対象の受け身のエンジニアが過去に経験したプロジェクトのロールと担当した工程を明示的に図表にしてください。

仮説は、受け身のエンジニアはロールがプロジェクトの一担当で且つ担当していた工程は下流工程のピークのみ、です。

調査対象のエンジニアの経験はその仮説の範囲に当てはまっていることでしょう。

受け身のエンジニアはアサイメントで作っている

担当するロールが一担当者で且つ担当していた工程が下流工程、それも開発、単体試験、やっても結合試験だけであったとしたら、プロジェクトへ途中参画するとしたらどういった感じでしょうか。

多分に、上流工程からいる既存メンバからの指示に従って物事を進めるのではないでしょうか。上流工程で決められてきたことをキャッチアップするには時間がありませんし、担当する役割を果たすためにも早期に立ち上がらなければなりません。

あまりにも主体的に考え、能動的に動くには情報と時間が足りません。結果、受け身で仕事をする習慣を受け付けられるのです。

そうしたアサイメントを変えないと受け身のエンジニアは減らないのです。

プロジェクト計画書はモノと情報の流れを書こう

「プロジェクトを成功させるために何をすればいいですか」

と聞かれるたびに「プロジェクト計画書を書き続ければいいのに」と思うのだけれど、そう答えると釈然としないお顔になるエンジニアが多いから言わないのだけれど。

でもですね、なぜプロジェクト計画書を書き続ける必要があるかがわかってるエンジニアなら、黙ってプロジェクト計画書に必要なアイテムは用意しているものなんですよ。

一つ足らないもの

Q　プロジェクト計画書は何が書かれているかを述べなさい。

さて、どう答えるかしら。パッと出てきた答えがそのエンジニアにとって日頃から考えている大事な価値の一つでだと思うのですけど。

エンジニアがプロジェクトマネージャにアサインされて、幸いにもプロジェクト計画書のテンプレートがあって、あったらあったで書かされて作ったプロジェクト計画書に足らないものが一つ生まれてしまうのです。

プロジェクト計画書に書くコンテンツとは

幸いにもテンプレートがあって書かなければならないプロジェクト計画書のコンテンツには何があるでしょうか。

チャーター？進捗管理？品質管理？WBS…えーっとそれからそれからたくさん。

そうなんですよね、下手にテンプレートがあると書かなければならない（と思ってしまう）フォーマットが用意されているのでうんざりするんですよね。

これだけ書かないといけないのか。

ここに存在するのはプロジェクト計画書ウゼーだし、プロジェクトマネージャやってられない、です。じゃあいいやいちエンジニアで、と。

どうして何種類ものフォーマットがあるのでしょうね。とそうした書かなければならないという視線、観点でプロジェクト計画書のフォーマットをみてしまうこと自体が実は間違っていることに気づかなければなりません。

プロジェクト計画書はあることを表現する手段としてあるのであって、プロジェクト計画書のフォーマットを埋めることがお仕事ではありません。

プロジェクト計画書に書くのは、プロジェクトを完了させるための価値を書くのです。

モノと情報の流れ

プロジェクト計画を完了させるための価値とはなんでしょうか。

プロジェクトとは顧客が実現したい業務課題をシステムで実現する業務活動です。業務課題に価値を添加して顧客が手に入れたい解決手段を提供するのです。

インプットが課題、アウトプットは業務課題の解決手段。間のプロセスに必要なものは、インプットの課題にまつわるモノと情報を価値により変換する手続きです。

プロジェクト計画書に書かれるのは、プロジェクトのモノと情報の流れを書くのです。

[resources]　　→　　[procedure]　　→　　[deliverables]
各種資源　　　　　モノと情報の流れ　　　アウトプット

書かされ感の根源

 プロジェクト計画書を書く際に書かされ感を１ミリでも感じているなら、それに足らないものはプロジェクトをどうしたいのか、それも具体的に運営するためのイメージ像を持っていないからです。

プロジェクトマネージャとして実現したいことが

「プロジェクトの成功」

 では絶対に実現することはできません。

必要なことは、どのようにして理想のプロジェクトを実現するかというプロジェクト運営の考え方、念持のようなものです。

将来を実現するための構想

残業をしないくらいスマートに、効率的に、かもしれませんし、致命的なバグを出さないための活動を伴った運営かもしれません。

いづれにしても、必要なのはプロジェクトマネージャを担うエンジニア自身がプロジェクトをどうしたいか、というプロジェクトの将来の構想です。

それがプロジェクト計画書のフォーマットを使って表現するのだと認識した時点が、プロジェクト計画書はやっと一つの道具として扱うアイテムになるので書かされ感から解放される瞬間となるのです。

ボトムアップでなんか進捗しない

某プロジェクトの上流設計から参画してもらったシニアなエンジニアさんがどうもしかめっ面しながらディスプレイを覗き込んでいるのが気になって声を掛けてみたのです。

「どう」
「キッツイです…」
「なんか、ご支援したほうが良さそうなのでご支援しましょうか」
「お願いします」

シニアエンジニアの方は年齢もスキルレベルもシニアで手が動く先生みたいな人です。ですから技術的な不安は全くありませんし、ハナっから敵わないのでそちらはお任せです。

ただ、エンジニアには

・ボトムアップから積み上げる
・作業の目的より自分の関心事を優先する

という特性があるので放っておくと進捗がとんでもないことになる場合があります。

もちろん、シニアなエンジニアの方は専門領域であればプロジェクトマネージャもできるのでWBSを作ることなんてお茶の子さいさいなのです。

でも、こんな制約があると途端に嵌るのですが、これ、他のエンジニアでもみたことないですかねぇ。

制約条件はナニ？

「じゃあ見せて」
（ガントチャート風のざっくりスケジュールを映して）
「最初にこれして、次にあれして…見てください、余裕ないです。というか無理です！」
「最初のこれ何するの」
「これは現状を調査して…」
「ふーん。ところでマイルストーンなに」
「ここでレビューして、ここでアレして。後ろが決まっているので後ろから前に倒すと、ほら、全然無理です」
「無理なスケジュール引いているの。無駄なことしてるね」
「しょうがないじゃないですか（怒」
「でもさ、そのマイルストーン本当に守る必要あるの」
「この会議で承認もらわないと次が」

その作業ナニ？

「そっか。それはそうだね。でもさ、承認もらう内容って完成版じゃないといけないの。その会議にこのテーマで割けるの１−２枚程度の情報量だよ、パワポで」
「でも、翌週に配布予定があるから」
「そっか。会議資料はポイントに絞るとしてもそのあとすぐに完成版が必要なんだ。なるほど。じゃあさ、その完成版の仕様書作るためのどう進めるの」
「現状調査して、並行して技術仕様を調査して…、それでまとめて」
「現状調査って何するの」
「点在する拠点でどんなものを使っているかと、どんな使い方をしているかとかです」
「それ調べて仕様書なるんだよね」

作業の目的ナニ？

「え、ええ」
「ちょっと待って。今の変。おかしい。目次考えていないんじゃないの」
「…」
「仕様書なんだから目次がWBSにならないとまずいんじゃないかな」
「このスケジュールでやる作業全てが仕様書にならないといけないと思うけど。逆に言えば、仕様書に繋がらない作業はしてはいけない。第一、時間の余裕がないんでしょ」
「そうですが」
「その仕様書、要件書けばいいんじゃないの」
「だったらさ、論理モデルを描いて拠点を管理している部署に確認すればいいんじゃないの」

進捗することにリソース割けよ

「でも前工程でそうするって」
「いいよ。忘れて。そんなの間違っているって言えばいいんだよ」
「それまとめた人まだいるから場の雰囲気が悪くなるじゃないですか」
「関係ないじゃん。そんな気遣いして仕様書がキツキツのスケジュールでできるの。できるならいいけど実現性のないスケジュールなんて止めるよ、キツいんじゃなかったの」
「キツいです」
「だったら、実現できるスケジュールを作らないといけないじゃん。仕様書にならない作業をしてもいけないじゃん。やることは仕様を期限に作ることじゃん、どう」
「そうですね。わかってます」
「ほんとぉかなー、わかってるかなー」

どうやって実現するの？

「わかってます、WBSに展開できていますし」
「どれ。細っ。なにこの0.05の工数って」
「これは準備に」
「わかった。じゃあさ、どうやって進めるの」
「スケジュールですか」
「ほら、仕様書に書く項目の内容。それ。一人で好き勝手に書くの」
「いえ、関係者がいるので検討会を開いて決めます」
「どうやって」
「調査して似ているものをグルーピングしてこれでいいかって」
「どのくらい」
「200…くらいでしたっけ」
「け、じゃないよ。それ一人でやるの」
「彼ら工数ないからって」
「そうじゃなくて、叩きはこっちで作るのはそういう仕切りだからいいんだけど、200一人でやるの。死ぬよ。そりゃ終わらないわ」

作業プロセスで考えようよ

「だから、困っているんです」
「そうしたらさ、その進め方が間違っているって気づかないと」
「？」
「作業プロセスが間違っているんだよ、それ」
「？？」
「何回打ち合わせするの」
「別の分科会に入れてもらって」
「だから何回やるの」
「10回くらい…かな」
「それもおかしい。仕様書の目次の分だけ検討テーマがあるのでは。項目が10あるなら10回は必要でしょ。1時間もらえるとして、1テーマ30分なら5回は必要じゃん。開催頻度は…なら何週かかるかわかるじゃん。それカレンダにはめたら間に合うか間に合わないかわかるじゃん」

主体者としてリクエストしよう

「？？？」
「スケジューラ出して。ほら、ここで1回、ここで2回目…ほら。だめだこりゃ」
「だからキッツイって」
「違うよ。こうすればできると考えるんだよ」
「いいかい、この期間に仕様検討ができればいい。でも今の条件なら2倍の開催が必要。開催頻度を守るならスケジュールを伸ばす、守るなら頻度を変える。頻度を変えるとリソースが足らなくなるじゃないのかな。資料準備はこちらだから。でしょ。あ、これ付帯作業もいるね。仕様書ばっかりじゃ足らない。そうすると２倍じゃなくて2.5倍だ」
「作業工数はこのWBSで見積もった規模とほぼ合っていると思います。やっぱりWBSの最初の工数は正しかった」
「その細かさで」
「いえ、これはそこから削って」
「できるスケジュールだっけ」
「いいえ」
「意味のない仕事してどうするの。最初のが正しいならあとで検算で使おうね。でさ、できるスケジュールを実現するために必要なリソースをリソースリクエストするんだよ。もしくはスケジュールを伸ばすのかを選べって」
「…」
「ねえ、わかってないでしょ」
「いいえ」
「これ楽しそうだね。乗っ取っていい」
「それは…」
「こういうのはさ、トップダウンでこうやりますって進め方を決めて、その中で収めるために必要なリソースを要求するんだよ。終わらせたいなら」

エンジニアをマイナス評価するマネージャからはさっさと逃げよう

目標管理の面談では、

「スキルエリアを広げるかレベルを上げる若しくは役割をステップアップしないとプラス評価できませんよ」

と伝えています。

１年間仕事をしていたら、専門的なスキル、技術かもしれないし基礎的なスキルかもしれないけれど、何かしら経験を積むことで成長しただろう、と期待しているからです。

だから、１年後にどのスキルが実際成長するかは確約なんてできないけれど、今はどれを意識して活動するか仮でいいから決めておこう、と思うのです。

目標なんて仮説ですから、変わったら変えたいと思ったときに「変えたい」と言えばいいのだし。ただ、終わってから「これでした」はちょっとなぁと思います。

で、これは目標を設定するエンジニアの今と１年後の絶対評価なのです。

この絶対評価の評価対象で成長がないとどうなるか。

人が３人集まると組織化するのです。そして活動にリターンが生じると分配をしなければならなくなります。

それは公平に按分することもありますが、活動の働きによって分配比率を変えるケースもあります。より活動で貢献したエンジニアには労いたいと思うと比率の傾斜を高くしたりします。

ここでエンジニア同士を相対評価が生じます。

組織の中でのポジションは相対評価の結果です。そのポジションや役割を上げていくには、相対評価の中で評価される必要があります。ですから、まずは絶対評価でプラス評価が必要になるのです。

脱線すると、マイナス評価をするマネージャもいるようですが、上記の絶対評価をしていれば自然と成長がビジネスへの貢献＝役割のステップアップが含まれるのでプラス評価だけで十分なのです。プラス評価だけをすることはエンジニアの成長だけを見ていれば良くなるので、あらさがしは無くなりますし、成長を促すことだけのフォーカスできるようになります。マイナス評価を取り入れると評価自体が２つの指標を持つことになるのと評価データも増えるのでメリットは全くないです。それにきづかないマネージャからは逃げたほうがいいです。

と、ここまで書いて脱線したところをタイトルに変えました。最初は別のタイトルで書き始めたのですけど。

１年後の面談のときにエンジニアの成果にマル、○をたくさんつけたい。つけさせて。これが本心なんですけどねー。言葉にも指定伝えていますけど。

だから目標をピボットせずに諦めちゃうエンジニアはちょっと残念なのですよ…。

プロジェクトなのに１年間ほぼ残業ゼロを実現するためにしたこと

ライフワークバランスとか働き方改革とか長時間労働時間をブラック認定する世情とかが今の流行りの世の中だけれど、相変わらずエンジニアの日常は数時間の残業をすることをデフォルトで作業見積もりを立てているのはどうしてなんだろう。

いや、コスト見積もりは定時で見積もっているけれど、作業工数の計画は残業する前提で無理やり押し込んで溢れさせているとしたら、問題はプロジェクト側にあるのではないだろうか。

契約とプロジェクトマネジメント

これは契約の都合もあるのだけれど、残業をされても追加支払いができないから間接的に残業をしないでほしいとオーダーをいただいているプロジェクトがあったのです。

追加契約をしないことが前提になりますから、受託側から追加費用を請求しても支払いはされない（請求してももめるだけ）なので、プロジェクトコストをマネジメントする必要が出てきます。

コストコントロール

エンジニアに対しては残業をしないようにワークのコントロールを求めることになります。

ここでエンジニアがやってしまいがちなのは、良かれと思って計画コスト以上に仕事をしてしまったり、エンジニアが工数より少ない成果でよしと判断してしまうことです。

問題なのは判断に顧客合意がないことです。良かれと思って計画コスト以上に仕事をしてしまうとある意味紳士協定で費用請求をしないことになっているのでプロジェクトコストはオーバーランすることなりますし、それはやってしまった後でしかプロジェクトマネージャは察知できません。顧客もコストオーバーランをした成果を標準工数のパフォーマンスと誤認識するとプロジェクトとしてはその誤認識を訂正しなければなりません。

エンジニアの独自の判断で工数より少ない成果でよしとしてしまうと目標としている計画に到達しないことになり、予実の較差の原因究明やキャッチアップの策を検討する場合もあり、これまた余計なコストを後につけ回す可能性を持っています。

まあ、プロジェクトマネージャ自身がこうしたことを予見した上で、エンジニアのワークをコントロールする責任を履行しなければならないのですけれど。

作業の可視化

このような契約の場合、エンジニアがしなければならないことは持っているワークロードの面積に対する予定作業がどのくらい占めているか明示した上で、プロジェクトマネージャや顧客と合意することです。

作業可視化でエンジニアに求められること

ただ一つ。作業見積もりをする際のエンジニア自身のスキルとレベルを自身が適正に評価することです。

予定している作業で活用する自分のスキルとレベルを甘く評価すれば必然とスケジュールオーバーランを引き起こし、コストオーバーランも起こします。

厳しい評価は、計画値を多く積み上げすぎる傾向にあり、計画時点で到達したい目標まで未達になり、これはこれで工夫という無駄で余計な作業に結びつきかねません。

仕掛品で軌道修正できるようにコントロールする

こうした策も作業を着手してから完了するまで放置するとエンジニアに染み付いた残業を前提とした日常に戻ってしまいます。

これでは色々と顧客と握ってもパーです。そうしないためにも途中の成果を見せることで顧客からの要望の変化の対応を検討する時間を確保したり、進めていて発見した課題の落とし所を顧客を巻き込んで調整したりすることが必要です。

顧客は形になったものでしか判断がつかないので、手書きのデザインでも、パワポのスライドでも、考え方の方針であっても、そうした途中経過のものを見せて意見を吸収しながら場合によっては計画のピボットを合意をしながら進めるやり方を採用することも工夫の一つです。

エンジニア側起因の計画のピボットは推進上の課題解決の意思決定で生じるものです。これも課題として共有して顧客を巻き込むことで合意プロセスを根付かせることができます。

積み本

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation