🤖

構造で育てる設計力：11ステップで学ぶ思考構造と判断の型

に公開
キャリア
設計
思考法
成長戦略
構造で育てる
idea

構造で育てる設計力：11ステップで学ぶ思考構造と判断の型

概要

このドキュメントは、プログラミング初学者からアーキテクトまで、段階的に設計力を高めていくための成長ステップを自分なりに体系化したものです
各ステップは「目的」「やること」「教材例」「NG例」によって構成され、設計判断・構造化思考・伝達力の向上を支援できるように構成しています

対象読者例：

  • 初学者：コーディングから設計への第一歩を踏み出したい人
  • 中堅〜シニア：設計判断に言語化と再現性を求めたい人
  • 支援者層：レビュー・育成のための観点や問い（考えるきっかけや確認ポイント）を探している人

ステップ0：まずは「動くコード」を楽しむ

目的：手を動かす習慣と成功体験の獲得

やること：

  • チュートリアルや模写でCLIやUIを動かす
  • カウントアプリ、ToDoリストなど小さいプロジェクト

教材例：

  • Progate / ドットインストール
  • 『たのしいRuby』『Python1年生』

NG例：

  • 手を動かさずに記事だけ読む
  • フレームワークだけ触って中身を理解しない

ステップ1：「なぜそう書くのか？」をちょっと考える

目的：自分の中の「設計の種」に気づく

やること：

  • 関数分けや命名理由を考える
  • 同じ処理が2回出てきたら「関数化できる？」と自問

教材例：

  • 『リーダブルコード』
  • PRレビュー系YouTube（ThePrimeagenなど）

NG例：

  • Linterの指摘を理解せず直す
  • コピペコードをそのまま使う

ステップ2：「書き方の違い」が気になるようになる

目的：実装方法の多様性＝設計判断だと気づく

やること：

  • 同じ機能を複数の方法で実装して比較
  • 記事や他人のコードを読んで「なぜこの書き方？」と考える

教材例：

  • QiitaやZennの比較系設計記事
  • 『良いコード／悪いコードで学ぶ設計入門』

NG例：

  • 「これがベスト」と思考停止
  • 実装の違いを好き嫌いで済ませる

ステップ3：構造の違いが将来性に響くと気づく

目的：保守性・拡張性を構造で感じ取る

やること：

  • 古いコードに機能追加してつらさを実感
  • 小さなリファクタ（ifの分離、変数名改善など）

教材例：

  • Refactoring Guru
  • 『オブジェクト指向設計実践ガイド』

NG例：

  • 「今動けばいい」で構造を軽視
  • 見た目の綺麗さだけでリファクタ判断

ステップ4：「なぜこう設計したか」を言語化しはじめる

目的：設計判断の説明責任を意識する

やること：

  • PRやIssueで「なぜこうしたか」を1文書く
  • 小さな構成図を描いてみる

教材例：

  • 『エンジニアのためのドキュメントライティング』
  • PlantUML入門記事

NG例：

  • 理由を持たずに設計を選ぶ
  • 他人の真似だけで判断理由を失う

ステップ5：トレードオフと代償で判断する

目的：最適化ではなく、制約条件下での最良選択をする

やること：

  • A案B案の比較を表にまとめる
  • どの観点を捨て、何を得るかを明示

教材例：

  • 『クラウドネイティブアプリケーション設計』
  • 各種Zenn設計記事（WebSocket vs Pollingなど）

NG例：

  • 「全部できます」と言いがち
  • 設計に制約を考慮しない

ステップ6：設計原則を状況に応じて使い分ける

目的：原則を「知識」でなく「判断軸」として使う

やること：

  • 原則の適用／非適用を事例で考える
  • 原則同士の衝突時にバランスをとる練習

教材例：

  • 『実践ドメイン駆動設計』
  • 『Clean Architecture』

NG例：

  • 原則を守ること自体が目的になる
  • 語彙だけで設計を語る

ステップ7：判断を伝え、合意をつくる

目的：設計を「他者と共有しうる判断言語」に変える

やること：

  • Docsに以下のテンプレで書く：
    • 背景：なぜ今これが必要か？
    • 選択肢：どの案があったか？
    • 理由：なぜこの案を選んだか？
  • 他者レビューで「何を根拠にそうした？」を問う

教材例：

  • Google Design Docsの書き方記事
  • 技術組織の設計レビューガイド（例：BASEのレビュー観点ドキュメント、クックパッドの設計レビュー運用）

NG例：

  • 「方針です」で説明が終わる
  • 合意形成を押し切りや妥協で終わらせる

ステップ8：判断を再利用可能な知に変える

目的：設計知を他者も使える形に変換

やること：

  • よくある判断を「設計原則カード」にする
  • 設計演習や観点レビューをチームに導入

教材例：

  • 『Team Topologies』
  • 以下のような社内ナレッジ・設計演習支援資料の自作：
    • 『設計レビュー観点チェックリスト』（Google Docsフォーマット）
    • 設計判断テンプレート（背景／目的／選択肢／判断理由）
    • チーム内設計演習課題（例：トランザクション設計・レプリケーション構成案レビュー）
    • Notionベースの設計観点マトリクス（スケーラビリティ・保守性など）
    • 社内Miroテンプレート：観点別レビューカード

NG例：

  • 経験を言語化せず属人化させる
  • 「ノウハウ」としてしまって再利用できない（例：一人のWikiメモ、Slackに流れる投稿）

ステップ9：設計育成の仕組みを作る

目的：他者の設計力を育てる支援構造を構築

やること：

  • 設計テンプレ・観点チェックリストを整備
  • レビュー演習／内省会を定期化

教材例：

  • 技術支援のしくみ設計記事（例：mercariのTech Mentorship Program、SmartHRの育成体制事例）
  • エンジニアリングマネージャー向け資料（例：『エンジニアリングマネージャーのしごと』『Team Geek』）

NG例：

  • 自分しか使えない支援ツール
  • 他人の設計を代わりに考えてしまう

ステップ10：構造知として理論化する

目的：経験知を超えて分野原理を抽象化

やること：

  • 設計思想をZennや書籍として発信
  • OSSや設計フレームワークへの貢献

教材例：

  • ThoughtWorksの技術戦略記事（例：Technology Radar、Software Architecture: The Hard Parts）
  • ソフトウェア設計に関する研究系資料（例：IEEE Software誌の設計原則論文、ACM Queueの分散システム設計論）

NG例：

  • 自己体験のみを絶対視する
  • 理論と現場の接続が弱い

ステップ11：知が流通する構造を設計する

目的：設計判断が組織・社会で循環する構造をつくる

やること：

  • ドキュメント文化／相談制度／観点共通言語を設計
  • 設計支援ツール・レビュー支援インフラを整備

教材例：

  • 知識経営・ナレッジマネジメント系文献（例：『知識創造企業』『ナレッジワーカーの時代』）
  • 技術組織設計事例集（例：Wantedlyの職能横断チーム設計、SmartNewsのTech Ladder事例）

NG例：

  • 仕組みが属人化／自分依存で回らない
  • 利用されない仕組みで満足する

補足：導入と活用のためのヒントと小並感

  • 初学者〜設計者〜支援者と成長できる地図として使うとよいかも
  • 勉強会や1on1での育成支援ツールとしても利用可能になってると思います
  • 学習スピートは異なるでしょうが、熟練でも門外漢の分野ではステップの初期からやり直すことになると思います
    • 余談ですが、このようなやり直しコストはエンジニアが慣れた道具やパターンを使いたがる理由でもあり、またgoogle cloudやawsなどのベンダーが独自用語やプロトコルによるロックインを好む理由でもあると考えています
  • ステップごとのチェックリスト／問い集は時間があれば今後提供するかも?
  • zenn初心者なので変な所あったらごめんなさい

📘 本記事の11ステップ構造は、「思考と育成を再現可能にする設計思想」から生まれました。

その設計観・判断の抽象モデルをまとめた記事があります
構造をどうつくり、どう伝播させるか
育成の“型”の背後にある“OS”に関心があれば、ぜひご一読ください

👉 構造で育てる思考：再現可能な成長フレームの作り方

🛠 補足：構造で育てた設計力が、実際にどんな現場でどう活きるのか──
SaaS設計レビューにおける「視座のズレ」や「判断観点の構造」を整理した実践記事もあります

👉 SaaS設計レビュー 観点チェックリスト【2025年版】

🧭 構造で育てる：思考と設計の3層モデル

この知識群は、以下の3つのレイヤーで構成されています。
思考のOSから、育成フレーム、現場実装まで──必要に応じて行き来してください。

Discussion