株式会社中海テレビ放送

Balusを用いた対話型モデリングによって、スムーズで手戻りのないサービス開発を実現


中海テレビ放送様が手掛ける地域新電力事業に関連するサービス開発において、Balusを活用したモデルベースな設計開発を実践しました。

<モデルベースな設計開発とは>

  • ドキュメントではなくシステムモデルで設計情報を記述し、モデルをそのまま設計フェーズの納品物とした
  • 実装フェーズにおける発注者(中海テレビ放送様)とベンダーの間の対話を、モデルを中心にして進めた

完全にモデルベースな形でプロセスを進めた結果、モデルの利点を十分に活かすことができ、認識の齟齬や手戻りのない効果的なシステム開発を実現することができました。

新規サービスの加入者を増やすため、LINEで簡単に申込みできるシステムを開発

今回開発したシステムは、中海テレビさんが提供する地域新電力事業「Chukai電力」のオール電化プランへのお申込み受付システムです。

新電力事業では、既存の電力会社からいかに乗り換えてもらうかが鍵になります。今回のシステムでは、新規に提供を開始するオール電化プランへ「誰でも簡単にお申込みできる」ことを目指し、LINEから手軽に申込みできるシステムを開発しました。お申込みにあたっては、もし乗り換えたらどれくらいお得になるのかを事前にシミュレーションして確認することができます。お申込みを受け付けると、中海テレビのオペレーターは申込者がどのようなシミュレーションをしてお申込みをしたのかという情報も合わせて知ることができます。そのようなデータを蓄積することで、今後の事業に活用することができます。

対話型モデリングで「本当に必要なシステム」を描く

まずはどのようなシステムをつくるべきかを明らかにしていくために、中海テレビさんの構想や要望をヒアリングしました。ヒアリングでは、コンテキストモデルと業務フローモデルを描きながら、次のことを明らかにしていきました。

  • どのようなステークホルダーがいて、どのようなシステムを使って事業を行っているか
  • 将来的にどのようなことをやりたいと構想しているか
  • そのためにはどのようなシステムが必要そうか
  • 事業についての知識(ドメイン知識)
ヒアリングで描いた業務フロー(非公開情報を含むため拡大できません)

モデリングの結果、中海テレビさんの将来的な事業のあり方とそのために必要なシステムの全体像がわかってきました。今回はそのうちの一部である「お申込み受付システム」を開発スコープにすることを意思決定しました。

完全にモデルベースな上流設計。ドキュメントをつくらなくても、モデルだけでここまでできる

次に、ヒアリングで得たモデルを出発点にしてシステムの上流設計に取り組みました。より細かい粒度まで記述したり、曖昧だった部分について意思決定したりしながら業務フローモデルをブラッシュアップしていきます。全体の業務フローと「料金シミュレーション」や「申し込み」などのシナリオ別の業務フローを階層に分けてそれぞれ記述することで、理解しやすいモデルになることを心がけました。

クリックで拡大
全体の業務フローとシナリオ別の業務フロー

さらに、システムを様々な視点から見て次のようなモデルを構築していきました。

  • 情報構造モデル
  • 情報要素の状態遷移モデル
  • システム構成モデル
  • ユースケースモデル
  • 画面遷移モデル
  • 画面コンポーネントモデル

上記のうちいくつかの例を取り上げて紹介したいと思います。

ユースケースモデル

ユースケースモデルは、ユーザーがシステムを使ってやりたいこと(期待)と、システムから見てどのユーザーに何をすればよいのか(機能)をつなぐモデルです。今回のシステムの場合は、新プランへの申込者(中海テレビさんから見た顧客)から見たシステムへの期待と、中海テレビさんのオペレータから見たシステムへの期待をそれぞれ描いていきます。

クリックで拡大
ユースケース(一部)

このようにしてユースケースを描きだしておくことで、今回の開発ではどこまで(どのユースケースまで)を実装するのかといった、スコープに関する議論も行うことができます。例えば上の図で紫色に変更してあるユースケースは、初期の実装では対象外であることを示しています。

情報要素の状態遷移モデル

システムまたはシステム要素の状態が何をきっかけに(きっかけのことをトリガーと呼びます)どのように変化していくかを表現するのが状態遷移モデルです。今回のシステムの中では、電力契約申込などの情報要素の状態が次々と変化していくので、その部分について認識を合わせるために下図のような状態遷移モデルを描きました。

クリックで拡大
情報要素の状態遷移(一部)

画面コンポーネントモデル

どんな画面があるのか、それぞれの画面の中でどのような情報が表示されるのか、そして各画面の中でユーザーはどのようなアクションができるのかを表現したモデルが画面コンポーネントモデルです。

クリックで拡大
画面コンポーネント(一部)

画面コンポーネントモデルをつくると、発注者(今回の場合は中海テレビさん)もシステムに対する具体的なイメージを持つことができ、様々なフィードバックを得ることができます。

対話と反復が重要

Balusを使うことで、ここまでに紹介したモデルベースな上流設計を発注者である中海テレビさんと対話しながら進めることができました。中海テレビさんは業務フローモデル、ユースケースモデル、画面コンポーネントモデルなどの理解しやすいモデルを閲覧して、イメージと違うところを伝えてくれます。そのフィードバックを受けてモデルを修正し、修正したモデルと整合性を保つように概念モデルやシステム構成モデルをアップデートします。モデルベースな設計では、各モデルの間を何回も行ったり来たりしながら少しづつ「欲しかったシステム」に近づけていきます。

クリックで拡大
上流設計で構築したモデルの全体

モデルで認識を揃え、効果的にプロジェクトが進む

設計の次は開発のプロセスに進みます。一般的なプロジェクトでは、システムの仕様としてRFP等のドキュメントを作成してベンダーに開発を依頼しますが、今回のプロジェクトでは、発注者である中海テレビさんとベンダーの間でモデルを中心に対話しながらシステム開発を進めました。

モデルを中心に開発することで、

  • 開発するシステムに対する認識が揃いやすい。
  • どこに影響があるか把握しやすい。変更に対して柔軟に対応できる。
  • 発注側と開発側で対話しやすい。

などの利点があります。

例えば今回のプロジェクトでは、管理側の画面を開発する際にお申込み受付後の具体的な営業プロセスについての理解が必要になったため、中海テレビさんとベンダーを交えて業務フローモデルを描いて認識を揃えながら進めました。

クリックで拡大
認識を揃えるために描いた営業プロセスのモデル

今回のプロジェクトでは、中海テレビさん・ベンダー・レヴィの3社が、着手から完成まで一度も会わずに全てオンラインで対話や作業を実施しました。このようなことが可能だったのは、モデルを中心に対話することで認識を揃えることができたからです。

オンラインミーティングの様子

「発注する側」も設計に参加。手戻りや認識違いがなくなり、計画通りにシステムが完成

このようにして設計開発を進めることで、スケジュールの遅れがなく計画通りにシステムが完成しました。

上流設計の段階でモデルを使ってしっかりと認識を合わせておいた上に、モデルを中心に置いて発注者とベンダーが対話しながら開発を進めたことで、とてもスムーズで効果的なシステム構築を実現することができました。

完全にモデルベースな方法で設計開発を進めた今回のシステムはすでにリリースされ、実業務の中で活躍しています。

完成したシステムの画面(一部)

お客様の声

Balusを使ったシステムの設計開発について、中海テレビ側の担当者である森龍一さんにお話を聞きました。

森 龍一 さん
株式会社中海テレビ放送 営業部営業二課課長

Q. Balusをつかった開発はいかがでしたか?

これまでも納品物としてシステムモデルのような図が出てくることはありましたが、上流設計の段階で一緒に図をつくりながら議論するというのははじめてでした。Balusを使うことで我々のような「発注する側」も設計に参加して欲しいシステムのあり方を伝えることができました。そのおかげで、手戻りらしい手戻りや関係者間の認識違いがほとんどなくて、計画通りに開発を進めることができました。

Q. これまでのシステム開発と比較して良かったところがありますか?

システム開発を発注する際にはまず関係者の認識を合わせるためにドキュメントをたくさん書くことが多いのですが、今回はその手間が減りました。いつもと違って「1件のプロジェクトにかかりっきりになっている」という状態になりませんでした。それだけ効率的に進めることができたということですね。

Q. 完成したシステムはちゃんと動いていますか?

ばっちし動いていて、活用しています。システムを担当していると、運用を開始してから「なぜこうなっているんですか?」とか「こんなことはできないんですか?」と言った質問や要望を多く受けて業務的な負荷になることがよくあります。しかし今回の新プラン申込みシステムでは、そのような問い合わせがほとんどないのでとても楽です。Balusを使うことで特定のメンバーだけでなく、システムの運用に関わるたくさんのメンバーが設計に口出しできたことが良かったのかなと思っています。ドキュメントだけだと設計に関する会話に参加できませんからね。

Q. 今後の展望は?

さらに良いサービスを提供するためにシステムの方も進化させて行きたいと考えています。Balus上にシステムモデルが残っているので、時間が経ってからでも設計の意図が分かるというところがいいですね。私も一緒につくった図なので、後から見ても設計の意図や意思決定の理由が分かります。次の開発でもBalusを使えるといいなと思います。

ありがとうございました。

おわりに

レヴィが提案するフレームワーク「システミング」やレヴィが提供するモデリングツール「Balus」によって、今回紹介したようなモデルベースな設計開発をチームで実践できるようになります。

ご興味・ご関心をお待ちの方は、お気軽にレヴィまでお問い合わせ下さい。