「 ITエンジニア採用入門」を読んで採用活動の全体像を学ぶ

最近エンジニア採用に関わる機会が増えました。エンジニアリングマネージャーとして、採用プロセス全体を機能させチームを組成する能力を獲得したいと考えており、その足掛かりとして面接官の役割を積極的にアサインしてもらっています。それなりの件数をこなして学ぶ土台ができてきた感触があるので、このあたりでエンジニア採用の全体像を学ぼうと考えました。

採用に関する書籍は数多くあり、どれを自分の教科書とするか迷いましたが、以前見つけてブックマークしていたITエンジニア採用入門がよさそうに見えました。自分が関わる採用市場とかなり近い文脈で、具体的な情報がエンジニアの目線から簡潔にまとめられています。全体像を学びたい自分にうってつけの資料です。これが無料で読めるのは本当にありがたいことで著者の方には頭が上がりません。

主要な学び

EVPとアトラクト

ITエンジニアの採用は競争が激しく、採用プロセス全体を通して「自社を選んでもらう」ことが重要になります。そのために自社特有の価値（EVP, Employy Value Proposition）をよく整理し伝えることが重要です。また、候補者の動機づけ要因や衛生要因をよく把握し、そこと自社のマッチングの様子を真摯に伝えることも重要になります。自分はこれまでハードスキルとソフトスキルを掘り下げることにフォーカスしすぎており、こうした部分が疎かであったと感じます。マッチングやアトラクトに関する部分を選考の後ろの方にまとめ、選考結果に影響しないことを明示してリラックスして実施するテクニックも紹介されており、これはぜひ実践してみたいと思いました。

採用プロセスを改善する時の考え方

今回のインプットで、採用改善の大きな前提として採用計画が存在することを強く認識しました。際限なくスループットを上げて多くの人を採用するのが必ずしも良いわけではなく、あくまで事業計画とセットで考えるべきだということです。とはいえ競争の激しさを考えると、採用数の目標を達成するのが簡単ということは滅多にない気もしますが、とにかく採用計画ありきで、量的な改善なのか、質的な改善なのか、いまどれくらいの頑張りが必要なのかといったことを考えるのが良いだろうと認識しました。

また質と量のバランスについても特徴があるように感じました。組織もプロダクトも人が形作るもので、採用においては質の面での妥協が致命傷になりかねません。本当に来て欲しい人に来てもらえるハイクオリティな採用活動を維持しつつ、徐々にスループットを上げていくような、丁寧な改善活動が重要と思います。

エンジニア組織の活動に対する解像度の向上

採用広報の観点で、エンジニア組織がどういった活動をするかは非常に重要になります。エンジニアブログや、セミナー、登壇時の費用補助などさまざまな施策が自社に存在することは知っていましたが、採用への解像度が上がることで、それらの活動に対する解像度も上がったように感じます。たとえば、採用したいペルソナから逆算して、いま組織から足りていないのはどういう種類の発信かといった切り口で考えられるようになりました。もちろん種々の活動の目的は採用だけではないので、広い視野で考えることが前提となりますが、長期目線でどういう力学を作っていくのかを考えるきっかけにはなりそうです。

まとめ

「 ITエンジニア採用入門」を読んで得た主要な学びを整理しました。本記事では特に自分の思考が広がった部分について書きましたが、他にもエンジニア採用に関する基礎的な情報を多く手に入れることができました。1、2時間ほどで読める資料なので、採用に関わるエンジニアはぜひ一度読むことをオススメします。

エンジニアリングマネージャーの最初の学び - このロールは何なのか

2023/6/16付の人事異動で正式にエンジニアリングマネージャー（以下EM）になりました。2021/8に「エンジニアリングマネージャーを目指す若者の戦略」という記事を書いて明確にEMを目指し始め、2022/12には「EMキャリアを切り拓く「最強の現場リーダー」という働き方」という記事でEMに近づく様子を書きました。さらにそこから半年余り、ついに会社からも正式にEMと呼ばれることになりました。実際には3ヶ月ほど前から強くEMを志向した動きにはなっていましたが、やはり正式な職位は特別なもので、キャリアにおける重要な実績をひとつ解除したと感じています。

これほどEMというロールを志向し色々とやってきたのですから、EMとしての振る舞いもさぞスムーズに立ち上がるかと思いきや、実際にEMとして動くのは非常に難しいことでした。書籍やブログ記事を読んで頭で理解したEMという働き方と、自分がチームでEMとして振る舞うということの間には大きなギャップがありました。3ヶ月ほど苦しんで、最近ようやく自分の中で「EMとは何なのか」という問いに整理がつき始めたので、この記事ではそうした学びをまとめていこうと思います。

EMとは何なのか

「EMとは何なのか」にひとことで答えるなら「組織の目標達成に向けて組織の成果を最大化するエンジニア」が私のいまの答えです。よって、EMは自分が責任を負う組織に良い目標が設定されているかを真っ先に確認するべきだと考えます。目標がなければ達成も成果も何もないわけですから。ここが不足しているなら、まずは上司やPOといった共に目標に責任を負っている人と対話をし、場合によっては自らの手で目標を掲げる必要があるでしょう。

EMの日々の振る舞いとしては、目標達成に近づくあらゆるアクションが正解になり得ると考えます。EMは「組織の目標達成に向けて組織の成果を最大化するエンジニア」であって、手段によって定義されるものではないという考え方です。ここに形式的な正解を求めると、マネージャー論やリーダーシップ論、その他の関連領域が無数に広がっており、とても学びきれない大海に放り出されてしまいます（私は実際に航海に出て3ヶ月ほど彷徨い続けました）。それよりも、少し近視眼的に、組織の目標達成のために必要な手当てをしていくとだけ腹に決めて始める方が、地に足のついた振る舞いをできると感じています。だからこそ最初の目標設定がより一層重要です。自分が組織の目標を心から納得し、その目標に没頭できていれば、課題は自ずと感じるものですし、ちょっとしたプラクティスの再発明くらいは案外できてしまうものです。

とはいえ手札が多いに越したことはありません。課題に先立ってベストプラクティスから始めていけないという法はないですし、スタート地点が良い方があとの課題を解決するのも簡単なことが多いです。EMの有力な手札をマネジメント領域に分類し網羅する試みはいくつかあり、私は以下の2つを見たことがあります。

• エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド
  • テクノロジー、プロジェクト、ピープル、プロダクトの4領域
• Engineering Management Triangle
  • テクノロジー、プロダクト、チームの3軸と各軸の間

私は特に前者を自分のメンタルモデルとして活用しており、マイスキルマップでエンジニアとしての己を見つめ直すでは自分のスキルを4軸に当てはめて整理しました。最近はエンジニアリングマネージャーに関する書籍も増えているので、そうしたものも参照しつつ、なんらか自分なりのメンタルモデルを持ち、自分の興味や得意、組織の課題に合わせて少しずつ手札を増やしていくしかないと考えています。

チームとメンバーを機能させ育成すること

経験と知識が豊富なシニアな存在として「組織の目標達成に向けて組織の成果を最大化」しようと考えると、持続可能性やスケーラビリティの観点から、委譲によって仕事の実行を手放していくことが最適解になる場面が増えていきます。また、組織の目標を志向する過程でそれをエンジニア個人の目標にブレークダウンする責任も同時に負うことになったり、より広い意味でのマネージャーとして人事評価や育成を任されたりもします。こうしたことを考えると、EMを手段によって定義しないと述べたものの、チームとメンバーを機能させ育成することは実質的に必須の仕事になると考えます。

「結局EMはピープルマネジメントをするロールじゃないか」という声もありそうですが、私はそれは芯を食わない指摘だと考えます。あくまで手札のひとつであることに変わりはないですし、そもそもどんな道を進もうが、経験と知識を備えて大きなことを達成しようと考えた時、人を育てて必要な仕事をやってもらうことは必須の技能であるはずです。マネージャーだから人を育てる仕事が求められるというよりは、そのロールに期待される規模の成果を出すには、自然と人を育てることが正攻法になってくるのだと理解しています。テックリードやICのキャリアを歩む人も同じ景色を見ることになるはずです。

以上の思考からチームやメンバーの育成に向き合うことに腹落ちしつつある私ですが、実際に取り組んでいくにあたって重要だと認識したことがふたつあります。

ひとつは対象の状態にあわせたアプローチを行うことです。何かひとつ固定の振る舞いをするのではなく、相手がジュニアなら手厚くティーチングを行い、相手がシニアなら自律性を引き出すコーチングを行うといったことです。こうしたやり方は、エンジニアリングマネージャーのしごと3章の委譲に関する議論や、エラスティックリーダーシップモデル、SL理論など様々なところに現れており、現代のベストプラクティスとして意識するに値するでしょう。また、対象の状態に合わせたアプローチを行うためには、対象の状態をよく把握しなければなりません。観察や傾聴といったメタスキルも同時に重要になってくるはずです。

もうひとつは、狙ったマイクロマネジメントを行うには強い意志が必要だということです。新米マネージャーが意図せずマイクロマネジメントを行い、メンバーの自律性をつぶしてしまうというのは良くある失敗談ですが、ひとたびマイクロマネジメントから離れると、今度は狙ってそれを行うのが非常に難しくなると感じます。理由はいくつか考えられます。丸投げしてしまった方がやることも考えることも少なくて楽ですし、その間に自分は自分で他の仕事ができるのでリソース効率が上がるように見えるし、理論的には手放している状態の方がハイレベルなので（機能していなければ全く意味がないのですが）そちらを目指したくなるという心理もあるでしょう。マネージャーをマイクロマネジメントから遠ざけるバイアスが様々あるという前提で、強い気持ちでマネジメントスタイルを選択していく必要があると考えます。

まとめ

会社のロールとして正式にEMになったこのタイミングで、改めて自分の経験と知識を踏まえて「EMとは何か」という問いに回答し、自分が思う姿から必然的に導かれる「チームとメンバーを機能させ育成すること」について論じました。

2年ほど前からEMを志向し、多くのインプットや素振りを行った自分ですら、いざEMというロールを受け取ると難しさに直面しました。まして準備のないエンジニアを突然マネージャーに任命するとなれば、大変な混乱と衝撃がもたらされることは想像に難くありません。自分の後に続く人を増やしていくためにも、組織として計画的なマネージャーの育成が重要になっていくはずなので、今後もEMや関連領域に関する学びを発信していこうと思います。

開発手法「カンバン」について学んだ 〜スクラム実践者の考察を添えて〜

自分のチームでスクラムからカンバンへ移行する機運が高まっており、本格的な取り組みに向けてザッと勉強したのでまとめる。

カンバンとは

カンバンとはトヨタ生産方式に由来するソフトウェア開発手法（ないし、より広く適用可能なプロジェクト管理手法）のことである。ソフトウェア開発の文脈では「スクラム」や「エクストリームプログラミング」と同じ箱に入っている言葉と捉えると良い。具体的には以下のような手法である。

• ボードにバリューストリームを表現しそこに仕事の状況を可視化する
  • 「TODO」「DOING」「DONE」などのレーンがありアイテムが並んでいるものを想像すると良い。カンバンという手法を離れて、そういったボードだけで「カンバン」と呼んで使っている現場も多くあるだろうし、「スプリントボード」といった名前で運用している現場もあるだろう。とにかく、よく使われているあのボードを想像すれば良い
• レーンごとに置けるアイテムの量を制限する（WIP制限）
  • カンバンはリーンやアジャイルを志向した手法である。リードタイムを短縮しフロー効率を高めるために、各レーンに置けるアイテムの量を制限する。たとえばDOINGレーンのWIP制限が4で、DOINGレーンに既に4つのアイテムがあるとしよう。このとき新たなアイテムを持ってきてDOINGに入れることはできない。DOINGに入っている自分の仕事を先に終わらせるなり、他の人を手伝うなりして、まずはDOINGレーンを空ける必要がある。このようにフロー効率を高める振る舞いがWIP制限によって自然に導かれる
  • この制約を満たすようにボードを更新しようと思うと、アイテムの移動は自然と「プル型」になる。つまりバリューストリームの下流から上流のアイテムをプルする形でレーンの状態を更新する。プルできる条件は「下流側がWIP制限に当たっていない && 上流側に完了条件を満たしたアイテムがある」である。このいずれかが満たされないことは、そのままフローが詰まっていることを示す
• デイリースタンドアップミーティングを実施する
  • ボードが見える状態で全員が集まる時間を毎日設けるのはカンバンの明なルールだ。そこでの議題はWIP制限によって明らかになったブロック要因を排除することである。もちろんチームに合わせて他のことを話しても良いが、カンバンとして推奨される議題は限られているようだ

多少関連する話題は残っているかもしれないが、大筋はたったこれだけである。カンバンは非常にルールの少ない開発手法だ。スクラムもルールの少ない小さなフレームワークと宣伝されることが多いが、その比ではない。WIP制限というたったひとつの仕組みによってフロー効率に目が向くようになっているのはとても巧妙で面白く感じる。

スクラム実践者から見たカンバン

多くのスクラム実践者がカンバンに移行するモチベーションは、スプリントのタイムボックスの制約ではないかと予想する。他のスクラムのパーツは概ねカンバンに馴染むのだが、スプリントだけはJust-In-Time方式のカンバンに馴染まない。ここがふたつの手法の決定的な違いではないだろうか。スクラムでは計画のタイミングによって制約されていたリードタイムを、カンバンは理論値まで短縮することを可能にする。これが機能したチームを見てみたい気持ちは間違いなくある。

一方で、これまでスクラムをやってきた自分からすると、やはりルールの少なさが目を引く。うるさく言われずに済むと喜ぶ声もありそうだが、チームが機能し安定して素早くデリバリーすることに責任を負う立場としては難しさの方が先に立つ。カンバンから見ればスクラムのルールは多いが、それでも絶対的な量としては多い印象はなく、著しい無駄がある感触もない。スクラムによってチームに実装されていた多くの機能を、自分たちで実装し直す必要が出てくるはずだ。制約が少ないほど、自由なほど難しいということだ。

たとえば私が参照した「今すぐ実践！　カンバンによるアジャイルプロジェクトマネジメント」では、ボードに分析フェーズを置くことを推奨している。これはスクラムにおけるリファインメントやスプリント計画に相当するだろう。実現したい事柄について、設計し、分解し、情報を展開して分担できる状態を維持するのは依然として重要になる。WIP制限をトリガーにしてそうした処理をオンデマンドに発火させる必要がある。

ふりかえりやスプリントレビューもカンバンでは規定されていない。ふりかえりは、WIP制限による詰まりを潰していれば常にふりかえりをしているのと同じ、スプリントレビューは顧客との対話を維持し常に最新の状態を触らせたらOK、といった論で押し切られているが、その程度でうまくいくのかという点について私は懐疑的である。

それぞれうまく行くまで手を打つというだけの話なので、だからといってカンバンはダメだという話をするつもりはない。しかし、スクラムの実践で価値を確認した仕組みそれぞれについて思考を要求されるのは、ルールが少ない手法を選ぶ代償として意識的になるべきだろう。このギャップを意識して軟着陸させることが重要になる。とはいえ、前述の書籍でもスクラムからカンバンへの移行については1章を割いて論じており、「かんばんとスクラム 両者のよさを最大限ひきだす」でも両者の差分が存分に論じられている。スクラムからカンバンへの移行は頻出の話題で、集合知から多くの支援を受けることができるだろう。

マイスキルマップでエンジニアとしての己を見つめ直す

最近テックリードのロールを手放し、働き方がEMに近づいた。折に触れてEMになりたいと言ってきたが、だからと言って最初からうまくできるわけもなく、ここ1ヶ月くらいは悶々としながら過ごしている。特に今回困ったのは、自分の現在地がぼんやりしていて漠然と据わりが悪い感触に苛まれている点だ。もう少し課題や方向性を精緻にして、自信を持って前進できる環境をつくりたい。その一環としてマイスキルマップを作ってみたので紹介する。

マイスキルマップへ至る思考

自分が大事にしている心構えのひとつに「練習していないことはできない」というのがある。十を知るには十を聞き、繰り返し実践することでしか一人前にはなれないという、ごくごく当たり前のことだ。この心構えでひとつひとつ丁寧にやっていくのが、ここ5、6年の自分の強みだと思っている。

しかしこの心構えを維持するのは簡単ではない。何かができるようになると、自分の能力のイメージは否応なく肥大する。周囲からの期待も大きくなる。新しいことに挑戦する時に、ひとかじりすれば最初から上手くできると慢心してしまうことがある。

今の自分はまさにこの状態であると気づいた。さらに悪いことに、大きく広がった自分のスキル領域の中に、これまでも準備していた事柄が点々と散っており、自分に何ができて何ができないかわからなくなっていた。それによって、何が課題であるか、次に何をすべきかがわからず、漠然とした据わりの悪さに苛まれていたのだと分析した。

こうした状況を打破するために、自分のスキルを棚卸して現状を整理したいと考えた。そのためには、自分のスキル群を複数の観点で可視化できるスキルマップが最適だ。このような思考の流れでマイスキルマップというアクティビティにたどり着いた。

マイスキルマップの構造をどうするか

いざ作るとなっても、漫然と自分ができることを並べていくだけでは構造化として弱い。グループや軸を使って、自分のスキルを種類ごとに可視化したい。自分はEMの世界観でエンジニアリングに取り組んでいるので、例によってテクノロジー、デリバリー、ピープル、プロダクトの4軸を使うことにした。Engineering Management Triangleも候補だったが、こちらはかなり視座が高く、まだプレイヤーとしての活動もやっていく自分にはマッチしないと考えた。3年後くらいにはTriangleを使う方が良くなっているかもしれない。人によっても全く違う分類方法を採用することになるだろう。

各スキルのレベルは以下の4段階としてみた。

• Lv.1
  • 過去に触ったりして前提知識がある
• Lv.2
  • 1年以上の業務経験があり普通に発揮できる
• Lv.3
  • チームをリードできる
• Lv.4
  • 組織全体やコミュニティに知見を配れる

特別なことは考えておらず、自分にとって自然な段階をつけたらこんなものかなという感触だ。採用担当として見た時に参考になるかという目線は多少あったかもしれない。

マイスキルマップ作成

以上のセッティングで作ったスキルマップが以下だ。

スキルマップ

各スキルの軸の位置は、あくまで自分の主観をざっくり反映したもので、そこまで厳密な意味はない。同じスキルでも違う軸の位置で捉えて取り組んでいる人もたくさんいると思う。あとmiroの無料版で作ったので、エクスポートする時の解像度が制限されていて文字は読みづらいかもしれない。

マイスキルマップ分析

作ったスキルマップを眺めることで、以下のようなことを改めて認識した。

デリバリー領域が自分の強みである

チームをリードして成功体験を積み、その知見をブログや登壇、社内ギルドで配ることができている。最近はアジャイルコーチとの壁打ちで井の中の蛙の気持ちを味わっているが、そこで自己評価を下げすぎるのも不適切だろうと思う。

テクノロジー領域が広く浅い

Webアプリケーションエンジニアとしてフルサイクル/フルスタック寄りの働き方をしているのがそのまま反映されている。ソフトウェア設計や基盤ロードマップなど、広く浅く身につけた道具を組み合わせるメタ的な能力が頭ひとつ抜けているが、それ以外の具体的な技術で抜けているものはない。「AWS」「Web全般」など異常に解像度が低い領域があるのも特徴的だ。既存のシステムのレールに乗って無難に開発をするには十分なスキルだが、非連続な改善を起こすには不足と言わざるを得ない。最近、開発の方向づけがイマイチまとまらず困っていたのはこのあたりが関係していそうだ。

ピープル領域に自信がない

実際に1on1などのスキルを配置する時にLv.3に置く自信が湧いてこなかった。もちろん無難に必要な業務はこなしているが、言語化された思想、成功体験、再現可能なノウハウがまだ不足している感触がある。同じ業務に従事する同僚に対して自信を持って体系的に教えられるイメージが湧かない。EMとしての振る舞いに困っている現状をよく反映しているようにも思う。人をマネジメントすることについて体系的なインプットが不足している感触があるので、そこからケアしていこうと思う。

プロダクト領域に少しずつアプローチできている

自分はプロダクト領域に全く関われていない、もっと何かしなければという思いが空回りして、最近いろいろと失敗があった。しかし自分のスキルを配置してみると、意外とプロダクト軸に近いものがチラホラあると気づいた。無理にプロダクトマネジメントの本丸やUI/UXに踏み込んでいくよりも、エンジニアとしてやれることを正しく認識して、そこにコミットしていくほうが地に足がついて良い感じがする。

まとめ

こうしてみると、ホットスポットはテクノロジーとピープルのLv.2の領域に見える。ここに燻っているスキル群がたくさんある。それらが伸びていないことと、自分のいまの悶々とした状況に関係があることも見えてきた。Lv.2の領域を上げていくにはひたすら頭を使ってインプットと経験を重ねるしかないと思っているので、やっていくぞ。

安定して成果を出せるエンジニアへの近道

ソフトウェアエンジニアとして安定した成果を出したいと思っている人は多いでしょう。妥当な方針を危なげなく定め、素早く的確に実装し、滞りなく仕事を片付けていきたいものです。しかし、いつでもそのように成果を出せるようになるのは簡単ではありません。言語、ミドルウェア、クラウド、アーキテクチャと、身につけるべき知識が無限に並んでおり、それら全てに習熟する日は永遠に来ないとすら思えてきます。

にもかかわらず、この記事を読むみなさんの同僚には、安定して成果を出せるエンジニアが相当数いるだろうとも思います。これは一体どういうトリックなのでしょう。彼ら彼女らは全てを勉強しているのでしょうか。もちろんそれに近い研鑽を積んでいる人もいるでしょうが、多くの人はそこまでしていないと予想します。少なくとも僕はそこまでやっていませんが、技術面でもそこそこバリューを出して、テックリードを1年勤め上げました。この記事では、もう少し再現性高く安定した成果を出していく方法について、自分の経験に基づいて議論します。

安定して成果を出せるようになる方法

その方法とは、自分が面倒を見ているシステムのコードをとにかくたくさん読むことです。そしてそれによって、「真似をしたら平均点が出せる」という無難なやり方のメンタルモデルを構築することです。

現実のソフトウェア開発は真似の連続です。ミクロには、HTTPのクエリパラメータの処理の仕方や、RDBから取得したデータをモデルにマッピングする方法といったもの。もう少しマクロには、非同期に処理を行う方法や、どのようにキャッシュをするかといった話題もあるでしょう。既にそのシステムがある程度の規模で動き続けているのなら、こうしたやり方をゼロから考える機会は思いのほか少ないものです。それどころか、既存のやり方を無視したコードは全体の一貫性を損なうため、ゼロから考えるのは望ましくないとすら言えるでしょう。

既に動いているコードというのは素晴らしいものです。様々な無難な（少なくとも動く）処理の仕方を教えてくれるだけでなく、パフォーマンスやリソース効率の観点でも実績があります。チームメンバーが見慣れたコードになるのでレビューもスムーズに進みます。真似をすることで、そうした信用情報を自分の仕事にも適用できます。これほど頼もしいことはありません。既存のコードと比較して優れたり劣ったりすることはなく、"平均点"と呼ぶにふさわしい成果物ができるでしょうが、これが安定した成果を形成する重要なパーツだと考えます。

真似から始めて大きな成長へ

コードを読んで真似して手札を増やすことは、単に仕事を上手く進める以上の利益をもたらします。「こうやったらうまくいくんだな」という具体例をひとつでも持つことで、エンジニアとしての思考に重要な広がりが生まれます。

ひとつは、新旧、優劣といった技術の質に関する広がりです。何か未知の概念に出会ったとき、「自分たちが使っているものと比べてどうであるか」という視点で見て、自分の中で位置付けられるようになります。その概念を単に上から下まで見るよりもずっと深い理解を得られるでしょう。

もうひとつは抽象度に関する広がりです。何か抽象的な知見を前にしたとき、そこに自分たちのやり方を当てはめてみて考えることができます。実際に当てはまるにしても、当てはまらないにしても、その思考実験から多くの示唆を得ることができるでしょう。単に言葉尻を追いかけるよりもずっと楽しい学びになるはずです。

よく、技術書の内容を覚えていないとか、読むのが大変といったことが界隈の話題に上がりますが、こういった点と関係があるようにも思います。上で紹介したような思考の広がりの中で目にした情報は高い強度を持ちます。忘れる忘れないといった次元の心配とは無縁で、自転車の乗り方のように体に身に付きます。こうした構造を狙っていくと自己効力感を持って楽しく学ぶことができるかもしれません。個人的な体験としても、社会人になって面倒を見るシステムができてからの方が技術の勉強をするのが楽しく感じます。

テックリードへの道

ここまで議論したことは、「テックリードになるにはどうしたら良いか」という問いにもよく答えています。テックリードの要件は色々ありますが、その中でも多くの場面で無難な方針を出す能力はとても重要だと思っています。信頼度が高くひとまず動く方針は、叩き台やセーフティネットとしてとても優秀で、ソフトウェア開発の健康な進行につながります。これは基本的には、システムのコードをたくさん読み、何度も真似し、システムを深く理解することで得られる能力です。

以前、自分のメンターから「テックリードの『理由はうまく言えないけど危なそう』はだいたい合っているから自信を持って」と言われたことがあり、これも近いことを言っていると気づきました。テックリードは既存のシステムで上手くいっている方法をよく知っているので、まだ言語化できるほどの理解が及んでいないにしても、そこから外れたときに違和感をキャッチできるのではないかということです。もちろん既存のやり方が100%正しいとは限りません。それでも、既存のシステムが持つ信用情報を適用できないことを認識するのは有益です。

また、そうしたメンタルモデルがよく構築されていることで、筋の良い変化にも踏み出すことができます。技術の質に関する相対感を獲得し、よい技術選択ができるようになるでしょう。単に選ぶだけでなく、チームの現状からどれくらいギャップがあるのかを認識することで、変化のためのアプローチをうまく構築できるはずです。また、具体と抽象に関する広がりを獲得し、説得力のある説明で他のメンバーを導けるようになります。より発展的な仕事を志向するにしても、既存のシステムに関するメンタルモデルが頼もしい踏み台になるでしょう。

まとめ

この記事では、自分の経験を元に安定して成果を出すための近道について考えました。面倒を見ているシステムのコードをよく読み、チームの無難なやり方のメンタルモデルをよく構築することが、安定して成果を出す近道であるという議論を展開しました。単に既存のコードの信用情報に裏打ちされた仕事ができるだけでなく、さらなる学びやリードの踏み石としても機能することが期待できます。成長したいのに伸ばし方が分からない時は、素朴に目の前のシステムに100%の力を注いでみると道が開けるかもしれません。