罰ゲーム化する管理職
私も30半ばにもなり、現職でも管理職から「管理職になってほしい」と言われるようになりました。
それ自体はとても喜ばしいこととして受け止めていました。
一方で、最近は『罰ゲーム化する管理職』という書籍が話題になっています。まだ読んでませんが
今の管理職や、来年管理職になるであろう人の責任の重さや負荷状況を見ていると、自分がその立場になったときの不安を感じてしまいます。
そんな感じで、どのようにキャリアを築いていくべきか、考えることが多くなりました。
プロジェクトの失敗と成功
ITエンジニアである以上、どのような立場で関わるかはともかく、プロジェクトは避けて通れないものです。
プロジェクトを継続的に成功させるためには、何が足りないのか、なぜ失敗するのか、考えることが多くなりました。
そして、プロジェクトの成功に貢献するため、長期的な目線で自分はどのようなスキルを身に付けるべきなのか、
どのような分野（マネージャー・スペシャリスト問わない）で専門性を高めるべきなのか、考えることが多くなりました。
私が経験した最も困難なプロジェクトは、何度も方針転換を繰り返しています。
なぜこのようなことが起こるのか、ChatGPTに訊いてみました。↓ここからChatGPT
- 目標・ビジョンの不明確さ
プロジェクトのゴールやビジョンが曖昧で、チームや関係者全員に共有されていないため、方針がぶれやすい。
スコープが明確でなく、途中で目標が追加される（スコープ・クリープ）。 - ステークホルダー間の調整不足および意思決定の不安定さ
ステークホルダーやリーダー間で意見の統一が取れていない、または意思決定が曖昧なため、方針が頻繁に変更される。
組織内部の権力争いや政治的な要因で、方針が変わることもある。 - 情報不足または過剰な分析
必要な情報が不足しているため、適切な意思決定ができず、後になって方針を変える必要が生じる。
過剰に分析しすぎて、方針決定が遅れたり、変更が生じる（パラリシス・バイ・アナリシス）。 - 技術的な不確実性
技術力が不足していると、適切な技術選択や問題解決ができず、試行錯誤が続き、方針が変更されやすくなる。
技術面でのスキルが足りていない場合、技術的な課題を乗り越えられず、プロジェクトの進行に支障をきたすことがある。 - リスク管理の不足
プロジェクトのリスクが適切に管理されておらず、予期せぬ問題が発生した際に方針転換が必要になる。 - 過剰な会議や意思決定プロセスの遅延
不要に多くの会議や調整が行われており、合意形成が遅れ、方針が頻繁に変更される。
↑ここまでChatGPT
いろいろ思い当たるものがあるので、特に当てはまりそうなものをピックアップしてみます。
- スコープが明確でないから
システムの設計や開発は、全体の整合性を取りつつ行われるべきだと思っています。
しかし、細かいレベルでのスコープが明確でなく、私目線では後出しで要件が追加されることが何度かありました。
こうなると、全体的にやり直しになることもあります。 - ステークホルダー間の調整不足
ステークホルダーが多いと、利害関係が複雑になり、全体としての要件も複雑になります。
コミュニケーションコストが高くなり、意思決定が遅れることもあります。 - 技術的な不確実性
私も含めてではありますが、実現にあたって必要な技術力が不足していることも考えられます。
指示する立場の人の技術力が低いのに、開発者に細かい指示を出すと、適切な技術選択や問題解決ができないこともあります。
指示を受ける立場の人の技術力が低いことによっても、技術的な課題を乗り越えられず、プロジェクトの進行に支障をきたすことがあります。
そう悩んでいるときに、ふと本屋を覗いてみると、『BIG THINGS』という本を見つけました。
その中でいくつか目に留まった成功の法則を紹介します。
- マスタービルダーと良いチームを雇う
たしかに、プロジェクトに合った経験を持っていなければ、プロジェクトに対する解像度が低くなります。
また、そういう経験のある人物がいたとしても、年功序列・トップダウンなどの理由であまり活躍できていないと問題だと思います。
さらに、近年はシステムに求められる要件が複雑になってきていて、特に大規模なプロジェクトだと、一人のマスタービルダーだけでは、解くべき問題や問題に対する解決方法などすべてを把握しきれないこともあります。
チーム全体で協力してプロジェクトを進めることが求められるようになってきていると感じています。
しかし、チーム全体で協力してやっていくということは、言葉で言うのは簡単ですが、実際には難しいことも多いと感じています。
一歩間違えれば、コミュニケーションが複雑化し、情報伝達が不十分になって遅延や手戻りの原因になることもあります。 - 「なぜ？」を考える
これは『プロダクトマネジメントのすべて』でも上位の前提条件として位置づけられていて、前回の記事でもリーンキャンバスのWhyを訊くなど実践しています。 - 「レゴ」を使ってつくる
IT業界においても、とくに設計の文脈で、小さな部品を組み合わせていくことが大切であるとはよく言われていることです。
『現場で役立つシステム設計の原則』でも、最初の章のタイトルが「小さくまとめて分かりやすくする」です。
プロジェクトの成否には、多くの要因が絡み合っていることがわかります。
周りを巻き込んでいくということをしたとしても、自分の力だけではどうにかなる話ではないなと感じました。
ただ、自分なりに正解の仮説を持って動かないと、この先永遠に苦しむことになるなと感じました。
新たな組織を求めて
自分の力だけではどうにもならないし、プロジェクトの成功を持続的に可能にしている組織が重要であるという考えの下、転職を考えました。
そうすると、非常にありがたいことに、いくつかの企業から内定をいただくことができました。いい企業はたくさんあるなと感じました。
その中で特に興味を持ったのが、ティール組織を採用し、組織のあるべき姿を求めてPDCAを繰り返している企業でした。
シェアド・リーダーシップを創発させるアプローチを取っており、リーダーシップを分散させることで、管理職の罰ゲーム化を防ぐ取り組みもしていると感じました。
大規模なシステム開発も実績がある企業で、長期的な視点でプロジェクトを進めることができる環境であると感じました。
ちょうどその企業はプロダクト志向も強いエンジニアを求め始めているところだったようで、最近アプリケーションエンジニアを「プロダクトエンジニア」と再定義しています。
私はプロダクト志向も強いエンジニアであると自負していて、私のために再定義したのかなと思いました。
現職でやっていたように、プロダクト目線で開発チームのリードを行うことで貢献できるのではないか、と考えています。
同時に、リーダーシップの分散ということで、チームにおけるプロジェクト管理もいきなり同時に求められることもないだろう、と考えています。
入社はまだ先ですが、これらが正しいかどうか－－。入ってみてのお楽しみですね。