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はない。
ましてやそれにアジャイルを使う意味はない。スコープが決まっているのだから、ウォーターフォールでやった方が失敗は少ない。
あれこれやるとして、それに投入するコストに見合うリターンがなければやる意味はない。
そこに作らない選択肢、である。
毎回このカードばかりきっているとそのうち誰かに怒られるだろうが、それでも作ることで意味がないなら作らない方が良い。
80'sのYOKOHAMA ASPECのCMが素晴らしい
エンジニアと権力
エンジニアに必要なのは権力である。権力とは職務上の裁量であり、職位を上げれば裁量の幅は増える。
あの開発手法をやりたい、この手法をやりたいと言っても聞いてもらえない。
OK。だったら、少し遠回りかもしれないが権力を手に入れよう。そのための活動に励もう。それが嫌なら自分でそのやりたい開発手法を取り入れている他社を探し、移ればいい。だってやりたいのだろう、であれば、そのどちらかを選ぶ他ないだろう。選ばないのだとすれば、その程度の思いでしかないということだ。
もう一つ、やり方はある。自分のタスクだけその手法を適用すればいい。もちろん、見かけ上は他のメンバと同じようにインタフェースを維持しなければならない。二重管理になるかもしれないがやりたいことのためならやれるだろう。それも嫌だというなら、ますます持ってその程度の思いで騒ぐな、と言いたい。
どのアプローチにするかにしても、共通しているのは覚悟と策を自分の頭で考え、結果に責任を持つということだ。
権力とは、組織上の制度に紐づくものだから、権力を手に入れるためには組織の構造を知らなければならないし、それは誰かが教えてくれるものではない。そうしたことも自分の実現したいことに対する思いと秤にかけて、決めれば良い。
どうなるか誰にもわからないものに、自分で責任を持つ意思決定するだけの話だ。
こんな風に書くと、萎えてしまったり、腹がたつかもしれないが、その気持ちの矛先は、自分であることに気づかなければならない。何もできていない自分を無闇にせめているだけだ。
それはとても無駄なことだ。凹んでいる時間があるなら少しだけ、調べられる範囲で調べれば良い。そこそこの組織であれば、職務や組織の決まりごとが共有されているはずだ。
決まりごとと実際の組織をみて、どういう構造になっているか、人事報を見て、どのくらいのサイクルで世代交代をしているか。そうしたことも知ることでどのようなアプローチを選ぶか補助情報となる。
エンジニアが成果の出やすいやり方を選ぶことが望ましい。それには権力が少なからず必要である。
さん付けと愛称の距離感
経験に基づく感覚でしかないのだが、腹を割ってストレートにものを言い合える相手の呼び方があると思う。
進捗を気にしていたプロジェクトがあり、進捗がまずいとある意味正しくプロマネを飛び越えて、そのやばさ加減を知ったとき、フレンドリーに顔を出すようにして裏をざっくりと掴んで、プロマネとこれどうするつもりかと聞いた。
プロマネは自分の感覚で（全部ものが丸く収まって＝次工程に必要なものは一揃えするまるでお花畑のような世界）目一杯工程のギリギリを示すから、現状からあり得ないだろう、五月雨で解決してもひと月前にはコア部分が定まらないと進められらないと指摘すると、ムキになって議論をし始める。
もともと愛称で呼んでいたから、過去にも意見がぶつかることはままあったのではあるが、愛称で呼び合うくらいに相手に思いをぶつけられる仲だったから、グサリと急所を指摘して、プロマネも取り繕うこともなく、素直に話を聞いてくれたのかもしれない。
これが苗字＋さんだったらどうかと思うと同じような結論にたどり着けたかはイメージできない。互いに仮面を被り、お行儀よく、言葉を選んでいたかもしれない。
要は、相手のパーソナルスペースにどこまで入れて、相手に多少不快感を与え（それはそうだ、本人は上手くやろうとしているのだから）ながらも、耳を貸してくれなければ意味がない。
そこには相手に対してのリスペクトというか、形式張りすぎない個人の尊重がベースにある。あの人が言うからではなく、個人の意見はまず受け止める。その上で、違う意見を持ったら違うと言う。言う必要があれば。
これは仕事ばかりではなく、家庭でも同じで、特に夫婦の間でも同じかそれ以上なのだと思う。
自分はワイフを名前で呼ぶ。これは結婚する前からそうだったし、結婚してからも変えていないし、変えるつもりはない。いつまでも、愛称で呼ぶ。
子どもさんたちのご両親は、子どもさんと同じようにパパママと呼び合う風景をよく見かける。いや、ほぼ、そう呼んでいる。改めて考えると、パパママという呼び方には個人が無いように思えてる。子どもさんたちの父親、母親という意味合いとしか受け取れない。
愛称で呼ぶことは、個人であることを理解し、尊重している。そうすることで相手から相談をしてもらえる資格を作っているような気がするし、相談を聞いてもらえる対等な立場のベースになっているような気がする。
くだんのプロマネもワイフもそうなのだが、自分の考えのベースにそれぞれが役割を担っているだけのことで、立場は対等であると信じているからもしれない。
それでも馴れ合いにならないのは、役割をになっているというのあり、それのバリューを発揮していないとそれなりにグサリと切り込むからかもしれない。
ただ、ワイフ様にはそれはしない。
内製化でやりたい気持ち
SIerだと受託になるので、契約を介して委託元とプロジェクト業務を分担する。得てして、RFPや見積もり依頼書がザルだとリスクてんこ盛りでコンテンジェンシを山のように盛らざるを得ない。顧客第一とかカスタマーサクセスと言いつつも、契約は最後の砦だから、掛け声と実態の溝は埋まらない。ここを上手に運用するプロジェクトマネージャは手練れであるから委託元も手羽さない。
一方、委託元である事業会社の立場で見れば、自分たちでできない技術領域やリソースを確保できないから業務委託をするのであり、事業会社のプロジェクトの成功（実現したいことを実現する）のために、それを一緒に実現してくれる業務委託先とやりたいと考える。
SIのプロジェクトをSIerの立場で意識していたのは、プロジェクト全体として成功するための意思決定かどうかだ。もちろん、契約以上のことをしてしまうと利益供与になってしまうし、大概そうしたことをすると小さなことが大きくトラぶる。良かれと思ってやったのに、というアレである。
そうならないように念頭にあることは忘れずに、上手にバーターをするとお互い納得感を得られてプロジェクトも回せる。その追加でやりたいと言っている課題をうちでやるなら、もともとうちでやる作業のここを同じ程度の工数だから、引き取ってくれないか、的なイメージだ。
SIerでも事業会社でも自社のみのリソースで賄えない規模だと業務委託にjoinしてもらう。やはりここでも契約をベースに業務を委託することになる。これはこれで良いというか当たり前なのだが、何せプロジェクト全体での成功をしたいと思っている自分と契約の範囲を我武者羅に履行しようとするから壁を作られる。いくらスコープを変えるときは再契約なり、追加発注するからと言っても壁はなくならない。
別な面で見れば、発注サイドの自分たちでできない業務の委託をするということは、委託契約が終わったら、それを引き継がなければならない。言い換えれば、業務委託を開始する時点で、指示をしなければならないし、終わった後は自分で面倒をみる覚悟をしなければならない。
フリーランスを何度か使ったこともあるが、たまたまなのか、体系的な開発手法を知らないことが散見された。SIerのエンジニアの方がいいのかというとそう簡単に割り切れるものでもない。SIerのエンジニアは分業だからフルスタックでできるエンジニアは少ない。やはり自分の担当領域をやることで一生懸命で、全体を俯瞰していない。それにSIerだと工数のボリュームが出ないと受けないこともままある。1人だけ優秀なエンジニアを出すわけにはビジネス的にはできないからだ。
こうなってくると、ものすごく業務委託を使うことにメリットを感じない。条件さえフィットすれば手軽に始められるが、ものすごく面倒でしかない。だから、ついつい内製化でやりたい気持ちになってしまう。しかし、なかなかチームのカルチャーに合うエンジニアと巡り会えない。
