エンジニアが無能なプロジェクトマネージャから身を守るためには
これまでエンジニアのスキルには、エンジニア自身を形成する基礎スキルと技術スキルの2つの軸があると述べてきた。過去ログを調べるのが面倒な人向けにおさらいすると、基礎スキルと技術スキルは次のとおりだ。
- 基礎スキル…問題提起、課題抽出、ゴール設定、解決方法のアプローチ、解決の推進力、チーミング、プロジェクトマネジメント力、交渉力、課題解決に対するマインドなど
- 技術スキル…方法論、アプローチ、手法、プログラム言語、適用時術など問題解決を実現する技能
エンジニアのキャリアを経るに従い、身につけるスキルのウエイトは変わっていく。
基礎スキル ＜ 技術スキル → 基礎スキル ＞ 技術スキル
技術スキルの技能は、とてもわかりやすい。手法を身につけ、実践の場で適用し、アウトプットしているかで判別できる。一方、基礎スキルは定性的で、身につけた基礎スキルを発揮しているのかどうか、わかりづらい。例えば、プロジェクトマネジメント力は、プロジェクトマネジメント自体は手法で、技術スキルであるが、それを活用してプロジェクトをキャリーする実行能力は基礎スキルで求められる。
ところで、この基礎スキルと技術スキルには共通項がある。
技術スキルとしてのプロジェクトマネジメントは、プロジェクトをマネジメントするときに必要なプロジェクトのリスクコントロールの方法論である。プロジェクトマネジメントと言えばPMBOKであるが、PMBOKはプロジェクトをコントロールするプロセスの定義とフローになっている。
基礎スキルのプロジェクトマネジメント力は、プロジェクトを推進する能力であるから、プロジェクトのゴールを実現するプロセスをプロジェクトマネジメントの観点からリスクコントロールするためにデザインする。
技術スキルはモデルのプロセスであり、基礎スキルは現実の対象に合わせたプロセスである。
プロジェクトの開発手法の違いでの成功率などは、プロジェクトの特性をろくに考慮せずに適用したことが原因であるが、適用した開発手法のプロセスの理解も知識も十分でないままに実行策としてやってしまったことが直接の原因である。
とは言え、システム開発のプロセスを定義した標準的なモデルが世の中には存在しない。ウォーターフォールもアジャイル開発（多くの手法があるが）も、同じだ。組織によっては、組織の中で標準化をしているところもあるが、あくまでも『組織の中で』である。それらは組織の集合知をまとめたものだから、組織ごとに名前がついていたりするし、実際に適用するときにはもれなくプロジェクトに合わせてテーラリングすることを要求している。
共通項というのは、標準なプロセスと標準なプロセスを適用するためには、プロセスがキーであり、ゴールを実現するプロセスを見極められなければ上手くいく確率を下げてしまう。
プロセスと聞くと標準を押し付けられたり、手続きが多くてやりたくないと脊髄反射するのは、開発手法の選定、テーラリングが間違っているか不十分なのが原因なプロジェクトばかり参画していたからだ。
そうした被害を受けたくなければ、エンジニア自身が技術スキルと基礎スキルでプロセスを学び、プロセスの実行能力をあげる必要がある。それを無能なプロマネに任せていると…。
キャリアの悩みには壁打ちがいい
エンジニアのキャリア、業務経歴を聞いていると誰一人同じことはない。壁打ちしたいというエンジニアのキャリアは割と悲喜交々、少しだけ悲が多いようで、いや、だから壁役を欲しているのかもしれない。
組織のエンジニアは部下になるから、キャリアの相談は仕事の内だ。ただ、マネージャ全員がそう思っているかと言えばそうでもないようだ。
あるグローバルなエンジニアの組織では、ローテーションが早く、マネージャもエンジニアもグルグルと回るため、マネージャは担当事業にフォーカスし過ぎて、エンジニアの育成には関心がないとエンジニア目線では見えている。
だからか、壁打ちの壁役を引き受けて欲しいとエンジニアは言う。
個室の居酒屋で話を傾聴する。これまでの経験を業務経歴書をなぞるように、丁寧に。壁に向かって呟けば、同じ言葉をリピートし、壁へのつぶやきを受け止めているとリアクションする。
自分の経歴と共通項があれば、その辺りは同じだと、タイミングを見て差し込む。壁とは言え、一方的に聞いているのではなく、壁に向かって嘆きたい、誰にも自慢できないと思っているキャリアのところどころが重なっていると伝える。
傷を舐め合うためではなく、かわいそうだと思うわけでもなく、ただ、共通項があることで、心理的な距離感を縮める目的で。
傾聴している間、いや、会計をして改札に吸い込まれるまで、一切の否定や壁側の意見は押し付けない。壁に嘆き、頭の中でどうしようか迷い迷っていて、でも、内心、方向性への確信はあり、その背中を押して欲しいと思っている。
エンジニアのキャリアは組織の都合と本人の希望の積み重ねだ。しかし、これからのキャリアの方向性を意識して、自分で決めることはできる。実際に組織の中で自分で決めた方向性の担当職に配置されるかは別であるが、willを持っていなければ組織に都合よく使われるだけだ。機会を作り、機会を手に入れられるのは、意思を持っているかどうかにかかっている。
良い壁役は、メモをとる。アナログでもデジタルでも構わないが、テキストエディタのようなものよりは、スタイラスペンで描くほうが良い。
タブレットなら、壁へのつぶやきのポイント、キャリアの方向性、選択肢、将来像などピボットしやすい分岐点にマークを入れて確認しながら聴ける。
壁役を欲しいのは、将来をよくしたいからだ。過去を嘆いているなら今はよくなっているし、今を嘆いているなら過去はよかったのだ。でもどちらも変えられない。変えられるのは自分の将来だけだ。
だから、壁はアクティブに聴き、メモを残しながら、将来どうしたいのかを聞く。将来像があるのか、野望があるのか、そうしたことをディティールアップしながら書き残していく。
エンジニアは多くの情報から必要な情報を整理するのが上手い。仕事で実践させられるからだ。ただ、ことが自分に向くと話が変わってくる。頭の中で妄想だけループして希望しない選択肢だけが記憶にこびりつく。
だから、壁は何が頭の中に入っているかを可視化する。壁役なのに聞いていることをグラフィックレコードしない壁は願い下げしたほうがいい。
壁に嘆きながらも将来像を聴き始めると考え始める。記憶からどうしたいかを自問し始める。誰も将来のことはわからない。ただ、そうありたいことに対して解像度をあげられるのだ。
壁は将来の解像度をあげる役だ。
だからその補助にグラフィックレコードとしてメモが必要になる。
壁打ちをしたいエンジニアが自身で嘆きたかったことと将来を語りきったとき、終わりの時間だ。その場でグラフィックレコードを共有する。
壁役もそこで終わりである。
壁打ちをしたければ、組織外の人のほうがいい。利害関係はなく、恣意も働かず、ニュートラルに、ひたすら聞いてもらえる人に。
ペアワークした話
あるエンジニアは、ホスピタリティが高く、システム運用業務ではトラブルの相談があると最優先に対処してくれている。当然、トラブって相談に来ているエンジニアからの信頼は厚い。
そのエンジニアの担当業務は、まずまず進捗するから実行能力は高いと評価していて、そのエンジニアがいないと業務が回らない。
さて、このエンジニアをあなたなら、どう評価し、どのようなロールまで任せられると思うか。
もちろん、上述で書いていない情報もあるし、実際に仕事を一緒にしたり、職場の風景として記憶を持っているわけではないから想像しづらいかも知れない。まあ、設問をするくらいだから、その辺りは何かしらあるのだろうと察することもできるかもしれない。
今思えば、おかしいと気づき、アセスメントして、コンピテンシレベルを見極められていれば、その分、リカバリもその分早くできたのかも知れなかった。
要点を並べれば、こんな感じだ。
・中堅エンジニアとしてはベテラン（上の年齢）
・コミットメント、目標達成への思いは強い
・ホスピタリティは高い
・実行能力は高い
しかし、エンジニアのその人を形成する基礎スキルのうち、
・課題設定能力は低い
・ゴール（成果物）設定が不十分
・課題解決のアプローチが組み立てられない
・ゴールから逆算した成果物への復元プロセスをデザインできない
などなどある。
Sierの感覚で言えば、上流設計の作業プロセスのデザイン、規模は小さくてもいいから自分でプロジェクトを回せられる程度のスキルセットを持ち合わせていればいい。
エンジニアの誰もがSIerに属しているわけではないし、ベテランのエンジニアであっても上流設計を経験しているわけでもない。エンジニアが100人いればキャリアも100通りである。
それを踏まえても、例え上流設計を経験したことがないとしても、課題設定やゴール設定は自分のアクティビティで日常的に経験しているし、段取りやスケジュールは引いて仕事をしてる。
ここまで読むと、じゃあ、そのエンジニアをどうしたかと言うと、プロジェクトのリーダからは降ろさず、続けてもらった。もちろん本人のwillもあってのことだが。
それで、結局、プロジェクトの筋書き作りをペアワークしたのである。
大きな枠だけ描いて、枠ごとのゴール設定、課題設定のアプローチ、ゴール（成果物）の分解、作業分解、入力情報、処理、分解したゴールと紐付け、マイルストーン、個別作業の作業手法などの観点を話して、それのオブジェクトは何かを考えさせ、言葉や図式化させるのである。
それをペアワークと呼ぶかどうかは怪しいが、それでも2人で成果を得られ、スキル的なジュニアなエンジニアがスキルのキャッチアップができるならそれをペアワークを称したい。
ウォーターフォールをやめて失敗する組織
ウォーターフォールしかやってこなかった組織がagile開発を取り入れることを決めたら、組織は非連続な成長を選択したことを理解しないといけない。
カンバンを取り入れたとき、開発チームの閉塞感やプロジェクトの進捗のオーバーランにテコ入れするだけでは無く、結果的にチームの価値観を変えることになった。機能しないWBSやウォーターフォールをチームに中では捨てて、価値のあるアクティビティから終わらせる意思決定をすることになった。
価値のある（と思う）アクティビティをチームで終わらせていく。進捗上の障害があり、ものづくりのアクティビティに手をつけるより価値があるなら、その障害を取り除くアクティビティに優先順位を高くつけて、それにリソースを回す判断をする。もちろん、アクティビティを選ぶのはチームだ。
それまではプロジェクトマネージャが工程を切り、WBSの大レベルをポンとおいてチームのそれぞれの担当が納期に実現性を考慮したのかわからないままスケジュールとしていた。
こう書くとまるでウォーターフォールが悪者みたいだが、そうではない。そのプロジェクトの特性に適合したシステム開発手法を選ぶ選択肢を持ちわせていない組織が成長を自ら捨てたからである。
これまでも、これからもスコープがフィックスしている、労働集約型の特性を持ったプロジェクトであるならウォーターフォールで連続した成長を続ければいい。これは組織としてもとても楽である。同じ開発手法を採用し続けられるので、意思決定の基準を変えることを求められないし、その必要性もない。
何しろ、価値はスコープの実現であるから、そこに集中する。スコープを実現さえすればいい。コミットメントはそこに集中する。だからプロジェクト計画を網羅的に作らなければプロジェクトのスタートの許可を得られないし、始まれば進捗は計測され乖離し始めるとPMOおじさんがやってくる。
スコープが不確かなプロジェクトであれば、それにフィットする開発手法を選ばなければならない。スコープが定まらないから、すべては（仮）である。多分やって価値があるだろうとチームが同意するアクティビティから手をつける。
意思決定は、不確かで定まらないスコープをどうにかするのでは無く、小さく分解して（仮）で価値があるかをいかに早く確かめることを選択できなければならない。
組織の意思決定のベースラインが変わるのである。これまでの延長線上ではなく、非連続の、新しい成長の世界線に転生することを組織が自ら決断しなければならない。
組織の意思決定、価値観、組織構造、文化を置き去りにして新しい価値観の道具を持ち込んでも使えないと思うのは、当たり前である。そもそもツールが合わないのだから。
開発手法は道具で、それ以上でも以下でもない。開発手法だけ急に導入したら組織自身が拒絶反応を起こして使えないとやめてしまうのは当たり前である。体質があっていないのだから。
A Scrum Book: The Spirit of the Game
- 作者:Jeff Sutherland,James O. Coplien,Lachlan Heasman,Mark den Hollander,Cesario Oliveira Ramos
- 出版社/メーカー: Pragmatic Bookshelf
- 発売日: 2019/09/03
- メディア: ペーパーバック
もし、二十歳の自分にアドバイスをできるなら
自分の感覚から言えば成人式は1月15日で、自分の成人式のときはいい天気だった。地元ではろくなことがなかったが、成人式は出ておかないと後悔しそうだと思ってアイビーぽい出立で市民会館まで行ってみた。
案の定、同級生はいたけれど昔を懐かしむようなことも互いにないから素通りだ。式典に出て、アフターで羽目を外すこともなく帰ったはずだ。
あれから34年も経った。自分が社会人になったころは、54歳なんて定年くらいで会社だったら窓きわで新聞を読み、近寄りがたい存在くらいのイメージだった。何せ、30代の先輩エンジニアでさえ、ものすごく年上でどうやって相手をすればいいのかよくわからなかった。
二十歳の頃の自分は自信もなく、頭も悪く（今は少しマシになった程度だ）、知識も少なかったが、心配しなくていいといって安心させてあげたい。仕事は30代半ばまでは思うようにいかないが、そのあと自分でキャリアを覚悟することで良い方向に進むから信じて進んで欲しい。34年後、他にもキャリアパスはあったかもしれないが、割といい意思決定をしたと思う。
もし、二十歳の自分にアドバイスをできるならこんなアドバイスをしたい。
・気になったことはやって経験をしておけ
・英語はやっておけ
・プログラムはもう少し頑張っておけ
・技術書を読んでおけ
・車は欲しいだろうが劣後しておけ
・自分の得意を見つけろ
・得意だけ伸ばせ
一番大事なことは
・素直であれ
正義感は大人の世界には不要だ。
公正で、嘘をつかなけばいい。
・正義はしまっておけ
多分、こんなアドバイスをしても耳を貸さないかも知れない。でも、アドバイスをもらえるうちが花なんだよ。加齢すると誰も言わなくなる。
その点においては、50歳を過ぎて本音を言い合える仲間を作れている。躊躇無くバッサリと切ってくれる仲間だ。
そうした仲間を作れるのは、相手をありのまま受け入れられることだ。
こうしたことは、仕組みを理解すると受け入れやすい。
・勉強して知識をためよ
・理解せよ
二十歳の自分が思っている以上にはいい経験を年齢を増すごとにしているから安心して生きろ。
積読はスタックの実装解除
とある編集と話をしていたとき、技術書が売れないとぼやきを聞いたり、別の出版関係者の話をきいたときには出版不況にもかかわらず技術書は一定の結果を出しているときかせてもらった。
さらに別の編集と話をしたときには、やはり出版不況の話から売れている本の要素の話になって、そう言われてみればそのジャンルが一定のボリュームがあるのを知って感心したことがある。
読み手側、それも学校の先生の話では、技術書を置いても厚くて読まれないとこぼしていた。だから、ここ数年の技術同人誌は入門の入門編として良いのではないかと話されていた。
自分の話をすれば、知人から口コミ的に紹介されたものは欲しいものリストに入れて、書店で実物をパラパラとめくって気になれば、そのままお買い上げする。
ではそうした本を読んでいるかと問われるとそうでもない。積読の方が圧倒的に多い。確実に読むのは、それをインプットに何かしらやらねばならないことを片付けるために仕方がなく読むことが多い。あとは積読か、パラパラと目次から拾い読みしたままか、である。
技術書には2つの種類があると思っている。一つは純粋に技術を取り扱うもので、多くはツールなどである。ツールであるから、前提のバージョンがある。バージョンは更新されるので、次のアップデートが賞味期限となる。だから書き手も読み手も最新のバージョンを追いかけるなければならない。
もう一つは、普遍性のテーマを扱うものだ。その人を形成する基礎コンピテンシで括られるスキルである。別の切り口で表現すれなら、マインドセットに近い。例えば、課題設定、問題解決、手法やアプローチ、終わらせるマインド、チームビルディング、プロジェクトマネジメント、交渉などである。こうしたコンピテンシはどの年代のエンジニアにも課題であるし、定性的にしかスキルを評価できないから、永続的なテーマとなる。よって、賞味期限はない。
こうした特性を持っているから、技術書は賞味期限を頭の隅に入れて、賞味期限のある技術書は買うタイミングか買ってしまったときに、積読にスタックする前に目次とパラパラめくりだけはしておきたい。
賞味期限のない技術書は目次だけは見て積読しても構わないが、OKRやMBO（目標管理）で自分の成長を意識したテーマ設定をするときに、引っ張り出して目次を眺めてみるといい。手元にあると言うことは、伸ばしたいスキルの現れであるからだ。ただ、不得手なテーマより、得手のテーマを選んだ方が心理的にとっつきやすい。
あと、積読はスタックを実装しているから、本を読まないエンジニアよりスキルは高い可能性がある。
マネージャの在り方若しくは廃止論に反する思い
はじめに
はじめに断っておくとマネージャには担当部門においてる無能なマネージャもいるし、有能なマネージャもいる。これはエンジニアに優秀なエンジニアもいるように、残念なエンジニアもいるのと同じである。ただ、マネージャとエンジニアの比率は1対Nになるから無能なマネージャに当たるエンジニアは総数としては多くなる。
自分に見えていた風景
自分に見えていた風景の話をすると、2011年ごろまで、アジャイル界隈ではアジャイル開発とウォーターフォールの対立を揶揄するようなスライドが散見された。ところが2012年のあたりから風向きが変わった。そんな対立に油を注ぐ暇があるならアジャイルで成果を出すべきだと言ったスライドを見かけるようになると同時に、組織論を語るようになった。
そこで問題になるのはマネージャである。個人的な解釈では、プロジェクトマネージャ＝プロダクトオーナであるから、アジャイル開発の役割に組織のマネージャの残れる場所はない。一方、アジャイル開発の組織はマネージャを廃しておきながら、分業化が進み、エンジニアリングマネージャやVPoEなど、一見組織のマネージャの一部の役割を分掌したロールが登場するようになった。
自分は、成果を得られる手法を選び、目的を達成したいことをファーストに考えているので、その視点から見ていると何をやっているんだとしか思えない。試行錯誤と言えばそれまでだが、結局、アジャイル開発界隈はどうなりたいのだろうかと不思議に思えてならない。
組織と権限
話を脱線するが、上場企業であれば、どの組織にも権限分掌の規程を定めているはずだ。経営、人事、規程制定、事業上の意思決定（予算執行など）を定め、そのとおりに業務を行う。これに基づいて業務を運用しているか監査を行い、違反をすれば是正しなければならない。
権限規程は、組織の構造に応じて権限をデレゲートする。予算執行の承認権限を役員、部長、課長に承認金額を設定し、権限の範囲でオペレーションする。
マネージャ廃止論
話を戻して、アジャイル開発界隈でマネージャを廃止する意見を見かけたとき、この辺りはどうするのかと思ったものだ。
もしかしたら、議論しているアジャイル界隈の人たちは非上場であったり、経営に関与していない、組織の運営に疎いのか、あえてそれをわかっていながら改善したい意図があってそう言っていたのか。
ただ、言葉の強ささはマネージャ不要という方が強いから、そうした意図があったとしてもそれは影に隠れてしまうし、そうした意図は捕捉されたことを見たことはない。
マネージャを廃止したくなる理由
マネージャを廃止したくなる理由のひとつにマネージャの能力不足があるのではないかと思う。エンジニアをマネージャにアサインするとき、エンジニアとして成果を出してマネージャに引き上げられるケースは多いのではないか。
これはエンジニアとして優秀だったから、マネジメントをやらせようというエグゼクティブの意図である。この意思決定をするとき、アサイメントするエンジニアにマネージャの素養を持っているか、マネージャのコンピテンシの観点で評価していないケースがあると、不幸が生まれる。
プレーヤとしては天才だが、監督には向かないというやつだ。天才なプレーヤでそれがそのエンジニアの属人的な優秀さに起因したものだと、自分と同じようにメンバのエンジニアも同等にできると思い、そこを閾値でことを始めるからメンバのエンジニアはついていけない。前提から噛み合わないからコミュニケーションも意思疎通がうまくいくはずがない。
ただ、前述のケースは少なくて、年次でマネージャになったケースの方がエンジニアの被害者が多い。実際、なんでこの人がマネージャになったのかと思うような上司に当たったことが多々ある。マネージャの資質もないのにマネージャをしているし、マネージャのコンピテンシを磨かないから、古臭い、個人の偏った価値観を押し付けられるため、エンジニアとしてついていけないと思ったことは数え始めたらきりがない。端的に言えば、自分も（特定の）マネージャなんていなくなってほしいと何度となく思ったことか。
こうした背景に、マネージャにアサイメントする際のqualifyを審査する制度を持ち合わせていない組織があるのである。ある意味、登用する側の責任に裏書きしているのである。実際、人事制度も候補者にマネージャ教育をして篩をかけるのではなく、任命されてからマネージャとはと教育を行う程度で、ひどい組織はそれもしない。
エンジニア目園で見れば、資質も教育もされないマネージャに何を期待できるのだろうか。そうした背景を知ってしまうと絶望しかない。
権限移譲と成長の機会
マネージャ不要論のひとつに、権限委譲があると思う。これも自分の理解であるし、他でも聞いたりするのでそれほど違和感はないと思うが、役割は人を成長させる。
この役割はロールでも構わないが、権限を与えることでも期待できる。何が言いたいかというと、ロールを伴わないとしても権限の一部を移譲することで委譲された人は成長する機会を手に入れられる。委譲されなければ委譲された範囲で考えることも意思決定することもないからだ。
だから、マネージャは自分の裁量の範囲でエンジニアに権限移譲をすればいいと思っている。実際、自分の担当事業の範囲では、エンジニアに権限移譲を行っており、極論を言えば、承認ワークフローのプロセスだけやっていれば事業は回る。承認ワークフローを残しているのは、権限規程で組織が定めているから移譲できないのである。そこまでやるなら規程を修正し、取締役員会などまで持っていけばいい。マネージャ不要論を主張するなら、現行の組織制度の変更まで面倒を見る覚悟を持っていてほしい。そこまでやっている組織の事例を見たことはないから、その程度なのだろうと思われても仕方がないのではないか。
マネージャとエンジニアの関係
エンジニアはマネージャに気を使って話しかけてくるケースが多い。自分がそこそこの年齢であることもあると思うのだが、こちらとしては偉くもないし、権限規程で持たされている権限はロール上の責任でしかなく、単なる組織の中で演じる役割でしかないと思っている。
それをわかっているエンジニアは気兼ねなく話しかけてくれる。そうした考えを持っているエンジニアとのコミュニケーションの始めはとても早い。いきなり本題から入れる。そうしたエンジニアは権限移譲を好む。裁量を求める代わりに裁量の範囲で責任を取ろうとする。もちろん、最後に謝るのは自分であるから、責任なんて言葉に出さないし、権限を移譲したのは自分であるから、そんなことを微塵も滲ませたりしない。
エンジニアの力量にもよるが、方向性だけ知っていて、マイルストーンに許容の範囲の中で進捗していれば、エンジニアはやりたい放題にしておく。これで結果を出してくれるのでさらに裁量を渡す。そうでないエンジニアには少しずつ経験をしてもらってエンジニアのキャパに応じた移譲を進めればいい。
おしまいに
長々と何を言いたいのかというと、それほど優秀でないマネージャでもマネージャの資質を少しでも持っていて、エンジニアとフラットな役割で、マネージャとしてのミッションを果たそうとしていれば、それなりにエンジニアと楽しくやれるという話である。
フォーカスするのは、組織のミッションの実現であり、日々の業務の中では試行錯誤の連続である。小さな失敗は多いし、ふりかえりをすればもう少しうまくやりたいと思う。こうした取り組みは組織の意思決定の上に成り立つから、他社の事例を持ってきても全く役に立たない。自分の組織の中で実験を繰り返すだけだ。その実験をしたければ、エンジニアも権限を持たなければならないし、そのためにはある程度の責任を負わなければならない。その覚悟を持てば、自分のもやもやとしているマネージャの在り方を実感することができるだろう。
頑張って。
