ぬるま湯は能力が弛緩する
打ち合わせをしていて、打ち合わせのテーマをどう実現するかを聞いても、ほんわかした説明しかないとダメなコンサルかSIerの営業の提案を聞かされている気分になる。
どういうことかというと、あるテーマについてそのテーマをやったぜと言えるdoneの定義を聞いても、こうやるよというロジックもゴールのディテールも説明できないないのだ。
ゴールの成果物設定から逆構成するわけでもないし、ゴールは仮で仮説検証してゴールを実現するアプローチでもない。どちらのアプローチをとったとしても、こうやるから実現できると考えているという自分で信じている軸があるものだと思うのだが、それがない。
それがないから、ゴールの設定が設定する期間に対して壮大すぎる。ちょっとオーバーなレベルを超えている。
ゴールに対する実現性を疑ってないから、こちらの感じる違和感はいくら説明しても伝わらないし、お互いに同じ土俵に立てていないこと自体理解できていない。
だから、どういう考えで実現するのかを繰り返し尋ねてもいっこうにほんわかしたままだし、ゴールのスペックをスペシフィックにしようと質問してもほんわかしたゴールの説明を繰り返すばかりだ。
その説明をずっと繰り返している。
そのテーマを取り上げて自分のタスクとスワップして、自分のタスクは指示してやれば設定する期限にMVP的な最小限の価値は得られるだろう。任せて、突き放して中堅エンジニアのコンピテンシを自覚させる方法もある。ある意味、突き放して自分の実力と対面させるのだ。
でも、前者はそれではそのエンジニアは成長しないし、後者も潰れてしまうかもしれない。
中堅のエンジニアが目の前で困惑しているのはとてもつらい。
エンジニアはエンジニアの人生を意味あるものにするために次の方法を実践し続けたい。
・時間の使い方を将来の自分に少し割り当てる
・会う人を変える
・自分の持っていない能力を持つ人たちのいる場に赴く
同じ環境は居心地がいい。でも、それでは知らないことにぶち当たったとき、思考が止まる。思考を止めない、停止させない機会づくりが必要だ。
居心地の良い場所からすこしはみ出る。はみ出たら興味を持てる人に会う。優秀な人の場に出向いて会話に混ざり、自分の考えとの違いを知る。
違いを理解して、共通の土俵に立ち、会話を始められないと主体性を持つことさえ難しい。
ナレッジ共有というお化け退治
組織が成長（100→1000のフェーズ）や高齢化（1年経って若手が配属されなければ一つ組織も老齢化する）と お化けのように要望として上がるのがナレッジ共有だ。
動機自体は極めて純粋で、増える要員への（過去の情報共有や育成の手間の）負担軽減だったり、シニアエンジニアの退職までの残存期間に危機感を持ってノウハウを言語化しておきたいというものだ。
ここまでの動機は良しとして、それに余計なオプションを言い始めるとタチが悪くなる。その代表が、そしき横断で同じツールを使いたいと言うものがある。
結論から言えば、好きにして、だ。ナレッジ共有の仕組みが欲しければ欲しいチームで、チームで良いと思うツールを選定し、そのチームで運用ルールを決めて実際にやってしまえばいい。
ナレッジ共有が組織横断で上手くいかない理由はきりがないほどある。
・ナレッジ共有したいと思っている人しかインセンティブがない
・運用負荷を考えていない
・全体の業務に組み込めない
などなどある。最初の理由だけで試合終了感満載だが、やりたい人はそこに気づかない。
これはエンジニアが新しい言語、ツール、環境をどこかで見聞きして、自分のチームでもやりたいというのと同じ症状である。変える理由も権限もないから導入されることはないし、逆に権限を持つトップから落ちてくると押し付けられ感だけで嫌になってしまう。上手いエンジニアは、自分だけか自分の裁量の範囲で闇研して、期待する結果を得られれば成功事例としてしれっと出す。
ナレッジ共有の要件を考えてみよう。
普通に考えれば、わざわざ手間を掛けて、共有したいもの、残したいものをコンテンツ化する。
多分にこれでは失敗する。「手間を増やさず」コンテンツを残す、が要件としては正解だ。
使い手のユースケースはどうだろうか。ディレクト構成が硬直的に決められた場所のコンテンツを探すだろうか。直感的に、困っているキーワードを検索するだろう。
・業務で使うツールで残せる
・キーワードか関連しそうなコンテンツをサジェストする
を実現できたらいいのではないか。
最大の障害はインセンティブであるから、わざわざ二度手間な実現仕様は論外でしかない。それよりはサジェストの方が困っている人にとって価値がある。
ナレッジ共有のシステムは90年代には既にいくつもあったが、ナレッジ共有の課題解決ならこれとなっていないのは、根本の要件への未達もあるのだろうが、困らないと必要ないからというところが本当なのだろう。
プロダクトの発想とかバカっぽいアイデアを言える環境
事業を20年以上続けている知己がいる。頻繁に会う機会を設けていて、会うたびに先方の事業の話をあれこれと聞いている。
SIerなどで新規事業部門を鳴物入りで立ち上げるも上手くいかないとか、スタートアップでプロダクトが思ったように立ち上がらないケースを耳にする度に、事業を続けていると言うだけで、すごいことだと思う。
先だってもその友人と話しているときに、新商品のアイデアの思いつく状況を話始めた。話している内容自体は、こんなタイミングで思いついたんだよ、程度のことなのだが、切り口を変えて捉えると、そのぐらいリソースを突っ込んでないとできないものなのだと改めて感心する。
PdM（プロダクトマネージャ）は、それこそ寝ていてもプロダクトのことを考えていて、如何にバリューを持たせるかしか興味がない。四十六時間中プロダクトのことを考えているとき、以前何かで見聞きしたものが何かのきっかけで結びつく。
プロダクトの発想は知っているいくつかの組み合わせだ。それもそんな組み合わせはあり得ないと思うようなピンポイントの所にオポチュニティは隠れている。
その組み合わせについても友人は語っていた。変な組み合わせ、それを探すために何でも組み合わせる。
人は知識を持っているから、セオリーで物事を考える。無意識に常識やルールに囚われる。プロダクトの発想はそれじゃない、と言っているのだ。
友人はデザインはからっきしダメである。本人がそう言っているのだから、そうなのだろう。そこは仲間のデザイン担当が受け持つ。
ただ、そこは分業しない。からっきしデザインがダメだと言っておきかながら、これはどうかとひどいデザインを見せる（実際、見せられた）。
デザイン担当をしている方は、思いっきり事業主である友人のアイデアをdisる。ただdisるだけではなく、そのdisったアイデアをベースに目標とする品質レベルを高い位置で目指してデザインする。言い換えると捨てる前提でデザインしない。一発で決めるつもりでデザインしていると主張していた。
そのあたりの念持はイズムに通ずるところがあり、とても共感できる。
ただ、興味深いのは、友人のように自分のデザインはからっきしダメだと言っているにも関わらず、臆することもなく自分のアイデアを形に、言葉だけではなくものとして見せられる場と関係を作れていると言うところだ。
人数的なもの、少人数というのもあるのかもしれない。自分（友人）やデザイン担当がやらなければ他にやる人はないというものあるのかもしれない。
これを当事者意識なんて表現するのも、また違うと感じている。やらなければ先細りして事業は衰退してしまうと思っているのだろう。
それはさておき、形にして見せて、あーだ、こーだと会話できるのは心理的安全性云々よりもっと先の目指すところなのかもしれない。
停滞する大企業と成長するスタートアップ
生産性の上がらない重厚長大でグローバルな大企業とWeb系クラウドサービス企業は、一見、真逆のような存在であるが不思議なことに共通項もある。
人事ローテ vs ゼネラリスト
大企業は、数年おきに人事ローテーションをかける。人事ローテーションを始めた頃には理由があったのだろうが、昭和、平成を経た今、人事ローテーションを始めたきっかけを機能しているか評価できている人事部は存在するのだろうか。情報システム部門も現場を知らないとと現場に数年出されることもある。場合によってはそのまま現場に置かれ、現場でのIT担当になることもある。組織は企業の意思決定のパターンであるから、現場でIT担当で置かれたとしても複数の役割を担わされ、複数の業務部門を兼務したりする。
一方、クラウドサービス、それもスタートアップに近い方は、圧倒的に人的リソースがない（＝欲しくても採用できない）から、必然的にゼネラリストのような役回りをすることになる。法務がリスクから情報セキュリティを、SREが社内インフラやOA環境の整備を、総務が入館カードの発行と合わせてアカウントの管理も、のような感じでIT担当を置ける体力をつけるまでは、いる人でなんとか回す。役割的にフルスタックとなるが、技術よりは業務の観点でしかなく、広く浅くでありこれをゼネラリストと呼ぶのは少々気がひける。
会議 vs slack
大企業は会議で仕事がスケジュールされていく。担当役員の報告会議がサイクルのゴールで、担当部長への報告会議、担当課長の報告会議、（プロジェクト）チームの進捗会議と段階を経る。報告会議も場合により、事前会議やスケジュール調整ができない場合の事前、事後報告などの場を踏んでおかないとひっくり返されないので、根回し的な会議も差し込む。結果作業はその隙間に行われる。
一方、クラウドサービスのような企業は会議は少ないが負けず劣らず、slackのチャンネルが総数を誰も知らないくらい多い。イシューごとに作られるプライベートチャンネルも入れれば、あっという間に数100になる。大企業のようにスケジュールをブロックされれば会議としてのコミュニケーションチャンネルを介するので、なんの話をしているか明示的（会議の内容は別次元）だが、slackにポンと投げられても気づけないまま流れてしまう。
コンプラ vs オープンなカルチャ
大企業はコンプラは必達である。ちょっとしたメールの誤送信でも大ごとになる。大ごとになるかどうかは誤送信したと正直に報告した場合で、顔が広ければ上手く丸め込んで水面下でポイだ。組織の階層構造と業務機能の分離の行き過ぎは情報の分断を自然と行わせる。結果、need to knowを実現することになるが人事ローテ、同期入社、学閥などのインフォーマルなインハウスのソーシャルネットで情報はいつでもダダ漏れだ。これを組織間でやれば風通しもよくなるものを、組織間となるとコンプラを縦に（実は部長同士の出世争いや縄張り争い）、情報は分断される。
クラウドサービスな企業は、バリューを掲げているところが多い。そのうちの1つにオープンなカルチャという情報セキュリティやインサイダー的にはアナーキなカルチャをオープンと捉える。端的に言えば、情報セキュリティに対するリソースを掛けられないからであり、中途採用者が前職で情報セキュリティやコンプライアンスで刷り込まれた資産で運用されているのが実態だ。人的規模が100→1000のフェーズに入るとその辺りに関心を持つ社外取締役が口を出すようになり、結果、同じようなルートを歩み始める。
多層防御 vs ゼロトラスト
大企業ならではのコンプラである。法令遵守はもちろん、自社での規程を継ぎ接ぎしながら、歴代の担当者がハウルの動く城ごとく、規程にパッチを当てる。典型的なものは、情報セキュリティで、右へ倣えで箸の上げ下げまで事細かく規程や要領レベルで記述してしまう。結果、実装しないと規定違反となるから情報システムがそれを実装し、教育を行う。気づくと、効果を測れない多層防御という名の外部からの脅威に対向するセキュリティアプライアンスのミルフィーユを積み上げる。しかし、ITを使う従業員の情報リテラシは低いから、すり抜けた添付ファイルを踏み抜き、ファイルサーバは暗号化されたり、BECに引っかかる。
クラウドサービスをやっている企業では、コンプラとスピードを量る。圧倒的にスピードを選択するが、ビジネスの根幹が情報管理の場合はセキュリテイとバランスをとる。極力クライドサービスで社内もSaaSも組むから、基本ネットがあれば業務は成立するためインターネットの接続点を集約する意味がない。必然とゼロトラストとして情報セキュリティが成り立たせる方向になる（ならないとおかしい）。PC＝インターネット接続点になるということは利用者の情報リテラシが求められる。ビジネスを拡大すると次第に情報リテラシは低減し、大事故を起こしかねない。
端的に言えば、企業としてのスケールをアップしていくロードマップのどこにいるかだけで、随分先の方で時間軸に対して並行しているか、ゼロからのスタートで急激にX軸を駆け上っている最中かのフェーズだけの違いなのかもしれない。ただ、目の前に辿りたくない背中は見えているので規模の拡大と大企業病からの距離感をどう取っていくかがクラウドサービスのようなスタートアップの経営者の悩みかもしれない。
走りながら考えるは嫌だけど出来るようになってから挑戦するはもっと嫌
『走りながら考えろ』と言われると『お前の準備不足の付けを現場に回すな』と言いたい。
プロマネをやるようになってから、いや、あるプロジェクトでの担当業務でのやらかしたときのインパクトを教えられたときからなのだが、準備での作業標準プロセスの洗練さを意識するようになった。
結果、準備期間が短くて、いくらシンドくても準備で手を抜くことをしなくなった。これを意識しないリーダやプロマネを見ると、コストと時間の感覚がないのだと思うようになった。
だからと言って、いつになっても結果を出さない方はもっとタチが悪い。あれがない、これがないなどと言って、始めないのは土俵に上がるつもりがないのだ。
あれこれないということを認知できているのであれば、リスク識別ができているということだ。始めるとしたときのリスクとその原因の所在をオープンに晒して、自分のミッションの裁量の中だけで初めてしまえばいい。
もしくは、グズグズせずに、中止の意思決定をしてしまう。これも始められない原因の所在をオープンにして、始めたときのインパクトを定量的に示し、始めること自体が自分の裁量を超えていると意思決定をエスカレーションするのである。
こうしたものの考え方は、決して難しいものではない。一つひとつは担当エンジニアやリーダエンジニアで実践で学んでいるだろう。
自分の担当する裁量を任せている人の目線で見ると、任せているのだからやって欲しいと思っているだろうし、やって欲しいのにやらないとするならとかやってみて上手くいかないとかとなったとき、どんな情報があれば理解は出来るかを考えると、バラバラのパーツを組み立てられる、かもしれない。
知の風邪の予防に、あなたは何を処方するか
ひどい風邪を引くと猫る。もとい、寝込む。
高熱はもちろん、中途半端な熱が出ると大人には辛い。市販薬なんて気休めにしかならないから服用してはいけない。素直に町医者の内科の開院時間をスマホで調べ、保険証と診察券（なければその場で作るので問題ない）と財布を持ち、マスクをして町医者にゆく。どうして町医者かというと、医者の処方箋の方が市販薬の10倍効くからだ。
検温して、呼吸にノイズがないかを調べられ、症状を聞かれて、３分か。インフルエンザの検査をすれば、もう少しかかる。鼻の奥にペロちゃんキャンディの棒のようなものでつっつかれ、ゲフンゲフンしてる間に陰性か陽性か結果を聞くことになる。
薬をもらい、帰り道にドラッグストアかスーパーに寄ることを忘れない。飲むセリーのパック、口径補水液的なペットボトル、ゼリー、杏仁豆腐、ティッシュ、マスク（箱買い）などを買い込む。ビタミン剤、チョコラBBやQPゴールドα的なものもなければ買っておく。そうするとやっぱりドラクストアの方にアドバンテージがあるか。
帰ったら、うがいをし、入念に手を洗う。20秒くらい。
症状がひどければ、飲むゼリーとビタミン剤をのみ、処方された薬を頓服する。枕元に着替え用のシャツ、パジャマかスゥエット、汗を拭くタオルを用意してマスクをして寝る。
寝る。
寝る。
スマホは置く。
寝る。
汗を掻いたら、着替え、屋内に乾燥付き洗濯機があれば洗剤を突っ込んで、乾燥機までのコースをセットする。
寝る。
ひどい風邪なのでこれを3日くらいやる。
間違っても間に仕事をしてはいけない。
寝る。
あと、処方箋は処方分を飲みきる。
3日経ってもさっぱり治らない時もある。
諦める。
寝る。
処方を飲みきる頃に、ようやく治る。
だいたい、３キロは痩せている。
この間、ほとんど栄養的なものは摂っていない。
体重が減るのは嬉しい。
ただ、これが知識だったら喜んでいいのだろうか。
これを無意識にやりかねないのが、仕事である。
恣意的に栄養剤のように摂らなければ体力からズルズルと栄養だけが減っていく。
知識は意図しなければ、機会も作れない。
意図すれば、機会は作れる。
知は誰にも奪えない。
ただ、意図して機会を作らなければ得られない。
風邪はもらい物だが、知の風邪は自分から引くようなものだ。
知の風邪の予防に、あなたは何を処方するか。
プロフェッショナル性のないマネジメントを目指しているとやがて老害になる
採用面談をしていると、マネジメントをやりたいと応募してこられるエンジニアがいらっしゃる。レジュメを見ると、中間管理職だったからとか、ステップアップとしてと希望を書かれている。こちらとしては募集要項をもう少しよくお読みになってから、希望するポジションが存在するかを確かめいただければ、お互いの期待のズレを確認するために使わなくて済むと思う。
エンジニアの場合、大雑把に2つに分類できる
- 技術のプロフェッショナル
- 事業を牽引するマネジメント
この分類自体、ありふれたものだ。ただ、キャリアとして後者を選ぶ場合、マネジメントを経験していたから、新しい組織でもとか、漫然とマネジメントになりたいと言われても、何をしたいのか全くイメージが持てない。
新しい組織での役割に、出来上がった組織、言い換えれば、手続きが多く、スピードが遅い組織では何をしているのかよくわからない役職に長やマネージャの肩書きの付いている役割の仕事をイメージしているとするならば、そんなポジションに外から人を持ってくる価値はない。
もともと、何をマネジメントしているかわからないようなマネジメントのポジションなって必要ないのではないか。
エンジニアな組織であっても、CEOから3階層を超えるような組織構造であったら、2層から最下位層のマネジメントのうち、仕事をしているマネジメントなんて半分くらいしかない。
そういったマネジメントには専門性がない。専門性を持つ部下のやることなすことにダメ出しかなんとかハラスメントをしているだけだ。だから老害と言われる。
マネジメントなら、事業を立ち上げる（0→1）、事業を強化する（1→10、10→100）など、事業のプロフェッショナルでなければならない。つまり、マネージャならマネージャの専門性を持たなければならない。ここでいう専門性とは、前年の実績をベースにexcelを舐め舐めしたようなものを事業だというような仕事っぷりではダメだということだ。事業のプロフェッショナルとしてのリーダーシップを発揮し続けれいなければ。
冒頭に挙げた後者の下線部の仕事を自分の仕事としてやっていなければ、エンジニアにとって障害でしかないし、老害にしかならない。
1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え
- 作者:エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2019/11/14
- メディア: 単行本
