目次
はじめに：完璧なコード、間違った問題
3年前、ある企業の業務管理システム開発を担当したときのことです。
クライアントからの依頼は明確でした。「営業担当者が日報を簡単に入力できるアプリを作ってほしい」と。要件定義書もきちんと作成され、UIデザインも承認済み。チームは2ヶ月かけて、Flutter製のアプリを完成させました。
技術的には完璧でした。
バリデーションも完備。オフライン対応も実装。UIも直感的。品質管理の観点からも、私は自信を持っていました。
しかし、リリース後、アプリは使われませんでした。
営業担当者たちは、相変わらず紙のメモやExcelを使っていたのです。なぜでしょうか？
答えは、私たちが最初から間違った問題を解いていたからです。
実際の課題は「日報入力が面倒」ではなく、「入力した日報が上司の意思決定に全く活用されていない」ことでした。営業担当者たちは、「どうせ読まれないのに、なぜ丁寧に入力する必要があるのか」と感じていたのです。
この失敗から、私は大切なことを学びました。
AIがどんなに優れたコードを書いても、「何を解くべきか」が間違っていたら、すべてが無駄になるということを。
AIは解くが、「何を解くか」は人間が決める
問題解決の本質
ChatGPTに「ソート アルゴリズムを実装して」と頼めば、瞬時に完璧なコードが返ってきます。でも、「そもそもソートが必要なのか？」はAIに聞いても答えてくれません。
これがAI時代におけるシステムエンジニアの最大の価値です。
「What（何を作るか）」を定義する力
プログラミング言語やフレームワークの知識は、AIでカバーできる時代になりました。しかし、以下の問いには、人間の洞察力が不可欠です。
- クライアントの本当の困りごとは何か？
- ユーザーが本当に求めているものは何か？
- この機能は、本当に問題を解決するのか？
- 優先順位をどう決めるべきか？
私が品質管理で重視していること
システム開発全体の品質管理を担当していると、こんな場面によく遭遇します。
- テストは全てパスしているのに、ユーザーからクレームが来る
- 仕様書通りに作ったのに、「こんなはずじゃなかった」と言われる
- 高機能なシステムなのに、誰も使わない
これらはすべて、課題定義の段階で失敗している証拠です。
技術的な品質（バグがない、パフォーマンスが良い）だけでなく、「正しい問題を解いているか」という品質を担保することが、これからのSEには求められています。
ユーザーの課題を構造的に捉える方法
ステップ1：表面的な要望を疑う
クライアントやユーザーが最初に言う要望は、多くの場合「解決策」です。
要望例：
- 「検索機能がほしい」
- 「もっと速くしてほしい」
- 「デザインをかっこよくしてほしい」
ここで、「わかりました」と即座に受け入れてはいけません。
必ず「Why（なぜ）」を5回繰り返す習慣をつけましょう。
実例：医療クリニックの予約システム
先日、あるクリニックから「予約システムに自動リマインドメール機能を追加してほしい」という依頼がありました。
私は、まず「なぜ」を掘り下げました。
1回目の「なぜ?」 「なぜリマインドメールが必要なのですか？」 →「患者さんの無断キャンセルが多いから」
2回目の「なぜ?」 「なぜ無断キャンセルが多いのですか？」 →「予約したことを忘れる人が多い」
3回目の「なぜ?」 「なぜ忘れてしまうのですか？」 →「予約から診察日まで1ヶ月以上空くことがある」
4回目の「なぜ?」 「なぜそんなに先の予約になるのですか？」 →「人気の医師の枠がすぐ埋まってしまう」
5回目の「なぜ?」 「なぜ特定の医師に集中するのですか？」 →「どの医師が専門か、患者さんにはわかりづらい」
この時点で、本当の課題が見えてきました。
リマインドメールではなく、以下の解決策が適切だったのです。
- 医師の専門分野を予約画面でわかりやすく表示
- 「この症状ならこの医師」というレコメンド機能
- キャンセル待ち機能の実装
- リマインド機能は補助的に追加
もし最初の要望をそのまま受け入れていたら、根本的な問題は解決されなかったでしょう。
プロジェクトでよくある「ズレた課題設定」事例
実際の開発現場で遭遇する、典型的な課題設定のミスをご紹介します。
ケース1：「手段」と「目的」の混同
間違った課題設定： 「Swift製のiOSアプリを作りたい」
正しい課題設定： 「既存のWebサービスを、外出先でも使いやすくしたい」
このケースでは、PWA（Progressive Web App）やFlutterでのクロスプラットフォーム開発の方が、コストとメンテナンス性の面で優れている可能性があります。
クライアントが「Swift」を指定するのは、それが解決策として思いついただけかもしれません。本当の目的を明確にすることが重要です。
ケース2：「症状」を「原因」と勘違いする
間違った課題設定： 「データベースのレスポンスが遅いから、サーバーを増強したい」
正しい課題設定： 「ユーザーが多い時間帯に、画面表示が遅くなってしまう」
この場合、問題の原因は以下の可能性もあります。
- N+1問題が発生している（SQLクエリの最適化で解決）
- 不要なデータまで取得している（SELECT句の見直しで解決）
- キャッシュが効いていない（Redis導入で解決）
サーバー増強は、コストが高く、根本解決にならない可能性があります。
ケース3：「誰の」課題かが曖昧
間違った課題設定： 「管理画面を使いやすくしたい」
正しい課題設定： 「月1回しか使わない店舗オーナーが、直感的に操作できる管理画面にしたい」 vs 「毎日何十回も使う運営スタッフが、効率的に作業できる管理画面にしたい」
ユーザーの特性によって、最適な設計は全く異なります。
思考整理ツール：ロジックツリー活用法
課題を構造的に捉えるために、私が日常的に使っているのがロジックツリーです。
ロジックツリーとは？
問題や課題を、樹形図のように階層的に分解する思考ツールです。
【例：ECサイトの売上が低い】
売上が低い
|
+---------------+---------------+
| | |
訪問者数が少ない 購入率が低い 客単価が低い
| | |
+---+---+ +---+---+ +---+---+
| | | | | |
SEO 広告 UI/UX 決済 商品 送料
不足 不足 悪い 複雑 少ない 高い実践例：Flutterアプリの離脱率が高い問題
あるFlutter製のショッピングアプリで、「ユーザーの離脱率が高い」という課題がありました。
私はロジックツリーで分解してみました。
離脱率が高い
├─ 初回起動時に離脱
│ ├─ 起動が遅い（スプラッシュ画面が長い）
│ ├─ 会員登録が面倒
│ └─ チュートリアルが長すぎる
├─ 商品閲覧中に離脱
│ ├─ 画像の読み込みが遅い
│ ├─ 検索結果が不適切
│ └─ 商品詳細情報が不足
└─ カート途中で離脱
├─ 決済方法が少ない
├─ 送料が想定より高い
└─ 入力項目が多すぎるこのように分解すると、どこを優先的に改善すべきかが明確になります。
アナリティクスデータを確認した結果、「カート途中での離脱」が最も多いことが判明。さらに詳しく調べると、「クレジットカード情報の入力が面倒」という声が多かったため、ApplePayとGooglePayを実装しました。
結果、離脱率は35%改善しました。
ロジックツリー作成の3つのコツ
1. MECE（漏れなく、ダブりなく）を意識する
各階層で、すべての可能性を網羅しつつ、重複しないように分解します。
2. 「Why（なぜ）」と「How（どうやって）」を使い分ける
- 原因分析 → 「なぜ？」で深掘り
- 解決策立案 → 「どうやって？」で広げる
3. データで検証する
仮説を立てたら、必ずアナリティクスやユーザーインタビューで裏付けを取ります。
論理的思考を鍛える3つの習慣
習慣1：「要するに」と「たとえば」を口癖にする
「要するに」 → 情報を抽象化する訓練 「たとえば」 → 抽象概念を具体化する訓練
この往復運動が、論理的思考力を鍛えます。
例：
- クライアントの説明が長くなったら → 「要するに、〇〇ということですね？」
- 仕様が抽象的すぎるとき → 「たとえば、どんな操作になりますか？」
習慣2：仕様書を書く前に「箇条書きメモ」を作る
いきなり仕様書を書くのではなく、まず思考を整理します。
私のテンプレート：
【課題】
- 本質的な問題は何か？
【制約条件】
- 予算、期間、技術的制約は？
【ゴール】
- 何を達成すれば成功なのか？（定量的に）
【解決策の候補】
1. 案A：〇〇（メリット/デメリット）
2. 案B：〇〇（メリット/デメリット）
【推奨案と理由】
- なぜその案が最適なのか？このメモをチームで共有すると、早い段階で認識のズレを防げます。
習慣3：AIに質問する前に、自分で10分考える
GitHub CopilotやChatGPTにすぐ頼るのではなく、まず自分で考える時間を確保しましょう。
思考プロセス：
- 何が問題なのか？（課題の特定）
- なぜそうなっているのか？（原因の推測）
- どうすれば解決できるか？（解決策の立案）
- 最適な方法は何か？（選択肢の評価）
この思考プロセスを経てからAIに相談すると、より的確な質問ができるようになります。
悪い質問例： 「このコードがエラーになります。直してください。」
良い質問例： 「このコードで〇〇を実現しようとしています。〇〇の部分でNullPointerExceptionが発生しており、原因は〇〇だと推測しています。〇〇と〇〇の2つの解決策を考えましたが、それぞれのメリット・デメリットを教えてください。」
課題定義力を高める「現場での実践法」
実践法1：ユーザーインタビューに参加する
コードを書くだけでなく、実際にユーザーと話す機会を作りましょう。
質問例：
- 「今、どんな方法で〇〇していますか？」
- 「その方法で、困っていることはありますか？」
- 「理想的には、どうなっていてほしいですか？」
- 「それが実現したら、あなたの1日はどう変わりますか?」
最後の質問が特に重要です。システムが与える価値を具体的にイメージできるからです。
実践法2：「Why」を聞く勇気を持つ
クライアントが「この機能をつけてほしい」と言ったとき、「わかりました」とすぐ受け入れず、「なぜそれが必要なのですか？」と聞く勇気を持ちましょう。
これは失礼な質問ではありません。むしろ、プロとして責任を果たすための質問です。
実践法3：レビュー会で「そもそも」を問い直す
チーム内のレビューで、こんな質問を投げかけてみましょう。
- 「そもそも、この機能は本当に必要？」
- 「この実装で、ユーザーの課題は解決される？」
- 「他にもっとシンプルな方法はない？」
これらの質問が、チーム全体の課題定義力を高めます。
まとめ：技術の前に、思考がある
AI時代になっても、いえ、AI時代だからこそ、課題定義力と論理的思考が重要になります。
なぜなら、AIは「How（どうやって）」には強いですが、「What（何を）」と「Why（なぜ）」には人間の洞察が必要だからです。
システムエンジニアの価値は、もはやコードを書く速さではありません。
「正しい問題を見つけ、適切な解決策を設計する力」こそが、私たちの真の価値なのです。
Flutter、Swift、PHPを使いこなせることは素晴らしいスキルです。でもそれ以上に、「何を作るべきか」を見極める力を磨き続けましょう。
次回予告
第3回では、「変わる技術トレンド、変わらない『設計思考』」をテーマにお届けします。
ChatGPTがコードを書いてくれても、システムの設計は人間の仕事。 「設計」と「コーディング」の違いとは何か？ 設計力を鍛える3つの習慣とは？
AI時代の「アーキテクト」としての思考法を、具体例を交えて解説します。
【AI時代を生き抜くシステムエンジニア論 - 連載目次】
- AI時代の到来と、SEの役割の変化
- AIに代替されないSEの基本「課題定義力」と「論理的思考」（今回）
- 変わる技術トレンド、変わらない「設計思考」
- AIと共存する時代の"チーム開発力"
- AIを味方につけるためのスキルマップ
- これからも変わらない"システムエンジニアの本質"
