この記事は そーだいなる Advent Calendar 2025 20日目 の記事です

adventar.org

はじめに

前職で技術顧問として そーだいさん にJOINしていただいていた際、私はデータベース設計から仕事の進め方相談まで、本当にお世話になりました。

そーだいさんは「ガタイも(物理的に)声も大きくて、ちょっと圧倒されるな……！」というものでしたが、実際にお話ししてみると、その中身は驚くほど優しく、そして本当にロジカルで誠実な方でした。
その圧倒的な「言語化能力」で、技術的な課題はもちろん、エンジニアとしての振る舞いや問題解決の考え方を、誰にでもわかる言葉で解きほぐしてくれます。

今回は、私が定期的に読み返し、1on1などの場でも「まずこれを読んで！」と周囲に布教している、そーだいさんの発信をいくつか紹介したいと思います。

1. 仕事を進めるうえでのマインドセット

1-1. Howだけ考えると複雑さを導入して仕事が増える

• 「偽の進捗」の連鎖によるリソース枯渇の防止

  • 手段に没頭して手順書の保守や不要な会議などの「偽の進捗」に陥ると、中毒的に不要な仕事が増え続け、リソースを枯渇させてしまいます。

• 「How」の没頭を脱し「Why」で本質を捉え直す

  • 「How（どうやるか）」という手段に没頭するのではなく、「Why（なぜやるか）」を常に問い直し、問題の本質を捉えることが重要です。

• 「仕事」の再定義：価値提供以外の徹底的な削ぎ落とし

  • コーディングや会議そのものは価値ではなく、エンドユーザーに価値を届けることのみが仕事であると定義し、不要な機能や工程は徹底的に削ぎ落とすべきです。

• 違和感に気づき「辞める勇気」でビジネスを加速させる

  • 「自分たちの仕事が増えていないか？」という機微を感じ取り、本質的でないと気づいた作業はその瞬間に辞める勇気を持ち、技術を使ってビジネスを前に進めることに注力するのが本来の仕事です。

1-2. 判断と決断の違いと決断のコツ

• 理屈で選ぶ「判断」と、意志で決める「決断」

  • データや情報を集めて正解を導き出すのが「判断」で、情報が足りない中で答えを出すのが「決断」。理屈だけで片付かない不透明な状況で、自らの意志で進むべき道を示すことが、組織を前に進める力になります。

•  「やり直し」ができる環境が、スピードを生む

  • 決断を早くするコツは、万が一失敗しても元に戻せる（ロールバックできる）状態を作っておくことです。やり直しがきくことならどんどん試して、素早くフィードバックを得る。そうした「小さな決断」をメンバーに任せていくことが、チーム全体の成長と自律に繋がります。

• 難しい決断を乗り越える「5つのステップ」

  • 決断に迷ったときは、まず条件を整理し、次に「小さく始めて失敗できる形」にできないか検討します。それが難しいなら周囲の知見を集め、それでも答えが出なければ無理に決めず時間を置く。どうしても今、重大な決断が必要なときは「最もダメージが少ない道」を選び抜く覚悟を固めます。

• 揺るがない「自分の軸」を日頃から磨いておく

  • 正解のない問いに立ち向かうには、日頃からビジョンや哲学といった「自分なりの指針」を持っておくことが不可欠です。決断は練習で上達するスキルだと心得て、日々小さな決断を積み重ねる。時には痛みを伴う選択も引き受ける「覚悟」を持つことが、リーダーとしての信頼を築きます。

1-3. 当たり前にリリースしていく ~ 新卒研修編

• リリースの「定常化」を支える予防と復旧の仕組み

  • リリースを「当たり前のこと」にするためには、事故を未然に防ぐ仕組みと、万が一の際に迅速に復旧できる仕組みの両面を整えることが不可欠です。

• 変更耐性の高い設計と、開発者による能動的な監視

  • コードには「変更を受け入れる遊び（Decoratorパターン等）」を持たせて影響範囲を最小化し、アプリケーションを最も理解する人が振る舞いを監視して異常を早期発見する必要があります。

• YAGNIの誤解を排した徹底的な思考とチーム連携

  • 「YAGNI（今は必要ない）」を設計を怠る言い訳にせず、納期などの制約内で最大限考え抜いた上で、早めにチームを頼って本質的な課題分解を行う姿勢が求められます。

• 破壊的変更の回避と「可逆性」の維持による成長

  • 破壊的な変更を避け、小さく部分的にリリースすることで「いつでも元に戻せる」状態を維持し、成功体験を積み重ねて自信を築くことが成長への近道です。

2. エンジニアとして成長し続けるための指針

2-1. ソフトウェア開発者に必要な考え方

• リリースによる価値創出と「完成」へのこだわり

  • ソフトウェアはリリースされユーザに届いて初めて価値を持つため、目的（Why）を軸にタスクを細分化し「完成」を明確に定義することが不可欠である。  

• 環境順応から自己主導へ：真の主体性の獲得

  • 指示を待つのではなく「主体性」を持って自らの意思で仕事を完遂する自律性が求められ、環境順応型から自己主導型の知性へと成長する必要がある。

• 知識を「成果」へ変えるための習慣と実践

  • 未完了のコードは無価値な「在庫」と心得て、先人の知恵を体系的に学びつつ、知識を実践を通して「習慣」へと昇華させ成果を出し続ける。

2-2. **強い**エンジニアのなり方

• 内省による成長

  • 強いエンジニアとは「問題解決ができる人」であり、日報や週報を通じて日々の仕事を振り返り、経験に複利を効かせる「内省」の習慣が成長の源泉となる。  

• 適切な問題設定

  • 解決したい問題にフォーカスし、問題を「実行可能な最小単位（タスク）」まで分解してスコープを調整することで、自然と適切なサイズでのリリースが可能になる。  

• 具象と抽象の往復

  • コルブの経験学習モデル（経験→内省→抽象化→実践）を意識し、具体的な経験から法則性を見出す「抽象的概念化」を繰り返すことで、エンジニアに不可欠な思考力を磨く。  

• 今この瞬間からの積み重ね

  • 成長のチャンスは常に目の前にあり、誰の許可も得ず「昨日の自分に誇れる今日の自分」を目指して一歩ずつ積み重ね続ける姿勢こそが、いつか偉業へと繋がる道になる。

2-3. 目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる

• 能力の定義と成長ステップ:

  • 能力（技能・熟練）は知識と経験を掛け合わせて「知恵」へと昇華させることであり、未知の状態から習慣化まで段階的にステップアップする反復学習が不可欠である。  

• 主体的なスキルアップ:

  • 会社が育ててくれる時代は終わったため、プロとして「計画実行力」「言語化力」「問題解決能力」を仕事の中で主体的に鍛え、ソフトウェアを通じた課題解決力を高める必要がある。  

• 実践的な訓練手法:

  • 適切な問題設定と「完了の定義」の明確化を重視し、日報・週報による内省や「理想のプログラマ」を演じるロールプレイングを通じて、日々の仕事にフィードバックサイクルを組み込むことが成長の近道となる。

• 日々の積み重ね:

  • 始めるのに遅すぎることはなく、毎日一つ「知らないこと」を見つけて能力へと変え、昨日の自分に誇れる今日の自分を目指して一歩ずつ強くなる姿勢が重要である。

2-4. 問題を解決するために必要な習慣

• 本質の追求と仕組み化:

  • 「How（手法）」に囚われて仕事を増やす中毒症状を脱し、「Why（目的）」を軸に不要な作業を削ぎ落とし、精神論ではなく「始めやすく辞めやすい」仕組みで課題を解決する。  

• 主体的な自律とタスク分解:

  • 自律とは主体性を持って働くことであり、5W1Hを整理して「他人に依頼できる」または「やる気に関わらず一歩目が踏み出せる」最小単位まで問題を具体的に分解・言語化する。  

• 現実の受容と優先度ハック:

  • 手が付かないタスクは無理をせず現実を受け入れ、納期の設定や他人を巻き込むことで優先度を管理し、時には豊かな人生のために「諦める」という選択も適切に行う。  

• 信頼に基づくチームの活用:

  • 「遠くへ行くなら皆で進む」精神を持ち、過去の評価である「信用」ではなく未来を信じる「信頼」をベースに、適切なサイズの課題を仲間とシェアしてチーム文化で解決していく。

2-5. 適切な問題設定と小さくリリースするということ

• リリースの価値と「在庫」の排除:

  • ソフトウェアはユーザに届いて初めて価値が生まれるため、未完了のコードを「無価値な在庫」と心得て、完璧主義を捨て市場のフィードバックを得るための早期リリースを最優先すべきである 。  

• 適切な問題設定とタスク分解:

  • ユーザーストーリーの5W1Hを整理し、チケットが巨大な場合はスコープを調整して「リリースの単位が最小になる」ようにタスクを分解することで、着実な成果の積み上げを可能にする 。  

• 失敗できる仕組みの構築:

  • リリースへの恐怖を「やる気」で克服しようとせず、サービスを壊さず安全にリリースできる手段を整え、小さく失敗して改善のサイクルを高速に回せる環境を仕組みで解決する。  

• 「小さいものは美しい」の実践:

  • Unix哲学の「一つのことをうまくやる」精神を貫き、最速かつ最小の手段でプロトタイプを試作・評価し、自分たちにしか直せない目の前のコードを通じて価値を提供し続けることが本質である。

3. 問題解決の本質を突く「思考法」

3-1. 仕事を前に進めるためのコツ - 判断と決断と共有

• オーナーシップとタスクの具体化

  • 仕事を前に進めるには当事者意識（オーナーシップ）を持ち、問題を深く理解した上で5W1Hに基づく具体的なタスクへ分解することが重要です。

• 停滞を生まない迅速な意思決定

  • 意志決定では、論理的な「判断」と不透明な状況下での「決断」を区別し、自らがボトルネックにならないよう迅速に動くことが求められます。

• SBIモデルによる期待値調整と対話

  • 円滑な共有のため、SBIモデル（状況・行動・影響）を活用した期待値調整や、日々の些細なコミュニケーションを積み重ねることが不可欠です。

• 成功体験の蓄積とアウトカムの創出

  • これらの知識と行動によって「できる」という経験を得ることで、問題を解決し大きな成果（アウトカム）を生むことが可能になります

3-2. 抽象化をするということ - 具体と抽象の往復を身につける

• 具体と抽象の往復による本質の把握

  • 抽象化とは複数の具体から共通項を見つけて名前をつけるスキルであり、五感で感じる具体と往復することで対象の理解を深め、一言で本質を伝えることを可能にします 。  

• エンジニアリングの本分としての概念化

  • ソフトウェア開発はこの「往復」そのものであり、抽象的な要求を具体的仕様へ落とし込み、具体的な業務知識を設計へと抽象化するプロセスの自覚的な反復こそがエンジニアの仕事です 。  

• 再現性のあるスキルへの昇華

  • 抽象化能力は知識と経験に紐づく後天的なスキルであり、日々の仕事で「理想のプログラマ」を演じ、成功体験を積み重ねることで、誰でも再現性のある能力として獲得できます。

• 知の探索と自己決定力の獲得

  • 「無知の知」から学びを始め、目の前の一段を刻むような地道な実践を積み重ねることが自信を築く鍵となり、自らの意思で人生の針を進める力へと繋がります 。

3-3. DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所

• DBの長命性と「ダブルループ学習」による本質的設計

  • データベースの寿命はアプリケーションより長く、ドメイン背景を理解せず過去のパターンを回答しがちなAIに代わり、人間が前提条件から見直す「ダブルループ学習」で設計することが不可欠です。  

• 「Easy」を排し、客観的な「Simple」を追求する

  • 主観的な馴染みやすさである「Easy」な設計に逃げず、客観的に概念を最小化した「Simple（正規化）」を追求し、事実のみを保存して重複や不整合、不要なNULLを徹底的に排除します。  

• 変化に強い「イミュータブルデータモデル」の確立

  • 「1テーブル1責務」の原則や、システムを複雑化させるUPDATEを最小限に抑える「イミュータブルデータモデル」の採用が、AIによって高速に肥大化する開発現場において変化に強い構造を維持する鍵となります。 

• 未来を救う「一生モノ」のモデリングスキル

  • データモデリングは複利で効く一生モノのスキルであり、AIに作業をサポートさせつつ、人間が物理世界の要求を整理して最適な要件へと昇華させることが、未来の自分を救うことにつながります。

おわりに

そーだいさんの口癖を借りるなら、「上記、全部きたはらが言ったことになんないかなぁ」です（笑）。

そーだいさんがミーティングに途中から参加されたとき、「今北三行でまとめて」と言ってくださるのにならって、各記事をできる限り3、4行でまとめてみました。要約して現況をお伝えする能力も、本当に重要ですね。

そーだいさんの教えは、私の中で単なる知識としてではなく、「どう生き、どう働くか」という習慣として根付いています。 そーだいさん、いつも温かいご指導と素晴らしい言語化をありがとうございます！これからも、そーだいさんの背中を追いかけつつ、学んだことをチームに還元していきたいと思います。

今度こそ、飲みに行きましょう！

参考