具体と抽象を往復するエンジニアリング 具体 ➡ 抽象 ➡ 具体
お前、誰よ?
給料を上げなければ殺すロボ def who_are_you(): self_introduction = { 'name' : 'ミソノ(miso_taku)', 'twitter' : '@miso_taku0221', 'Qiita' : '@miso_taku', 'job' : 'ブラック企業に務めるSE(便利屋orなんでも屋)', 'skill' : ['組み込み', 'データベース', 'ネットワーク'], 'hobby' : ['呑み歩き', 'ライブ参戦', '本屋巡り'], 'interest' : ['アジャイル開発', 'Python', '機械学習'] } return self_introduction
作れるようになった、その先にある課題解決 ソフトが作れること AIによって作るハードルは下がった。 アイデアをすぐ形にできる。 ≠ 課題が解決されること その人が何に困っていて、何が変われば その困りごとがなくなるのか 課題を解決するには、人と現場の理解が必要。
AI時代に注目されるFDE FDE Forward Deployed Engineer (現場駆動型エンジニア) 顧客と現場で直接関わって課題を理解し、その課題を解くための仕 組みを設計・実装・検証するエンジニア STEP 1 課題を理解する 顧客の話を聞き、データを調べる STEP 2 仕組みを作る 設計、実装し、関係者と調整する STEP 3 役に立つか確認する 実際に使われ、成果に繋がったか 単に現場に近いエンジニアではなく、プロダクト開発と顧客価値創出の間にあった境界を取り 払ってその両方を同時に担う存在。AIによって技術が進化するほど「何をつくるべきか」を正し く定義することが重要になる。
FDEへ繋がる2つの出発点 ビジネス側から 強み 業務理解、顧客との対話 何に価値があるのかの判断 広げていくポイント 技術でどう実現するか 品質や運用をどう成立させるか 開発側から 強み 設計や実装の理解 技術的な制約の理解 広げていくポイント 誰が何に困っているか 何が変われば成果が生まれるか FDEが目指すのは、現場の困りごとと動く仕組みをつなぐこと
ケーススタディ「チャットボットを作って」 顧客 問い合わせが多いので、チャットボットを作ってほしい チャットボットは手段、問い合わせが多いという困りごとについて深掘り をする。困りごとの解決つまり目的を固定し手段には余白を持つ。 問い合わせの記録を見たり、利用者や対応担当者に話を聞いたりすると… 1. FAQに答えがあるのに、そのページを見つけられない。 2. 説明を読んでも、専門用語が難しくて理解できない。 3. FAQには上位プランで使えると書かれているが、自分の契約がどのプランかわからない。 同じ問い合わせでも、困っている理由が違う。
AIとの壁打ちで課題の構造の仮説を得る AI 以下の問い合わせ事例から、共通する目的や、利用者の 行動を妨げている構造を整理してください。 事実と推測を分け、複数の捉え方を提示してください。 各捉え方の根拠と、現場で追加確認すべきことも挙げて ください。 ... (省略) 利用者の行動を妨げている構造 1. UI/UXおよびナビゲーションの不備 2. コンテンツ(言葉選び・説明文)のミスマッチ 3. ユーザーの心理的・認知的プロセスの分断 ワイ ※スライドでは1ターンのやり取りになっていますが、回答内容次第で話を広げたり深掘り したり納得できる回答が得られるまで徹底的に話し合います。
AIとの壁打ちで解決策の仮説を得る AI この障害を取り除くために必要な変化を整理し、それを 実現する解決策を複数提案してください。 各案について、仮説に効く理由、成立する前提、解決で きないこと、小さく検証する方法を示してください。未 確認の情報は推測として扱ってください。 .... (省略) 障害を解決する具体案 1. マイページ内の「ファーストビュー統合」と「常設 ヘッダー」の設置 2. 専門用語の日常語への書き換えと注釈の追加 3. コンテキストに応じたアクションボタンの追加 ワイ ※この例では1ターンの…(以下、省略)
この流れを「具体と抽象」で考える 具体 個別の出来事 誰が何をしようとして、 どこでつまずいたか ・ FAQを見つけられな い ・ 専門用語がわからな い ・ 自分の契約プランが わからない 抽象 構造を取り出す 何が行動を妨げている か ・ UI/UXおよび導線の 不備 ・ コンテンツのミス マッチ ・ 心理的・認知的プロ セスの分断 具体 解決策の候補 チャットボット以外に も選択肢が見えてくる ・ 情報の視認性とアク セス経路の最適化 ・ 専門用語の日常語へ の言い換えと注釈 ・ 文脈に応じたコンテ ンツの表示 現場の具体を基に問題の構造を抽象化し、そこから解決策を具体化する。 具体だけならその場限りの対処になってしまい、抽象だけでは現実の合わない解決になっ てしまう、だから具体と抽象の往復する。
AIと壁打ちで実現する施策を選ぶ 1. 候補を比較する 各解決策の効果の見込み・必要なデータ・運用負担をAIに比較させる 2. 前提を疑う 「この案が役に立たないとしたら、どんな前提が間違っているか」 3. 現場で確認 AIが出した効果や原因は推測なので担当者にも確認 比較にはAIを使い、選んだ理由は自分の言葉で説明する
作ったものを現場で確かめる 1. 体験してもらう 選んだ施策をAIでプロトタイプ作成し利用者や担当者に使ってもらう 2. 出てくる反応 「説明は理解できたけれど、自分の契約をどこで確認するかわからな い」「担当者には届いたが、調査に必要な情報が足りない」 3. 次の策が見えてくる 契約情報の確認方法を示す、引き継ぎ時の入力項目を変える プロトタイプを試すことで、課題の捉え方も更新される
まとめ 課題は人が達成したいことと、現実との間に生まれる。 課題の発生源はどの時代でも人なので、AI時代でもエン ジニアは人と向き合うことが重要になる。 人と向き合って具体を知り、抽象化して解決策を広げ、 再び具体化して人のいる現場で確かめる。 この具体と抽象の往復が、課題解決につながるエンジニ アリングです。
参考文献 ・ システム開発と「具体と抽象」 (https://www.amazon.co.jp/dp/429715790X) ・ エンジニアのAI壁打ち実践術 (https://www.amazon.co.jp/dp/4297158191) ・ 要件定義の極意 (https://www.amazon.co.jp/dp/B0GMP2LLBG)