私が担当する事業計画分野のDX化の一環として、基幹システムの刷新を進めています。

今まで複数回にわたって要件定義会が開かれてきました。

コンサルと社内情報システム部で構成される開発チームとユーザーである事業部の代表メンバーがオンラインで会議をしますが、アジャイル開発という名の下、「必要最小限の要件を定義する」という進行になってしまっているがために、非常にミクロな確認会になってしまっています。

今までの会議の様子は以下の記事をご覧いただけると嬉しいです。

要は、アジャイル開発と言ってしまっているがために、ユーザーとの交流を数多く設定している（記事にしている以外にも複数開かれています）ものの、議論に時間を割くより、開発画面ベースでの確認に重点が置かれてしまっています。

それはそれで開発チームの「スケジュール」に対して進んでいるようですが、参加するユーザー側としてはどうしてもすっきりしません。

会議の終わり方も、「開発側で本日確認したいことは以上ですので終わります」という形であり、ユーザーとしては、「開発チームのために集まっている」という印象は拭えません。

そのようなもやもやを抱えていたら、開発チームよりダイレクトに連絡がありました。

開発チームは社内情報システム部門と言いましたが、エンジニアだけではなく、DX推進を見越して、複数名の事業部出身者が含まれています。
そのうちのリーダー格の部長さんが、過去私の部署にいたこともあって、旧知の中でしたので、それもあって連絡をくれました。

「ちょっと個別に相談させてくれないか」

と言われました。その部長さんは私にとって尊敬する人で、事業計画の知識が深い人であることを知っていましたので、喜んでお話しさせてもらいました。

呼ばれてみたらエンジニアの方含め、社内メンバー5人ほどが招集されていました。

相変わらず開発画面を見ながらの議論だったのですが、そこで

「この画面で海外の生産拠点から輸入する部品の情報を見れるようにしたいのだが、そうしたら使えるかな？」

という問いかけをもらいました。

我々の会社は日本だけでなく、海外に数十の生産拠点を持っており、部品の輸出入を頻繁にしています。しかし、現状ではそれぞれの会社の事業計画はそれぞれの会社で個別に立案していたため、日本が輸入したいと思う部品の数量と、海外が輸出するつもりの数量の不整合が発生していました。

これは連結事業管理という意味で、不整合が起こりえますので、なんとか解消したい課題であることは間違いありません。
その目線で、新システムでは海外とクラウド上でつながるという利点を活かし、こういった情報の日本と海外のすり合わせが一覧でできるようにしたい、とのことでした。

そのコンセプトは全く同意でした。しかしそれは、言ってみれば会社全体を管理する立場でのニーズであり、日本や、海外各地の会社一つ一つを司っているユーザーにとっては嬉しさを感じにくいポイントです。

もちろん、邪魔にならない機能であれば、すべてのユーザーに嬉しさがなくとも実装すればいいと思います。
しかし、出来るだけ多くの人に嬉しさが出ればそれがいいに決まっています。

何が言いたいかというと、「ある機能をベースにそれを有効活用する想像力が必要」ということです。

ユーザー自身の想像力が大事

ユーザーがすべて与えられるものを使うだけというスタンスならば広がりがありません。
いかに、こういった機会を自分の業務における付加価値に結び付けるか、そういったマインドセットが必要だと思います。

今回の例で行けば、海外の生産会社と日本の間でやり取りされる部品の数量が一元管理されるようになるわけです。
経理上の整合を取っていくというきっかけはあるものの、自分の事業計画業務で如何にそれを活かすか考えてみるわけです。

例えば、部品の数量だけのやり取りではなく、そこで価格も確定させられないか、といった、複数の業務をこなしていく。
そのほかにも、海外生産拠点から日本に輸出する量だけでなく、海外生産拠点の生産量全体を見に行くことで日本で余分な投資をせず海外の設備を有効活用することを考えることができるのでは、など。

こうすれば、数量だけでなく価格や原価も同時に進められますし、日本の投資圧縮にも繋げられます。

今の会議はユーザーに想像力を求めていない

いつもの要件定義会議は「今の業務をベースにした場合に不都合のないようにする」というスタンスで進められています。

よって、新しいシステムのポテンシャルを理解して、それによって業務を変える議論はできていません。

いつもの要件定義会議はかなりの人数が参加しますので、議論をしようにもなかなか難しいところがあります。
それで今回私が個別に呼ばれたわけですが、もちろん全員を順番に呼び出して意見を聞くわけにもいきませんし、かと言って私だけの意見で進めるのもよくありません。なにより、全員が自ら想像力を働かすことができるとは限りません。

そこで、私が開発チームに提案したのは、「ビフォーアフターをベースにした骨子を見せること」です。

叩き台があれば想像するきっかけになる

この時に重要なのはアフターだけではダメだということです。まずはビフォー、つまり現状認識が無ければどれだけアフターが変化しているのか見えません。

まずは開発チームや少数の事業部で議論した結果をビフォーアフターで示し、システムの骨子とする。
これ叩き台として、意見を出してもらう。
ビフォーの解釈が違うかもしれないし、アフターの可能性も広がるかもしれない。
それも骨子を叩き台として示さないと議論が発散します。

計画＝スケジュール、ではない

今、開発チームが示している計画はあくまでスケジュールしか示されていません。これではユーザーは何を実現しようとしているのか理解できません。
計画＝スケジュール、と思う人も多いですが、計画には骨子が必要です。

アジャイル開発と言って、目に見えるシステム画面を急いで作ろうとしてしまっていますが、骨子の議論を早く回すこと。そのためにビフォーアフターを示して議論のベースを用意すること。

これが変革を導くアジャイル開発に必要なのではないかと考えた出来事でした。

いま、ビフォーアフターを定義する打ち合わせの設定を開発チームにお願いしているので、早く作って行きたいと思います。