パネル進行スライドはこちらからご覧いただけます。融合」ということで、すべての会社がテクノロジーと直面すべきであり、テック企業化するのではないか、そういうテーマでお話を進めていきましょう。この点について、皆さんのご意見をうかがいたいと思います。長谷川:私は完全にそう思っているタイプです。大なり小なりテクノロジーの波はきており、無視することはできません。ような動きもあります。小売業界に限らず、テクノロジー無しでは起こり得ないことがたくさんあります。小島:今日のテーマは、小野さんのブログ「クレディセゾンでエンジニアリングチームを立ち上げます」からヒントを得たものです。小野さんは完全にテックの人であり、その方が事業会社の中の人として活動している、外部のシステム開発会社にいてもできることをなぜ中の人としてやっているのか。そこには何かしらの意味があるのだなと思って、このイベントを開催したわけです。そこで小野さんはどのように見ていますか。小野:「読み書きそろばん」は学問の基礎という話があります。現代社会では、さらにコーディングも必要だと思っています。小学校ではプログラミングが義務化されますし、「読み書きそろばんコーディング」は当然という時代です。そろばんをできない人が経営企画の仕事をしたら周りが困ります。財務だともっと困るわけです。今の世の中、とりわけデジタル分野での事業戦略を立てる人には、コーディング経験が求められるようになってきていると思います。関係において、要件定義して、ミーティングを重ねて、ウォーターフォールモデルで開発して何かあったら瑕疵担保責任でという考え方でも良かったかもしれません。今は、試作して、市場の反応を見て、場合によってはピボットしてという流れです。事業は生き物ですし、仮説検証と改善のサイクルを繰り返すのが一般的でしょう。なると必然的に、企画する人とその企画を実装する人との距離は近いほうが良いわけです。企画する人と実装する人との距離はまだまだ遠い状況です。下請け先の壁があり、企画する人と実装する人との間にはいくつものレイヤーが存在します。すると、コミュニケーションの中で誤解というものが絶対に発生します。これを変えたいとか微修正しようとしたときも時間もコストもかかります。事前に要件が確定できず、試行錯誤的に進めるしかない状況が多いはずなのに、無理やりウォータフォールで進めなければならないということもあります。ウォーターフォール型開発を進められていた辻さんは、今の小野さんの話を聞いてどう思いますか?辻:そうですね。Guide:アプリケーション開発標準化ガイド)というガイドラインに従って私も長年ウォーターフォールで仕事をしてきました。開発したシステムをユーザー側に移管した後、ユーザー側で改善することはなかなか難しいので、結局、新たに要求とまとめて、お金払って外部に開発を委託することになるわけです。前職の製造業でも、また現職でもその課題はあり、内製化戦略の必要性を感じています。すると、自動車も含めてハードウェアの開発でアジャイルというのは適さないかなと思うのですが、いかがでしょうか?辻:確かに、自動車の中を制御するインカーの部分は難しいと思います。アウトカー、すなわちサービスの部分はアジャイルでどんどんやっていくべき領域です。小野:むしろ、インカーは今後もウォーターフォールが向いている領域ではないでしょうか。ウォーターフォールが適したものは、他にもあります。いう製品は今でもコアの部分の絶対的に安定性が求められるところはウォーターフォールで開発しています。自動車は安全が一番大事じゃないですか?安全性を最重視する領域ではあらかじめ要件が確定できないなんてことになったらそれ自体が危険なわけで、安全性や安定性を重視するもの、事故を起こしたら絶対にだめなものは、ウォーターフォールの方が絶対向いていると思います。あらゆるものがアジャイルで良いわけではなくて、アジャイルの良さも悪さも両方を知った上で選ぶことが大切です。小島:事業がウォーターフォール的に物事を進めるべきものなのか、アジャイル的に進めるべきものなのか、そこの判断を誤ってはいけないということですね。なんとかテックというものを見つけることができます。共通していることは昔から存在する事業にテクノロジーを取り入れて、バージョンアップしようという考え方です。合理的にもっと早く安くということではなく、新しい価値をつけるのにテクノロジーを使っています。変化のサイクルが加速まずは、顧客接点のデジタル化。アウトカーの部分ですよね。カーナビでいろいろな情報にアクセスできるという点です。いえば、スバルさんはカーナビでいろいろなテストをされていますよね。辻:スバルが大好きな方のことを「スバリスト」と呼ぶのですが、スバリストは最短コースでは走りたくないのです。小島:通常、カーナビでは、最短距離の経路を教えてくれますよね。辻:毎回、同じ道ではなくて、天気の悪い日だったらこの道、あるいはカーブ好きにはカーブが多いところ、森の中とか、それぞれが楽しく走れるところを求めているのです。社員が一番のスバリストなので、普段からどうやったら自分は楽しく走れるだろうという議論をしています。社内情報システムの話題から離れますが、「デジタルよ、車の楽しさを奪うな」という考えがベースにあるのです。使うのではなく、もっと本来の良さを引き立てるところに使って行こうということですね。物が作りやすくなったので、テクノロジーを取り込みやすくなった。これは小野さんの視点から見てそうですか?小野:プログラマーは、あるものを使って、ないものを作ることを原則とすべき、という考えです。クラウドが出てきているのに使わないのはナンセンスです。クラウドは使いまくった方が良いということはもう明らかでしょう。ブロックチェーンとかクラウドでやろうとするのも違います。目的に応じた使い分けが必要です。つめが、変化のサイクルが加速しているという点です。長谷川さんは、エンタープライズ分野の中でも急進派で、すぐにやりましょうというタイプですよね。使う仕事のスタイルについていけなかったそうですね。長谷川:はい、ついていけなかったですね。仕事をすることが普通になっている会社がどんどん増えています。変化のスピードが更に加速していませんか。長谷川:メルカリは概ね四半期を単位に、いろいろなことが一気に変わります。毎期、フルスクラッチで事業のことを考えて成長していくと言えば良いでしょうか。一般的に、都度フルスクラッチで考えていたら、業務効率はとても悪くなると思うのですが、メルカリはそれを上回る高い生産性があります。ツールをフル活用していることもこの生産性を高めている要因です。小島:お客さんもテクノロジーを駆使して変化している、今述べた外的要因もあり、自らもどんどん変化していかなければならないということですね。融合しようとした時に必ず議論になること、「内製と外注」。このテーマに移りましょう。内製と外注を比較する小島:私は若い頃にシステム開発は外注すべしと教えられました。その理由は開発需要にあわせて人を雇うことが非常に難しかったからです。専門家が社内には少なくて、外部に仕事を出すことが一般的でした。最近はその考え方が変わってきた気がします。辻:確かにコストが厳しい時代には私も外注化を勧めていましたが、結局中にいる人が、手配屋になってしまうのです。出す仕事の中身はわからないけれどベンダーに仕事を出せる人が増えてしまうわけです。使うという選択肢もありますが、それでも、アジャイル的に仕事を進められる人材確保は急務だなと感じています。年間、内製化を進めていました。よっていろいろなことが実現できて、ユーザーの期待値もどんどん上がって、あれもこれもやろうということになっていきました。その結果、開発サイドの能力の限界を超えてしまったんです。すると、ユーザーの要求はもう受けられませんから、ユーザーは何もやってくれないじゃないかということになり、不満をぶつけられる我々エンジニア側もテンションが下がる、そういう悪いサイクルに入っていきました。小島:ユーザーの期待値の調整ですね。長谷川:エンジニアを管理する立場としても、こうした状況が続くといろいろと投げ出したくなる気分でした。か月でできますという言い方に変わりました。しないと、ユーザーに責められるからです。そこで、ある時、同じ開発案件について、外注から見積もりをとってみました。すると、内製した方が時間がかかるものが出てきたわけです。これはちょっとショックでしたね。誰が作っても同じ結果になるものであれば、外注でもいいでしょう。単純に在庫データを管理するだけなら誰が作っても同じでしょうから、外注はありです。最適な在庫を持つとなったら話は別です。ここは小売業にとって重要なところです、内製化となるでしょう。小島:コモディティ化している機能のように見えるが、こだわりのある部分は自社で作ったほうが良いということですね。IT小島:内製とするか外注とするかの判断基準として、コストとコモディティ化というものが上がりました。位置づけがこの数年間で大きく変わっています。