日本ユニシス「スマートタクシー」に見る、アジャイルによるサービスビジネス開発事例のポイント

プロジェクト開始時の要求の把握

タクシー専用のデジタル無線による自動配車システムは複数の他社メーカーより提供されています。そういった既存の専用システムを活用している会社がお客さまのグループ企業内に存在していたため、担当者から支援を受ける事ができ、事前にある程度、システムに対する要求を挙げていただくことが可能だと推測されました。

まずは開発メンバーの知識レベルをある程度お客さまに合わせるために、今までのタクシー会社の経験や日々の業務を取材し、業務について開発メンバーが理解するところから始めました。業務フローや配車システムへの要求をリストアップするだけではなく、既にデジタル無線による自動配車システムが稼働している配車センターや、旧来のアナログ無線の配車センターを幾度も訪れ、実際の配車業務を見学しました。

配車センターの見学は、最初のうちは営業メンバーが中心でしたが、本格的に開発が決定してからはできるだけ開発メンバーと共に実施しました。

開発プロセスと開発のための技術

開発開始からリリースまでの計画

2週間を一つのサイクル（以後イテレーション）として、開発を実施する事にしました。

2週間で実装できないであろう要求は細かく分割することで対応しました。

開発投資元である自社（日本ユニシス）からは、リリースできるゴールを設定し、実現可能な事前計画の立案と提出を求められました。

本開発では、要求はある程度変更がきくよう、大きめの要求で留めておいた状態で開発計画を立案し、進捗状況に応じて計画を変更できる素地（そじ）を残すこととし、そのことを自社に説明し承認を得ました。

状況に応じて詳細な部分の計画を変えていき、細かく状況を把握してリスク管理を実施する事を会社へ説明したうえで、求められたマスタースケジュールとゴールを設定しました。

例えば、マスタ管理画面はまずはお客さまが自分で管理できるレベルのUIか、要望を受けて運用するSEが対応するレベルのUIで良いかについては、この時点では決めていません。

要求の優先順位の設定とその内容の確認

事前にリストアップされた要求の中からビジネスとしての必要の度合い、および技術的に高いリスクが予想されるものから順に高い優先度を付けていきました。

要求の実現方法を最終的に決定する役割としての「プロダクトマネージャ」は、本プロジェクトのビジネスマネージャの竹本さん（仮名）にお願いしました。彼は、最もお客さまと会話し、本サービスのコンセプトと価値を理解していたからです。

竹本さんとは、イテレーションの中で開始時期に、実装する内容と方法を説明し、終了時期に実装されたものを確認してもらいました。システムの仕様についてはどうしても多く盛り込みたい立場となるので、盛り込む仕様の大きさについて何度か意見が合わない場面もありましたが、進捗状況の説明と実際のシステムを見せる事で、盛り込む仕様の取捨選択がスムーズになってきました。

また、ファーストユーザーとなるタクシー会社に、定期的に開発中のシステムをデモする事で、各要求の重要性や、開発されるシステムの方向性を確認し続けました。

開発中の計画見直し

計画はイテレーションが終了する毎に、これまでの開発生産性を算出し、現在の開発がいつごろ終了するかを把握し続けました。開発計画は、技術的な問題の発覚する度合いや、お客さまへのデモ結果などをイテレーション毎に反映し、優先度の変更と未開発の要求リストの中から規模や内容を見直しました。

何度か、既に開発済みの要求部分に見直し内容が及ぶ事態となりましたが、その場合は、できるだけ優先度を上げた形で新たな要求をリストアップして開発しました。その部分については、ある程度「手戻り」となりましたが、多くは2週間（1イテレーション分）よりも小さい粒度で済む事が殆どでした。

要求や計画の見直しを自動テストで援護射撃する

開発計画や要求を見直し続ける間には、仕様および実装が変わる事が起こりました。

また、イテレーション毎に実装部分が追加されるために、新規に追加した部分が既存部分に影響を及ぼしたり、仕様の思いがけない見落としなどが発生することが予測されました。

そのために、修正や追加を安心して実施し続けるためにはバグの埋め込みを即座に発見できる仕組みが必要となります。

本事例ではできる限り、各実装済み機能に対して自動テストを用意し、即座に発見できる仕組みを作りました。定期的にソースコード管理ツールから自動的に最新コードをテストできるようCIツールであるJenkinsを活用しました。CIツールの活用により、問題があるコミットをした場合は即座にメールが届きます。

既存部分へのバグの発見が分かる状況であれば、実装の追加や修正に対する開発者の心理的障壁が下がります。そうする事で、よりよいソフトウェアとするための提案を前向きに受け取れる開発者となり、それは「プロダクトマネージャ」と今後の開発の方向性を議論する上で大切な事だと感じます。

自動テストを中心とした仕様変更・仕様追加へのコストを下げる努力は、開発者心理・ソフトウェア品質両面で、できるだけ継続した方がよいと感じました。