停滞する大企業と成長するスタートアップ
生産性の上がらない重厚長大でグローバルな大企業と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
- メディア: 単行本
20年代にオタマジャクシなエンジニアは生き残れない
若い事業会社を眺めていると、即戦力かポテンシャル採用だから、どちらにしても持っているスキルを発揮することを期待して採用されている。ゆえに、採用されたエンジニアに組織の中で教育を行うことはしない。リソースは全部、事業へ振り、短期間に成果を発揮することだけを求められる。
こう書くと、そんなことはないと思うかもしれないが、そうでないことは以前に述べた。
SIerの体力のある組織では、今思えば極めて長期間の研修期間を設け、コンピュータサイエンスを取っていないオタマジャクシな新卒学生を促成栽培する。途中、成果発表や卒検のような試験を経て、一定の水準に育った新人エンジニアは、組織により3ヶ月、6ヶ月、9ヶ月と手間と時間とコストを掛け、配属部署に出荷される。
新人エンジニアの希望と配属部署のマッチングはどうかと言えば、それなりでしなく、新人エンジニアの方で希望が実現されないとわかるとさっさと外の市場へ自ら流れてしまう。やりたいことをイメージできていて希望を明確に持っているエンジニアや技術に自信を持っているエンジニアの方がその傾向は高いのではないか。
自分のやりたいことを具体的に言語化でき、それを実現したいと思いのあるエンジニアは、他のことにおいてもとても可能性を持っている。例えば、近頃はプロダクトマネージャをやりたいと採用に応募していくるエンジニアは多い。しかし、プロダクトオーナになって何を実現したいかと尋ねると、課題を解決したいというピント外れの答えをするエンジニアが散見される。
繰り返し書いていることに、これから必要とされるエンジニアは、具体的なオペレーションをITに置き換えてくれる人ではない。そこはよりITがコモディティ化し、EUCで解消されるセグメントだ。複数の課題をまとめてITで解決するエンジニアが求められる時代がすぐ目の前まで迫っている。
そのときになってSIerのエンジニアは少し困るかもしれない。あまりに分業をしすぎているからだ。1つの部署の同じ業種インダストリや技術領域ばかり、ましてや1社のシステムばかりしていると、その中ではそこそこかもしれないが、価値を評価する市場はそこだけになってしまう。
そういった背景からかどうかはわからないが、ゼネラリストを目指す若手エンジニアがチラホラといるそうだ。事業サイドに移りたい意向を持っているのか、プロダクトを一人でやりたいと思っているのかもしれない。まあ、単純に1つの技術だけで乗り越えられるかなんて誰も保証してくれないのだから、組織に対するリスク対策のなのかもしれない。
もし仮に、ゼネラリストなエンジニアを目指すなら、これなら誰にも負けないという柱を1つ、2つ持っていて欲しい。それがないとシニアエンジニアになったとき、専門性がなく、メッキの技術であることがすぐにバレてしまう。例え専門性が違うエンジニアであっても、問題解決へのアプローチや問題解決の計画の立案などで共通的で基礎的で高度な基礎スキルを求められるときのアクティビティで見切られるからである。
それよりはゼネラリストを選択しようと思ったきっかけが、メディアの記事や有名な誰の発言だったりしたら、それが自分の望むことかもう一度考えてみて欲しい。そのパスを選び、上手くいくときはいいとして、上手くいかないときのリカバリの方針くらいは考えておこう。どうせ思っていたこととは全然違うけど、修正しながらキャリアを実現していくのだから。
さて、事業会社に中途採用されるエンジニアは教育されないし、SIerは配属後に色々と困りそうである。ではどうしたらいいのかというと、そういう仕組みであることをまず知ろう、しかない。仕組みを知った上で、自分で判断する他ない。でも知っている分、生き残れるはずだ。
えっ、配属でドナドナされたエンジニアはどうすればいいのか、だって。オタマジャクシだったエンジニアはゆっくりとボイルされるのさ。
京都市基幹系刷新の2度の失敗でPOは何を意思決定したのか
20歳までと言うのは綾だが、でも実際にそうだ。正論や手法をそのままやれって言うのは、守破離の種の段階か、身につけるときの話であって、実際の運用に入れば正論なんてなんの役にも立たないし、邪魔にだけにしかならない。
技術で商売をしているエンジニアは意思決定の連続でものを作っているのだから、それをわかっていればなさなければならないことは正論を言うのではなく、意思決定だとわかるだろう。
この京都市の基幹システム刷新プロジェクトは、一度失敗してやり直しをしたものだ。そもそも、この仕切り直しの案件をC社が応札したことに驚いた。てっきり、どこも手を挙げないか、大手コンサルがいいようにするのかと思っていた。
それはさておき、現行システムがあり、新システムがある。失敗したプロジェクトの成果物はあり、現行システムのドキュメントも官庁だからあるだろう。ドキュメントがないとしても、コストを掛ければ現行システムをコードからドキュメントに起こすこともできるし、実際、やっていただろう。
ちょっと調べたところ、失敗した最初のプロジェクトでは、新旧照合で不一致だったところが合意できなかったらしい。仕切り直しのプロジェクトも同じなのだろう。
でも、おかしいと思わないだろうか。稼働している現行システムと稼働しているコードがあり、そこには業務ロジックも存在するのである。どうせ現行システムと同じにとしか言わないだろうから、それを仕様とすればロジックは再現できる可能性が高い。
それでも完全な再現は無理だろう。
ここまで相当の時間とお金を使ってきた。これは事実で、これからもコストを受け入れられるなら今のままズルズルと何度もエンドレスサマーをハルヒのように繰り返せばいいのだが、多分保守切れか特別延長しているACOSのHWの方が根をあげるかもしれない。
どんな規模のトラブルプロジェクトでも、最重要なのは意思決定である。
どうしても現行システムと新システムとの現新照合を一致させたければ、一致しない処理のロジックを現行システムは市の担当部局に説明させる指示を意思決定すれば済む話だ。この意思決定により、結果的に担当部局に要件を説明させることになる。新システムの仕様は明らかだろうから、机上で、同じデータを使い、同じ結果になる説明をさせれば良い。説明できなければ、根拠のない主張だから退け、新システムを採用するかを判断すればいい。
現新照合で一致ない→要件を出せ、ではなく、進めるための意思決定をプロジェクトオーナがせよ、である。
多分に、POは名ばかりで、全部下々に押し付けているような気がして現場が不憫に思えてしまうのだが。
アジャイルネイティブな時代と
仕事場でも自分の子どもさんと同じくらいの若者が多くいる。数年の違いだからほとんど同じようなものだ。そんな中にオーバー50歳のおじさんエンジニアがそれっぽい格好をしているものだから、会釈をしてスルスルと目の前を過ぎていく。
執務室なのだし、どこであっても不思議ではないのだから会釈なんていいのにと思うが、どっちにしても今の若いエンジニアは能力も高いし、ちゃんとしている。自分の同じくらいの年頃と比べるのは失礼とこちらが思ってしまう。
アジャイル開発の中でもっともいいところは、『それ作る必要あるか』というように何でもかんでもシステム化しないというところだ。
作らない選択肢の存在。
ウォーターフォールはスコープが固定されている（厳密には違う）から、作らないという選択肢はない。以前参画したことのある大規模なシステム開発では、開発途上で開発を止め、残置するという扱いがあったのをみて、そのときは意味がわからなかった（あとで大人の事情ということがわかった）。
契約書上、作ると記載があれば作らなければならないし、納品してもらわなければならない。監査で指摘されるからだ。
DX、DXと某が煽り、それでIT投資は旺盛なようである（青い銀行のプロジェクト終了で冷えるかと思っていたのに）。ただ、そのDXも単なる業務のIT化ではOAしているだけで昭和のままだ。ToDoを解決するだけでは、どこにもDXはない。
ましてやそれにアジャイルを使う意味はない。スコープが決まっているのだから、ウォーターフォールでやった方が失敗は少ない。
あれこれやるとして、それに投入するコストに見合うリターンがなければやる意味はない。
そこに作らない選択肢、である。
毎回このカードばかりきっているとそのうち誰かに怒られるだろうが、それでも作ることで意味がないなら作らない方が良い。
