はじめに -具体と抽象とは-
具体と抽象は細谷功さんが書かれた名著で、「思考の幅と深さを広げるための鍵」として多くのビジネスパーソンやクリエイターに支持されています。この本では、具体的な物事と抽象的な概念の間を行き来する思考法を学ぶことで、問題解決能力やコミュニケーションスキルが格段に向上すると説かれています。
具体とは、目の前の課題やタスクのように、明確で詳細な情報を指します。一方、抽象とは、物事の背後にある原則や本質を指し、個々の具体的な事象から共通点を引き出して整理したものです。この2つを自由に行き来する能力が、個人やチームのパフォーマンスを大きく左右します。
なぜ具体と抽象が大切なのか？
現代の複雑化するビジネスや開発現場において、具体的な実行力と抽象的なビジョンの両方をバランスよく持つことが求められています。例えば、抽象的な目標だけでは行動に移せず、具体的なタスクだけでは方向性を見失いがちです。両者を適切に使い分けることが、成功の鍵となります。
具体と抽象をうまく使い分けられると
- 問題解決がスムーズになる：課題の本質を見極めつつ、現実的なアプローチを取れる
- コミュニケーションが円滑になる：抽象的なビジョンを共有し、具体的な行動に落とし込むことでチームの認識を一致させられる
- 効率が上がる：余計な作業を減らし、最短距離で目標に到達できる
この記事を読むとどんな良いことがあるか？
本記事では、この具体と抽象の思考法をスクラム開発にどう応用するかを解説します。以下のようなメリットを得られるでしょう
- スクラムの現場で役立つ具体例を学べる：リファインメントやふりかえりでの活用法を紹介します
- POと開発チームのギャップを減らせる：抽象的なビジョンと具体的なタスクの橋渡し方法を理解できます
- チームの生産性を向上させるヒントが得られる：無駄を省き、効果的にゴールを達成する方法を知ることができます
この記事を通じて、具体と抽象の思考法をスクラム開発の現場で活かし、チームの力を最大限に引き出す一助になれば幸いです。
抽象化は日常に溢れている
実は、私たちの日常生活でも、具体と抽象の往復は繰り返されています。そして、この具体と抽象の話の段階が合わない場合、コミュニケーションがしづらくなることがあります。
例えば、夕食の準備をめぐる夫婦の会話を想像してみましょう。
夫: 「今日の夕食、カレーがいいんじゃない？」
妻: 「いや、野菜炒めの方が手軽じゃない？」
夫: 「でも昨日カレーの材料買ったよね。」
妻: 「野菜もたくさんあるから早く使わないとダメになるよ。」
この会話では、どちらも具体的な提案をしていますが、「夕食をどうしたいのか」という抽象的な目的が共有されていないため、会話が平行線をたどっています。夫は「食材を無駄にしたくない」という意図でカレーを提案しているのかもしれません。一方、妻は「手間を省いて時短したい」という意図で野菜炒めを提案しているのかもしれません。しかし、具体的な料理名ばかりを挙げて話しているため、双方の意図が見えず、噛み合わないのです。
このような場合、「何を優先したいか」を明確にすることで話がスムーズになります。
夫: 「夕食は、できるだけ買った材料を無駄にしないようにしたいと思ってるんだ。」
妻: 「私は手間をかけずにサッと作れるものがいいな。」
こうして互いの意図を抽象化して共有することで、「じゃあ、カレーを簡単に作れる方法を考えよう」や「野菜炒めにカレーの材料を使うのはどう？」といった、より具体的で合意しやすい解決策を見つけられるようになります。
具体的な提案だけではなく、抽象的な目的や意図を共有することは、日常生活でもスムーズなコミュニケーションを実現する鍵となります。具体と抽象の往復を意識することで、お互いの思いがより深く理解できるようになるでしょう。
チームで仕事をする場合も同様に、具体と抽象を行き来することで目的を見失わず、チームで同じ方向を向いて進むことができるでしょう。
リファインメントは「抽象→具体」を行う場
スクラム開発ではリファインメントでPBIの内容をチームで確認しながら、見積もりを行います。その際にPOに対してPBIの不明点を質問を行い、やることを明確にしてから見積もりを行うためエンジニアとPOとで話し合うことになります。
このとき自分が意識していることが、POは抽象を語り、Devは具体を語るということです。この考え方を理解していると、何か話が噛み合わない・やりたいことがわからないといった疑問を減らすことができます。
例えば、あるPBIが「ユーザー登録時のエラー体験を改善する」という抽象的な内容だった場合、POは次のように説明するかもしれません。
PO（抽象を語る）:
「ユーザーが登録時にエラーに遭遇すると、アプリの信頼性が下がります。特に入力ミスやネットワークの問題で登録ができない場合に、ユーザーが次にどうすればいいのかを明確に示したいと考えています。」
ここでエンジニアが意識すべきことは、この抽象的な目標を具体的な実装案に落とし込むことです。例えば、次のような質問をしながら具体化を進めます。
Dev（具体を語る）:
- 「エラー発生時にはどのような情報をユーザーに提供したいですか？例：フィールドごとのエラーメッセージ、全体的なエラーメッセージ。」
- 「エラー内容はどの程度詳細に表示する必要がありますか？例：技術的なエラーメッセージか、それともユーザー向けの簡易的な説明か。」
- 「ネットワークの問題の場合は再試行ボタンを設けるべきでしょうか？」
これにより、PBIの内容が具体的になります。
具体化されたPBIの例
リファインメント後、PBIは次のような具体的な形に落とし込まれます：
1. エラー発生時のメッセージ
- 入力ミスの場合：該当フィールドの下に具体的なエラー内容を表示（例：「メールアドレスが無効です」）。
- サーバーエラーの場合：画面上部に「現在、サーバーに接続できません。しばらくしてから再試行してください。」と表示。
2. 再試行ボタンの追加 - エラーがネットワーク関連の場合に、再試行ボタンを表示し、クリックでリクエストを再送信する。
3. デザイン改善案 - エラーメッセージを強調するために赤文字＋アイコンを使用。
- 再試行ボタンはユーザーが直感的に見つけやすい位置に配置。
POは抽象を語り、Devは具体を語るを理解していない場合のデメリット
1. ゴールの不明確さによる無駄な作業
デメリット
- POが抽象的な目標を具体化せずにDevに伝えると、開発チームが何を作るべきか迷い、不要な作業を行ってしまう。
- Devも抽象的な内容を深掘りせず、そのまま進めてしまうと意図と異なる成果物ができる。
具体例
状況:
POが「ユーザー登録プロセスを改善したい」という要望を出し、Devがそれを詳細に確認せずに「新しいフォームを作れば解決するだろう」と仮定して作業を進めた。
結果:
実際には、POが期待していたのは「登録時のエラーメッセージを明確にしてユーザー体験を改善すること」であり、フォームの刷新は不要だった。この誤解により、時間とリソースが無駄に。
2. 課題が技術的な視点に偏り、価値が生まれない
デメリット
- Devが抽象的な目標に踏み込まず、技術的な詳細ばかりに集中すると、ユーザーやビジネスの価値につながらない成果物になる。
- POも具体性を欠いて説明すると、技術的視点だけで解釈されてしまう。
具体例
状況:
POが「検索機能のUXを向上させてほしい」と依頼。Devが「検索速度を高速化すれば解決するだろう」と判断し、検索アルゴリズムを最適化した。
結果:
実際にPOが求めていたのは「検索結果にフィルタリング機能を追加して、ユーザーが目的の情報に素早くアクセスできること」だった。検索速度の改善はユーザーの課題解決に直結しなかった。
3. リファインメントで議論が堂々巡りする
デメリット
- POが具体的すぎる議論に巻き込まれると全体像が見えなくなり、リファインメントの時間が非効率的になる。
- Devが抽象的な目標を理解せずに詳細ばかり議論すると、チームの足並みが揃わない。
具体例
状況:
POが「新機能を導入してコンバージョン率を上げたい」と提案した際、Devが「どのライブラリを使うべきか」「API設計はどうするか」といった技術的な詳細に話を偏らせた。
結果:
「なぜこの機能が必要なのか」「どんな成果を期待しているのか」という全体像が共有されず、仕様変更が頻発。開発計画も遅延。
4. チーム内での摩擦や信頼関係の低下
デメリット
- 役割の違いが理解されないと、POとDevが互いに「相手が自分の意図を理解していない」と感じるようになる。
- 意図と成果物が食い違い、無駄なリワークが発生して不満が募る。
具体例
状況:
POが「ユーザー登録時の成功体験を向上させたい」と語ったが、具体化を怠ったため、Devが「成功時のポップアップを追加する」と勝手に解釈して実装を進めた。
結果:
POは「登録完了後に次のアクションへスムーズに進めるような案内を出す」ことを望んでいた。成果物が意図と異なるためやり直しとなり、両者に不満が残る。
理解することで得られること
「POは抽象を語り、Devは具体を語る」という役割を理解することは、単に役割分担を明確にするだけでなく、チーム全体の生産性や信頼関係を向上させます。
- エンジニアは受け入れ条件の穴をつくのではなく、一緒に抽象から具体に落とし込む意識を持つ：PBIに疑問点があれば、目的や価値を再確認しながら、チームで解決策を練り上げる姿勢が求められます。
- POはPBIにある価値（抽象的）を伝え、それを具体化させるための方向性をチームに共有する：なぜこのPBIが重要で、どのような価値を生むのかを明確にし、具体化のガイド役としてチームを導きます。
この意識を持つことで、PBIが曖昧なまま進行してしまうリスクを減らし、全員が共通の目標に向かって協力する強いチームが生まれます。
ふりかえりでの活用法 -具体的な問題から抽象化へのアプローチ-
ふりかえり（レトロスペクティブ）は、チームが過去のスプリントを振り返り、改善を模索する場です。この場で提案されるトライ（試み）は、しばしば具体的な問題解決に焦点が当たります。しかし、時には問題を抽象化し、その問題群に対する抽象的な解決策を考えることが、長期的に見て有効な場合があります。
なぜ抽象化が重要なのか？
具体的な解決策は、その場の問題を解消するためには有効ですが、似たような状況に適用できる場合は限られています。一方で、抽象的な解決策は応用性が高く、同じ本質を持つ複数の問題に対処することが可能です。これにより、チームはより汎用的な方法論を身につけ、継続的に改善を進める力を得ることができます。
具体例：タスクの進捗共有不足
状況:
スプリント中、タスクの進捗状況が十分に共有されず、いくつかのタスクがスプリントの最後まで手つかずのまま残る問題が発生しました。JIRAなどのタスク管理ツールを使っているものの、チームメンバーがツールを活用しきれていない状況です。
具体的な解決策
- 「デイリースクラムで各自のタスク進捗を必ず報告するようにルール化する。」
- 「JIRAのステータスを更新するタイミングを明確にする。」
これらの解決策は進捗の見える化には有効ですが、タスク共有不足という問題に限られており、他のコミュニケーション不足の課題（例：障害対応時の情報共有不足）には応用できません。
抽象的な解決策
- 問題を抽象化して「重要な情報が適切に共有されない仕組みの課題」として捉えます。
- 解決策として「チーム全体が同じ情報を常に把握できる仕組みを強化する」という方向性を考えます。これにより、タスク進捗以外の共有不足（例：依存関係の認識不足）にも対応可能になります。
試したトライ:
スプリント中、JIRAのタスクに「担当者コメント」機能を活用することをルール化しました。各タスクには、進捗状況や障害となっている課題を簡潔に記載し、全員がJIRAを通じて情報を確認できるようにしました。また、デイリースクラムでタスク進捗をただ報告するのではなく、「次にこのタスクで何が必要か」を共有するフォーマットを導入しました。
抽象化のメリット
抽象的な解決策を考えることで、以下のようなメリットがあります：
- 応用性の高さ: 類似する問題にも適用可能で、チームの幅広い課題解決に貢献。
- 本質的な理解: 問題の根本原因を捉えやすくなり、表面的な対応に留まらない。
- 長期的な改善: チーム全体の成熟度が向上し、再発防止策を一般化できる。
ふりかえりでは、具体的な問題に直面した際でも、その背後にある共通する課題やパターンを抽象化し、より汎用的な解決策を模索してみてください。これが、チームの持続的な成長と柔軟性を高める大きな一歩となるはずです。
スクラムにおける具体と抽象のバランス
スクラムでは、具体と抽象のバランスを適切に保つことが成功の鍵となります。それぞれの役割に応じて具体と抽象の使い方が異なりますが、全員がこのバランスを意識することで、チーム全体の効率性と成果が向上します。
プロダクトオーナー（PO）の視点
プロダクトオーナーの役割は、抽象的なビジネス目標を具体的なタスクに落とし込むことにあります。
- 抽象的な視点: ビジネス価値の高い目標や製品のビジョンを示し、チームに共有します。たとえば、「ユーザーの継続利用率を向上させる」という目標を立てます。
- 具体的な視点: その目標を達成するために、「ユーザー登録プロセスの改善」や「エラー発生時のガイドを強化する」といった具体的なPBI（プロダクトバックログアイテム）を作成します。
POが抽象的な目標を具体化する際に重要なのは、「なぜこのタスクが重要なのか」という背景を明確にすることです。これにより、開発チームがただの作業としてではなく、価値を意識した取り組みが可能になります。
開発チーム（Dev）の視点
開発チームの役割は、具体的な実装に取り組むと同時に、その背景にある抽象的な価値を理解することです。
- 具体的な視点: タスクを実際にコードや設計として具現化し、プロダクトを形にします。たとえば、「新しいログインフォームを作成する」「エラーメッセージを分かりやすく表示する」といった作業を行います。
- 抽象的な視点: なぜそのタスクが重要なのか、最終的にユーザーやビジネスにどんな価値をもたらすのかを考えます。これにより、単に指示通りに作業をするのではなく、目的を意識したより良い提案や改善が生まれます。
開発チームが抽象的な視点を見失うと、「ただ言われたことを作る」状態に陥り、チームのモチベーションや成果が低下する可能性があります。背景を理解し、POと対話を重ねることで、抽象的な目標と具体的なタスクを結びつけることが重要です。
スクラムマスター（SM）の視点
スクラムマスターの役割は、チーム全体が具体と抽象の間で迷子にならないよう調整を行うことです。
- 抽象的な視点: チームがスクラムの原則や目標に沿って動いているかをチェックし、進むべき方向性をサポートします。たとえば、「このスプリントの目標は明確か？」「目標達成のためにチームが効果的に協力できているか？」といった全体的な観点でチームを見守ります。
- 具体的な視点: デイリースクラムやリファインメントの場で、タスクの優先度や進捗に問題がないかを確認します。また、POと開発チームの間で具体的なタスクが正しく共有されているかをチェックします。
SMは、抽象的な目標に対して具体的なアクションが適切に進んでいるかを見守り、どちらか一方に偏りすぎないようバランスを取る潤滑油の役割を担っています。
チーム全体の具体と抽象のバランスを保つために
スクラムでは、PO、Dev、SMがそれぞれの役割を果たしつつ、以下のようなポイントを意識すると、具体と抽象のバランスを保ちやすくなります：
- PBIの背景を共有する: POは、PBIに込めた意図や価値を具体的に説明する。
- 具体と抽象を行き来する会話をする: Devはタスクの進め方を共有しつつ、そのタスクがどう価値に繋がるかをPOに確認する。
- ふりかえりで調整を行う: SMは、スプリント終了後にチームが具体と抽象のバランスを保てていたかを確認し、次の改善点を考える。
このようにして具体と抽象のバランスを保つことが、スクラムチームの成功を支える大きな要素となります。
まとめ -具体と抽象を行き来する力をチームの武器に-
この記事では、「具体と抽象」という思考法が、日常生活からスクラム開発まで幅広く活用できることを解説しました。この思考法を身につけることで、コミュニケーションがスムーズになり、問題解決やチーム運営がより効率的かつ効果的になります。
具体と抽象を意識することで得られる効果は次の通りです：
-
課題解決の幅を広げる
問題を具体化することで現状の課題を解決し、抽象化することで本質的な原因を見極める力がつきます。 -
チームの連携を強化する
抽象的な目標を具体的なタスクに落とし込み、全員が共通のゴールに向かって協力することで、無駄を省き成果を最大化します。 -
応用力を高める
一つの解決策を抽象化して整理することで、類似の課題にも適用可能な汎用的な方法論を構築できます。
スクラム開発においては、「POは抽象を語り、Devは具体を語る」という役割を理解することで、PBIの意図や価値を共有しやすくなり、チーム全体が迷子になることを防ぎます。また、リファインメントやふりかえりで具体と抽象を行き来することで、目先の解決策に留まらず、長期的なチームの成長につながる改善を図れます。
次に取るべき一歩
この具体と抽象の考え方は、一朝一夕で身につくものではありません。日々の業務やチームの会話の中で以下のポイントを意識してみてください：
-
会話の中で「なぜ」「どうやって」を意識する
ゴール（抽象）から行動（具体）を結びつける質問を習慣化します -
課題を振り返る際に一段抽象化して考える
「この課題の背後にある本質は何か？」と問いかけてみましょう -
ふりかえりやイベントの場で役割ごとの視点を確認する
PO、Dev、SMが具体と抽象の両方を意識し、それぞれの役割に応じて適切にバランスを取ることが大切です
この記事が、あなたのチームにとって新たな視点を提供し、具体と抽象を行き来する思考を武器として活用できる一助になれば幸いです。