事業会社のエンジニアに必要な3つのコンピテンシ
いまいま、事業会社のエンジニアに必要なコンピテンシはこの3つではないかと思っている。
- Product Management
- Agile mind
- Done
きっかけは、メンバが手を挙げたプロジェクトの進捗が捗っていないところで、突発的な役員との打ち合わせで、内心はそろそろ忍耐の閾値かと任せるのは諦めかけていたところで、その役員からどうしようかと振られたとき、覚悟を決めたことがあった。
基本的にはwillをもつメンバがやりたいと手を挙げているのであるから任せておきたい。苦労もあるだろうが、それの乗り越え方を覚えることも成長の一つであるからだ。もちろん、漫然と乗り越えられたり、右往左往してパニックで乗り越えられても成長はゼロだ。未経験から体験する学びは、意識を持った上で体験する方が経験から言語化を介してパターンとして知識がオーバーライドされる。これが成長の形の1つだと思う。
結局のところ、企画すること自体が事業上の経営課題なり達成したい目標に到達することであって、目的を持った有期限性の活動となる。そうだとするとプロジェクトマネジメントを1番目に持ち出したくなるが、目的を持った活動の成果は、そこでお仕舞いではなく、社内外何れにしてもフェーズを切り替えて、サービスとして運用されていく。
一歩引いて、そうしたライフサイクルで捉えると、プロジェクトマネジメントはライフサイクルでのサービスのイニシャル時のマネジメントシステムでしかなく、全体を捉えるのはプロダクトマネジメントである。
そのような企画は、スコープを明確に持つか事業化の中で解像度を上げることでフィックスすることも可能なケースもあるが、事業会社の場合はスコープをフィックスできない場合の方が多い。企画での要件やそこから抽出されるスコープは仮説でしかなく、誰も確証も持てないばかりか、ゴールさえ看板の仮置きで実態を決められずに、プロジェクト化されることもある。
冒頭のメンバのプロジェクトは後者のタイプで、その意味では難易度が高い。後者のような案件は、思いを強く持っている役員が関わるため、プロジェクトをキャリーする担当者が自分で台本を描き、あらすじのディティールを浮かび上がらせながら進めないと役員に振り回されるか、担当者が自ら役員の声を天の声で変えることの出来ないものだと思い込んでしまう。疑うことをせず、自分の頭で実現するサービスなりの所産を持っていないから、自分で筋道を立てられずに安易に進捗をスタックしてしまう。なぜなら、借り物の考えでは、目指す姿をリバースして再構築するプランを構想できないからだ。
だからこそ、大風呂敷を広げず、小さく、スピードで欲しいものは何かを確かめるアジャイルな志向が必要になる。スコープをきっちり決めてなんてやっていると招集した参加者は必須も任意も区別せずに思いつきで言い放つから、フィックスしないばかりかひたすらにクリープし続ける。大風呂敷の中から必須の要件を寄り抜くだけでも時間は取られるし、一度出てきたものを初期段階でクラスファイしておかなければ、誰もそれを劣後する判断をしなくなる。
スコープのあるもの、設定できるものは、ビックバンでも長大なプロジェクト化でも構わない。あとはプロジェクトマネジメント能力が問われるだけだ。でも、そうでなければ小さく確かめて、やった結果で期待を満足するかを確かめなければ危なくてやっていられない。だからこそ、小さなアクティビティにして終わらし、次の小さなアクティビティに手をつけるのだ。これでやっていると方針転換、天の声、思いがけない割り込みがあったとしても対応できるし、後続をスリップさせたときの影響は小さい。
Product Management、Agile mind、Doneは粒度の並びでも良さそうだ。全体俯瞰、インプリ、マインドセットだからだ。
とはいえ、概念的過ぎてバックグランドとして補完関係なコンピテンシは数多あるため、これだけでやられてもボロが出てしまいそうだ。
報酬と生産性と価値
システム開発で生産性と話を持ち出すとプログラムのステップ数を持ち出すのはレガシなシステム開発を経験したシニアエンジニアか新卒から刷り込まれたエンジニアだろう。顧客とエンジニアサイドで成果と報酬の折り合いをつける共通の基準は測れるものでなければならず、必然とLOCになったと推測できる。
生産性をLOCで評価すること自体、問題しかない。コードをコピペして似て非なるプログラムを量産すればLOCはいくらでもカサ増しできる。リファクタリングした方が報酬が少ないという何だかな、という現象が起きてしまう。
これは開発手法に捉われない。成果と報酬がLOCと対価になっている限りは。
報酬の成果をLOCから何に変えるか。すぐに思い浮かぶのは価値だ。価値を言い換えると使う機能である。業務で使うものだけ。
あとは報酬と機能を何をもってレーティングすれば良いのかとなる。
結局ここで折り合いがつかない。例えば機能の利用頻度とすると、日次処理の方が年次処理より価値があることになってしまう。決算業務に価値はないのか。そんなことはない。必要な機能には価値はある。
では他に報酬に見合う単位はないものか。
スピードはどうだろうか。
報酬とスピード。良さそうだ。
ただ、ひとつ難点がある。基準が作れない。作ったことのない機能の開発スピードはどのくらいで開発できるのか誰も知らない。やったところでその結果を比較する基準がない。
周り回って、結局報酬は確保したエンジニアのリソースで支払うしかないのか。これはこれでまた冒頭に戻るのである。
脳の体力
40代の頃、50歳を超えたくらいの直属の役員が身体が持たないと飲むたびにこぼしていた。帰る方向が同じだったからもあったのと、自分がわりと話を聞き出す様にしていたのでガードが下がっていたのかもしれない。身体が持たないから週末は寝る時間に充てていると言いつつもスポーツクラブの話もしていたので適度な運動はしていたのだろう。まだ40代だったから、その身体が持たないというニュアンスが分からなかった。ああ、そうなんだくらいで聞き流していた。
それが、である。50代になり、フィジカル、体力より先に来たのは脳の体力の衰えの方を感じるようになった。去年の後半からガクッときた感じだ。
身体は相応だと思うが、脳の体力が落ちてやりたいことの中でも作業に近いアクティビティに手が出ない。ようやく手を動かしたとしても一向に進捗しない。いくらでもできる別のアクティビティはあるのに、パフォーマンスを発揮できないばかりか、マインドを縛ってしまうアクティビティが出てきた。
これは脳の体力が落ちで、たくさんあるアクティビティの中でも自分に達成感の報酬をリアルタイムに感じられないアクティビティまで脳の体力が残っていないのではないかと疑う様になった。
たった1年前にはなかった感覚だ。1年前ならガッツリと集中してやれた。では、本業の方はというとそこそこやれているし、やりすぎ感があるくらいなのだ。もしかすると、本業の方で脳の体力を消耗しすぎているのか…。
それとも、フィジカルな体力が加齢と共に段階をズドンと落ちていくように、脳の体力も落ちているのが当たり前なことで、それを知らないだけなのだとしたらこわいことだ。
まだ自分は新しい技術を関心のある方面で試したり、アウトプットしてプロダクトにしているのでマシなのかもしれないが、脳の体力の減衰に気づかず新しいことをインプットもしていないとしたら、了見はシュリンクする一方である。
エンジニアの技術のバリューを維持するだけでも大変なことは、エンジニアであれば誰でも知っていることだ。その大変さは年齢の階段を登れば登るほどフィジカルばかりか脳の体力も自分のハンディキャップになっているたのかもしれない。
こうしたことは、それの当事者になってから体験して事象として初めて認識するものであるが、何も準備していなければ手遅れでしかない。
脳の体力を認識して、理解して、受け入れる。その上で延命と言うよりは、経験からのプラクティスでいかに回避するパスを探索したい。
BCP はどこまで必要か
大手ならBCPと称して初動対応の安否確認や事業再開のため事業復旧計画を整備していたりする。よくよく考えると、無駄なことなのではないかと頭をよぎる。
などと書くと、
・何をいっているんだ社員の安全を確認するのだから社員に優しいじゃないか
・事業再開に社員がいなければ業務を回復できないじゃないか
こんな声が聞こえてきそうだ。
そもそも初動の安否確認は何のために行うか。目的は、事業再開のための社員というリソースの確保である。例え事業場が被災し、修繕をしなければならなかったとしても、事業再開の段取りを組み、速かに事業再開を目指す。社員生命の確認をしてよかったね、で終わることはない。その辺りの一連の流れはちょっと検索すれば政府の資料などにたどり着ける。
だから、安否確認を行う。
安否確認システムは、いざという時に使うものだから、日常の業務の中で訓練する。それは訓練の災害発生通知を送ると、他部署よりいかに速く部下が生存のレスを返すかを競う。
ところで、災害が発生するときどこにいるだろうか。事業所にいるとは限らない。外出先かもしれないし、移動中かもしれないし、自宅かもしれないし、海外出張中かもしれない。3.11のときはどこにいただろうか。
あのときは偶然身体に怪我を負わなかったかもしれないが、深夜自宅だったらタンスの下敷きになっていたかもしれない。気のみ気のままに避難するかもしれない。
そのとき、安否確認の通知が届いたとしても、それに構っていられない。優先すべきは生命の安全の確保だ。
とするならば、安否確認で競うのは意味がない。
ところで、社内の業務システムや事業用のシステムがクラウドに移行していたらどうだろう。事業再開にそもそも人を確保する必要があるだろうか。データセンターであれば関東大震災を想定したファシリティが整備されている。少なくとも自社よりは安全だ。DCがやられたら、どうしようもないし、そもそもGCPもawsも似たり寄ったりではないか。
働き方改革でどこからでも仕事ができるなら、ネットさえ生きていれば良いのだから、業務は継続可能だ。紙手続きの労務などは多少影響あるかもしれないが、被災地全て同じだ。
業務システムがクラウドなら、事業再開はシステムの死活監視で済んでしまう。
安否確認も関東大震災級が来たら後回しだ。
被災は実際起きてみないと計画は立てても無駄だ。
チームのslackチャンネルで安否確認確認で十分かもしれない。
ぬるま湯は能力が弛緩する
打ち合わせをしていて、打ち合わせのテーマをどう実現するかを聞いても、ほんわかした説明しかないとダメなコンサルかSIerの営業の提案を聞かされている気分になる。
どういうことかというと、あるテーマについてそのテーマをやったぜと言えるdoneの定義を聞いても、こうやるよというロジックもゴールのディテールも説明できないないのだ。
ゴールの成果物設定から逆構成するわけでもないし、ゴールは仮で仮説検証してゴールを実現するアプローチでもない。どちらのアプローチをとったとしても、こうやるから実現できると考えているという自分で信じている軸があるものだと思うのだが、それがない。
それがないから、ゴールの設定が設定する期間に対して壮大すぎる。ちょっとオーバーなレベルを超えている。
ゴールに対する実現性を疑ってないから、こちらの感じる違和感はいくら説明しても伝わらないし、お互いに同じ土俵に立てていないこと自体理解できていない。
だから、どういう考えで実現するのかを繰り返し尋ねてもいっこうにほんわかしたままだし、ゴールのスペックをスペシフィックにしようと質問してもほんわかしたゴールの説明を繰り返すばかりだ。
その説明をずっと繰り返している。
そのテーマを取り上げて自分のタスクとスワップして、自分のタスクは指示してやれば設定する期限にMVP的な最小限の価値は得られるだろう。任せて、突き放して中堅エンジニアのコンピテンシを自覚させる方法もある。ある意味、突き放して自分の実力と対面させるのだ。
でも、前者はそれではそのエンジニアは成長しないし、後者も潰れてしまうかもしれない。
中堅のエンジニアが目の前で困惑しているのはとてもつらい。
エンジニアはエンジニアの人生を意味あるものにするために次の方法を実践し続けたい。
・時間の使い方を将来の自分に少し割り当てる
・会う人を変える
・自分の持っていない能力を持つ人たちのいる場に赴く
同じ環境は居心地がいい。でも、それでは知らないことにぶち当たったとき、思考が止まる。思考を止めない、停止させない機会づくりが必要だ。
居心地の良い場所からすこしはみ出る。はみ出たら興味を持てる人に会う。優秀な人の場に出向いて会話に混ざり、自分の考えとの違いを知る。
違いを理解して、共通の土俵に立ち、会話を始められないと主体性を持つことさえ難しい。
ナレッジ共有というお化け退治
組織が成長（100→1000のフェーズ）や高齢化（1年経って若手が配属されなければ一つ組織も老齢化する）と お化けのように要望として上がるのがナレッジ共有だ。
動機自体は極めて純粋で、増える要員への（過去の情報共有や育成の手間の）負担軽減だったり、シニアエンジニアの退職までの残存期間に危機感を持ってノウハウを言語化しておきたいというものだ。
ここまでの動機は良しとして、それに余計なオプションを言い始めるとタチが悪くなる。その代表が、そしき横断で同じツールを使いたいと言うものがある。
結論から言えば、好きにして、だ。ナレッジ共有の仕組みが欲しければ欲しいチームで、チームで良いと思うツールを選定し、そのチームで運用ルールを決めて実際にやってしまえばいい。
ナレッジ共有が組織横断で上手くいかない理由はきりがないほどある。
・ナレッジ共有したいと思っている人しかインセンティブがない
・運用負荷を考えていない
・全体の業務に組み込めない
などなどある。最初の理由だけで試合終了感満載だが、やりたい人はそこに気づかない。
これはエンジニアが新しい言語、ツール、環境をどこかで見聞きして、自分のチームでもやりたいというのと同じ症状である。変える理由も権限もないから導入されることはないし、逆に権限を持つトップから落ちてくると押し付けられ感だけで嫌になってしまう。上手いエンジニアは、自分だけか自分の裁量の範囲で闇研して、期待する結果を得られれば成功事例としてしれっと出す。
ナレッジ共有の要件を考えてみよう。
普通に考えれば、わざわざ手間を掛けて、共有したいもの、残したいものをコンテンツ化する。
多分にこれでは失敗する。「手間を増やさず」コンテンツを残す、が要件としては正解だ。
使い手のユースケースはどうだろうか。ディレクト構成が硬直的に決められた場所のコンテンツを探すだろうか。直感的に、困っているキーワードを検索するだろう。
・業務で使うツールで残せる
・キーワードか関連しそうなコンテンツをサジェストする
を実現できたらいいのではないか。
最大の障害はインセンティブであるから、わざわざ二度手間な実現仕様は論外でしかない。それよりはサジェストの方が困っている人にとって価値がある。
ナレッジ共有のシステムは90年代には既にいくつもあったが、ナレッジ共有の課題解決ならこれとなっていないのは、根本の要件への未達もあるのだろうが、困らないと必要ないからというところが本当なのだろう。
プロダクトの発想とかバカっぽいアイデアを言える環境
事業を20年以上続けている知己がいる。頻繁に会う機会を設けていて、会うたびに先方の事業の話をあれこれと聞いている。
SIerなどで新規事業部門を鳴物入りで立ち上げるも上手くいかないとか、スタートアップでプロダクトが思ったように立ち上がらないケースを耳にする度に、事業を続けていると言うだけで、すごいことだと思う。
先だってもその友人と話しているときに、新商品のアイデアの思いつく状況を話始めた。話している内容自体は、こんなタイミングで思いついたんだよ、程度のことなのだが、切り口を変えて捉えると、そのぐらいリソースを突っ込んでないとできないものなのだと改めて感心する。
PdM（プロダクトマネージャ）は、それこそ寝ていてもプロダクトのことを考えていて、如何にバリューを持たせるかしか興味がない。四十六時間中プロダクトのことを考えているとき、以前何かで見聞きしたものが何かのきっかけで結びつく。
プロダクトの発想は知っているいくつかの組み合わせだ。それもそんな組み合わせはあり得ないと思うようなピンポイントの所にオポチュニティは隠れている。
その組み合わせについても友人は語っていた。変な組み合わせ、それを探すために何でも組み合わせる。
人は知識を持っているから、セオリーで物事を考える。無意識に常識やルールに囚われる。プロダクトの発想はそれじゃない、と言っているのだ。
友人はデザインはからっきしダメである。本人がそう言っているのだから、そうなのだろう。そこは仲間のデザイン担当が受け持つ。
ただ、そこは分業しない。からっきしデザインがダメだと言っておきかながら、これはどうかとひどいデザインを見せる（実際、見せられた）。
デザイン担当をしている方は、思いっきり事業主である友人のアイデアをdisる。ただdisるだけではなく、そのdisったアイデアをベースに目標とする品質レベルを高い位置で目指してデザインする。言い換えると捨てる前提でデザインしない。一発で決めるつもりでデザインしていると主張していた。
そのあたりの念持はイズムに通ずるところがあり、とても共感できる。
ただ、興味深いのは、友人のように自分のデザインはからっきしダメだと言っているにも関わらず、臆することもなく自分のアイデアを形に、言葉だけではなくものとして見せられる場と関係を作れていると言うところだ。
人数的なもの、少人数というのもあるのかもしれない。自分（友人）やデザイン担当がやらなければ他にやる人はないというものあるのかもしれない。
これを当事者意識なんて表現するのも、また違うと感じている。やらなければ先細りして事業は衰退してしまうと思っているのだろう。
それはさておき、形にして見せて、あーだ、こーだと会話できるのは心理的安全性云々よりもっと先の目指すところなのかもしれない。
