강의

멘토링

로드맵

Inflearn brand logo image
Programming

/

etc. (Programming)

問題化:「開発の無駄」を減らす基礎能力

問題化(Problematization)は、問題提起、問題作成などとも翻訳される用語です。そして、問題設定や問題定義とも翻訳され得ます。要請事項や常識のような既知の事実に対し、新しい観点から疑問を呈し、問題を定義し、この問題を解決する方法を組み立てていく過程が含まれている概念です。問題化はあらゆる開発の出発点となるべきですが、未だ開発分野で十分に議論されていないテーマです。プロジェクトを遂行することやプログラムを開発することも、実は問題を解決する計画を立てる作業です。つまり、問題化と関連があるということです。 問題を解決するには、まず問題が明確に定義されている必要があります。しかし、ほとんどの場合、曖昧な要請の形で問題が与えられます。したがって、曖昧な要請を明確な問題に変える力があってこそ、不必要な「開発の無駄」を減らし、協業は円滑になり、ユーザーの真のニーズを正確に把握することができます。この講義は、実践事例とツールを通じて、問題を「構成する思考」を訓練するよう手助けします。

  • arigaram
요구분석
코드리뷰
리팩토링
커뮤니케이션
pm/po
Team Collaboration Tool
soft skills
Business Problem Solving

こんなことが学べます

  • 依頼、要求事項、ユーザーからのフィードバック、コードレビューの中に隠れた本当の問題を見つける方法

  • 実際の問題を問題記述の公式などを用いて構造化された問題として表現する方法

  • 問題の根本原因を探す方法

  • 現象から本質を洞察する '問題化'という哲学的概念

  • '問題化'を遂行するための様々な道具

🎯問題化:「開発の無駄」を減らす基礎能力

新人・ジュニア開発者のための協業、要求分析、コードレビューの出発点!

PM/POの立場から「開発の無駄」を防ぐために全チームメンバーに推奨する基本スキル!

コラボレーションツール、ソフトスキル、問題解決能力などに関連する基礎能力!

人工知能がコードを書く時代でも開発者の仕事を守ることができる能力!

このような悩み、したことはありませんか?

  • 企画書があまりにも曖昧で、何を作ればいいのかわかりません。

  • 「レビューでフィードバックは受けたのですが、正確にどこを直すべきか感覚が掴めません。」

  • 「いざコードを書こうとしたら…私は何を解決しようとしていたんだっけ?」

  • 「質問をしたら『で、何が問題なの?』と逆に聞き返されました。」

この全ての混乱の核心は問題を正確に定義できなかったためです。開発者は絶えず問題に直面します。しかし、その問題を正確に見つめ定義できてこそ正しい解決が始まります。

曖昧な要求仕様:新人開発者はプロジェクトでしばしば不明確な要求仕様を与えられる。例えば「ウィジェットを作ってほしい」といった曖昧な指示を受けると、具体的にどのような機能を実装すべきか混乱してしまう。開発者向けブログによると、新規入社者は「曖昧な指示」(vague instructions)と十分なガイドの不在により混乱を経験する(codeanywhere.com)。

経験不足: 業務経験が少ないため、問題を体系的に分解したり、必要な情報を自ら見つけ出すことが困難である。実際の事例として、ある新人開発者はどの程度自分で解決すべきかを判断することが難しく、過度に長時間解決を試みた後でようやく質問することを学んだ(rachsmith.com)。このような不確実性は不安感(インポスター症候群)につながり、学習と協業を阻害する。

コミュニケーションギャップ:ドメイン知識やビジネス文脈が不足していると、要求事項の核心問題を正確に把握できない。開発コミュニティでもドメイン知識の不足が要求事項の誤解につながるという指摘があり(kedin.com))、これは間違った実装や再作業を生み出すことになる。

📌 この講義で学ぶこと

曖昧な要求を明確に整理し、核心的な問題を設定する実践的思考法

  • 要件から問題を引き出す質問法

  • 「問題」を問題らしくする5つの基準

  • 他のチームメンバーとも共感を形成するコミュニケーション技術

  • 問題を「定義」し「構造化」する図式化方法

  • コードレビュー、企画会議、業務伝達時に正確に聞き返すテクニック

  • 15の主要パターン

🎓 この講義は誰のためのものでしょうか?

1. 曖昧な要件の前で途方に暮れる開発者

  • クライアントや企画者が投げかけた言葉が曖昧すぎて、何を作ればいいのかわからない場合

  • 例:「UXがちょっとイマイチです」、「遅いです」、「もう少し直感的にしてください」

  • → リクエストを問題に変換する力が不足している状態

リクエスト: "UXをもっと良くしてください"
反応: "ただUXを良くしてほしいと言われても.....どういう意味だろう?"

"'もっと直感的にしてください'という言葉に戸惑ったことはありませんか?曖昧なリクエストを明確な問題に変える技術、今から始めましょう。"

2. 要求分析や設計段階に自信がない新人・ジュニア

  • 問題を分析し構造化する能力がまだ慣れていない

  • 企画者の話を書き取る程度にとどまる場合

  • → 自ら問題を定義できる技術が必要

要求: 'OO' 機能 - 未定状態。間もなく決定される予定。
反応: 「いくつかの機能が決定されていない現在の状態のまま開発を進めても大丈夫なのだろうか?」


「言われた通りに作るだけになっていませんか?企画を解釈し、問題を自ら定義できる開発者として成長しましょう。」

3. 「なぜこれを開発するのか」を説明するのに苦労している開発者

  • 機能実装は上手だが、その機能がなぜ必要なのか説明できない

  • 開発の目的と問題の文脈を設計することに困難がある

  • → 開発者 → 問題解決者 → 問題設定者として成長しようとする人

リクエスト:ボタンサイズ + 10ピクセル
反応:「それが...そんな風に作ったらいいような気がして...」


「機能を実装することはできるが、その理由を説明できないとしたら?問題の本質を見抜く思考が今必要な時点です。」

4. 企画者やデザイナーとの協業に困難を感じている開発者

  • 多くの議論が交わされているが、「何が問題なのか」についての共感が形成されていない

  • フィードバックが繰り返されたり、コミュニケーションの衝突が頻繁に起こる

  • → 異なる言語を構造化して協業の中心を築きたい人

リクエスト:「もっと直感的な感じにしてください」
反応:「デザイナーはなぜいつも『感じ』みたいな曖昧なことばかり言うんだろう...?」


「企画者と話が通じないと感じていませんか?お互いの言語を『課題』として整理すれば、協業が変わります。」

5. 企画、PM、指揮業務を準備するジュニア以上

  • 問題を定義し方向性を提示する役割へと成長中の開発者

  • 曖昧な要求をチームのタスクに構造化する能力が必要

  • 問題設定こそがリーダーシップの始まり

リクエスト:[情報要請(Request) > 原因(Cause) > ユーザー状況(User Situation)] 構造に合わせて...
反応:「これをチーム課題にするにはどう定義すべきだろう?」


「漠然とした要求を実行可能なタスクに構造化する能力、それが今あなたがチームを率いる開発者になるための第一歩です。」

6. まとめ

  • この講義は「コードは書けるけど、何を作ればいいのかわからない」という悩みを抱えるすべての開発者に必ず必要な講義です。

  • 特に新人〜3年目のジュニア開発者にとっては必須スキルと言えるでしょう。

要件収集に関する質問: 開発者掲示板やRedditで新人・準備生が「要件をどのように収集・分析するのですか?」と尋ねる投稿がよく見られる。例えば、あるコンピュータ工学科の学生は「実務でステークホルダーの要件をどのように集めるのですか?」と先輩開発者にアドバイスを求めた(reddit.com)。これは実際のプロジェクトで明確な要件を得る方法に対する需要を示している。

役割の強調: 中堅開発者のアドバイスによると、ソフトウェア開発の核心は「問題定義(Problem definition)」であり、真の専門家には要求事項を正確に定義する能力が必要だと言及されている(medium.com)。開発者コミュニティでも、このように問題定義の重要性を強調する意見がよく見られる。

教育の必要性:韓国の開発者ブログでは「基本スキル」として問題定義能力を挙げており(medium.com)、データを分析したりシステムを設計したりする際に、ツールよりもまず解決すべき問題を定義することが必須であることを指摘している(inflearn.comvelog.io。このような記事は学習者に問題定義スキルの必要性を浮き彫りにしている。

💡 講義の特徴

  • 実務ベースの思考法:

    実際のコラボレーションで経験する問題事例を中心に構成

  • 短くて明確な講義:

    各授業は一般的に10分以内で構成(例外もあり)されており、集中力の高い学習が可能

  • 思考構造化トレーニング:

    問題を定義する「思考の流れ」を視覚的に整理するスライド中心の講義

  • 実戦例:

    曖昧なフィードバック、抽象的な企画を明確な問題に変える対話方式を収録

📂 カリキュラムプレビュー(一部)

  1. 問題設定とは何か – 問題解決の出発点

  2. 曖昧な要求、どこから間違ったのか

  3. 問題を問題らしくする5つの基準

  4. 「だから何が問題なの?」を違った方法で尋ねる技術

  5. コードレビュー、企画、スケジュール調整…問題設定が使われるすべての瞬間

💬 受講後の期待効果

  • 混乱した要求も自ら構造化して整理することができます

  • 一つの質問で核心を突く開発者になることができます

  • 業務協業時に不要な誤解を減らし、正確な対話を主導することができます

  • レビューフィードバックも単純な指摘ではなく解決可能な問題に変換することができます

💬 開発者にとってこの講義が実質的に有益な理由


1. 実務で最もよく直面する問題を扱う

開発者の仕事の始まりは、いつも「要求」を受けることから出発します。しかし、要求は大抵曖昧で不明確です。これを正確な問題に変えることができなければ、企画がずれて、開発は空回りし、スケジュールは遅れます。

例:「ボタンをもう少し大きくしてください」→→ なぜ?誰に?何が問題なの?


2. 新人とジュニアが最も不足している能力である

新人開発者やジュニアにとって最も難しい部分は、単純な実装ではなく「何を実装すべきか」を判断する能力です。この講義はまさにその点を指摘してくれます。


3. コラボレーション能力の向上に直結する

要求分析、コードレビュー、コミュニケーション、PMとの協議…すべて問題定義をうまくやってこそ流れがスムーズになります。この講義は話を聞いて本質を引き出す思考法を訓練してくれます。


4. 現実的な実戦フレームとツールを提供する

理論だけでなく、すぐに実務で活用できる問題提起の公式、フィードバック基準、質問技法などを提供します。


要約すると、この講義は「なぜこれを開発する必要があるのですか?」「これは本当に問題なのですか?」という質問の前で立ち止まることなく
明確な判断と発言ができる開発者になれるよう支援します。

🎯 現在の開発者市場では、このように「考えることができる開発者」が最も速く成長します。

今度は、問題解決ではなく問題設定からうまくできる開発者になってみましょう。

問題を正確に見ることができてこそ、解決も成長も始まります。

こんな方に
おすすめです

学習対象は
誰でしょう?

  • 与えられた要求をただ実装するよりも、真の問題が何か自ら考え判断する能力を養いたい開発者

  • 曖昧な要求と意見の中でチームの方向性を定め、開発者とスムーズに意思疎通したい企画者、デザイナー、PM/PO

こんにちは
です。

366

受講生

17

受講レビュー

1

回答

4.6

講座評価

17

講座

IT가 취미이자 직업인 사람입니다.

다양한 저술, 번역, 자문, 개발, 강의 경력이 있습니다.

カリキュラム

全体

72件 ∙ (17時間 16分)

講座資料(こうぎしりょう):

授業資料
講座掲載日: 
最終更新日: 

受講レビュー

全体

1件

5.0

1件の受講レビュー

  • HelloWorld님의 프로필 이미지
    HelloWorld

    受講レビュー 2

    平均評価 4.5

    5

    31% 受講後に作成

    • 아리가람
      知識共有者

      감사합니다.

¥6,526

arigaramの他の講座

知識共有者の他の講座を見てみましょう!

似ている講座

同じ分野の他の講座を見てみましょう!