🧠

「能力不足」ではなく「情報不足」 - 成長するエンジニアに必要な視点 ✏️ by GPT

2024/12/11に公開

※ChatGPT o1にテーマを投げて数回やり取りして書き上げてもらいました。趣旨は自分の主張ですが、文章はほぼ全てGPTによるものです。

はじめに

エンジニアとして成長し、マネジメントやリーダーシップを発揮するには、何が必要でしょうか。多くの人は「スキル」や「経験値」を思い浮かべるかもしれません。しかし、組織内でより大きな役割や裁量を担う人とそうでない人との違いは、必ずしも能力そのものではありません。
実は、「どれだけ情報を持っているか」が、その人の視座や意思決定力を大きく左右します。

本記事は、まだメンバーレベルの視点に留まっているエンジニアが、殻を破り、マネジメントやリーダーシップへとステップアップするために「情報」に着目することの重要性を解説します。スタートアップでCTOを務めるなかで得た経験を交えながら、なぜ情報が役割や裁量を生み出すのか、その実践的なヒントをお伝えします。

情報が意思決定を形作る:スタートアップCTOの視点

スタートアップでは、日々多種多様な意思決定が求められます。新機能のリリース、アーキテクチャの改善、採用方針、マーケットの変化への対応──そのどれもがスピード勝負であり、かつ不確実性が高い環境です。

いくらロジカルシンキングを磨いても、手元の情報が不足していれば正しい判断は難しいものです。情報不足のままの意思決定は、ほぼ間違いなく誤った方向へ進む危険を孕んでいます。だからこそ、今しようとしている意思決定は本当に十分な情報を踏まえた上で行えているか?を意識的に問いかけるべきです。

とはいえ、スタートアップのようなスピードが求められる現場では、すべての意思決定を完璧な情報で固めることは困難です。そんなときは、情報不足を自覚したうえで、出口戦略やリスクヘッジを講じておくことが大切です。たとえば、プランBやロールバック手段を用意したり、小規模な実験から始めてフィードバックを得たりといった行動を取ることで、情報不足の中でも被害を最小化しながら前進することができます。

プロダクトの将来性を左右する技術選定ひとつをとっても、単に自分が得意な技術だけでなく、市場動向、ユーザーニーズ、将来的な拡張性、メンテナンスコスト、チームの熟練度など、幅広い観点が必要です。
「完璧な情報」は得られなくとも、「今何が足りていないのか」を自覚し、必要な情報へ自らアクセスしようとする姿勢や、情報不足を前提にしたリスク対策があれば、より妥当な意思決定へと近づくことができます。

「能力不足」ではなく「情報不足」だと捉えるマインドシフト

情報不足が「能力不足」に見えるケース

あるエンジニアがアーキテクチャ改善案を出す際、なかなか有効なアイデアが出せない状況がありました。一見「その人は引き出しが少なく、改善の能力が足りない」ように見えたかもしれません。しかし、実は必要な情報が不足していただけでした。

そこで1on1などの場を使い、アーキテクチャ改善と事業・企画改善との関連性を整理して共有しました。「この設計変更によって、将来こういった機能拡張が容易になり、それがユーザー体験を向上させ、事業成長にも繋がる」という上位レベルの視点を提示したのです。この背景情報を得たエンジニアは判断軸が増え、実行力のある改善案を出せるようになりました。
ここで重要なのは、「能力不足」ではなく「情報不足」と考えることで、必要な情報提供という「次の一手」が明確になる点です。

自分自身が情報不足を自覚して克服した例

創業初期、筆者自身も情報不足に起因するミスを重ねました。当時は前職で得た限定的なノウハウのみを頼りに技術選定していたため、非効率な選択が目立ちました。しかし、学習量と情報発信を増やし、SNSや技術イベントで他社の優秀なエンジニアやCTO、CEOたちと交流した結果、飲み会などのカジュアルな場で最新技術動向や実務知見を得られるようになりました。その積み重ねがアーキテクチャ改善に生き、外部エンジニアからも高く評価される状態へと導きました。
このとき能力が突然上がったわけではなく、情報取得経路を増やし不足を補ったことで、本来持っていた力を最大化できたのです。

情報不足を自覚したうえで意思決定した例

ある新規施策をリリースする際に、新しい技術要素を用いたため、Staging環境のみのテストでは本番稼働の挙動に対する不安が残るケースがありました。また、この技術特性上、Feature Flagを用いたカナリアリリースも困難でした。
この状況で、「自分の能力や経験が足りない」と嘆くのではなく、「この技術のProductionでの挙動に関する情報が不足している」という問題設定をしました。結果として、当該機能に監視ログを仕込むなど、状況を観測可能にする仕組みを整え、専用の体制を組むことで、十分な情報がないままでもリスクを最小化しながらリリースする戦略を取ることができたのです。
ここでも重要なのは、能力不足ではなく情報不足を問題としたことで、明確な対策(監視・ログ収集・体制づくり)というアクションへとつなげられた点です。

組織的な情報共有の仕掛けづくり

情報不足の問題は個人だけでなく、チーム全体でも起こります。朝会や週次定例を「単なる報告の場」から「改善点や取り組みの意図を共有する場」に変えたところ、チームメンバー同士が必要な情報を得やすくなり、相談のハードルも下がりました。これにより、ソースレビューの引き継ぎがスムーズになり、複数のメンバーが開発体験の改善に関わることができるようになったのです。

情報共有とコントロール、そしてタイミング・環境

ただし、必要な情報を常に全員にオープンにすればよいわけではありません。情報を無差別に拡散すれば、使われない「死蔵情報」や混乱を招く要因が増えるだけです。また、人は過剰な情報に晒されると、むしろ判断を誤る可能性もあります。

ここでいう「情報コントロール力」とは、あくまで組織全体が健全に成長し、メンバーが適切な行動を取れるようにするための配慮であって、自衛や不当な権利強化のための手段ではありません。オープンなチャットツールやWikiで誰でも拾える形で残しておく「プッシュ型」の共有が有効な場合もあれば、1on1や小規模な会食などクローズドな場を活用して、必要な人に必要な深さの情報を届ける場合もあります。

さらに、情報共有には「タイミング」も重要です。渡したい情報があっても、その情報を受け取る側が「今、その情報が必要だ」と感じていなければ、記憶にも行動にも結びつきにくいのです。場合によっては、事前に「その情報が必要だ」と当人が思う環境や仕組みを用意することで、情報の価値を最大化できます。
たとえば、特定の技術分野に強いコミュニティへ自ら身を置くと、自然とその分野の情報が重要に感じられるようになります。フロントエンドのキャッチアップに熱心なコミュニティに参加すると、同じ情報であっても急に「輝いて」見えることがあるのです。これは組織側がメンバーに対しても同様で、適切な環境づくりや問題設定によって、メンバー自身が「その情報が欲しい」と思えるようなシチュエーションを生み出すことが可能になります。

視座を上げるための行動指針

情報不足を補うには、「何が足りないのか」を明確にすることが第一歩です。プロダクト改善に直結するなら事業ロードマップやユーザーデータ、人材戦略なら市場の人材動向といった具合に、必要な情報は状況によって異なります。また、社外コミュニティやSNSでの発信・収集は外部知見を得る大きなチャンスです。

「能力不足」ではなく「情報不足」と捉えれば、何を補えばよいかがより具体的になります。そして、必要な情報を適切なタイミングで受け取りたくなるような環境を整えることで、情報はただのデータから行動を生む原動力へと変わるのです。個人の成長でも同様で、自らが「この情報が必要だ」と思える場所へ飛び込んでみれば、同じ情報でも違った価値を感じ、視座を高めることができます。

まとめ:情報こそが成長エンジン

「役職や裁量の差は情報の差で決まる」という視点は、「能力が足りないから成長できない」という思い込みを覆し、具体的な改善策へ導いてくれます。情報こそが、意思決定の土台を強固にし、エンジニアからリーダーへのステップアップを後押しする最大のエンジンです。

ただし、その情報を適切な形・量・タイミングで、必要な人に届けるための工夫と配慮が必要です。そして、その情報が必要だと受け手が感じられるような環境づくりも欠かせません。これらを踏まえた情報活用は、組織と個人双方の成長を促し、より高い視座と裁量を手に入れるための確かな手がかりとなるでしょう。


※ここからGPTじゃなくて手打ちの文章です

GPTで「お気持ち系」記事を書くと気楽かも

最後に余談として個人的なお気持ちを書き残しておきます。
技術知識を書くTech系ではなく、本記事のようなマネジメント寄りのIdea系記事を書くのが、個人的にハードル高く感じています。
主な理由としては、絶対的な正しさがない領域なので、ネットの反応が怖いからです。

  • 『この記事の筆者、「知識」と「情報」の差が区別できてなさそう』(単語の定義拗らせ批判コメ)
  • 『前職にこういう情報を意図的に隠すEM居て、面倒だったわ〜』(勝手に知人と筆者を重ねてくる系コメ)
  • 『実際能力不足の場合が多いでしょ』(記事の主張が何ら理解されていない系コメ)

ついつい私はこういうコメントを意識しながら書いてしまうので、気がつくと文章量が肥大化して読めたものではなくなったり、途中で書くのをやめてしまったりするんですよね。
そこで、主張だけ何点かして、文章はGPTに書いてもらいハードルを下げつつ、記事の冒頭で「GPTに書いてもらったんですよ〜」を一言書いておくことで、個人的な公開ハードルを下げる試みをやってみました。

マネジメント系というか人間系(?)の記事、自分の記録も兼ねて残していきたいので、AIといい感じに付き合いつつ書いていこうと思います📝

Discussion