若手エンジニアを消耗させない
もう20年近く経つので昔話ではあるのだが、その組織のSIプロジェクトの人的リソース計画をみたとき、ちょっと衝撃を受けた。
どうしたのかというと
『若手エンジニアを都合よく使いすぎ』
で、
『これでは若手エンジニアは育たない』
と感覚的に衝撃というか違和感を覚えた。
多分に、会計的な観点でコスト計上を正しく行うことを要請され、それを遵守するためにプロジェクトの人員計画を工程毎の工数から、配分したためだろう。
人員計画を見ると、いわゆるプレイングマネージャのプロジェクトリーダがいて、そのロールは通しで工数を積んでいるが、詳細設計や開発、テスト周りの、いわゆる下工程は適用技術で分解して、幾人かの若手エンジニアに割り当てていた。
幾人かの若手エンジニアも信頼、要は過去の実績や作業品質から使いやすいエンジニアに多く任せていて、若手エンジニアの中でも経験の少ないジュニアなエンジニアはまるでアルバイトのような時間しか割り当たっていなかった。
これで何が起きるかを想像して欲しい。観点は、1年後、3年後、5年後と時間軸で想像するとイメージしやすい。
当たり前だが、
プレイングマネージャのプロジェクトリーダ ＞ 使い勝手のいい若手エンジニア ＞ ジュニアエンジニア
の順でしか成長する機会がない。ましてや、ジュニアエンジニアは、信頼貯金を得る機会自体が非常に少ないから、成長の機会がない。
プレイングマネージャのプロジェクトリーダは、こうしたやり方でやってきていて、それでそれなりにやってこれているから続けているはずだ。
ということは、やり方に工夫の改善もみられていないということで、経験ベースの固定観念で仕事をし続けて、実際には成長の機会を不意にしている可能性が高い。
この想像から容易に考えられることは、
- ジュニアエンジニアから辞める
- 成長しないエンジニアを育てる
しかない。
若手エンジニアが成長しない、技術力がないというシニアエンジニアやマネージャをよく見聞きするが、そう言った不満をいう、
エンジニアをアサイメントできる裁量を持っているロールにいるものが、その実態を、時間を掛けて作り上げていることに気づかなければならないが、そう言った観点を持っていないから、結果的に、彼らのいう『無能な若手エンジニア』しかいない状態になる。
マネージャは、プレイングマネージャのプロジェクトリーダがそうした人員計画を立てていたら、組織の観点で正すように改善を要求しなければならない。
場合によっては、組織がコスト負担しなければならないこともあるかもしれないが、それでも、将来の組織を実現するために、若手こそ成長の機会を作らなければならない。
そして、そうした成長の機会は、プロジェクトの裁量をもつエンジニア全員のミッションなのだ。
だから、人的リソース計画をみたとき、どれだけエンジニアが通して入っているかをチェックすることが、将来の組織作りに繋がるかを判断できる。
若手エンジニアをアルバイトのように便利に使って、成長の機会を与えず、消耗させるようなことを回避しなければならない。
中途採用が急に増えたとき既にカルチャーは衰退している
ダメかは知らないが、エンジニアが仕事をしたい組織かと言えば…。
SIerのような新卒一括採用をしているような組織では、ない悩みかもしれない。クラウドサービスをやっている組織では、新卒を育てている余裕はない（メガベンチャーか上場済みなら別だが）。
即戦力が欲しいから、jdを書いてポジションを用意して、採用も優先度を上げてリソースを突っ込む。
クラウドサービスなどのプロダクトを提供する大元のミッションがあり、プロダクトを育てながら培った価値観、（何度となく書いているが）意思決定の基準をカルチャーとして言語化し、カルチャーに共感する人だけを採用する。
ポジション、jdに書いたコンピテンシとレベルを出来るかを見極められなければ、組織は遠からず致命傷を負う。小さい組織にコンピテンシのないリソースは障害にしかならないからだ。
だから、採用時にプログラムなどの課題を出すし、そうでもしなければ思考の癖も最低限のスキルも判断つけようがない。キャリアシートと面接だけで採用なんてあり得ない。
採用の課題は、組織の現状のレベルである。採用する側は、自分たちより優秀な人をとらなければ、組織は価値を今以上、増やすことはできない。よくできて、連続したイノベーションで精一杯で、非連続のイノベーションはおき得ない。だから、衰退し始めるのである。
採用される人、応募する側も、自分のやりたいことを持っていなければ、募集しているポジションでスキルをパフォーマンスすることはない。実現したいことがなけれが、採用後の推進力を見つけるところから始めることになる。そんなことをされては、組織はやはりダメージを負う。
肝心なのは、採用候補者がカルチャーフィットするかどうかである。組織が若いうちはカルチャーフィットしないと採用後の仕事のあらゆることでストレスを被る。これはとても辛い。
カルチャーは意思決定の基準だからである。
これだけの条件を満たす採用候補者だけをとらなければ、組織の価値観は自ら減衰させてしまう。
私見であるから、さてどうやら。
人生のハンドルを渡されたことに気付いたとき
ある平日、メッセンジャーにて。
友人「今日の夜食事どう」
自分「（うーん、作業しようと思ってたけど平日は珍しいな）どうした」
友人「君のこと話したら、話してみたいという人がいて、食事でも」
自分「（2時間くらいか）いいよ、どこで」
予定していたことがあったのだが、会いたいというのも面白いと思い、予定していことは先送りして。
これはこれで締め切りがしんどくなるのだが。
待ち合わせ場所にいってみると若い風貌のひとと見間違えることもない友人の2人連れ。
自己紹介をしてお店に。
友人がいるから飲むのかもと予想をしていたら、案の定、友人はハイボールを飲むのだそうだ。じゃあ、いいかとこっちも輸入ものの瓶ビールを選ぶ。会いたいを言ってきた人は生ビール。
店員に促されてw、乾杯をしてから、つまみを。この会いたい人、チョイスが少し独特。面白いのでその人と友人に選択は任せる。
会いたいと言ってきた人の素性をバラせば、若者である。どこかで友人と繋がっていて、何かのきっかけで自分のことを知ったのか、友人が意図的に話したのか。
自分「それで何を話したい」
若者「いろいろとやられていますけど、直近で始められたのはどういった経緯で」
自分「以前経験していたことがあって、それを久しぶりに再開したら理由はわからないがいい塩梅に仕上がって、それを続けてやっていたら途中で失敗した。その失敗をみせたの、プロに。で、プロは一発で原因を見抜くんだね。で改善し続けたの。でもまだ勘でさ。それをエンジニアリングしたの。あとプロダクトマネジメント。で続けてる。それだけ」
若者「はあ」
友人「急にクオリティがね上がったね」
自分「やっている方は継続してやっているから自覚なしだけどさ」
このあと、ポツポツと話す若者の、脈絡のない質問にただ「若いな」と「このくらいの年齢なら自分のときよりも優秀なんだろうな」と頭を過った。
若者の質問を集めて、煮詰めると、自分は何をしたらいいか、ということのようだ。
若い時間が、一番勉強出来る。知識をためるにはいい時間。外に出て、体験をするにもいい時間。
気になることは自分で試してみるにもいい時間。
この２つだけ、話す。あれこれしろとか、長々と話したりしない。
結局、将来自分は何をしたらいいかの教えを欲しているのだろう。知らなければ、選べない、知るためには良い時間を持っている。人生で、一番多く持てるタイミング。
今までは誰かが選択肢を教えてくれた。
でも、これからは、自分で決め、結果を出す。きゅうに、ポンっとハンドルを渡された。
戸惑っているのだろうけど、これからは自分でハンドルを握り続ける。
道はどこかに繋がっているから
プロジェクトについて語り続けたい
プロジェクトマネジメントが好きだ。何を今更と思うかもしれない。まあ、ポジトクというやつである。ただ、PMBOKは版を重ねるごとに厚くなるし、どうしてそうしたかよくわからないこともするから、割とどうでもいい。
ああ、実はプロジェクトマネジメントが好きというよりは、プロジェクトマネージャのロールが好きなのかもしれない。とはいえ、あれこれとプロマネのロールであれこれ指示をするのは面倒臭い。自分でやってしまいたい。計画を作り、マイルストーンを置いて、ここまでにこれだけは最低限やろうと、バックログ的なものを決めてやるものはやり、できたらいいはなは無理してやらない。それでいい感じであれば満足だ。
じゃあ、チームは嫌いか。そんなことはない。相談できる、自分よりも優秀なエンジニアのいるチームはいい、バッサリと鉈で切り裂くくらいの切れ味がいい。笑顔なのに、不用意な質問を投げると鉈が頭の上から落ちてくる。マサカリなんてスピードがない。鉈だよ、エンジニアの装備は。そんなチームならいい。でも一からチームをビルドするのはやっぱり面倒だ。
じゃあ、チームは嫌いかだって。メンバのキャリアパスを一緒に考えるのは好きだ。あれこれ押し付けるのではなく、選択肢を示したり、伸ばす候補のスキルを確認したり、どの仕事で、どのロールで、どんなコンピテンシを伸ばすかの相談を受けるのは好きだ。さらに、メンバが成長して、なんなら自分を追い越すくらい優秀なメンバでもいい。キャリアでもプロジェクトでも制度設計でもプロセスをデザインし、自分で食べ、デザインを洗練させていくのも好きだ。プロセスデザインをできる人はだいぶ世の中に少なくなったらしいのだが、それが本当なら自分は絶滅希少職種かもしれない。大事にしてほしいものだ。
大事にして欲しいほど自分が好きかというと10代は大嫌いだった。学力もプアで知識も少なく、ただ、バイトだけには精を出していた。価値を見極められず、時間やお金を無駄にしてきた。じゃあ今も嫌いかというと、そんなことはない。50歳前あたりから、いや30歳後半からいい感じになってきた。もちろん、自分のキャリアをデザインし、ゆるくプロジェクト的に、でも継続的に、段階的に自分をマネジメントをしてきた。その結果がまあまあだな、という感じだ。
おや、やはりプロジェクトが好きだったのかもしれない。でももっと好きなのはワイフである。
言われたらそのとおりやらないといけない病
スケジュールを確認する前にメンバが席までやってきて、打ち合わせしましょうと打ち合わせスペースまで連行られる、そんなある日の午前中。
打ち合わせテーマは、テコ入れで首を突っ込んだプロジェクトの2つ目のアクテビティをどう進めたらいいかという相談。
どう進めようと思っているかを聞いてみると、うむー、どうしてそう思うとか、それはこっちで決めて仕舞えばいいじゃないかとか、アクテビティで扱うタイミングと対象のチャンクの話じゃないかとか、どっちでやったとしても結果は一緒だぞとか、ファシリはどっちが実現的かとか、思う。
一番気になったのは、インプットになる前工程のアクティビティの結果に対する、受け止め方である。
エンジニアに限らないのかもしれないが、ある場での結果と、そのある場の前に自分たちで想定していた仮の進め方と違うと、そのある場で決まったことを正として「変えられない」ものと捉える人がいる。
元々こうやって進めようと仮説、つまりこうやればうまくいくだろうと仮の進め方を組み立てていた。それが前工程で作業対象に一つ属性が加わった。
自分たちのやりたい結果は全く影響しない。ただ、途中のアクティビティでの取り扱う対象の単位を元々の粒度でいくか、それとも追加した属性でやるかという話でしかない。
相談してきたエンジニアは、追加した属性で後続のアクティビティをファシリしないといけないのだという。
でも、
・目指すゴールは変わらない
・追加した属性はチャンクの粒度であって階層が増えるだけ
・ファシリする裁量はこっち
なのであれば、追加した属性なんぞ、気にする必要はない。結果は変わらないのだから。
これがゴールを変えるほどのインパクトのある観点だったら、後続のアクティビティlを見直す必要があったかもしれない。
でもそんな影響は1ミリもない。制約を自分から掛ける意味はない。無駄。
誰かが何かを言ったらそれを全部汲み取る必要があるかどうか。それを考えられない。そんな考えを持っているから、自分で書いた筋書き通りに進まないのである。
ゴールに影響するなら話は別で、どこまでどう対応するか筋書きを書き直しなければいけない。
でも、そうでないのなら、いちいち対応しなくて良い。これが処方箋。
そういう判断をしてもいいという考え方を持っていないと、とても辛いと思う。
習慣化の6つのステップと習熟度の6のステップ
習慣化にすることと習熟度を上げて上手になって行くことは別のステップを踏むと思う。どうして別と考えているかというと、習慣化だけでは上手にならないからである。
例を挙げれば、運動したいからフィットネスジムに行くことに決めて、マシントレーニングを始めたとしても効果を得られる適切なフォームを身につけられるとは限らない。
まずは継続して通わなければならない。継続して通い、さらにマシントレーニングを続けた結果、得られる自分の将来像に近づくために適切なフォームと今の自分のフォームを比べて適切なフォームに近づけてることが必要になる。
習慣化と習熟度は（自分の中では）次のステップを踏む。
習慣化
・興味を持つ
・試してみる
・できるようになってみたいと思う
・決まった時間にやることのする
・やらないと居心地悪くなるまでやる
・習慣化完了
習熟度
・やってみる
・手本（イメージ）と違う
・手順を確認する → やってみる
・計測する
・ギャップを見つける
・できる人に聞く → やってみる
習慣化だけで止まってしまうと、いわゆる下手の横好きになってしまう。そうしないため、ではなく、自分のイメージするできるという状態にしたい。
このできる状態とは、自分で結果をコントロールできるというニュアンスになる。ここまで仕上げたいとか、ここまでやらないと終われないというようなものだ。
習熟度を上げていくポイントは2つ。
計測、つまり客観的な視点を持てるかと、できる先人、プロに聞き、フィードバックも中から取り入れることである。
計測は自分一人でできる。ただ、計測して少しずつ変えて効果を確かめても限界がある。例えば1つ変えて良くなったとしてもその理由がわからないときがある。1人での限界は知識量なのである。
そこで先人、プロに教えてもらう。
話は飛んでしまうが、自分を変えたければ付き合う人を変えなさいというのは、こういったところに効いてくる。
プロジェクトマネジメント講座について
講座について
この講座は、プロジェクトマネジメントを学ぶ講座である。この講座では、プロジェクトマネジメントおよびプロジェクトマネジメントに関連するコンテンツを取り上げることもある。
受講の目的
この講座を受講することで、プロジェクトマネジメントの知識を得て、実践する際に受講者の助けとなる。
想定する受講者
この講座の受講者は、プロジェクトマネジメントについて知識を得たい人を受講対象とする。具体的なペルソナには、事業会社の企画部門、IT企業でプロジェクトマネジメントを実践する人などである。
免責事項
この講座で得た知識を実践したからといって、必ずしもプロジェクトマネジメントを遂行できるコンピテンシを身につけられるとは限らない。講座の受講程度でプロジェクトマネジメントのコンピテンシを身につけられ、実践でき、プロジェクトを成功させられるなら、様々な調査でプロジェクトの成功率があれほど低いわけがない。そういうことである。
目次
目次を次に示すが、当初の構成と違うことが想定される。細かいことは気にしないこと。
- 用語定義
・プロジェクト
・プロジェクトマネジメント - プロジェクトとは
・プロジェクトがなければプロジェクトマネジメントはいらない - プロジェクトをデザインする
・チームを編成する
・チーム内での役割を定義する
・要件を決める
・制約条件を列挙する
・前提条件を列挙する
・アウトプットを決めるまたは仮定する
・アウトプットを分解する
・分解した部品のスペックを決める
・分解した部品を実現する手法を確立する
・試作し、基準規模を計測する
・部品を実現する規模を見積もる
・付帯作業を列挙する
・付帯作業のアウトプットを決める
・付帯作業の仕様を決める
・付帯作業の規模を見積もる
・マイルストーンを設定する
・部品・付帯作業をスケジューリングする
・部品、要件の検証基準を定める
・部品を製造する
・部品の機能を検証する
・部品を再構成する
・アウトプットの要件を検証する
・プロジェクトを終了する - プロジェクトマネジメント
次に記載する事項を定め、プロジェクトに組み込む。
・プロジェクトの目的を言語化する
・要件から定量的または定性的目標を言語化する
・スコープを登録する
・会議体を設計する
・品質を設計する
・人的リソースを調達する
・リソースを調達する
・リスクを識別、評価、対応策を策定する
・定量的または定性的目標のモニタリングサイクルを定義する
・定量的または定性的目標のモニタリング要件にプロジェクトの部品の単位を合わせる
・モニタリング方法を確立する
・モニタリングで較差の発生時は、分析、影響、対応策を検討、実施する
・スコープの変更を行う場合は、変更の実施評価を行う
・会議体に従いレポーティングする
・品質を検証する
理解度テスト
この講座を受講後には理解度テストを受講する。テストの理解度が低い場合、再受講を義務付ける。
などと講座の目次の各項目の内容を考えただけで、テキスト化にうんざりする。
ここに記載していない別の切り口の2つの視点が追加で必要で、それもボリュームが大きい。
もともと、ボリュームが大きい講座テーマで、何十年の集大成でもあるから、講座程度に収まるわけがない。講座と称して、別の方法で経験できなければ受講者は途中で離脱してしまうだろう。
