システム開発を進めるのに「いっぱい人を入れる」のは間違い　一流の人が集まってもトラブル続きの“負の遺産”ができてしまうわけ

どっちもハッピーじゃない受託開発の問題

坂東孝浩氏（以下、坂東）：先ほど「納品が邪魔だよな」と言ったんですけど、たけちゃんももともとITの会社を経営していて、IT業界では「納品が邪魔だよね」って普通に思うことなんですか？

武井浩三氏（以下、武井）：いや、普通ではないですよね。まだまだマイノリティです。基本的には受託開発とか請負とかって言われますけれど。僕らはよく「IT土方」とかって言うんですけど。

坂東：土方ね。

武井：家を建てるとかビルを建てるとかと一緒で、設計図を作って、建物を作って、完成したら引き渡す感じで、システムも引き渡しするんですよね。でも、引き渡しした瞬間に基本的には「もう後のことは知りません」となるんですね。

もちろんメンテナンス契約とかはあったりしますけど、どこまで責任を持つのかというのが、作る側と金を払う側で（話が噛み合わない）。だからしょっちゅうでっかい訴訟があるんですよね。

坂東：そうなんですね。

武井：銀行のシステムとかもそうだし、大手のところは言った・言わないで、「結局依頼したものが納品されなかった。50億円払っちゃいました」って言って訴訟をしているんですけど、結局どっちもハッピーじゃないのが問題だと思っていて。

「納品のない受託開発」は、目線が同じ方向を向くんですよね。作る側も変なやっつけの仕事をすると、後で自分に返ってくるので。だから、いい仕事をしたほうが理にかなっているんですよね。

「ぐっちゃぐちゃなシステム」は負の遺産であり、社会課題である

武井：お客さん側も、利害関係が同じ方向を向いているから安心して任せられるし。いや、本当に……変なシステムを納品されて、それを作り直すコストが発生すると、本当にやばいんですよ。

倉貫義人氏（以下、倉貫）：（笑）。

武井：新しいものをゼロから作ったほうがよっぽど楽なぐらい、ぐっちゃぐちゃなシステムというのは負の遺産なんですよ。だから、これは表から見えない領域なので、なかなか認知されにくいですけど、本当に社会課題だと思いますよ。

坂東：もはや社会課題なんですね。

武井：いや、銀行のシステムとか、しょっちゅう止まっているじゃないですか。

坂東：そう。あれ、なんでああいうふうになるのかなって。一流の人たちが寄ってたかってやっているだろうに。

武井：本当ですよ。銀行のシステムとか大きなトラブルが起こると、これは本当に都市伝説じゃなくて、何人か人が死ぬって言われているんですよね。

坂東：え？　どういうこと？

武井：その責任の重さに耐えかねて。あと過去にあったのが、ちょっと名前は出せないんですけど、大きいそういうシステムが止まっちゃった時に、ユーザーに対して補償しないといけないので、だいたいQUOカードとかを配るんですけど。

坂東：ああ、あるある。

武井：だいたい相場があるんですよね。1件当たり500円とか、収入とか病気とかクリティカルな情報だと2,000円とか。金で換算できるものじゃないけど、金で精算するしかなくて。そういうのが起こると、本当に行方不明者が出たりするんですよね。

倉貫：こわっ。怖い世界。

武井：それぐらい裏側では本当にストレスを抱えているエンジニアたちがいて、マネジャーとかはだいたい現場のせいにするので、現場の人が本当に大変なんですよね。

大規模システムによくある「建造物としてシステムを作る」発想

坂東：なるほどねぇ。建物のようにかちっと決まったものじゃなくて、ソフトウェア、特にサービスとかアプリとかだと、使い始めてからどんどんアップデートとかしていくから、当然建物のようにちょっと修繕費を積み立てておけばいいということじゃないんですね。

倉貫：そうですね。今出てきたような多くの大規模システムって、昔ながらの作り方をしている時のもので、それこそビルを作っていたとか、もっと前で言うなら国家事業でダムを作る時の感じで、「建造物としてシステムを作る」という発想があったんですね。ダムを作るって考えたら、ダムの場合は一回作ったらもう直さないんですね。「ダムをちょっと高くしよう」とか「厚さ、厚みを増やそう」とかないですよね。

坂東：うん、ムリムリ。

倉貫：作った後は直さない代わりに、何十年と耐久年数があり、当然多少のメンテナンスは入るにせよ、それは維持していくことがメインになっているのが建物で。

それを作る時はしっかりと計画を立てて、「どれぐらいの厚みにすると」「どれぐらいの高さにすると」もしくは「どれぐらいのセメントを入れると」というのを事前にしっかりしっかり計画を立てて、その上でその計画を実行できるだけのたくさんの人を入れるんです。

だけど、ダムを設計する人はたくさん人が必要かというと、そうじゃないですよね。

坂東：そうだわ。

倉貫：ダムを作る時には100人の工員さんがいて、一生懸命ダムを作ってくださるかもしれないけど、ダムの設計をする人が100人いたら、100倍速く、100倍いいダムが設計できるのかというと、できないですよね。

一方で、最近の銀行さんはわからないですけど、僕が昔いたシステム会社だと、銀行さんとか大きなシステムを作るとか、たぶんマイナンバーを作るとかもそんな感じだったのかもしれないけど。

ダムを作るみたいに立派な計画を作って、「これだけのものを作ったら、耐久年数はどれぐらいかかるので、そのためにはどういう機能が必要で、あとはたくさん人を入れたら作っていける」と作っちゃうんです。

ソフトウェア開発は「人を入れたら解決するもの」ではない

倉貫：でもポイントが2つあって、1つはダムと違って、使い始めてから直したいことがいっぱい出てくるのがソフトウェアです。直したいことが出てきた時に直すことができるというのが、本来のソフトウェアなんですね。

ダムの形を途中から変えるのはできないけど、アプリの場合は変えられるし、変えていけるからソフトウェアだという話があるのに、先ほどの話のように、どこかのダムを作るみたいにゴールを決めて作り切って「作った」と言って、「あとはみなさん使ってください」だけだとうまくいかないのに、作って終わりにしようとしてしまう。

作る時にダムを設計する人が100人いても揉めるのと一緒で、ソフトウェア1個1個を作る人は、ダムのセメントを埋める人じゃなくて、設計する人だと思ってもらったほうがいいんですね。だとしたら、いっぱい人を入れてもしょうがないんですよ。

実はたくさん人を入れたら解決するものではないというのが、本来のソフトウェア開発だと思うんです。なのに、デジタル庁が「まだまだ人を入れなきゃ」とかって言っているから、ぜひ僕の本を読んでほしいなと思っているんです。

『人が増えても速くならない　～変化を抱擁せよ～』（技術評論社）

（一同笑）

坂東：なるほど。だから建物に例えると……。

倉貫：作り方がまず違う。

坂東：有名な建築家で安藤忠雄というコンクリートの建物を作る人がいますけど、安藤忠雄が10人とか100人とかいれば、100倍いいものが作れるとか速く作れるとかいうことじゃないということですね。

倉貫：たぶん安藤忠雄同士で大喧嘩しますよね。

坂東：いや、元ボクサーだから、めちゃめちゃやり合うでしょうね（笑）。

倉貫：（笑）。

プログラマーの役割は、大工ではなく設計士

坂東：すごくよくわかるな。設計するのはクリエイティブな仕事であり、それは属人的な仕事なんだということですね。

倉貫：そうですね。これもよくシステム開発だと、家を作る時に例えたりするんですけど、施主がいて、設計士がいて、あとは大工さんが作って。「いや、設計士さんみたいな人がいて、プログラマーの人は大工さんですよね」という発想があったりするんですけど、先ほどの話で、「いや、大工さんではないんですよ。プログラマーの人たちがやっているのは、設計士の仕事なんです」と。

「じゃあ大工さんって誰に当たるんですか？」と言われたら、それがコンピュータなんですね。プログラマーの人はコンピュータに対しての指示書を作っているんです。指示書を作る人がいっぱいいたら揉めるので、少ない人数のほうが生産性が出るし、人数がいたとしても、ちゃんと意思疎通ができる人たちでできる。そのほうが良いサイズ感だと思いますね。

坂東：そうかそうか。プログラマーも設計者なんですね。

倉貫：そうです、プログラマーこそが設計者だということです。

坂東：大規模システムとかを作る時は大変ですね。いわゆるクリエイティブな仕事、クリエイター的な仕事の人たちをたくさん抱えないといけなくて、それぞれクリエイティブな仕事をする人たちを、うまくマージしなきゃいけないというイメージですか。

倉貫：これが、「でも本当にマージしなきゃいけないのか？」ということなんですよね。

「大規模なものは大規模に作らなきゃいけない」という常識にとらわれ過ぎている

倉貫：これも本に書かせてもらっているんですけど、例えばAmazonって、今は本屋というよりはAWSという、いろんなインフラを提供している会社になっていますけど、AWSってめちゃくちゃでかいシステムですよね。

坂東：そうですね。

倉貫：だけど、本当にマージしているのかというと、以前はマージせずにいました。今もどうかはわからないですけど、「two-pizza team」と言われているんですね。two-pizza（2枚のピザ）を食べ合えるぐらいのチームにしましょうと。

いっても10人ぐらいか、もっと少ないか。アメリカのピザは大きいからもっと多いかな？　わからないですけど、一桁ぐらいの人数にして、そのチームをたくさん並べて、あとはチーム間で連携しましょうと。

チームで見ているシステムは、一個一個は小さいということですね。小さいシステムを連携させて、大きく動くようにしていくようなこともやっています。なので、本質的に、「本当にでかいものをでかく作る必要があるのか？」というのは、考えたほうがよいところですね。

みんな大規模システム、大規模システムと言うから、「大規模なものは大規模に作らなきゃいけない」という常識にとらわれ過ぎているところはあるのかもなという気はしますね。

坂東：なるほどね。Amazonのように自社のサービスだと、どんどん作りながら、大きくしながらみたいなことができる気がするんですけど、例えば銀行から受託を受けて、何千店舗に一気にドンみたいなことだと、事情が違うのかなという気もしたんですけど、そんなこともないんですか？　ちょっとずつ、アジャイル的に作りながらみたいのが難しそうなイメージがあります。

倉貫：難しいのかどうかは証明できないので、できるんじゃないかなとは思っていますけど。それは、いつか僕らができたら「やれましたね」と言うしかないのかなとは思います。

坂東：なるほどね。じゃあ倉貫さんは、仮にそういう大企業からドサッとシステムを作ってほしいと言われたら、嫌ではないんですね。

倉貫：従来の作り方でドサッと出されたとしたら、それは「その作り方ではうまくいかないので」と言ってお断りしますね。

だけど、僕らが考える作り方で良いというのであれば、OKできる可能性はある。それこそ武井さんと一緒にお仕事をさせてもらっているeumoさんとかも、言ってみたらそんな小さなシステムじゃないんですよ。立派なシステムだし、なんだったら通貨を扱うので、ある意味金融のシステムみたいなものなので。

坂東：間違っては絶対いけないしね。

倉貫：うん、難易度はめちゃくちゃ難しいんですね。でもそれもやれると考えたら、やりようによってはやれるんじゃないかなとは思ってはいますけどね。