アジャイル型製品開発の成功要因と落とし穴：顧客起点でデザインするサービスイノベーション（3）（2/3 ページ）

[柴田健一、井上拓／フューチャー，MONOist]

アジャイル型アプローチを進める製造現場

　ある製造業の顧客企業で、スマートファクトリーを推進した事例を紹介する。この企業では、製造現場のデータを集め、設備の稼働状況や製造するモノのトレーサビリティーや品質チェックなどを行うためにスマートファクトリー化を進めることにした。将来的には、稼働状況の変化の予兆を捉える予知保全を行うことも想定している。これらを実現するためには「どのようなデータ」を「どこからどのように集める」ことが必要かを整理しなければならない。ただ、これらの取り組みを進めることで、どれほどの効果が得られるかという投資判断が難しく、まずは短期間で最小単位のシステムを構築し、現場で日常的に行う業務の改善提案から進めたという。ここで、システムの構築をアジャイル型アプローチで推進したわけだが、成功に至ったポイントは以下の3つだと考えている。

1. アジャイル型の取り組み経験がある第三者を、外部人材として招き取り組み自体が間違った方向に行かないかを常に修正しながらプロジェクトを推進
2. 現場の開発メンバーだけではなく、組織を運営する部長クラスやその上長にあたる経営メンバーにも、アジャイル型の取り組みについて繰り返し説明し共通の意識を醸成
3. 現場の業務（作業）やデータの流れをきちんとおさえて可視化

　この企業では、プロジェクトを開始するタイミングで、全てを自己流で行おうとするのではなく、外部の力をうまく活用するというアプローチ（第一歩のマインドチェンジ）が結果的にターニングポイントになった。特に、開発メンバー以外にも早いタイミングで繰り返し理解を進めることで、予算確保も少しずつ進めることができ、アジャイル型のプロジェクトを止めることなく推進することができたという。

　また、工場現場の各ラインをきちんと観察し、現場の工場長に限らず、各ラインを実際に操作する現場の作業員にもきめ細かくヒアリングをし、その結果を1つのフローとして可視化したことも大きなポイントになった。業務（作業）とデータの流れを可視化することで、現場の作業員、現場管理者、システム開発者、システム開発部門の管理者などのさまざまなステークホルダーが同じイメージを持って、取り組みを進められた。同じ土台の上で、改善点を探し出すことができたことが成功の重要なカギとなったといえるだろう。

　一方、別の顧客企業であまりうまくいかなかった事例についても紹介しよう。その企業では、開発メンバーによるプロジェクト開始当初は、アジャイル型アプローチで取り組みを開始したが、次年度の予算を確保するタイミングで「中長期的な活動の細かな内容」や「将来の投資対効果」を厳密に求められた結果、要件や将来の展望を全て決めた上で決議しなければ、予算が下りなくなってしまった。最終的にはアジャイル型でプロジェクトを推進できず、3〜5年をかける長大なプロジェクト推進となってしまったという。そういう意味では、より幅広い関係者で共通の認識を作り出し、アジャイル型アプローチの本質的な意味を伝えていくというのが非常に重要になることが分かる。

アジャイル型アプローチの落とし穴

　アジャイル型アプローチでの進め方には根本的な注意点も存在する。アジャイル型アプローチは「これまでにない顧客体験の創出」「UI（ユーザーインタフェース）やUX（ユーザーエクスペリエンス）のクイックな向上」に対して大きな効果を発揮する。しかし、アジャイル型アプローチは設計手法として万能なわけではない。「業務UI/UXの改善」事例を通じて、注意が必要な「落とし穴」を紹介する。

　ある企業における「業務UI/UXの改善」プロジェクトでは、クライアントのシステム責任者から「担当者が毎日使う機能なので高い操作性を実現したい」という要望があった。そこで、モックアップを活用した設計段階でユーザー確認プロセスを盛り込み、スパイラルモデル（反復型プロセスにて設計詳細化する手法）で機能設計を計画した。設計工程が進み、ユーザーからのフィードバックの反映を完了し、一見順調に進んでいるように見えたが、ここに「落とし穴」があった。

　それはアジャイル型アプローチで簡略的に示されたモデル以外の「目に見えない部分」の仕様定義やユーザー確認が不十分になっていたということだ。例えば「ボタン押下後の処理でデータがどのように更新されるべきか」や「暗黙で指定される一覧検索の並び順はどのようなものか」など、簡易モデルで確認したために安心し、仕様として詰まっていない部分がさまざまな形で噴出してきたのだ。最終的には、プログラム実装フェーズに入ってから指摘を受け、手戻りが発生しアジャイル型アプローチのメリットを享受できたとはいいがたい結果となった。

　この事例の反省点は「アジャイル型アプローチだからといって業務仕様を定義するドキュメントを軽視してはいけない」ということだ。現場業務の制約や前提事項、非機能要件など製品には「目に見えない部分」で満たさなければならない要件が数多く存在する。アジャイルアプローチであっても設計資料にまとめ、ユーザーや設計者など関係者がすぐに分かる状態にすることが必要不可欠だ。例えば、処理パターンを網羅的に定義・確認するには「ディシジョンテーブル（正解表）」を作成することが効果的である。後工程でのテストケースにも用いることができ、効率的な進め方が行えるだろう。

PoCの落とし穴

　PoCを行う際は「対象ユーザーと目的の認識合わせをする」ことが重要だ。ここでも「業務におけるパターン最適化ロジックのPoC」プロジェクトにおいて、反省を伴う事例について紹介したい。

　このプロジェクトでは、もともと人力で行っていた「組み合わせ計画」業務に対し、最適化アルゴリズムによって、計画作業の自動化や省力化を行うことを目指したものだった。そのため、現場担当者に協力を依頼し、PoCを行った。確かめたかったのは「アルゴリズムと人力を比較してアルゴリズムが同等もしくはより高い精度を実現できるか」という点だ。実証を行うシステムは、入力・結果確認機能など簡素なものを用意して臨んだ。しかし、ここに「落とし穴」があった。現場担当者は日々の業務で忙しいこともあり、既存業務に存在しない「条件入力」作業が大変で、活用されないという状況が生まれたのだ。結果的にそのままでは実証作業が進まないため、もともとの計画にはなかった「条件入力」機能の拡充を行い、本来の実証作業を行った。

　この事例の反省点は「PoCに際しても関係者との目的合わせを十分に行い、実証作業上の制約や前提事項を考慮すべし」ということだ。PoCとはいえ、現場ユーザーは「この仕組みで業務が回るかどうか」という観点を重視するのが当然のことである。しかし、PoCに用いるプロトタイプの機能を完璧に作り上げることは難しく不完全が前提となる。だからこそ、PoCの目的を明確にして関係者で共有することにより、プロトタイプが目的達成に耐え得るものなのか、何を満たさなければならないのかをしっかりと確認することが重要である。

　そもそも、PoCの目的が現場業務の大きな負荷となってしまえば、実証そのものがいびつな形で進められることになり本当の意味で価値があるかどうかを検証することは難しい。最終的には「PoC止まり」の原因にもなりかねない。いかに関係者を巻き込み、当事者意識を持って協力してもらえるかは、その後の実用フェーズも踏まえると非常に重要な要素になる。