郷に入りては「つよつよエンジニア」の流儀に
従う必要はありません。十人十色です。自由だー！
その上で考えてみてほしいのです。彼らの行動を表面だけ真似しても、本当の意味で成長することは難しいのではないか、と。
「郷に従う」という言葉は、表層的な模倣ではなく、その土地の文化や思想といった「なぜ」を理解して初めて意味をなします。同様に、私たちも「つよつよエンジニア」の行動の裏側にある「思考の型」を学ぶべきではないでしょうか。
これまでの連載で彼らの「立ち位置」や「学習法」に触れ、最終回となる今回はその具体的な「行動」を探ります。彼らの振る舞いの裏にある「なぜ？」を紐解き、あなたの成長の羅針盤となるエッセンスを見つけにいきましょう。
連載記事リンク
- 「つよつよエンジニア」は一日にして成らず
- すべての道は「つよつよエンジニア」に通ず
- Do as the 「つよつよエンジニア」s do（この記事）
根底にある思想
では、彼らの「行動」を支える前提とは何でしょうか。核となるのは、次の2つの姿勢です。
これは、後述する「アウトプットの傾向」と「教えることの傾向」の両方に通底する基盤であり、実践の質を左右します。
「Why」の追求と課題解決への情熱
彼らのアウトプットの中心には、常に「Why」があります。
- なぜその技術を選んだのか？
- ユーザーが本当に解決したい課題は何なのか？
- この設計にした根本的な理由は？
流行りの技術をただ使うのではなく、その背景にある課題を深く掘り下げ、本質的な解決策を追求する。その情熱が、単なる「作ってみた」で終わらない、説得力と価値のあるアウトプットを生み出す源泉となっています。それは、技術が本来「課題解決の手段」であるという原点に忠実な姿勢とも言えるでしょう。
知の循環と共創
彼らは知識を自分のものだけに留めません。第一弾の記事で定義したように、彼らは自らが「知を循環させるハブ」となることを体現しています。
自分の得た知見をオープンソースプロジェクトへの貢献や、勉強会やライトニングトークでの発表、Qiita記事といった形で積極的にコミュニティに還元します。それは単なる一方通行の提供ではなく、他者との対話やレビューを通じて、自分のアイデアが磨かれ、より大きな価値へと昇華していく「共創」のプロセスだと理解しているからです。
知識は共有することで増え、コミュニティ全体が豊かになる。その循環の中に身を置くことを楽しんでいます。
アウトプットの傾向
ここでは、「Whyの追求」と「知の循環」という思想が、日々の発信や制作にどう現れるのか。「していないこと／していること」という視点から、その実態に迫ってみましょう。
していないこと
完璧を待たない
「もう少しリファクタリングできたら…」「この部分の検証が完全に終わったら…」そんな風に完璧を追い求めるあまり、アウトプットの機会を逃してしまった経験はありませんか？
「つよつよエンジニア」は、完璧な状態を待ちません。未完成でも仮説段階でも、ためらうことなく世界に問いかけます。GitHubで WIP (Work In Progress) とタグ付けしたプルリクエストがやり取りされる光景を思い浮かべてみてください。彼らは「完成度60%」のアイデアを恐れず共有し、フィードバックを求めるのです。なぜなら、その不完全さこそが新たな議論や発見の種となり、自分一人では決して見ることのできなかった景色へ導いてくれることを、経験から知っているからです。
私自身、初めて WIP プルリクエストを出すときは「こんな中途半端なものを見せていいのか…」と非常に怖かったのを覚えています。しかし、勇気を出して投げてみると、完成前のコードからでも変更意図は十分に伝わり、自分一人では思いつかなかった視点からの有益なフィードバックをもらえたのは驚きの体験でした。
インプットのまま放置しない
技術書を読破し、勉強会に参加して「良い話を聞いたな」で終わらせることはありません。彼らにとってインプットは最高の料理を作るための「仕入れ」にすぎません。
第二弾で紹介した知識の領土をいくら拡大しても、仕入れた食材（知識）を自分の言葉で再構築し、「調理」（アウトプット）しなければ、真に血肉とはならないのです。ブログ記事にまとめ、小さなツールを作り、チームで共有することで初めて、それは価値ある「ごちそう」に変わります。
彼らにとってインプットとアウトプットは、呼吸のように切り離せない一対のサイクルなのです。
他人の評価ばかりを気にしない
もちろん、良い評価は嬉しいものです。しかし、彼らのアウトプットの第一目的は「LGTMの数」や「いいねの数」ではありません。一番の読者は「未来の自分」であり、アウトプットは何よりも自分のための「思考の整理」や「知識の定着」が主目的です。
自身の学びや発見を共有する行為そのものに価値を見出しているため、他者の反応はあくまで副産物。だからこそ、周りの目を気にせず、純粋な知的好奇心に基づいた発信を続けられるのです。
していること
学びの過程を積極的に共有する
ブログ、Qiita、ライトニングトーク登壇など、彼らはあらゆる機会を捉えて自身の学習記録や試行錯誤のプロセスを公開します。これは単なる自己満足ではありません。アウトプットは「教えることは最大の学習」という言葉通り、自身の知識を体系化し、曖昧な理解を明確にする最高の機会です。
さらに、その発信が誰かの助けとなり、新たなフィードバックや次の学びのヒントが返ってくるという「知の循環」を生み出す原動力にもなっています。
事実、この連載記事を書くこと自体が、私自身の思考を整理する最高の機会となりました。そして願わくば、この連載があなたにとっての新たな「学びのヒント」となることを期待しています。
思考の軌跡を可視化する
彼らが共有するのは、華々しい成功事例だけではありません。それに至るまでの試行錯誤や、「このアプローチは失敗だった」という生々しい学びの過程もまた、大切なアウトプットだと考えています。
例えば、Qiitaで「最初はAというライブラリで実装を試みたが、特定の条件下でパフォーマンスが出ない問題に直面し、Bという、より低レイヤーなアプローチに切り替えた」といった失敗談や試行錯誤の過程をストーリーとして語る。それは、読者にとって単なる解決策以上の価値を持ちます。
他者の学びを加速させ、同じ轍を踏む人を減らし、何よりその人間味あふれるプロセスが多くの共感を呼ぶのです。
「とりあえず作ってみる」精神
新しい技術や面白そうなライブラリに出会ったとき、ドキュメントを隅から隅まで読んで完璧に理解しようとする前に、リーナス流「Talk is cheap, show me the code」の精神で、まずは小さく手を動かします。
例えば、新しい画像処理ライブラリに心惹かれたなら、週末に「フォルダ内の画像をリサイズしてWebPに変換するCLIツール」を作ってみる。npm init -yでプロジェクトを立ち上げ、sharpを導入し、数時間でプロトタイプを完成させる。その過程で、非同期I/Oの扱い、予期せぬ入力へのエラーハンドリング、そしてパフォーマンスの勘所が、ドキュメントを読むだけでは得られない「生きた知識」として身体に刻まれます。READMEに使い方と所感をメモしておけば、それは未来の自分への最強のプレゼントになるでしょう。
この小さな「やってみた」の積み重ねが、やがて大きな技術的アドバンテージに繋がっていきます。
教えることの傾向
根底の二つの姿勢が、教える場面において具体的にどのような行動に現れるのか。
ここでは「教えないこと」と「教えたいこと」の二つの側面から掘り下げていきます。
あえて教えないこと
すべてを教えきってしまわない
後輩から「このエラーが解決できません」と相談された時、彼らはすぐに正解のコードを示しません。代わりに「どこまで調べてみた？」「このエラーメッセージは、私たちに何を伝えようとしていると思う？」と問いかけます。第二弾で提示した「思考の羅針盤」を後進自身が使えるようにするための訓練なのです。
山頂までヘリコプターで運ぶのではなく、地図の読み方とコンパスの使い方を教えることにこそ、本当の価値があると知っています。
一方的な情報提供をしない
自分が当たり前に使っている専門用語が、相手にとっては外国語のように聞こえるかもしれない。その可能性を常に念頭に置いています。相手の表情や質問の仕方から理解度を測り、必要であれば「イミュータブルって、一度作ったら変更できない性質のことなんだけど…」のように、専門用語を噛み砕いたり、身近な例に置き換えたりします。
一方的な知識の洪水で相手を溺れさせるのではなく、相手の歩幅に合わせて並走する。それが彼らのスタイルです。（ただし、これは個別対応になるため講師としてスケールしにくいという側面も認識しています）
「正解」を押し付けない
技術の世界に「銀の弾丸」はありません。あるコンテキストでは最適解でも、別の場所では悪手になることもあります。彼らはそのことをよく理解しているため、「これが絶対に正しい」というスタンスを取りません。
「僕ならこう考えるかな。でも、君のアプローチにもこういうメリットがあるよね」と、多様な視点やアプローチの存在を示し、トレードオフを一緒に考えることを促します。
唯一の正解を探させるのではなく、状況に応じた最適解を自ら考える力を養おうとしているのです。
教えたいこと
自力で問題を解決する楽しさ
彼らが本当に伝えたいのは、技術そのものよりも、それを使って何かを成し遂げる喜びかもしれません。暗闇の中で手探りだったエラーが解決した瞬間の高揚感。自分の書いたコードが思い通りに動いた時の小さな感動。その一つ一つのプロセスにこそ、エンジニアリングの醍醐味があると信じています。
だからこそ、簡単に答えを渡さず、相手が自らの力でその達成感という「果実」を掴み取るためのサポートに徹するのです。（謎解きゲームによく似ています）
本質的な思考力
彼らが本当に伝えたいのは、単一のフレームワークの使い方や特定のコマンドではありません。その技術が「なぜ生まれたのか」、その設計思想の背景にある「何を解決したかったのか」という本質です。
表面的なテクニックは時代と共に色褪せますが、「なぜそうなるのか」「どうすればもっと良くなるのか」といった根本的な思考力は、どんな技術にも応用が利く一生モノの財産です。それは、第一弾で触れた複数の領域に渡って価値を発揮し続けるための土台となります。
彼らは後進に、第二弾で言うところの知識の「根」や「幹」を見極める力を身につけてほしいと願っているのです。
「なぜ」を深く探求する姿勢
「このライブラリを使うとなぜ速くなるのか？」
「このエラーはOSのどのレイヤーで起きているのか？」
目の前の事象だけでなく、その裏側にある原理原則や抽象的な概念へと、思考のドリルを深く深く掘り進めていく。
その「なぜ」を問い続ける姿勢こそが、未知の問題に直面したときの突破力になると考えています。
彼らが伝えたいのは、魚の釣り方だけでなく、海流の読み方や生態系の知識なのです。
「つよつよエンジニア」の舞台裏
ここまで「つよつよエンジニア」の行動を語ってきました。
しかし、彼らも霞を食べて生きているわけではありません。時間は常に足りませんし、差し込みの依頼や障害対応に追われ、自分のタスクで手一杯なことも日常茶飯事です。それでも教えることに時間を割くのは、それが長期的なリターンを生む「投資」だから…。というのは理想論かもしれません。実は、そこにはもっと現実的で、エンジニアならではの合理的な理由も存在するのです。
後進が育てばチームは自走し、自分は面倒な問い合わせから解放される。結果として、本当に面白い課題や学習に集中できる時間を確保できる。これは究極的に、自分のための最も効果的な戦略なのです。だからこそ「つよつよエンジニア」の時間を奪って申し訳ないと思わず、どんどん教えを乞うてほしいとすら思っています。
エンジニアなら、この気持ち、きっと分かってくれますよね？
まとめ
三部作にわたって旅してきた「つよつよエンジニア」への道も、いよいよ終着点を迎えます。ここまで長い連載記事にお付き合いいただき、本当にありがとうございました。
本連載では一貫して、古代ローマのことわざに学びを重ねてきました。
- 「ローマは一日にして成らず」 が示す、立ち位置の確立と成長への忍耐
- 「すべての道はローマに通ず」 で示す、学びのスタイルやキャリアパスの多様性
- 今回の 「郷に入りては郷に従え」 では、本質の理解と、新たな価値の創造
これらは、単なる「技術の習得」に留まらない、エンジニアとしての奥深い哲学を映し出しています。先人たちの知恵を盲信せず、その根底にある「なぜ」を理解し、自らの手で新たな価値へと昇華させる。この能動的な姿勢こそが、これからの時代を築く「つよつよエンジニア」の真髄だと私は信じています。
この連載で私が最も伝えたかったのは、「指示待ち」ではなく、自ら問いを立て、考え、道を切り拓く、本質的なエンジニアリングの姿勢そのものです。
次は、あなた自身の「ローマ」へ
「つよつよエンジニア」たちの行動は一見するとバラバラに見えるかもしれません。しかし、その根底には「他者とコミュニティへの貢献」「学びへの飽くなき好奇心」「アウトプットによる知の循環」という共通の姿勢が流れています。
彼らをそっくりそのまま模倣する必要はありません。大切なのは、彼らが大切にしているこれらのエッセンスを、あなた自身の活動に少しだけ取り入れてみることです。
例えば、来週のあなたは…
- 読んだ技術記事に、自分の環境で再現した結果や補足リンクを添えてコメントしてみませんか？
- 週末に気になったライブラリを使い、3時間で小さな便利ツールを作ってGitHubに公開してみませんか？
- 後輩へのアドバイスで、答えを示す前に「君ならどう調べる？どこまで試した？」と問いを重ねてみませんか？
- 完成度60%の学びをライトニングトークで共有し、課題点（次に検証したいこと）をあえて最後に箇条書きで晒してみませんか？
このポエム連載が、皆さんが自分だけの「ローマ」すなわち「つよつよエンジニア」スタイルを見つけるための羅針盤の一つとなることを願っています。
この連載を書くにあたり、多大な影響を与えてくださった十人十色な先輩諸氏（Sさん、Bさん、Dさん、Zさん、Mさん、L씨、K씨、Yさん、Hさん）に、この場を借りて心より感謝申し上げます。
お断り
記事内容は個人の見解であり、所属組織の立場や戦略・意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。