本記事を書いたきっかけ

先日、3年半ほど勤めたメガベンチャーから、ずっと憧れていたグローバルテック企業に転職しました。

この3年半の間、前職(メガベンチャー)では本当に多くのことを学ばせてもらったので、「この学びを忘れないよう」「今後もこの学びを有効活用できるよう」本記事にまとめておきたいと思いました。

これは新しい環境で迷った時に、立ち戻るための自分用のメモです。

思考・スタンス

🔸 視座の高いエンジニアとは何か

明らかに自分とは見えている景色が違うエンジニアの方々がたくさんいた。
そのエンジニアの方々に共通しているのは、視座の高さだと思っている。

目の前のタスクだけではなく、事業・会社の目標やロードマップを達成するために「今どうすれば良いか」「どう作れば良いか」を考え・実践していた。

全体最適の視点を持ち、短期的な効率だけでなく、技術選定や設計判断が将来の保守性、拡張性などに与える長期的な影響を考え意思決定・説明ができる人達である。

🔸 他者の決めたHowを鵜呑みにしない

Why, Whatと一緒にHowもある程度決まった段階で、相談に来たり、プロジェクトが開始してしまうことが稀によくある。

そんな時、改めて「そのHowが一番適切なのか」「他にどんなHowと比較検討したのか、するべきなのか」を関係者と議論することが大切である。

また上記の議論と合わせて、提示された前提条件のうち譲れるもの・譲れないものも明確にしておきたい。

🔸 今それをやるのが一番ベストか？を考える

何も考えていないと、ただただ目の前のタスクをこなすだけになってしまう。

「なぜこのタイミングでこのタスクをやるのか」を理解した上で取り組むと、納得感が生まれるし、タスクに対してよりオーナーシップを持って取り組むことができると思っている。

またこの問いかけは、目的と手段の逆転を防ぐことにも繋がる。

「今、このタスクをやるのが本当にベストか？」と問うことで、常に目的（なぜやるのか・完了後のあるべき状態）に意識が戻ります。
その結果、目的達成のために「タスクを捨てる」「タスクの順番を入れ替える」「タスクそのものを変える」という戦略的な判断ができるようになります。

🔸 考える時間を意図的に作る

1日 or 1週間の中で、考える時間を意図的に作る・自身のスケジュールをブロックしておかないと、これもまた目の前のタスクのことだけを考えて毎日が終わってしまいます。

1日のうちに15分でもいいので、チーム・事業・ロードマップについて振り返り・今後何が起こりそうかを予測して事前に打てるアクションを考えておくと、日々の仕事を自分でコントロールできるようになっていくと思っています。

また1人で考える時間では、チーム・事業・プロダクトの理想の状態を明確にして、理想の状態とのギャップが何か、ギャップを埋めるためにできることは何かも考えると、ビジネスパーソンとして成長・評価されていくでしょう。

🔸 as-is / to-beから明確にする

プロジェクトや問題にぶつかった際は、まず「as-is（現状）」と「to-be（あるべき姿）」を明確にすることが重要です。

どちらも明確にしておかないと、as-isとto-beのギャップを定義できず、適切なソリューションが選べず、誤った方向に進んでしまう可能性もあります。

また、ソリューションを実施した後に「本当に問題が解決されたのか」「成果は出ているのか」を測る基準も不明確になります。

逆に、as-isとto-beを事前に定義できれば、ゴールが共有され、進捗や成果の評価がやりやすくなり、関係者間での認識齟齬も減ります。

良いことばっかりです。

🔸 ソリューションとROIはセットで考える

課題に対してソリューションを考えるときは、常にROI（費用対効果）をセットで検討することが重要です。

どんなに優れたHowでも、投資に対して得られるリターンが見合わなければ、実際にそのhowで課題を解決できたとしても旨味は小さくなってしまいます。

開発工数や運用コスト、将来的な保守性などを踏まえ、期待される成果と投資のバランスが取れているかを、できる限り定量的に見極める必要があります。

ROIを意識することで、優先順位付けや意思決定がやりやすくなり、限られたリソースの中で最大の価値を生み出すことが可能になります。

🔸 QCDを考えて、ロジカルにNoを伝える

プロジェクトにおいて、すべての要求に「はい」と答えることは難しいです。

限られたリソースの中で価値を最大化するには、QCDの観点から、実現可否や優先度を論理的に判断・説明することが重要です。

なぜ難しいのか、品質・コスト・納期のどれに影響があるのかを定量化し、トレードオフを説明した上で「No」を伝えることで、相手の納得感も得やすくなります。

ロジカルな説明があれば、単なる拒否ではなく建設的な議論につながり、結果的にチーム全体の信頼関係が構築でき、無理せず持続的にプロダクトをグロースすることができるようになります。

🔸 腹落ちして仕事する

ずっと似たようなことを、ちょっと言い換えているだけの気がしますが、「思考・スタンス」編の最後は「腹落ちして仕事する」ことです。

プロジェクトや方針に対して、「なぜやるのか」「なぜこの方針なのか」「誰のどんな行動をどう変えたいのか」を理解できていないまま進めると、判断が受け身になり、言われた通りの仕事をするだけの人になってしまいます。

まずはプロジェクト・方針に対して、疑問点を持てるように状況を正しく認知する。
疑問点が何も出てこないということは、「自分が内容を正しく認知できていない」「オーナーシップが持てていない」状況の可能性があります。

まずは疑問点を持つ。そして疑問点を解消し、自分の言葉で目的を語れる状態を目指すことが、仕事のオーナーシップを持つ第一歩だと思います。

メンバー全員がそういう意識を持って仕事をすれば、「作ってリリースしてみたけど誰にも使われない」みたいなものを作らずに済むのではないかと思っています。

やるからには、ユーザが本当に喜ぶもの・価値のあるものを作っていきましょう。

プロジェクトマネジメント

🔸 プロジェクトのキックオフは大事

自身の開発チーム内に閉じているならキックオフは不要かと思いますが、他チームを巻き込む必要がある場合は、短い時間でもキックオフを行った方が後々楽になるかと思っています。

ゴール・スコープ・役割分担・進め方などが曖昧なまま走り出すと、後から認識のズレや責任範囲の曖昧さが表面化し、手戻りやコミュニケーションコストが高くなります。

キックオフでは、関係者全員で目的や背景を共有し、to-beの状態と進行方針を明確にすることが重要です。
また、質疑応答を通じて初期の不安や前提のズレを解消しておくことで、プロジェクトを進めるための「共通の土台」を築けます。スタートの丁寧さが、後のスピードと成功を支えるでしょう。

🔸 タスクではなくリスクから考える

プロジェクトを進める際、多くの人はまず「やるべきタスク」から計画を立てがちです。
しかし、実際に計画を崩壊させたり品質を落としたりするのは、見えていなかったリスクです。

だからこそ、最初に着手すべきはタスクではなく、リスクを洗い出すために必要な作業です。
前職では、「プレモーテム」や「リスク分析」と呼ばれる活動をしていました。

実際に起きたらまずいこと、ボトルネックになりそうな箇所、不確定要素、依存関係、遅延や手戻りの可能性などを早い段階で明確にし、優先的に潰していくことでが大切です。

タスクベースの計画にリスク視点を加えるのではなく、まずリスクを起点に計画を組み立てることが、不確実性をできるだけ減らしたプロジェクトマネジメントに繋がります。

🔸 MVP・ユーザに提供できる価値をベースに計画を立てる

リスクを起点に計画を組み立てた後は、MVP（Minimum Viable Product）やユーザに提供できる価値を起点に考えることが重要です。
（※ リスクと価値どちらを起点に考えるべきなのかはケースバイケースだったり、諸説あるかもしれません。）

機能要件や組織内の事情をベースに計画を立てると、本来届けたかった価値が後回しになったり、優先度の低い機能で計画が膨らんだりしがちです。

まず「ユーザにとって何が一番価値になるのか」を明確にし、そこから逆算してMVPを定義し、優先順位をつけていくことで、限られたリソースの中でも早く価値をユーザに届けられます。

完璧を目指すより、価値の核となる部分から段階的に積み上げていくことで、無駄のない計画と素早く検証サイクルを回すことが可能になります。

🔸 曖昧な定義・認識のままプロジェクトを進めない

プロジェクトを進めるうえで、言葉や前提の曖昧さを放置したまま進行すると、後から大きな認識齟齬や手戻りにつながります。

特に、「対応する」「完成する」「暫定的に」や「サービス・業務ドメイン特有の単語」など、意味が人によって異なり得る曖昧な単語をそのまま使うのは危険です。
これらを明確に定義せずに進めると、各メンバーがそれぞれの解釈で動き、成果物やスケジュールにズレが生じやすくなります。

初期段階では「なんとなく共有できた気になっている状態」が最も危険です。曖昧な部分は早めに明文化・ユビキタス言語化し、用語や完了条件の定義をそろえることで、認識のズレを防ぎ、不確実性をできるだけ減らしたプロジェクトマネジメントに繋がります。

🔸 前提知識・目的がずれていないか確認する

プロジェクトを進めるうえで、関係者間の前提知識や目的の認識がズレていると、議論や意思決定が噛み合わず、後になって大きな手戻りを生む原因になります。

「当然共有されているはず・知っているはず」と思い込むのではなく、背景・目的・前提条件を一度立ち止まって確認することが重要です。

特に、他のチームとのコミュニケーションやフェーズが変わる時は、知識レベルや目的の理解度がバラバラになりがちです。

共通の土台をそろえることで、議論での認識齟齬が減り、判断や計画の精度も高まります。
曖昧なまま進めず、丁寧に認識合わせを行うことが結果的に近道です。

🔸 スクラムの目的・柱を見失わない

スクラムは、単なる儀式や運用ルールの集合ではなく、チームが価値を継続的に届けるためのフレームワークです。

しかし実務では、デイリースクラムやスプリントなどのイベントを「やること自体」が目的化し、本来の意図が形骸化してしまうケースが少なくありません。

スクラムの柱は「透明性」「検査」「適応」の3つです。
これらを機能させることで、チームは課題を早期に発見・改善し、変化に対応しながら成果を高めていけます。

イベントはあくまでこの柱を支えるための手段であり、形式だけをなぞってもスクラムは機能しません。
常に目的と柱に立ち返る姿勢が重要です。

🔸 何事にも効果計測・振り返りをセットで行う

施策やプロジェクト・何かの改善などを進めるときは、実行するだけで終わらせず、効果計測と振り返りを必ずセットで行うことが重要です。

実施後の効果を測らなければ、施策の良し悪しや次の改善点が見えず、惰性的な取り組みになってしまいます。

定量的な数値だけでなく、定性的なフィードバックも含めて成果を検証し、事実に基づいて改善を重ねることで、チームの学習サイクルが回り始めます。

「やりっぱなし」にせず、振り返りをプロセスに組み込むことで、意思決定の精度と再現性が高まり、チームの成長も早くなるのです。

🔸 ドキュメンテーションをサボらない

ドキュメンテーションは、後回しにすればするほど内容が曖昧になり、結局自分やチームの首を絞めることになります。

記憶が鮮明なうちに書くことで、背景や意図、意思決定の経緯を正確に残せ、後からの認識齟齬や引き継ぎコストを減らせます。

忙しいときほど「今は仮でいいから、「決まったこと」と「背景」「経緯」のメモを残す」姿勢が大切です。

ドキュメントは未来の自分とチームへの投資です。
サボらず、今やることが結局一番効率的です。

🔸 こぼれそうなボールは積極的に拾いに行く

プロジェクトを進めていると、「誰がやるか明確でない作業」や「対応漏れになりそうな課題」が必ず発生します。

こうした「こぼれそうなボール」を放置すると、後からトラブルや遅延の原因になります。
担当が決まっていなくても、まずは気づいた人が拾い、必要に応じて周囲に共有・アサインしていく姿勢が重要です。

自分の担当範囲ではないからと見て見ぬふりをしてしまうと、最終的にチーム全体の成果にも影響してしまうかもしれません。

全員が「こぼれそうなボールを拾うこと」を意識することで、チームに一体感が生まれ、プロジェクトの安定した推進に繋がります。

🔸 自分・チームの状況を常に他者が見えるようにオープンにする

プロジェクト・タスクを円滑に進めるには、自分やチームの作業状況を他者から見える状態にしておくことが重要です。

どんなタスクでもTODOリストやチケットを作成し、進捗・残作業・課題をチームがキャッチアップできる状態にすることで、状況把握のための無駄な確認コストを減らし、早期のフォローやリスク発見が可能になります。

特定の人の頭の中だけに情報がある状態は、属人化や抜け漏れの温床です。
オープンな情報共有は、透明性と信頼を高め、チーム全体でプロジェクトを前へ進める土台になります。

「見える化」は単なるコストではなく、チームの生産性を支える投資です。

🔸 プロジェクトの定例MTGは用法用量を考えてから実施する

プロジェクトでは定例MTGを設定しがちですが、目的や頻度を考えずに惰性的に続けると、生産性を下げる要因になります。

MTGは「なぜやるのか」「何を決める場なのか」「本当に定例が必要なのか」を明確にした上で設計することが重要です。
例えば、進捗共有が目的ならドキュメントやタスク管理ツールで代替できる場合もあります。

必要なメンバー・適切な頻度・時間の上限を意識し、議題がないときは思い切って中止する判断も有効です。
MTGは習慣ではなくツールです。
用法用量を適切に考えることで、チームの集中力と推進力を高められます。

🔸 非機能要件は漏れがちなので、忘れずにタスク化しておく

プロジェクトでは、機能要件に意識が集中しがちです。
一方、非機能要件は後回しにされやすく、最悪の場合タスクとして認識すらされないことがあります。

セキュリティ、パフォーマンス、ログ設計、監視、バックアップ、運用設計などは、後から対応しようとすると大きなコストや手戻りを招く要因になります。

非機能要件は「気づいたときに検討」ではなく、最初から明示的に洗い出し、タスクとして管理することが重要です。

早い段階でタスク化しておけば、設計や開発と並行して検討・実装でき、スムーズなプロジェクト進行に繋がります。

🔸 悩む前に聞く。起案者を捕まえるのが最速の要求定義

要求定義で最も時間を浪費するのは、情報が足りないまま一人で悩み続けることです。
仕様や目的に不明点があるときは、まず起案者や有識者を捕まえて直接話を聞くのが一番早く、確実です。

文書やチケットだけでは、背景や「なぜそれをやるのか（why）」まで読み取れないことが多く、誤解したまま設計や実装に進むと大きな手戻りを生みます。

早い段階で対話し、やること・背景・意図・期待を明確化することで、認識のズレを最小限にできます。自分でうだうだ考えるより、5分話す方が圧倒的に早く、正確です。

コミュニケーション

🔸 MTGの前にゴール・アジェンダを決めておく

会議を効率的に進めるためには、MTG前にゴールとアジェンダを明確にしておくことが不可欠です。

目的が曖昧なまま始めると、議論が発散し、何も決まらないまま時間だけが過ぎてしまいます。
「何を決めたいのか」「どんな状態になったらMTGが終了するのか」を事前に定義し、必要なメンバー・資料・議題を整理しておくことで、全員が同じ目的意識でMTGに参加できます。

また、参加者も事前準備ができるため、議論の質が格段に上がります。
アジェンダとゴールをセットで準備することが、時間対効果の高い会議運営につながります。

🔸 他チームを巻き込む時は要求から認識を揃える

他のチームも巻き込んで進める必要があるプロジェクトでは、認識ズレや依存関係の抜け漏れが発生しやすくなります。

そのため、まずは要求（何を実現したいのか。なぜ必要なのか）から認識を揃えることが重要です。
背景や目的を共有した上で議論することで、他チームも自分ごととして考えやすくなり、建設的な協力関係を築けます。

単なる依頼ではなく、「なぜこの変更が必要なのか」「どんな価値を生むのか」を丁寧に伝えることで、共通のゴールに向かう推進力が生まれます。巻き込みは丁寧な説明から始まります。

🔸 何事も早め、早めのコミュニケーションで遠慮しない

プロジェクトで問題が大きくなるのは、大抵「コミュニケーションが遅れた」ことが原因です。
迷った時点・違和感を覚えた時点で早めに共有すれば、小さな問題で済むことも、放置すると大きなトラブルになります。

「もう少し様子を見よう」「忙しそうだから言いづらい」という遠慮が、結果的にチーム全体に負担をかけることもあります。
困りごと・不明点・懸念は、完璧に整理できていなくても大丈夫です。

早めに声を上げることが、チームを助け、自分を守る一番のリスクヘッジです。
コミュニケーションは“遠慮より早さ”が信頼を生みます。

🔸 問題を深掘る時は、何に困っているかを明確にして進める

問題を深掘る際に重要なのは、「何に困っているのか」を明確にすることです。
表面的な現象だけを追って議論すると、原因や優先度を見誤り、的外れな解決策に時間を費やしてしまいます。

まずは困っている事実を具体的に言語化し、「誰が」「どの場面で」「なぜ困っているのか」を整理することで、問題の本質が見えてきます。

曖昧なまま議論を進めると、意見がすれ違い、いつの間にか「別の話」をしてしまうこともあります。
問題の深掘りは、原因探しではなく“困りごとの明確化”から始める。それが本質的な課題解決への第一歩です。

🔸 否定と代替案はセット

議論やレビューの場で「それは違う」「やめたほうがいい」と否定だけを伝えても、建設的な議論にはつながりません。

大切なのは、否定と同時に「ではどうすれば良いか」という代替案を提示することです。
代替案があることで、次のアクションを取りやすくなり、チーム全体が前向きに動けます。

否定だけでは問題意識の共有で止まってしまいますが、代替案を添えれば改善への提案になります。

代替案を考えるのは難しいですが、批判だけに終わらず代替案を考える姿勢が、信頼を生み、議論の質を高めるのです。

🔸 魚を与えるのではなく、魚の釣り方を教える

メンバーを育成するうえで大切なのは、課題を直接解決してあげることではなく、解決のプロセスを学ばせることです。

答え（魚）を与えるだけでは、その場しのぎで終わり、次に同じ課題が出たときに自走できません。
まずは「魚の釣り方」を教え、考え方や判断軸を共有することが成長につながります。

さらに理想は、相手が自分で釣り方を考えられるようになること。
つまり、再現性のある問題解決力を育むことです。
指示ではなく思考を促すサポートを意識することで、チーム全体が自律的に動ける強い組織へと変わっていきます。

まとめのまとめ

他にもたくさん学んだことはありますが、以上が「今後も忘れずに実践していきたい」学んだことでした！

前職では3年半、たくさんの優秀な方々と一緒に仕事ができて本当に幸せでした。
そんな方々に負けないように、私もこれから更に成長して、社会をより良くするプロダクトを創っていきます！