개발자를 위한 (바이브 코딩) 프롬프트 패턴
아리가람
이제는 인공지능을 활용해서 개발하는 시대. 인공지능을 더 잘 활용해 더 좋고, 더 정확한 코드와 문서를 만드는 방법이 필요하므로 이에 알맞은 방법을 제시합니다.
초급
프롬프트엔지니어링
問題化(Problematization)は、問題提起、問題作成などとも翻訳される用語です。そして、問題設定や問題定義とも翻訳され得ます。要請事項や常識のような既知の事実に対し、新しい観点から疑問を呈し、問題を定義し、この問題を解決する方法を組み立てていく過程が含まれている概念です。問題化はあらゆる開発の出発点となるべきですが、未だ開発分野で十分に議論されていないテーマです。プロジェクトを遂行することやプログラムを開発することも、実は問題を解決する計画を立てる作業です。つまり、問題化と関連があるということです。 問題を解決するには、まず問題が明確に定義されている必要があります。しかし、ほとんどの場合、曖昧な要請の形で問題が与えられます。したがって、曖昧な要請を明確な問題に変える力があってこそ、不必要な「開発の無駄」を減らし、協業は円滑になり、ユーザーの真のニーズを正確に把握することができます。この講義は、実践事例とツールを通じて、問題を「構成する思考」を訓練するよう手助けします。
受講生 28名
依頼、要求事項、ユーザーからのフィードバック、コードレビューの中に隠れた本当の問題を見つける方法
実際の問題を問題記述の公式などを用いて構造化された問題として表現する方法
問題の根本原因を探す方法
現象から本質を洞察する '問題化'という哲学的概念
'問題化'を遂行するための様々な道具
新人・ジュニア開発者のための協業、要求分析、コードレビューの出発点!
PM/POの立場から「開発の無駄」を防ぐために全チームメンバーに推奨する基本スキル!
コラボレーションツール、ソフトスキル、問題解決能力などに関連する基礎能力!
企画書があまりにも曖昧で、何を作ればいいのかわかりません。
「レビューでフィードバックは受けたのですが、正確にどこを直すべきか感覚が掴めません。」
「いざコードを書こうとしたら…私は何を解決しようとしていたんだっけ?」
「質問をしたら『で、何が問題なの?』と逆に聞き返されました。」
この全ての混乱の核心は問題を正確に定義できなかったためです。開発者は絶えず問題に直面します。しかし、その問題を正確に見つめ定義できてこそ正しい解決が始まります。
曖昧な要求仕様:新人開発者はプロジェクトでしばしば不明確な要求仕様を与えられる。例えば「ウィジェットを作ってほしい」といった曖昧な指示を受けると、具体的にどのような機能を実装すべきか混乱してしまう。開発者向けブログによると、新規入社者は「曖昧な指示」(vague instructions)と十分なガイドの不在により混乱を経験する(codeanywhere.com)。
経験不足: 業務経験が少ないため、問題を体系的に分解したり、必要な情報を自ら見つけ出すことが困難である。実際の事例として、ある新人開発者はどの程度自分で解決すべきかを判断することが難しく、過度に長時間解決を試みた後でようやく質問することを学んだ(rachsmith.com)。このような不確実性は不安感(インポスター症候群)につながり、学習と協業を阻害する。
コミュニケーションギャップ:ドメイン知識やビジネス文脈が不足していると、要求事項の核心問題を正確に把握できない。開発コミュニティでもドメイン知識の不足が要求事項の誤解につながるという指摘があり(kedin.com))、これは間違った実装や再作業を生み出すことになる。
曖昧な要求を明確に整理し、核心的な問題を設定する実践的思考法
要件から問題を引き出す質問法
「問題」を問題らしくする5つの基準
他のチームメンバーとも共感を形成するコミュニケーション技術
問題を「定義」し「構造化」する図式化方法
コードレビュー、企画会議、業務伝達時に正確に聞き返すテクニック
15の主要パターン
クライアントや企画者が投げかけた言葉が曖昧すぎて、何を作ればいいのかわからない場合
例:「UXがちょっとイマイチです」、「遅いです」、「もう少し直感的にしてください」
→ リクエストを問題に変換する力が不足している状態
リクエスト: "UXをもっと良くしてください"
反応: "ただUXを良くしてほしいと言われても.....どういう意味だろう?"
"'もっと直感的にしてください'という言葉に戸惑ったことはありませんか?曖昧なリクエストを明確な問題に変える技術、今から始めましょう。"
問題を分析し構造化する能力がまだ慣れていない
企画者の話を書き取る程度にとどまる場合
→ 自ら問題を定義できる技術が必要
要求: 'OO' 機能 - 未定状態。間もなく決定される予定。
反応: 「いくつかの機能が決定されていない現在の状態のまま開発を進めても大丈夫なのだろうか?」
「言われた通りに作るだけになっていませんか?企画を解釈し、問題を自ら定義できる開発者として成長しましょう。」
機能実装は上手だが、その機能がなぜ必要なのか説明できない
開発の目的と問題の文脈を設計することに困難がある
→ 開発者 → 問題解決者 → 問題設定者として成長しようとする人
リクエスト:ボタンサイズ + 10ピクセル
反応:「それが...そんな風に作ったらいいような気がして...」
「機能を実装することはできるが、その理由を説明できないとしたら?問題の本質を見抜く思考が今必要な時点です。」
多くの議論が交わされているが、「何が問題なのか」についての共感が形成されていない
フィードバックが繰り返されたり、コミュニケーションの衝突が頻繁に起こる
→ 異なる言語を構造化して協業の中心を築きたい人
リクエスト:「もっと直感的な感じにしてください」
反応:「デザイナーはなぜいつも『感じ』みたいな曖昧なことばかり言うんだろう...?」
「企画者と話が通じないと感じていませんか?お互いの言語を『課題』として整理すれば、協業が変わります。」
問題を定義し方向性を提示する役割へと成長中の開発者
曖昧な要求をチームのタスクに構造化する能力が必要
→ 問題設定こそがリーダーシップの始まり
リクエスト:[情報要請(Request) > 原因(Cause) > ユーザー状況(User Situation)] 構造に合わせて...
反応:「これをチーム課題にするにはどう定義すべきだろう?」
「漠然とした要求を実行可能なタスクに構造化する能力、それが今あなたがチームを率いる開発者になるための第一歩です。」
この講義は「コードは書けるけど、何を作ればいいのかわからない」という悩みを抱えるすべての開発者に必ず必要な講義です。
特に新人〜3年目のジュニア開発者にとっては必須スキルと言えるでしょう。
要件収集に関する質問: 開発者掲示板やRedditで新人・準備生が「要件をどのように収集・分析するのですか?」と尋ねる投稿がよく見られる。例えば、あるコンピュータ工学科の学生は「実務でステークホルダーの要件をどのように集めるのですか?」と先輩開発者にアドバイスを求めた(reddit.com)。これは実際のプロジェクトで明確な要件を得る方法に対する需要を示している。
役割の強調: 中堅開発者のアドバイスによると、ソフトウェア開発の核心は「問題定義(Problem definition)」であり、真の専門家には要求事項を正確に定義する能力が必要だと言及されている(medium.com)。開発者コミュニティでも、このように問題定義の重要性を強調する意見がよく見られる。
教育の必要性:韓国の開発者ブログでは「基本スキル」として問題定義能力を挙げており(medium.com)、データを分析したりシステムを設計したりする際に、ツールよりもまず解決すべき問題を定義することが必須であることを指摘している(inflearn.com、velog.io)。このような記事は学習者に問題定義スキルの必要性を浮き彫りにしている。
実務ベースの思考法:
実際のコラボレーションで経験する問題事例を中心に構成
短くて明確な講義:
各授業は一般的に10分以内で構成(例外もあり)されており、集中力の高い学習が可能
思考構造化トレーニング:
問題を定義する「思考の流れ」を視覚的に整理するスライド中心の講義
実戦例:
曖昧なフィードバック、抽象的な企画を明確な問題に変える対話方式を収録
問題設定とは何か – 問題解決の出発点
曖昧な要求、どこから間違ったのか
問題を問題らしくする5つの基準
「だから何が問題なの?」を違った方法で尋ねる技術
コードレビュー、企画、スケジュール調整…問題設定が使われるすべての瞬間
混乱した要求も自ら構造化して整理することができます
一つの質問で核心を突く開発者になることができます
業務協業時に不要な誤解を減らし、正確な対話を主導することができます
レビューフィードバックも単純な指摘ではなく解決可能な問題に変換することができます
開発者の仕事の始まりは、いつも「要求」を受けることから出発します。しかし、要求は大抵曖昧で不明確です。これを正確な問題に変えることができなければ、企画がずれて、開発は空回りし、スケジュールは遅れます。
例:「ボタンをもう少し大きくしてください」→→ なぜ?誰に?何が問題なの?
新人開発者やジュニアにとって最も難しい部分は、単純な実装ではなく「何を実装すべきか」を判断する能力です。この講義はまさにその点を指摘してくれます。
要求分析、コードレビュー、コミュニケーション、PMとの協議…すべて問題定義をうまくやってこそ流れがスムーズになります。この講義は話を聞いて本質を引き出す思考法を訓練してくれます。
理論だけでなく、すぐに実務で活用できる問題提起の公式、フィードバック基準、質問技法などを提供します。
要約すると、この講義は「なぜこれを開発する必要があるのですか?」「これは本当に問題なのですか?」という質問の前で立ち止まることなく
明確な判断と発言ができる開発者になれるよう支援します。
🎯 現在の開発者市場では、このように「考えることができる開発者」が最も速く成長します。
今度は、問題解決ではなく問題設定からうまくできる開発者になってみましょう。
問題を正確に見ることができてこそ、解決も成長も始まります。
学習対象は
誰でしょう?
与えられた要求をただ実装するよりも、真の問題が何か自ら考え判断する能力を養いたい開発者
曖昧な要求と意見の中でチームの方向性を定め、開発者とスムーズに意思疎通したい企画者、デザイナー、PM/PO
全体
72件 ∙ (17時間 16分)
講座資料(こうぎしりょう):
23. 授業5-1. 問題定義書式の使用
21:01
25. 授業5-3. 悪い問題記述の特徴
08:42
26. 授業5-4. 実務適用事例比較
19:17
27. 授業5-5. 実習:要求を問題記述に変える
01:02:29
38. 授業 8.2 構造再解釈パターン
10:05
39. 授業8.3 目標–障害パターン
13:04
全体
1件
¥6,526
知識共有者の他の講座を見てみましょう!
同じ分野の他の講座を見てみましょう!