2024-10-07 17:27

第8回「日通とアクセンチュアは他人事じゃない!」

spotify apple_podcasts


第8回目のテーマは「日通とアクセンチュアは他人じゃない!」

日本通運が基幹システムの開発失敗を巡ってアクセンチュアを提訴した問題について深掘りします。

このようなトラブルがなぜ発生したのか、そして同じような失敗を防ぐために、どのような対策を考えるべきか、システム開発会社のリアルな視点で解説します。

▼ホスト:島田徹

▼MC :鴨志田怜

▼ゲスト:辰巳純基 ------------------------------------------------------

▼国内ラボ型開発の詳細はこちら

https://labo.plumsa.co.jp

------------------------------------------------------

▼お便りメール

メッセージをお待ちしております!

Googleフォーム: ⁠https://forms.gle/DCema6crfoux1ZAR9⁠

------------------------------------------------------

▼会社プラムザ のホームページ

 システム開発などでお困りの事があればお問合せ下さい。

⁠https://www.plumsa.co.jp/⁠

------------------------------------------------------

▼𝕏アカウント

⁠♯ふてはな⁠ 』で番組の感想、ご意見、質問など、ポストしてくれた投稿には返信することもあるのでぜひフォローお願いします!

 ・番組𝕏: ⁠@futehana⁠ 

------------------------------------------------------


サマリー

日本通運とアクセンチュアの間で発生している基幹システム開発に関するトラブルについて議論されています。両社の認識の不一致やテスト基準の曖昧さが問題を引き起こし、今後のコミュニケーションの重要性が強調されています。日通とアクセンチュアのトラブルを受けて、ラボ型開発の重要性とメリットが話し合われており、開発スタイルの変革が求められています。また、コミュニケーションを重視した誠意ある開発が成功の鍵であると強調されています。

トラブルの発端
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、辰巳です。よろしくお願いします。
3名でお送りいたします。
さて、さっそく今回のタイトルなんですが、日通とアクセンチュアは他人事じゃないというタイトルになっておりまして、まさにこれ今自治、ネタを扱っていくというところになると思います。
まず簡単に記事からの概要をお伝えします。
日本通運が基幹システムの開発を委託していた外資経営コンサルティング会社アクセンチュアに対し、開発が失敗中止となり債務不履行が生じているとして、約125億円の損害賠償を求めて提訴したと報じたというニュースが流れておりまして、
これざっくり、あまり知見のない中で見るに、研修完了とかテストの基準とかが曖昧だったみたいな記事を見たんですけど、大体そんな認識であっているんですかね。
あってますね。本当にこうメディアの記者が書いてましたが、胃がキリキリするっていうのは、私たちにも身にしめて共感できる内容かなというふうに。
なるほど。これはどういった理由で、単純に第三者から見たら揉めてるんだろうなというのはわかるんですけど、実際どういうところが焦点になっていると言いますか。この詳細のところをお伺いしたいなと思うんですが。
私から簡単に説明すると、その業務システムの開発をアクセンチュアに日本通運が依頼していて、一番の焦点、根本の問題は認識の不一致が相互に生じていると。その内容は何かというと、テストをしましたとシステムの開発が終わって。
それがコンサルティングというか、アクセンチュア側にとっては、これはもう終わったものです。完了してますというふうに認識しているものの、日本通運側は、これ不具合まだあるじゃないか。これバグ出てるよ。終わってないでしょっていう意味合いでごっしょうしていて、これこのままだったら開発は失敗なので訴えますよというような状態。
なるほど。ちょっと規模が大きいので、単純におぉと思ったんですが、内容としてはおそらくこれで完成してますよ、いやしてないですよっていうのがこう発展してこうなっているという感じなんですね。
テスト基準の問題
そうですね。もう少し技術的というか専門的な話をすると、アクセンチュア側としてはそのITBテストといって、結合テストの後半部分にあたる。ほぼもう完成に近いですよというような状態のテストをクリアしているんだけれども、日本通運側はそうではない。まだまだそんなレベルではないんじゃないのっていうことを主張されているような状態です。
結合テストっていうのはちょっとあれですが、テストの段階がいろいろあるんだろうなという認識を持っていながら聞いていたんですが、島田さんはこの件に関して思うこととかありますか?
実際具体的にどういうシステムを作ったのかっていうのは細かいところまで伝わってきてないのでわからないところがあるんだけど、基本的にシステムを作ってテストっていうのをやるんだけど、結合テストが済んでもちゃんと業務が回るかどうかっていうシステムテストとかを行わないと完成したと自分は思わないと思うけどね。
完成したって言えないんじゃないかなっていうのは思っていて、これは多分結合テスト、細かい機能ごとの動きは確認とってもらったし、多分ハンコをしてもらったりしたんだと思うんだけど、業務フローはこれじゃ回らないよみたいな、そんな話になってるのかなって思うんでね。
なるほど。結合テストっていうのはおそらくそれぞれ機能しているのが合わさったもののテストみたいな認識かなというふうに思ってるんですけど。
そうそう。単体テストっていうのはちっこい機能ごとのやつで、それはエンジニアが自分作ったところとか、補助者が入って単体の機能をテストするんだけど、画面フローごとにやっていったりするのが結合テストなんで、ちゃんと一連の動きとしてちゃんと使えるのかみたいな。
っていうのが結合テストで、ITBテストでもそこまではしっかり見てもらったということかなって気がするね。
僕も思ったのが結合テストで諸々の機能としては成立しているけれども、システムとして運用していくには成り立っていない部分があるので、多分それを日本通運側は不具合とみなしているのかなとかちょっと読み解いたしだい。
ちなみに結合テストの上と言いますか、そういうテストみたいなものが基本的には行ってシステムとしてちゃんと稼働してっていうのが基本的に収める形になるんですかね。
そうだね、その後大体システムテストっていうのをやって業務のストーリーを作ってパターンを作ってね、ちゃんと回るかっていう。
一番大事なのは要件定義っていうのがあって、そこに業務フローのパターンがたくさん書いてあって、その通りに回るのかっていう、それを最後にテストするんだと思うんでね。
そこまでやってない気がするね。
コミュニケーションの重要性
やってないのに理由があるんですかね。最初に取り決めだったみたいな感じになるんですかね。
やっぱりそこのテストの基準でどういう状態になったらクリアになるのかっていうのがお互いで共通で認識が取れてなかったっていうのもあると思いますし、
これはあくまでも推測ですけど、アクセンチュアってあくまでもコンサルティングの会社で、開発実行とかそういった舞台は別の会社に委託しているはずなんですよね。
そこがどういうふうに考えてるかっていうところにもよるのかなと思う。
じゃあ、委託された先がそこから先は知らないですよって、ここまでしか依頼受けてませんよっていうことも全然考えられるって感じなんですかね。
考えられると思います。これもその裁判が進んでいくにつれて、そういう情報とかもメディアで可能な限り公開されていくんだと思うんですけど。
なので、両者の言い分がこのままだと平行線だなっていう状態ですね。
なんとも怖い話だなっていうのは思うところですね。
冒頭に言った通りよくある話だと思います。
明日は我が身と言いますか、本当に気をつけないと我々ももう首を絞めるようなことになるとずっと思います。
これは最初の定義決めと言いますか、どこまでやるかとか、例えば言った言わないとか、そういったことをどうやって防いでいくのかっていうところに結局はなってくるコミュニケーションだったり、そこら辺の問題なんじゃないかなというふうに思うんですが、
やっぱりそこら辺はしっかりしないとと言いますか、どうしたら言った言わないみたいなものが防げるのかっていうところも、ある種開発の技術に含まれるんじゃないかなというふうに聞いていて改めて思ったところなんですけど、
辰巳さんの方で、意志疎通とか言った言わないっていうことを防ぐこととしてどんなことをされてたりするんですか。
そうですね、意識としてはお互いに嘘つかないようにまずしましょうっていう、騙そうとしないとか言いくるめようと思ったりしないっていう意識がすごい大事だなと思ってて、
ある程度の伝え方とか配慮っていうのは重要だと思うんですけど、変ににカッコつけないというか飾りをつけすぎないというのは大前提。
仕組みとしてどういうことをやるかというと、打ち合わせに関しては口頭だけだとどうしても記憶のそれこそ繰り違いが出てきてしまうんで録画録音するとか、それを元に文字を起こして要約してそれを共有していたとかっていうことも必要だと思ってますね。
今だったらAIのツールとかを使って簡単にできるので、昔と違って都度議事録要員がいてパッパッパッパって記載し記録していくっていうのもそんな必要もなくなってきてるのかなと思ってます。
そういうのを有効活用する必要もありますし、あとは先方も可能であれば議事録つけてもらった方がいいですよね。それで擦り合わせてここがちょっと違いますねみたいなところを火種を小さい位置から消していくっていうのがすごい重要なことです。
それをやってでもやっぱり言った言わないっていうのは少なからず出てくるんじゃないかなというふうに思ってますね。
確かに単純に記録に残すっていうのは、業務が大変になってくればどうしても見落としとかあるかもしれないんですけど、そういう時にも単純に自分たちのためにはなりますし、できればそういうことはない方がいいと思うんですけど、裁判になった時とかももちろんそれが証拠としても出せるっていうところもあるのかなっていうのをちょっと今聞いていて思いました。
島田さんの中で意識だったりこういう対策してるっていうものがあればお伺いしたいですね。
難しいんだよね。初めにこういうシステムを作りたいとかっていうのをお互いに共有して要件定義の段階でやっていきましょうってこういう管理が必要ですねって形でスタートするんだけど、細かい実装になっていて質問するとお客さんの中で矛盾があったりするんだよね。
どうしてもそういうことがあるんで、こちらが質問する、お客さんはその場で答える。他まで質問する、答えるって言ってるとその答えが矛盾してるんだよね。矛盾してるけど、じゃあそのままね、その通りに作っていいかっていうと、その通りに作るとですね、初めの要件定義、約束した内容が作れないとか、矛盾したものは出来上がったりするんだよね。
確かに言った言わないはしっかり防いで、言った通りに作ってるんだけど、その通りに作ったら要件定義にあったものが出来ないみたいなことが容易に起きるので、これは議事録取っておけばうまくいくとかっていう問題なかったりするんだよね。
なるほど。まさしく人間関係の悩みを聞いてるみたいな。
ラボ型開発の重要性
お客さんはわからないので、内部的なデータベースの仕組みとかもわからないんで、結構その場で思ってたことを言ったりするんだよね。ある程度はこちらとしてはきちっと議事録取って確認するっていうのもあるんだけど、変なこと言ってるなと思ったときにわざと聞き飛ばしたりすることもあるんだよね、俺としてはね。
たぶん来月の定例のときにあれがね、意見変わったんだなと思ったりしてね。
恋人関係とか夫婦関係にも言えてきそうですよね。
今熱くなっているからちょっとほっとこうみたいなことも結構あるんだよ。
あんた家事するって言ったじゃないのって言って、洗濯は家事に入らないといけないかなみたいなことを言ったりとか言った。
なんか島田さん思い当たりそうな顔をしてますけど。
いやいや、そんなことはないけどね。
なるほどですね。その辺の、なんでしょうかね。
わかりやすく身の回りのところに置き換えたりすると、確かにそんな簡単に方法論とかで解決するのもなかなか難しいんじゃないかなっていうのはちょっと思ったところですが、なんかいい解決方法とかないもんなんですかね。
一つ選択肢はあり得ますね。
島田さん教えてください。それは何ですか。
絶対わかったよ、それは。それは例のあれですね。
それは国内ラボ型開発ですね。
ラボ型開発ですね。前の回やりましたよね。
そうですね。ラボ型は基本的な目標、ゴールを共有して、あと細かいところの言った言わないのを考えずに、お互いに考えながらアイディアを出しながら動作を見て、これ違うねとか言いながら
いいものを作り上げていこうっていう開発スタイルなので、そういう細かい議事録とかを、議事録取るんだけど間違っても別に構わないと。
言ったことを間違っても構わない。どんどん前へ進んでいくっていうスタイルなのでね。
そう考えるとあれですよね。お客様が実際目に見てどんどん意見が変わっていくっていうのも、それもついていく。一緒に作っていくっていうのをどんどん進めていくってことですよね。
そうですね。
確かにそうすると、ちょっと聞いてて思ったのが、例えば予算がはっきり見えないっていうのも問題点の一つとしてあったじゃないですか。
ある程度のところまで一括で作って、その先の修正とかそういったものはラボ型でみたいな形もあったりするんですか?
それは非常に良いと思いますよ。実際最近もそれで提案しようとしてるのもあるんで、8割型まで一括で作って、ただ絶対それで終わらないというか、
それを見ると、確かに要件定義のとき話した内容は出来上がってるんだけど、ちょっと違うなっていうことが多分日本通信さんもそうだったと思うんだけど、そういうのはたくさん思いついてくるんだよね。
そこの穴埋めをラボでやっていくっていうのは非常に良いと思いますよ。
確かにそうしたら、日通さんとアクセンチュアさんみたいなことになりづらそうなイメージはありますよね。この先修正していきますって形になると思うんで。
結局この2者も今トラブルになっちゃって、一体誰がどういう指示したのかとか、初めの要件定義どうあったのかとか掘り起こして調べてると思うんだけど、そういう昔のことをほじくり返して調べるっていう労力って本当に無駄だと思うんだよね。
協力による成功の鍵
間違いないですよね。だってこの規模でいうと何億、何十億ぐらいの話ですよね。損害賠償請求額が125億なんで、もっとそれ以上の開発費用がつぎ込まれてるはずなんで。
単純に同じ労力なら前向きな方に割きたいですよね。
一括受けを言うと、普通の一括受けを言うと、ラボ型開発って同じシステムを作っていく手法ではあるんだけど、全く開発者の姿勢が違っていて、基本的にラボの方は常に前向きでお客さんの役に立つために何しようかと考えてるんだけど、
今回のこのアクセンチュアさんがそのように一括でやってしまうと、契約結んだ瞬間から何とか研修費を上げてもらうっていうね。
使い良かろうが悪かろうが、そこはゴールではなくて、検収印をもらうっていうのはゴールになってしまうんで、非常にお客さんと意識の乖離が激しくなるんでね。
お客さんとしては決まった額でできるだけ盛り込みたい。ベンダー側はこの決まった額でできるだけ少なくコストを抑えたいっていう矛盾がほこたての状態になってしまってるんで、それはうまくいかないですよね。規模が大きくなればなるほど関わる人も増えてくるし。
では、最終的には是非国内ラボ型で開発していただくっていう答えになるんですかね。もちろんコミュニケーションとかあると思うんですけど、他補足点とか島田さんはありますか。
一括にしてもですね、やっぱりこちらも誠意を持って作っていこうと思ってるんですけど、お客さんの方もですね、無理を言うとどうしてもこじれてしまって、あれなんで、お互いのためにもですね、お互いに協力し合っていいものを作っていこうっていう意識でやっていくべきかなって思いますね。
ありがとうございます。では本日はこの辺りでよろしいでしょうか。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。またXでも最新情報を随時発信していますのでよろしくお願いします。システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。それではまた次回お会いしましょう。
ありがとうございました。
17:27

コメント

スクロール