事業会社のエンジニアに必要な3つのコンピテンシ

 

いまいま、事業会社のエンジニアに必要なコンピテンシはこの3つではないかと思っている。

  • Product Management
  • Agile mind
  • Done

きっかけは、メンバが手を挙げたプロジェクトの進捗が捗っていないところで、突発的な役員との打ち合わせで、内心はそろそろ忍耐の閾値かと任せるのは諦めかけていたところで、その役員からどうしようかと振られたとき、覚悟を決めたことがあった。

基本的にはwillをもつメンバがやりたいと手を挙げているのであるから任せておきたい。苦労もあるだろうが、それの乗り越え方を覚えることも成長の一つであるからだ。もちろん、漫然と乗り越えられたり、右往左往してパニックで乗り越えられても成長はゼロだ。未経験から体験する学びは、意識を持った上で体験する方が経験から言語化を介してパターンとして知識がオーバーライドされる。これが成長の形の1つだと思う。

結局のところ、企画すること自体が事業上の経営課題なり達成したい目標に到達することであって、目的を持った有期限性の活動となる。そうだとするとプロジェクトマネジメントを1番目に持ち出したくなるが、目的を持った活動の成果は、そこでお仕舞いではなく、社内外何れにしてもフェーズを切り替えて、サービスとして運用されていく。

一歩引いて、そうしたライフサイクルで捉えると、プロジェクトマネジメントはライフサイクルでのサービスのイニシャル時のマネジメントシステムでしかなく、全体を捉えるのはプロダクトマネジメントである。

そのような企画は、スコープを明確に持つか事業化の中で解像度を上げることでフィックスすることも可能なケースもあるが、事業会社の場合はスコープをフィックスできない場合の方が多い。企画での要件やそこから抽出されるスコープは仮説でしかなく、誰も確証も持てないばかりか、ゴールさえ看板の仮置きで実態を決められずに、プロジェクト化されることもある。

冒頭のメンバのプロジェクトは後者のタイプで、その意味では難易度が高い。後者のような案件は、思いを強く持っている役員が関わるため、プロジェクトをキャリーする担当者が自分で台本を描き、あらすじのディティールを浮かび上がらせながら進めないと役員に振り回されるか、担当者が自ら役員の声を天の声で変えることの出来ないものだと思い込んでしまう。疑うことをせず、自分の頭で実現するサービスなりの所産を持っていないから、自分で筋道を立てられずに安易に進捗をスタックしてしまう。なぜなら、借り物の考えでは、目指す姿をリバースして再構築するプランを構想できないからだ。

だからこそ、大風呂敷を広げず、小さく、スピードで欲しいものは何かを確かめるアジャイルな志向が必要になる。スコープをきっちり決めてなんてやっていると招集した参加者は必須も任意も区別せずに思いつきで言い放つから、フィックスしないばかりかひたすらにクリープし続ける。大風呂敷の中から必須の要件を寄り抜くだけでも時間は取られるし、一度出てきたものを初期段階でクラスファイしておかなければ、誰もそれを劣後する判断をしなくなる。

スコープのあるもの、設定できるものは、ビックバンでも長大なプロジェクト化でも構わない。あとはプロジェクトマネジメント能力が問われるだけだ。でも、そうでなければ小さく確かめて、やった結果で期待を満足するかを確かめなければ危なくてやっていられない。だからこそ、小さなアクティビティにして終わらし、次の小さなアクティビティに手をつけるのだ。これでやっていると方針転換、天の声、思いがけない割り込みがあったとしても対応できるし、後続をスリップさせたときの影響は小さい。

Product Management、Agile mind、Doneは粒度の並びでも良さそうだ。全体俯瞰、インプリ、マインドセットだからだ。

とはいえ、概念的過ぎてバックグランドとして補完関係なコンピテンシは数多あるため、これだけでやられてもボロが出てしまいそうだ。