中海テレビ放送様が手掛ける地域新電力事業に関連するサービス開発において、Balusを活用したモデルベースな設計開発を実践しました。
＜モデルベースな設計開発とは＞
完全にモデルベースな形でプロセスを進めた結果、モデルの利点を十分に活かすことができ、認識の齟齬や手戻りのない効果的なシステム開発を実現することができました。
今回開発したシステムは、中海テレビさんが提供する地域新電力事業「Chukai電力」のオール電化プランへのお申込み受付システムです。
新電力事業では、既存の電力会社からいかに乗り換えてもらうかが鍵になります。今回のシステムでは、新規に提供を開始するオール電化プランへ「誰でも簡単にお申込みできる」ことを目指し、LINEから手軽に申込みできるシステムを開発しました。お申込みにあたっては、もし乗り換えたらどれくらいお得になるのかを事前にシミュレーションして確認することができます。お申込みを受け付けると、中海テレビのオペレーターは申込者がどのようなシミュレーションをしてお申込みをしたのかという情報も合わせて知ることができます。そのようなデータを蓄積することで、今後の事業に活用することができます。
まずはどのようなシステムをつくるべきかを明らかにしていくために、中海テレビさんの構想や要望をヒアリングしました。ヒアリングでは、コンテキストモデルと業務フローモデルを描きながら、次のことを明らかにしていきました。
モデリングの結果、中海テレビさんの将来的な事業のあり方とそのために必要なシステムの全体像がわかってきました。今回はそのうちの一部である「お申込み受付システム」を開発スコープにすることを意思決定しました。
次に、ヒアリングで得たモデルを出発点にしてシステムの上流設計に取り組みました。より細かい粒度まで記述したり、曖昧だった部分について意思決定したりしながら業務フローモデルをブラッシュアップしていきます。全体の業務フローと「料金シミュレーション」や「申し込み」などのシナリオ別の業務フローを階層に分けてそれぞれ記述することで、理解しやすいモデルになることを心がけました。
さらに、システムを様々な視点から見て次のようなモデルを構築していきました。
上記のうちいくつかの例を取り上げて紹介したいと思います。
ユースケースモデルは、ユーザーがシステムを使ってやりたいこと（期待）と、システムから見てどのユーザーに何をすればよいのか（機能）をつなぐモデルです。今回のシステムの場合は、新プランへの申込者（中海テレビさんから見た顧客）から見たシステムへの期待と、中海テレビさんのオペレータから見たシステムへの期待をそれぞれ描いていきます。
このようにしてユースケースを描きだしておくことで、今回の開発ではどこまで（どのユースケースまで）を実装するのかといった、スコープに関する議論も行うことができます。例えば上の図で紫色に変更してあるユースケースは、初期の実装では対象外であることを示しています。
システムまたはシステム要素の状態が何をきっかけに（きっかけのことをトリガーと呼びます）どのように変化していくかを表現するのが状態遷移モデルです。今回のシステムの中では、電力契約申込などの情報要素の状態が次々と変化していくので、その部分について認識を合わせるために下図のような状態遷移モデルを描きました。
どんな画面があるのか、それぞれの画面の中でどのような情報が表示されるのか、そして各画面の中でユーザーはどのようなアクションができるのかを表現したモデルが画面コンポーネントモデルです。
画面コンポーネントモデルをつくると、発注者（今回の場合は中海テレビさん）もシステムに対する具体的なイメージを持つことができ、様々なフィードバックを得ることができます。
Balusを使うことで、ここまでに紹介したモデルベースな上流設計を発注者である中海テレビさんと対話しながら進めることができました。中海テレビさんは業務フローモデル、ユースケースモデル、画面コンポーネントモデルなどの理解しやすいモデルを閲覧して、イメージと違うところを伝えてくれます。そのフィードバックを受けてモデルを修正し、修正したモデルと整合性を保つように概念モデルやシステム構成モデルをアップデートします。モデルベースな設計では、各モデルの間を何回も行ったり来たりしながら少しづつ「欲しかったシステム」に近づけていきます。
設計の次は開発のプロセスに進みます。一般的なプロジェクトでは、システムの仕様としてRFP等のドキュメントを作成してベンダーに開発を依頼しますが、今回のプロジェクトでは、発注者である中海テレビさんとベンダーの間でモデルを中心に対話しながらシステム開発を進めました。
モデルを中心に開発することで、
などの利点があります。
例えば今回のプロジェクトでは、管理側の画面を開発する際にお申込み受付後の具体的な営業プロセスについての理解が必要になったため、中海テレビさんとベンダーを交えて業務フローモデルを描いて認識を揃えながら進めました。
今回のプロジェクトでは、中海テレビさん・ベンダー・レヴィの3社が、着手から完成まで一度も会わずに全てオンラインで対話や作業を実施しました。このようなことが可能だったのは、モデルを中心に対話することで認識を揃えることができたからです。
このようにして設計開発を進めることで、スケジュールの遅れがなく計画通りにシステムが完成しました。
上流設計の段階でモデルを使ってしっかりと認識を合わせておいた上に、モデルを中心に置いて発注者とベンダーが対話しながら開発を進めたことで、とてもスムーズで効果的なシステム構築を実現することができました。
完全にモデルベースな方法で設計開発を進めた今回のシステムはすでにリリースされ、実業務の中で活躍しています。
Balusを使ったシステムの設計開発について、中海テレビ側の担当者である森龍一さんにお話を聞きました。
これまでも納品物としてシステムモデルのような図が出てくることはありましたが、上流設計の段階で一緒に図をつくりながら議論するというのははじめてでした。Balusを使うことで我々のような「発注する側」も設計に参加して欲しいシステムのあり方を伝えることができました。そのおかげで、手戻りらしい手戻りや関係者間の認識違いがほとんどなくて、計画通りに開発を進めることができました。
システム開発を発注する際にはまず関係者の認識を合わせるためにドキュメントをたくさん書くことが多いのですが、今回はその手間が減りました。いつもと違って「1件のプロジェクトにかかりっきりになっている」という状態になりませんでした。それだけ効率的に進めることができたということですね。
ばっちし動いていて、活用しています。システムを担当していると、運用を開始してから「なぜこうなっているんですか？」とか「こんなことはできないんですか？」と言った質問や要望を多く受けて業務的な負荷になることがよくあります。しかし今回の新プラン申込みシステムでは、そのような問い合わせがほとんどないのでとても楽です。Balusを使うことで特定のメンバーだけでなく、システムの運用に関わるたくさんのメンバーが設計に口出しできたことが良かったのかなと思っています。ドキュメントだけだと設計に関する会話に参加できませんからね。
さらに良いサービスを提供するためにシステムの方も進化させて行きたいと考えています。Balus上にシステムモデルが残っているので、時間が経ってからでも設計の意図が分かるというところがいいですね。私も一緒につくった図なので、後から見ても設計の意図や意思決定の理由が分かります。次の開発でもBalusを使えるといいなと思います。
レヴィが提案するフレームワーク「システミング」やレヴィが提供するモデリングツール「Balus」によって、今回紹介したようなモデルベースな設計開発をチームで実践できるようになります。
ご興味・ご関心をお待ちの方は、お気軽にレヴィまでお問い合わせ下さい。