現在、クラウドを取り巻く状況は一気に進み、少し前まで「これから」の取り組みとして語られることも多かったクラウド化の取り組みは、「今やらなければならないこと」として語られるようになってきたように思います。しかし、そのためにこれから何にどう取り組めばよいのでしょう、あるいはそもそも、クラウド化の流れは今どういう状況なのでしょう。

そこで今回、セゾン情報システムズのCTOであり、またテクノベーションセンター長である小野 和俊に、クラウド時代に向けた変革の取り組みを踏まえて、クラウドの「今」と「これから」について、クラウド化が進む今後「何に取り組むべき」なのか伺います。

前回：クラウドが当たり前になった時代に起こりつつあること

前回は失敗せずに「クラウドへ移行」するにはどうしたらいいかについて話を伺いました。

ここまで、まずクラウドを検討する時代になり、システムの在り方にも変化が求められるようになったことを伺ってきました。

次に、クラウド時代のシステム開発について話を伺いたいと思います。ビジネス環境の変化に合わせて、業務システムの開発にも、これまでになく速度感や柔軟さが求められるようになってきました。

システムをクラウドに変える話に続いて、開発をどう変えなければいけないのか、またどうやって変えるのかについて、話を伺いたいと思います。

開発合宿で、クラウド時代の速度を「体感」する

この間、開発合宿をやったんですよ。セゾン情報でHULFT部門も含めて各部門から人を出してもらって、「クラウド×アジャイル」というようなテーマで。

今までの日本の業務システムの開発では、例えば、システムを作って欲しい人たちがシステムの企画をして、要件定義して、外部設計、内部設計、詳細設計と下ってきてやっとコードを書く、というようなやり方が多かったわけです。あるいは、SIのプライムベンダーが下請けに出して、それを孫請けに出して、開発する人は外から呼んだ人で・・というように、企画をする人とコードを書く人の距離が遠かったわけです。間にいろいろなプロセスがあり、間に人も会社もたくさん入る。

そしてそれが当たり前で、業務のシステム開発とは、そういうものだと思われていたところもあります。

一方で新しい取り組みでは、例えばリーンスタートアップとか、デザインシンキング、XP、スクラム、これらに共通しているのは、企画と実装の距離が近いことだと思うんですね。

今までは、そもそも仕様を決めるためのミーティングとか、そのための事前ミーティングとか、これまでは重厚なプロセスが「当たり前」だったところもあったと思います。しかし、開発合宿をすると、そういう「これまでの当たり前とは異なる環境」を作ることができる。

利用者がこういうものを使いたい、こういうものを作って欲しいという要望と、作る人までの「間」を全部一気に抜いてしまう体験ができます。つまり、「こういうのが要るんだよね」と言っている人と、コードを書く人が急に隣になるわけです。隣になるし、一緒に寝泊まりして、卓球大会までする。今までのやり方だとありえなかった状況です。そうすると、思いついてから作るまでの時間はこんなに短くできるんだ、ということが体験で理解できる。まさに「Practice over Theory」で、体験してみるとすぐわかる。

昔からのやり方にも、新しいやり方にも長所があると思うのですが、確かに「現代のIT」が本来備える速度感や柔軟性を理解していないと、何と何をトレードオフしているのかわからないですよね。「これが当たり前」だと思っていただけだった、というのは、わかってしまいますね。

クラウドの時代と速度の時代

これからのシステムの作り方は、こういう「速度感」の方を重視した作り方が多くなってゆくんじゃないかと思うんですね。

クラウドがこれをさらに加速させているところもあります。例えば、インフラ系の環境を作る必要があるとき、従来だと、データベースをダウンロードしてインストールしてセットアップして、となるとそれだけで時間がかかってしまう。しかしクラウドなら、あっという間に必要なリソースを用意できる。

クラウド時代の開発は、これまでと比べると、使う側と作る側の距離を一気に縮めて、早いサイクルで仮説を作ってみての試行錯誤をするようなことが多くなるはずです。「こういうのはどうだろう」「こういう感じではないんだよね」「じゃあ直そう」というサイクルを回してどんどん試すやり方です。技術的にも例えばAWSなら、RDBが必要になったら、Amazon RDSをさっと借りて使って試せるし、データベースが100台必要でも、すぐに用意して試せる。DWHを試してみたいならAmazon Redshiftですぐ試せる。試してダメならすぐに使うのをやめられる。

出来てみてから、これは違う、みたいなことを避けたいときにはクラウドが向いているし、クラウドがそういうやり方を後押ししている。どういうシステムをどういう作り方で作るか、どういうインフラを使うかどうか資料を作って会議室で時間をかけて検討すると、そもそもスタートする前にすごく時間がかかりますが、クラウドならすぐ借りてすぐ試してすぐ結論を出せる。

システムを求めている側と作る側の距離を縮めて、アジャイルでスピーディーにやろう、というときにクラウドは凄く向いているし、逆にクラウドがあるからそういう開発がどんどん進んでいるようなところもある。

クラウドの「圧倒的な速さ」といえば「kintone」を使った業務システムの開発で、お客さんにリアルタイムで作ったものを見せて相談しながらシステム開発をする取り組みが知られていますし、内製化の取り組みがなされるようなってきたのも、速度感が求められるのに開発に時間がかかる過ぎるので、担当者が自分自身で対応するしかなかった、というような話も聞きます。

プログラマがしっかりコードを書くようなやり方でも、システムを作って欲しい人に直接話を聞いて、15分くらいでプロトタイプを作って、すぐに作って見てもらうこともできる。そして、その場でコメントをもらってすぐ修正して、それが思った通りの修正なのかもフィードバックをもらうことができる。

料理をしたことのない人のレシピ

中島聡という方がブログで「ソフトウェアの仕様書は料理のレシピに似ている」という記事で、「自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない」と言っています。

大事な恋人とのディナーとか家族の大事な誕生日に、料理をほとんどしたことのない人がマスターシェフをやっている店には行かないですよね。しかし、日本のSIではなぜか、ほとんどソフトウェアを書いたことのない人が仕様書を書くことがある、そして業務を預けて組織の命運を託すはずのITシステムの開発を、料理をしたことのないシェフが書いたレシピに託している。

そして、システムを発注するお客さんも、指示は出しているけれども作ったことはないし作れないので、お客さんもわからない。作る力がSI側にもないし、お客さん側にもない、孫請けぐらいにしかない。

作れないから、例えばクラウドを使ってすぐ作って試すようなやり方も難しくなる。作り方が解らない人が設計したシステムを作るから、望ましくない設計をしてしまっていて、開発速度を落としたりメンテナンス性を落としたりしている。そのため変えたいときも修正が重くなったり遅くなったりする。それが極端に目立ってきた。

隣の席にできる人がいたらこんなに早くできるのに、それを知らない。ドキュメントを書いてシステムを作って、作ってから思った通りではない必要なシステムとはどうも違うと言っている間に、何十回も何百回も作って試せるかもしれないのに。

昔は自分たちで作っていた

このやり方は、よく考えると、昔からそうだったわけではないんですよね。最初は自分たちで作っていたはずなんです。

でも、開発するシステムの規模をスケールさせていこう、となったときに、多重下請けにしてビジネスパートナーさんの比率を上げて、案件規模を上げていくんだ、という力学というかプレッシャーが経営から働いてそうなっただけで、ずっとそうだったわけじゃないはずです。

そういうやり方にも良いところはあるわけです。ただ、もともと自分で作っていた人が、スケールさせるために外部のリソースを使っていたのが、いつの間にか、10年ぐらい前からは新人でいきなり入って、作る経験をきちんと経ずに、PMの真似事をするようなことになってきた。

そうすると、自分たちで作ったことがないから解るわけがない。話がもう変わってしまったわけです。コードを書いている現場の人からすると解らないことをする人になってしまい、お客さんにも組織の上にも怒られて現場との板挟みになる、みたいなのが業界構造として出来てしまっていると思います。

外製が前提になってしまったので、ちょっと何かをするだけでも下請け孫請けを動かさないといけなくなります。間でマージンを取る人が入ってしまうのですぐに二百万円三百万円になってしまうし、その都度、時間もかかってしまいます。そういうのはお客さんもおかしいと気づき始めたし、現実問題として、事業に求められるスピードにも対応できなくなってきたと。