将来の技術的負債を作らないチーム作り

マネージャやプロジェクトマネージャがプロジェクトメンバを調達し、アサイメントする際に犯してしまう間違い…それは頭数を揃えてしまうことです。

プロジェクトマネジメントとしてプロジェクトの目的を達成するためには、プロジェクトの目的達成でのアウトプットを作成するために必要とするスキルセットを持っているリソースを調達しなければなりません。もちろん、リソースにはIT機器や人的リソースが含まれています。

マネージャやプロジェクトマネージャは、プロジェクトの立ち上げの準備作業で多忙という言い訳をしてプロジェクトチームとして必要なスキルとスキルレベルを充足するメンバを集めるまでを考慮せず、その手前の人数だけで揃えてしまうのです。これが間違いであり、プロジェクトチームに見積もりやプロジェクト計画で考慮されていないリスクを潜在的に抱え込ませることになるのです。

こうしたエンジニアの調達をどこかで見かけた記憶はありませんか。

そう、大規模プロジェクトの多重契約で見かける風景です。javaが書けるということになっているエンジニアを頭数だけ揃えて、あとはプロジェクトで教育してください、というやつです。これがどれだけプロジェクトにリスクを持ち込んでいるか、将来の技術的負債を持ち込んでいるかわかっているかを小1時間問い詰めたいし、負債解消のためのコスト負担を請求させて欲しいくらいです。 

どっちのチームがお好み

あなたがプロジェクトマネージャだとして、次のどちらのチームでプロジェクトを回したいですか。

  1. プロジェクト計画の見積もりで必要なエンジニアの頭数を揃えたチーム
  2. プロジェクト計画で必要なスキルセットの充足には一部足らないが精鋭なチーム

 個人的には項番2を選択しますが皆さんはどちらを選びましたか。

心理的に必要とするリソースを埋めたくなるのはわかります。でも、どちらを選ぶにしてもメリットデメリットがあるわけです。

将来の技術的負債には何があるか

 チーム1の将来の技術的負債にはどのようなことがそうてできるでしょうか。

  • チームとして必要とするスキルとスキルレベルを充足できない。
  • スキルとレベルに満たないエンジニアの教育コストが追加でかかる
  • スキルとレベルに満たないエンジニアのフォローのためにコミュニケーションコストが積み上がる
  • スキルとレベルに満たないエンジニアのフォローのためにできるエンジニアのリソースを使ってしまい進捗が出ない
  • メンバ別のスキルとレベルに満たないエンジニアのアウトプットがプロジェクトの品質目標に満たず修正コストが積み増す
  • スキルとレベルが足らないエンジニアの成果に対し、期待していた成果分のキャッシュアウトが発生する

将来の技術的負債の観点で抽出しているのでデメリットばかりです。スキルとスキルレベルが未達でも投入せざるを得ないケースも組織的な戦略上取らなければならないケースもあります。それは若手や技術転換などのエンジニアの育成です。このケースの場合は、組織からの財政的支援やKPI的な数値の引き下げなど組織的なサポートを考慮しつつそれでも行われるのは教育なので将来の投資の観点があり、将来的にはプラスになることを期待するからです。

 

チーム2の技術的負債で考えられることは何でしょうか。

 

  • プロジェクトチームとして必要とするスキルとレベルが不足した状況で運営せざるを得ない。
  • 進捗はメンバのスキルとレベルが充足される場合と比較して遅れる。
  • メンバに負荷が掛かる。

 

 でも、このくらいなんですよ。ここのエンジニアに対してのスキルレベルが必要とする分だけは充足されているので作成するアウトプットの品質は期待できます。

遅れることを是としてスケジュールを引けば、ですが。

さらに、低レベルなエンジニアが混入してこないのでコミュニケーションコストは想定の範囲で済みますし、期待するスキルとレベルを持っているのでフォローアップは必要ないので想定外のコストを払い出す必要もありません。

進捗についてさらに言えば、チームに必要とするフルなリソースでの計画に対して、足らない分だけの遅延で済みます。

将来の技術的負債を作らないチーム作りのメリット

育成以外であれば、無理して適切でないエンジニアをよそから持ってこない方がプロジェクト最適化の考えからいえば、ベターな判断です。

とはいえ、全く途中でエンジニアを補充しないのもアレです。基本的にはマネージャやプロジェクトマネージャは、不足した状態でプロジェクトを始めるなら、それでできる範囲でのスケジュールを引いてステークホルダと協議し、受けれてもわなければなりません。

ただ遅れるよという伝え方もありますが、プロジェクトの計画を多段階にする(=ステップ分けをする)など見せ方の工夫もできますし、全機能のリリースリミットを伸ばせるなら、人的リソースの面積は伸ばした方が品質管理上の観点からも合理的です。

まあ、その際には段階的リリースをすることでのメリットを前面に持ってくることが必要でしょうが。

 

 

人材開発研究大全

人材開発研究大全

 

 

後任のリーダをどう育てるか

プロジェクトマネージャもマネージャも、そしてSEリーダでさえ、常時、後任を育てなければならない。後任になる候補がいないならその仕事から抜けることを考えるか、ビジネスを育てて後任候補をアサインしてもらえるところから始める必要があるの。

なぜ後任を育てる必要があるかは、これまでのどこかのエントリに書いてきたので割愛するとして、後任をどう育てるかを考える。

多くのリーダは、頭では後任や後進育成(こちらの方が対象が多くなる)が必要なことはわかっているけれど、実務のやりくりの中で後任を育成することについては全くもって手につかない状態のままだ。

なぜなら、後任育成についてのメリットを体感していないことと後任育成で手に入れられる価値の大きさをわかっていないから。

もうひとつある。リーダ役のエンジニアが後任を育てないのは、そのポジションの居心地がよく、居座るつもりだからだ。

このパターンのリーダの下についたメンバは、そうであることを察したら早々に配置転換をマネージャに伝え、出ていくことを考えた方がいい。そうでなければ都合よく使われて、しかも、他で通用しない古く、適用力のない業務しか身につけられないからだ。

話を戻して、後任をどう育てるか。

リーダである自分自身が育ってきたことをそのまま繰り返そうとするリーダが少なくないが、それはそれで育ってきたリーダが適用できただけで、これから育てようとする後任がフィットするかはわからない。

ひとつ確認しておきたいことは、リーダは人に教えをする技術を身につけているかどうか、である。教えることの技術を持ち合わせていなければ、自分の体験を後任に同じようにしたとしてもリーダのようにリーダとして育つと思ってはいけない。多くの場合は、育てられた経験は反面教師であることが多い。

後任を候補として育てるのであれば、次のことを行うことを検討してほしい。 

  • 期待する後任の範囲を対面で伝える。
  • 後任候補として担当する作業。特に、後任候補として増やす担当業務の部分。

特に配慮したいところは、後任候補として増やす担当業務がリーダの仕事の中で中核の業務に位置付けられているかどうか。ここを考えずに作業を増やすと単に都合よく使われている感が増すばかりだ。

更に言えば、実際、リーダが中長期で不在になったケースを想定したときに業務が回るかどうか、である。この観点で渡す業務が適切かをテストすればいいのである。

もし、業務が滞るようであれば、それは担当させている業務が適切でないということだ。

もうひとつ。マイクロマネジメントにならないように=仕事の仕方を考え、自主的に完了させるために、仕事の目的と完了状態を伝えることを忘れずに。 

 

 

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

 

 

know your project!! (己のプロジェクトを知れ)

ものの例えで話を始めると、潜水艦が潜行しているときには計画した通りの航路で進みながら、様々な計器を使用して安全を確かめる必要があります。

#軍事専門家から見た時の表現的な誤りはご容赦

これ、何かに類似していますよね。そう、システム開発のプロジェクトそのものです。

ではどうして潜水艦の先行ではそうなってしまうかというと、視認できないからです。浮上していればハッチから出て確認すれば見ている海面より上は視認できますけど、相変わらず海面下はね、計器頼みな訳です。

元々が潜行して航行することを目的として建造されているのですから、常時海面に出ているわけにはいかないので。で、潜行するとまた計器頼みに。

一方のシステム開発は、プロジェクト計画書という計画した航路に沿って設計書を作成し、顧客と合意しつつコードを書くわけですが実際の動くシステムが組みあがらないとどんなシステムになっているのか誰も知らないのです。

いやいや、エンジニアは知っているじゃないか。だって自分たちで設計して、コーディングをしているんだろう、と、エンジニア以外の人は思っているんですよ。

でも、実は誰もどんなシステムに構成されるのか知らないわけです。

なぜなら、分業をしているから。

ただ、分業をしているからばかりじゃない。プロジェクトマネージャ以外は、誰もプロジェクトを知らないから、誰一人どんなシステムを作ろうとしているか知らないのです。

そしてプロジェクトマネージャもエンジニアにどんなシステムを作らなければならないのかを仔細に話をしないし、繰り返し説明もしない。

さて、これでプロジェクトという潜水艦に乗ったクルーを担うエンジニアと艦長のプロジェクトマネージャは航路の計画(プロジェクト計画書)どおりに計器頼みで安全に目的地に進むことができると思いますか。

航路の計画もただ海図に出発地と目的地に直線を引いいて進めばいいわけじゃないのです。湾内であれば決められた航路があるものだし、それは水深が浅いところがあって座礁しないように配慮されているという理由があったりするからです。

湾外に出たとしても同じように海中の隆起や他の船舶との衝突を避けて運行しなければならないわけです。

決められた航路はプラクティスや法律での制約と同じようなものだし、湾外での機器による検知はリスクマネジメントのようなものです。

f:id:fumisan:20171123105727j:plain

know your boat!! (己の艦を知れ)

ならぬ、

know your project!! (己のプロジェクトを知れ)

なのではないか、と。

 

今のエンジニアはプロジェクトを安全に進度させたいと願っているなら、まず初めにしなければならないのは know your project!! なのではないでしょうか。

まあ、プロジェクトマネージャも繰り返し説明してエンジニアが期待する成果を出すようにしろよ、ってところですけどね。

 

 

米海軍で屈指の潜水艦艦長による「最強組織」の作り方

米海軍で屈指の潜水艦艦長による「最強組織」の作り方

 

 

 

 

エンジニアの評価はマネージャに見えていた残像でされている

エンジニアの業績評価は難しいのです。何せ、誰一人として同じ仕事をしていないところで、1年分の労働に対する貢献度を評価しなければならないのですから。

評価方法と言えるかどうかも怪しいですが、それぞれの組織においてエンジニアの業績方法は通常、人事担当が主務として構成し、それをマネージャに指示するのが一般的でしょう。

エンジニアの業績評価での問題点というか曖昧さが生じる事項は次のようなものが挙げられます。

  1. 同じ仕事でないエンジニアを1つの評価基準で評価しようとしていること
  2. エンジニアの仕事をマネージャが全て知っているわけではないということ
  3. エンジニア個人の絶対評価と組織の中での相対評価の2軸があること
  4. 評価結果は次年度予算に組み込まれるので評価の上限があること
  5. マネージャは人の評価方法を知らないこと

 

同じ仕事でないエンジニアを1つの評価基準で評価しようとしていること

製造業で、同じラインで働いているなら、 評価もしやすいでしょう。生産計画に従った生産量を確保でき、期待する品質を確保できるような監視と予防活動に取り組み、後進を指導し、勤怠も問題なければプラスの評価をされるでしょう。

ものを作ることには変わりはないですが、エンジニアは一人ひとりの作業が違います。まあ、大規模プロジェクトで同一サブシステムの機能を分担してプログラムを書くようなケースは割とニアリーイコールかもしれませんがやはり担当する機能の難易度が同じということはないです。何かしら違うので。

つまり、評価対象であるエンジニアの業務の成果は一品ものなのだ、という評価対象が違うというところの理解が必要です。

エンジニアの仕事をマネージャが全て知っているわけではないということ

 標題のとおり、エンジニアの仕事をマネージャが全部知っているわけではないです。マネージャもプロジェクトにどっぷり入って、プロマネ=マネージャのようなアサイメントなら割と知っているかもしれませんが、それでもやはり、エンジニアのひとつ一つの成果までは知りようがありません。断片的に、進捗や品質評価でしか知りようがないのです。

エンジニア個人の絶対評価と組織の中での相対評価の2軸があること

 エンジニアの成果の評価は、個人の成果を評価する軸とそれを組織の中での貢献度合いを評価する2つの軸で評価するケースが多いです。なぜなら、前者だけで評価をしてしまうと、エンジニアの評価がインフレを起こしやすいからです。

どういうことかというと、評価項目に対して達成したかどうかになるのでやったと言いやすいし、エビデンスとしての成果が提示できれば評価せざるを得ないからです。

一方、組織としては有能なエンジニアは上に引っ張り挙げたいので序列をしたくなるのです。結果的に相対評価が必要になります。

評価結果は次年度予算に組み込まれるので評価の上限があること

 エンジニアの対価は予算措置をされた上で支払われています。つまり、前年の評価を考慮し、昇給を反映した上で労務費を計上しているわけです。

逆に言えば、労務費の予算枠があるよ、それ以上は評価=昇給はできないよということです。

いくらエンジニアが評価しろ、昇給させろと言っても枠でキャップがかかるのでその中で調整が組織全体で入るよということです。

マネージャは人の評価方法を知らないこと

これが一番の問題なのですけれど…マネージャが正しい業績評価の手法を学び、習得しているなんて思ってはいけません。

例えば、オリジナルだとしても評価方法を持って、その評価方法で評価しているマネージャなんて一握りくらいなものです。ちなみに、これまでそうした評価方法をしているマネージャは一人を除いて聞いたことはありません。

つまり、エンジニアの評価はマネージャの印象で評価されているのです。これは、エンジニア同士の評価であっても同じです。基本的には持っている情報若しくは提供される情報の範囲だけで主観により評価されているのです。

問題だと思うことは、印象で評価をすることになるのでマネージャに見えているエンジニアほど良くも悪くも評価を受けやすいということです。マネージャが評価方法を持っていて、評価項目からエンジニアを見る場合は全てのエンジニアを評価項目の視点で見ようとするので同じ評価軸で評価する方向に働きますが、エンジニアの見えている部分だけで評価するマネージャはマネージャに対する見え方でバイアスが強く掛かるので評価軸で評価するマネージャとは違う評価結果を出します。

マネージャの見え方で評価しているから労働時間が長いエンジニアや炎上させて周りを巻き込んで鎮火に到るまで残ったエンジニアが評価をされるのです。

違いますよね。本来であれば、

 実現できたエンジニアを評価しなければなりません。

 

こういったことも一切合切含めてそういうものだ、と思えるくらいの評価をしてくれるマネージャなら当たりなんだと思います。 

滅多にいませんが。

 

 

氷菓 (角川文庫)

氷菓 (角川文庫)

 
ピーターの法則 創造的無能のすすめ

ピーターの法則 創造的無能のすすめ

 

 

 

 

プロジェクトマネジメントは誰のものか

最近立ち上がった勉強会での一コマ。

 

「若いうちからプロジェクトマネージャにアサインするケースがあるじゃないですか。でも、プロジェクトマネジメントの全体をわかっているわけではないので、日々の転がしで精一杯なんですよ。そう言う状況で経営にも報告しなければならないのって、すごく無理がありませんか」

「プロジェクトマネジメント自体が経営者のものだからねぇ。経営の見通しをするために進捗中のプロジェクトの健全性を把握するためのツールだし」

「そこにたどり着くまでにどれだけ時間が掛かるか…」

「プロジェクトマネジメントは経営のものだという前提に立って、経営に報告するためのインタフェースがレポートに当たるわけで。プログラムと同じでインタフェースのお作法は守らないと通信できないでしょう。だから、進捗管理をレポートに合わせられるメッシュでデータを持っておく必要があるし、そうしておかないとレポート用にリソースを割かなければならなくなってしまうんだなぁ」

 

プロジェクトマネージャになるとやらなければならないことがそれこそPMBOKに書いている知識エリア以上のことをやらなければならないので。

現場のチームを向けば、システム開発手法による実際のものづくりを進めなければならないし、それこそプロジェクトを経営者の代行としてマネジメントしなければならないので。

場合によってはプレイングマネージャだったりすると、一部のリソースはエンジニアとしての自分に振り分けなければならないことになってしまうので。

3つも帽子を被ろうとすると、それはそれで無理が出てくるわけです。だからプロジェクトマネージャは専任に、と言うよりはエンジニアとは分離せよ、なのだと思うのですが。

 

話はさらに続きます。

 

「経営がアジャイルでやろうとか、どこで齧ってきたのか突然バズワードを言い始めることがありますよね」

「世間ではあるようですね」

「どうですか」

「どうなんです、そちらでは」

「やばいですね。手段が目的…もあるんですが、プロジェクトのレポートをみて『アジャイルじゃダメか』とか」

ウォーターフォールの事故数の方が積算では絶対数が多いいのにね」

「そうなんですよ」

「だから小さく、成功度合いの高いプロジェクトから適用しないといけないと言われるんだよね」

 

新しい手法に好感を持っていたり、広めたいと思っていたら成功させたいと思うことは当然です。失敗するとそこから学ぼうとする経営でなければ打ち切られて、2度と採用できなくなってしまいますから。

じゃあウォーターフォールはどうなんだと。

 

アジャイルには標準がないと思うんですけど、何かテンプレートになるものがないですか」

「みんな誤解をしていると思うんだけど、ウォーターフォールだって標準ってないですよ。亜種ばっかり」

「そんなことはないのでは。エンジニアは誰でも知っているじゃないですか。それに特段、学習しなくてもウォーターフォールで開発を始められますよね」

「それは、エンジニアが過去に経験してきた経験知で予測して対応しているだけの世界ですよ。それが成り立たない上でのプロジェクトはすぐに崩壊してしまうんです」

 

結局、何かしらこれがテンプレートだと一旦仮置きしてそれをその組織の標準とするか、手続きのプロシージャだけを決めておくしかないのではないかと。

まあ、これがテンプレとできるくらいなら、ウォーターフォールであって当然なんだけれどどれだけあるんだろうなぁと思っているうちに、勉強会は続くことが決まったようでした。

さて、大元のプロジェクトマネージャはどう育てるのかしら。

 

 

学習する組織――システム思考で未来を創造する

学習する組織――システム思考で未来を創造する

 

 

生きる失敗、無駄な失敗

振り返ると30代半ばまでの失敗はその失敗を生かすことができなかった「無駄な失敗」だったと思うのです。30代半ばがひとつのターニングポイントなのでそこからは全部が無駄な失敗ではなく、なんとか、そこそこにその失敗を生かせているのではないか、と。

生きる失敗

 生きる失敗としているのは、進捗させてみたら想定していたとおりにならない状態になってもその作業期間のお終いにはなんらかの修正をすることで失敗したことを作業期間内にフィードバックして別の手段を考えるように方向転換したりするケース。

別のパターンは、がっつりと心に2度と繰り返したくないほどの、謂わばトラウマのような失敗をして、同じリスクに対する感度を目一杯あげて同じようなケースの場面に遭遇したときには、2度と繰り返したくない経験を引っ張り出してきて同じ轍を踏まないようにすることかと。

前者の小さな失敗は、その作業内で上手くいかないことを経験的に識別して、別の選択肢にスイッチすることで辻褄を合わせる感じです。大事なことは、上手くいっているか、ダメダメそうなのかの判断ポイントの見極めです。

この判断をすると言うことに全力をかけておかないと、ズルズルと引っ張ってしまい、終いにはリカバリできなくなってしまうのです。そうならないように、どこまで我慢するか、スパッとスイッチするかは悩みそうなら、作業を始める前に決めておき、我慢し過ぎたり、逆に効果を得られる前に間違った判断をしないようにすることは気に留めておいた方が良いです。

 

無駄な失敗

 生きる失敗の真逆といってしまえば簡単でそれっぽいですが、実はそうじゃないのです。

まず、無駄な失敗とは失敗している状態で終わりにしてしまうことです。もちろん、プロジェクトを失敗したと組織が判断してプロジェクトを中止してしまったら何かしらの失敗があったと言うことですし、バサっと突然に終わることの方が多いのでそうしたケースでは取り戻すためのスイッチなり、後続する工程で修正策を行うことができません。

これはプロジェクトの特性としての有期限性のためなので、それはそう言うものだ、としておきます。

ではどうするのかといえば、失敗してしまったことの当事者として次はどうするのかと言うことを行動に移せるか移せないかが無駄な失敗にしてしまうかどうかの判断ポイントなのです。

失敗した当事者として、失敗した様々な要因を分解して、どこの判断からの積み重ねで方向を間違っていったのか。これを人が判断したからとしてしまうのもまた無駄な失敗となってしまいます。

しなければならないのはどこから判断を間違え続けたかの起点を探すこととどんな情報でどんな判断基準で判断をしたか、定量的にすることが無駄な失敗のままにしておくか、生きる失敗に質を変えるかの分岐点になります。

 

 

失敗はしていい、小さな失敗をたくさんしようと言うのは失敗のままにしておかないことを前提としているのです。

穿った見方をすれば、結局、コントロールできる範囲の持ち方の捉え方で辻褄を合わせているだけなのですけれど、そのくらいでないとオチオチと失敗できないので、このくらいのゆるさでいいのですよね。

 

 

 

仕事は楽しいかね?

仕事は楽しいかね?

 
失敗の本質―日本軍の組織論的研究 (中公文庫)

失敗の本質―日本軍の組織論的研究 (中公文庫)

 
システムを「外注」するときに読む本

システムを「外注」するときに読む本