「【翻訳】外注したら約400万円かかるシステムを、コーディングなしで自前でつくったお話」の裏にあるもの
タイトルを見て、エンジニアに出さずに内製化したのかって早合点していたのだが、読んでみたら、人ってバイアスを掛けて情報をみているのだな、と自分で自分を諌めるなどしている。
エンジニアになって数年した頃、知り合いの知人の建設関連の人で
『こんなのをPCで実現したいんだけどいくらくらい』
と聞かれ、何も話を聞いていないから『100万くらいですかね』と言ったことがあった。要件わからないで規模を言うのもアレだし、それが自分で作れるかもアレなのに、随分と適当だったなと冷や汗ものではある。
あと、世間を知らなすぎな感じはある。今なら話を聞いて、誰でも持っているものでできないか、そもそもいるのか的な方向に持っていくだろう。なぜなら、ITにポンと100万出すほどの規模ではないからと察しがつくためだ。
数ヶ月した後、知り合いからその話があって、結局、知人の方はexcelで自分で作ったと聞いた。引用の記事のタイトルをみて、それを思い出して、引っ張られた。
今の自分は、外に出すよりはエンジニアのチームを抱える指向性を持っているので、そうしたこともバイアスの1つになっていると思われる。自分のことであるが、意思決定は自分の過去の成功体験などの積み重ねで捻じ曲げられるから、思われるとしか言いようがない。
とは言え、何が何でも内製かと言えば、そうでもない。SaaSは使う。もう、全部SaaSでいいとも思っているが、属する組織の実現したいことがSaaSで実現できないものもある。そういったものやSaaSに置き換えられないものは内製化になる。
SaaSを使い始めると、引用記事のように情報が分散する。目的に応じてSaaSを選び、業務を行うから、結果的に情報は業務別のSaaSに収容される。
ここで問題が起きる。SaaSの乱立は手作業を生じさせる。どんな手作業かと言うと、転記やデータを手動で出し入れである。
これはオンプレと言うかシステム間インタフェース（連携）の話だ。
インタフェースを決め、csvファイルをHULFTを使ったり、指定のディレクトリにファイルを置いて、決めたサイクルでファイルを読みに行き、スクリプトで取り込むなどよくやるものだ。
令和になり、2020年にもなろうと言うのに、平成なことを今度はクラウドでやろうとしているのである。
でどう繋ぐか。no codeだZapierなどで業務担当が繋いだり、codeならAPIでエンジニアが繋ぐことになる。
話は脱線するのだが、microserviceの本をサラリと斜め読みして、『あー、大規模システム内のサブシステムの開発をリリースはときどき合わせて、あとはサブシステム毎に業務都合の裁量で開発しているようなものか」と解釈していた。
組織内の業務アプリがSaaSへ移行すると、業務システムのmicroservice化が起きる。もともとSaaSだから勝手に機能もインタフェースも変わる。利用者やエンジニアへの配慮はない。プロダクトの都合で進んでいく。
やっぱり繋ぐ仕組みが必要で、microserviceならAPIなのだがZapierなどで繋ぐのでもいいのではと思うようになった。
なにせ、Zapierを使ったり設定したりするのが業務担当なら、SaaSのバージョンが勝手に上がって、インタフェースのサポートが切れようなものなら、すぐにわかる。直接のユーザだから。
使えなくなったら自分で直せるからエンジニアに頼まなくていい。エンジニアはAPIでゴリゴリ繋ぐ方か内製化の組織内向けのサービスプロダクトに集中すればいい。
そのことを事象として語っているのが、引用の記事なのだと思う。
そしてそれが事業会社のエンジニアリングの進む方向なのだろう。
The Ultimate Guide to Business Process Automation with Zapier (English Edition)
- 作者:Benjamin Mulholland
- 出版社/メーカー: Process Street
- 発売日: 2016/09/26
- メディア: Kindle版
若手エンジニアを消耗させない
もう20年近く経つので昔話ではあるのだが、その組織のSIプロジェクトの人的リソース計画をみたとき、ちょっと衝撃を受けた。
どうしたのかというと
『若手エンジニアを都合よく使いすぎ』
で、
『これでは若手エンジニアは育たない』
と感覚的に衝撃というか違和感を覚えた。
多分に、会計的な観点でコスト計上を正しく行うことを要請され、それを遵守するためにプロジェクトの人員計画を工程毎の工数から、配分したためだろう。
人員計画を見ると、いわゆるプレイングマネージャのプロジェクトリーダがいて、そのロールは通しで工数を積んでいるが、詳細設計や開発、テスト周りの、いわゆる下工程は適用技術で分解して、幾人かの若手エンジニアに割り当てていた。
幾人かの若手エンジニアも信頼、要は過去の実績や作業品質から使いやすいエンジニアに多く任せていて、若手エンジニアの中でも経験の少ないジュニアなエンジニアはまるでアルバイトのような時間しか割り当たっていなかった。
これで何が起きるかを想像して欲しい。観点は、1年後、3年後、5年後と時間軸で想像するとイメージしやすい。
当たり前だが、
プレイングマネージャのプロジェクトリーダ ＞ 使い勝手のいい若手エンジニア ＞ ジュニアエンジニア
の順でしか成長する機会がない。ましてや、ジュニアエンジニアは、信頼貯金を得る機会自体が非常に少ないから、成長の機会がない。
プレイングマネージャのプロジェクトリーダは、こうしたやり方でやってきていて、それでそれなりにやってこれているから続けているはずだ。
ということは、やり方に工夫の改善もみられていないということで、経験ベースの固定観念で仕事をし続けて、実際には成長の機会を不意にしている可能性が高い。
この想像から容易に考えられることは、
- ジュニアエンジニアから辞める
- 成長しないエンジニアを育てる
しかない。
若手エンジニアが成長しない、技術力がないというシニアエンジニアやマネージャをよく見聞きするが、そう言った不満をいう、
エンジニアをアサイメントできる裁量を持っているロールにいるものが、その実態を、時間を掛けて作り上げていることに気づかなければならないが、そう言った観点を持っていないから、結果的に、彼らのいう『無能な若手エンジニア』しかいない状態になる。
マネージャは、プレイングマネージャのプロジェクトリーダがそうした人員計画を立てていたら、組織の観点で正すように改善を要求しなければならない。
場合によっては、組織がコスト負担しなければならないこともあるかもしれないが、それでも、将来の組織を実現するために、若手こそ成長の機会を作らなければならない。
そして、そうした成長の機会は、プロジェクトの裁量をもつエンジニア全員のミッションなのだ。
だから、人的リソース計画をみたとき、どれだけエンジニアが通して入っているかをチェックすることが、将来の組織作りに繋がるかを判断できる。
若手エンジニアをアルバイトのように便利に使って、成長の機会を与えず、消耗させるようなことを回避しなければならない。
中途採用が急に増えたとき既にカルチャーは衰退している
ダメかは知らないが、エンジニアが仕事をしたい組織かと言えば…。
SIerのような新卒一括採用をしているような組織では、ない悩みかもしれない。クラウドサービスをやっている組織では、新卒を育てている余裕はない（メガベンチャーか上場済みなら別だが）。
即戦力が欲しいから、jdを書いてポジションを用意して、採用も優先度を上げてリソースを突っ込む。
クラウドサービスなどのプロダクトを提供する大元のミッションがあり、プロダクトを育てながら培った価値観、（何度となく書いているが）意思決定の基準をカルチャーとして言語化し、カルチャーに共感する人だけを採用する。
ポジション、jdに書いたコンピテンシとレベルを出来るかを見極められなければ、組織は遠からず致命傷を負う。小さい組織にコンピテンシのないリソースは障害にしかならないからだ。
だから、採用時にプログラムなどの課題を出すし、そうでもしなければ思考の癖も最低限のスキルも判断つけようがない。キャリアシートと面接だけで採用なんてあり得ない。
採用の課題は、組織の現状のレベルである。採用する側は、自分たちより優秀な人をとらなければ、組織は価値を今以上、増やすことはできない。よくできて、連続したイノベーションで精一杯で、非連続のイノベーションはおき得ない。だから、衰退し始めるのである。
採用される人、応募する側も、自分のやりたいことを持っていなければ、募集しているポジションでスキルをパフォーマンスすることはない。実現したいことがなけれが、採用後の推進力を見つけるところから始めることになる。そんなことをされては、組織はやはりダメージを負う。
肝心なのは、採用候補者がカルチャーフィットするかどうかである。組織が若いうちはカルチャーフィットしないと採用後の仕事のあらゆることでストレスを被る。これはとても辛い。
カルチャーは意思決定の基準だからである。
これだけの条件を満たす採用候補者だけをとらなければ、組織の価値観は自ら減衰させてしまう。
私見であるから、さてどうやら。
人生のハンドルを渡されたことに気付いたとき
ある平日、メッセンジャーにて。
友人「今日の夜食事どう」
自分「（うーん、作業しようと思ってたけど平日は珍しいな）どうした」
友人「君のこと話したら、話してみたいという人がいて、食事でも」
自分「（2時間くらいか）いいよ、どこで」
予定していたことがあったのだが、会いたいというのも面白いと思い、予定していことは先送りして。
これはこれで締め切りがしんどくなるのだが。
待ち合わせ場所にいってみると若い風貌のひとと見間違えることもない友人の2人連れ。
自己紹介をしてお店に。
友人がいるから飲むのかもと予想をしていたら、案の定、友人はハイボールを飲むのだそうだ。じゃあ、いいかとこっちも輸入ものの瓶ビールを選ぶ。会いたいを言ってきた人は生ビール。
店員に促されてw、乾杯をしてから、つまみを。この会いたい人、チョイスが少し独特。面白いのでその人と友人に選択は任せる。
会いたいと言ってきた人の素性をバラせば、若者である。どこかで友人と繋がっていて、何かのきっかけで自分のことを知ったのか、友人が意図的に話したのか。
自分「それで何を話したい」
若者「いろいろとやられていますけど、直近で始められたのはどういった経緯で」
自分「以前経験していたことがあって、それを久しぶりに再開したら理由はわからないがいい塩梅に仕上がって、それを続けてやっていたら途中で失敗した。その失敗をみせたの、プロに。で、プロは一発で原因を見抜くんだね。で改善し続けたの。でもまだ勘でさ。それをエンジニアリングしたの。あとプロダクトマネジメント。で続けてる。それだけ」
若者「はあ」
友人「急にクオリティがね上がったね」
自分「やっている方は継続してやっているから自覚なしだけどさ」
このあと、ポツポツと話す若者の、脈絡のない質問にただ「若いな」と「このくらいの年齢なら自分のときよりも優秀なんだろうな」と頭を過った。
若者の質問を集めて、煮詰めると、自分は何をしたらいいか、ということのようだ。
若い時間が、一番勉強出来る。知識をためるにはいい時間。外に出て、体験をするにもいい時間。
気になることは自分で試してみるにもいい時間。
この２つだけ、話す。あれこれしろとか、長々と話したりしない。
結局、将来自分は何をしたらいいかの教えを欲しているのだろう。知らなければ、選べない、知るためには良い時間を持っている。人生で、一番多く持てるタイミング。
今までは誰かが選択肢を教えてくれた。
でも、これからは、自分で決め、結果を出す。きゅうに、ポンっとハンドルを渡された。
戸惑っているのだろうけど、これからは自分でハンドルを握り続ける。
道はどこかに繋がっているから
プロジェクトについて語り続けたい
プロジェクトマネジメントが好きだ。何を今更と思うかもしれない。まあ、ポジトクというやつである。ただ、PMBOKは版を重ねるごとに厚くなるし、どうしてそうしたかよくわからないこともするから、割とどうでもいい。
ああ、実はプロジェクトマネジメントが好きというよりは、プロジェクトマネージャのロールが好きなのかもしれない。とはいえ、あれこれとプロマネのロールであれこれ指示をするのは面倒臭い。自分でやってしまいたい。計画を作り、マイルストーンを置いて、ここまでにこれだけは最低限やろうと、バックログ的なものを決めてやるものはやり、できたらいいはなは無理してやらない。それでいい感じであれば満足だ。
じゃあ、チームは嫌いか。そんなことはない。相談できる、自分よりも優秀なエンジニアのいるチームはいい、バッサリと鉈で切り裂くくらいの切れ味がいい。笑顔なのに、不用意な質問を投げると鉈が頭の上から落ちてくる。マサカリなんてスピードがない。鉈だよ、エンジニアの装備は。そんなチームならいい。でも一からチームをビルドするのはやっぱり面倒だ。
じゃあ、チームは嫌いかだって。メンバのキャリアパスを一緒に考えるのは好きだ。あれこれ押し付けるのではなく、選択肢を示したり、伸ばす候補のスキルを確認したり、どの仕事で、どのロールで、どんなコンピテンシを伸ばすかの相談を受けるのは好きだ。さらに、メンバが成長して、なんなら自分を追い越すくらい優秀なメンバでもいい。キャリアでもプロジェクトでも制度設計でもプロセスをデザインし、自分で食べ、デザインを洗練させていくのも好きだ。プロセスデザインをできる人はだいぶ世の中に少なくなったらしいのだが、それが本当なら自分は絶滅希少職種かもしれない。大事にしてほしいものだ。
大事にして欲しいほど自分が好きかというと10代は大嫌いだった。学力もプアで知識も少なく、ただ、バイトだけには精を出していた。価値を見極められず、時間やお金を無駄にしてきた。じゃあ今も嫌いかというと、そんなことはない。50歳前あたりから、いや30歳後半からいい感じになってきた。もちろん、自分のキャリアをデザインし、ゆるくプロジェクト的に、でも継続的に、段階的に自分をマネジメントをしてきた。その結果がまあまあだな、という感じだ。
おや、やはりプロジェクトが好きだったのかもしれない。でももっと好きなのはワイフである。
言われたらそのとおりやらないといけない病
スケジュールを確認する前にメンバが席までやってきて、打ち合わせしましょうと打ち合わせスペースまで連行られる、そんなある日の午前中。
打ち合わせテーマは、テコ入れで首を突っ込んだプロジェクトの2つ目のアクテビティをどう進めたらいいかという相談。
どう進めようと思っているかを聞いてみると、うむー、どうしてそう思うとか、それはこっちで決めて仕舞えばいいじゃないかとか、アクテビティで扱うタイミングと対象のチャンクの話じゃないかとか、どっちでやったとしても結果は一緒だぞとか、ファシリはどっちが実現的かとか、思う。
一番気になったのは、インプットになる前工程のアクティビティの結果に対する、受け止め方である。
エンジニアに限らないのかもしれないが、ある場での結果と、そのある場の前に自分たちで想定していた仮の進め方と違うと、そのある場で決まったことを正として「変えられない」ものと捉える人がいる。
元々こうやって進めようと仮説、つまりこうやればうまくいくだろうと仮の進め方を組み立てていた。それが前工程で作業対象に一つ属性が加わった。
自分たちのやりたい結果は全く影響しない。ただ、途中のアクティビティでの取り扱う対象の単位を元々の粒度でいくか、それとも追加した属性でやるかという話でしかない。
相談してきたエンジニアは、追加した属性で後続のアクティビティをファシリしないといけないのだという。
でも、
・目指すゴールは変わらない
・追加した属性はチャンクの粒度であって階層が増えるだけ
・ファシリする裁量はこっち
なのであれば、追加した属性なんぞ、気にする必要はない。結果は変わらないのだから。
これがゴールを変えるほどのインパクトのある観点だったら、後続のアクティビティlを見直す必要があったかもしれない。
でもそんな影響は1ミリもない。制約を自分から掛ける意味はない。無駄。
誰かが何かを言ったらそれを全部汲み取る必要があるかどうか。それを考えられない。そんな考えを持っているから、自分で書いた筋書き通りに進まないのである。
ゴールに影響するなら話は別で、どこまでどう対応するか筋書きを書き直しなければいけない。
でも、そうでないのなら、いちいち対応しなくて良い。これが処方箋。
そういう判断をしてもいいという考え方を持っていないと、とても辛いと思う。
