開発テーマの決め方〜情報処理をともなうシステムとは

• 日程: Day 2 / セッション 3
• 時間: [11:10-11:35]
• 形式: 座学
• ゴール: 「情報処理をともなうシステム」に該当する例と該当しない例をそれぞれ2つ以上挙げ、課題候補を絞り込む評価軸を説明できる
• 学習形式: 対話型解説、ケーススタディ

前のセッションで、課題候補が20個以上集まりましたね。お疲れさまでした。

でも、22日間で取り組めるのは1つだけです。どうやって選べばいいのでしょうか？

ここで思い出してください。セッション1で学んだ開発テーマの前提条件です。

情報処理をともなうシステムの開発であること。

これは服選びに例えると「サイズが合っていること」のような、絶対条件です。どんなに素敵なデザインの服でも、サイズが合わなければ買えません。同じように、どんなに良い課題でも、その解決策が「情報処理をともなうシステム」にならないなら、このPBLのテーマには選べません。

このセッションでは、(1) 「情報処理をともなう」とは何か、(2) 候補を絞り込む評価軸、の2つを学びます。

「情報処理」とは、情報を入力し、加工・蓄積し、出力することです。

つまり「情報処理をともなうシステム」とは、データを受け取り、ためて、加工して、誰かの役に立つ形で返す仕組みのことです。

具体例と非具体例を対比してみましょう。

該当する例（その1）: 飲食店の順番待ち管理システム
来店客の受付情報を入力し、待ち行列として蓄積し、待ち組数や予想時間を計算して出力します。入力→処理→出力が揃っています。

該当する例（その2）: サークルの備品貸出管理システム
「誰が・何を・いつ借りたか」を記録し、貸出中か返却済みかを管理し、未返却の一覧を表示します。情報の蓄積と検索が中心にあります。

では、該当しない例はどうでしょうか。

該当しない例（その1）: 「ゴミ拾いボランティアを月1回開催する」
これは素晴らしい活動ですが、活動そのものは情報処理ではありません。人が集まって掃除をするだけなら、システムの出る幕がないのです。ただし注目してください。「参加者の募集・出欠管理・活動記録の共有」という形に捉え直せば、情報処理をともなうシステムに変換できます。

該当しない例（その2）: 「おしゃれなデザインのエコバッグを作る」
モノづくり（プロダクトデザイン）であり、情報の入力・蓄積・出力がどこにもありません。「啓発ポスターを作る」「マスコットキャラを作る」も同じ仲間です。

該当しない例（その3）: 「電卓で1回計算するだけのページ」
意外に思うかもしれませんが、これは境界例です。計算（処理）はありますが、情報を蓄積せず、ユーザーごとの状態も持ちません。このPBLではDay 4以降に情報モデルを定義し、Day 7でデータベースを設計します。ためる情報がないテーマは、後の工程で空っぽになってしまうのです。

見分けるための簡単な問いはこれです。

• 「このシステムは、何の情報を、ためて、どう加工して、誰に返すのか？」

この問いに具体的に答えられれば該当、答えに詰まれば非該当のサインです。

• 情報処理 = 入力→加工・蓄積→出力。3つが揃っているかを確認する
• 「活動・モノづくり」そのものは非該当。ただし「その活動を支える情報管理」に捉え直せば該当になることが多い
• ためる情報（蓄積）がないテーマは、Day 4以降の情報定義・DB設計で行き詰まる
• よくある間違い: 「アプリっぽいから大丈夫」と思い込むこと。見た目がアプリでも、情報をためないなら情報処理が薄い

「情報処理」という言葉が日本で公式デビューしたのは意外と古く、1960年に「情報処理学会」が設立され、1970年には「情報処理振興事業協会（IPAの前身）」が生まれました。当時のコンピュータの主な仕事は給与計算や銀行の勘定処理。つまり「大量の情報をためて、計算して、帳票で出す」ことでした。半世紀以上たった今、スマホアプリもSNSもAIも、突き詰めれば「入力→処理→出力」の3点セットは変わっていません。技術は変わっても原理は変わらない。だからこの3点セットで見分ける方法は、流行に左右されない一生モノの物差しなのです。

前提条件（情報処理をともなう）をクリアした候補が複数残ったら、次は2つの軸で評価します。

• 価値: 解決されたら、どれくらい嬉しい人がいるか。困りごとの深さ×人数
• 実現可能性: 自分たちのチームが、残り期間（実装は実働約8日）で形にできるか

この2軸でマトリクスを作ると、候補の位置づけが見えます。

狙うべきは右上の「本命ゾーン」、価値が高く実現可能性も高い課題です。

ここで少し考えてみてください。「価値は最高だが実現可能性が低い課題」（左上）は、捨てるしかないのでしょうか？

実は、課題の範囲を縮小するという手があります。たとえば「全国の災害時の安否確認を変える」は8日では無理でも、「自分の研修クラス40人の安否確認連絡網」なら作れるかもしれません。価値の核を残したまま、対象を絞るのです。逆に右下の「簡単だけど誰も困っていない課題」は、作っても発表会で「……で、誰が使うの？」と聞かれてしまいます。

実現可能性を見積もるチェック項目:

• 使う技術は前提知識（プログラミング基礎・データベース基礎）の延長で扱えるか
• 必要なデータは自分たちで用意できるか（外部の特殊なデータが必須だと危険）
• 画面数・機能数が多すぎないか（目安: コア機能2〜3個で価値が伝わるか）

価値を見積もるチェック項目:

• 困っている人の顔が具体的に浮かぶか（Day 3のペルソナにつながる）
• 解決前と解決後で、その人の行動がはっきり変わるか（Day 3のCJM As-Is/To-Beにつながる）
• チームのメンバー自身が「使ってみたい」と思えるか

• 絞り込みは「前提条件（情報処理をともなう）→価値×実現可能性」の2段階で行う
• 価値が高く実現困難な課題は、対象範囲を縮小して救えないか考える
• 実現可能性の見積もりには実装期間（実働約8日）を必ず織り込む
• よくある間違い: 「全部入り」の壮大なテーマを選ぶこと。コア機能2〜3個で価値が伝わるサイズが22日間のベストサイズ

「範囲を縮小して成功した」最も有名な例の1つがFacebookです。最初から「全人類をつなぐ」を作ったのではなく、2004年の開始時はハーバード大学の学生だけが使える名簿サービスでした。対象を1つの大学に絞ったからこそ素早く作れて、価値が検証できた。その後、他大学→一般公開と広げていきました。スタートアップの世界にはこんな格言があります。「100人がまあまあ好きなものより、10人が熱烈に愛するものを作れ」。皆さんの22日間も同じです。小さく絞った課題を深く解決するチームのほうが、発表会で強いのです。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「『情報処理をともなうシステム』の該当例と非該当例を、あと5組見せて。境界例も交えて」
• 「『地域の防災活動を活性化したい』という課題を、情報処理をともなうシステムのテーマに変換する案を3つ出して」
• 「実現可能性の見積もりで、新人チームが見落としがちなコストは何？」
• 「価値と実現可能性のほかに、テーマ選定で考慮すべき軸はある？」

今回学んだことを一言でまとめると、**「開発テーマは『入力→蓄積・加工→出力が揃った情報処理をともなうシステム』が前提で、価値と実現可能性の2軸で絞り込む」**ということです。

• 見分けの問い: 「何の情報を、ためて、どう加工して、誰に返すのか？」
• 活動・モノづくり系の課題も「それを支える情報管理」に捉え直せば該当しうる
• 狙いは「価値が高く、実働8日で作れる」本命ゾーン。大きすぎる課題は範囲を縮小する

次のセッションでは、いよいよこの物差しを使って、課題候補リストから「取り組む課題」と「開発テーマ」をチームで決定します。Day 1で決めた合意形成ルールの出番です。

以下の問いに答えられるか確認してみましょう：

• 「情報処理をともなうシステム」に該当する例を2つ、該当しない例を2つ挙げられますか？
• 該当・非該当を見分ける問いは何でしたか？
• 課題候補を絞り込む2つの評価軸は何ですか？
• 「価値は高いが実現可能性が低い課題」への対処法を説明できますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: IPA「共通キャリア・スキルフレームワーク」、情報処理の入門解説（入力・処理・出力モデル）
• 発展課題: 自分の好きなサービスを1つ選び、「入力・蓄積・加工・出力」がそれぞれ何にあたるかを分解してAIに添削してもらいましょう

このセクションは、受講者が理解を深めることをサポートする参考情報です。