ファイル転送、データ連携ならHULFT

クラウド時代の今とこれから クラウドが当たり前になった時代に起こりつつあること

第3回

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

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

PROFILE

小野 和俊

セゾン情報システムズ CTO・テクノベーションセンター長
アプレッソ 代表取締役

  • 肩書と所属はインタビュー時点のものです

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

デジタルトラスフォーメーションの時代

MITメディアラボ所長の伊藤穣一さんの言葉に「Compass over Maps」というのがあります。インターネット登場後(After Internet時代)に取るべき行動様式が大きく変わったと言っています。

昔って、地図を書いたり詳細に計画を立てて、それに従って生きるとか、企業がどっちに向かうかを定めていた。先輩の経験や先人の体験を踏襲して、しっかり実践してゆくことが成功への近道であると、そういうのがよしとされる時代があったわけですよね。

しかし、今では、世の中全体の変化の速度があまりにも速くなりすぎて不確実性が高くなってしまいました。予測不可能性が高まったので、地図を書いている間に地形がそもそも変わってしまう。今でも地図や計画の意味がなくなったわけではないのだけれど、しかし、地図を書くことが役に立たない場面が増えてきてしまいました。時代が変わってしまったわけです。

伊藤穣一さんは、きちんと計画と立てることが難しくなった例として、100万円の案件に出資するかどうか300万円かけて確認しているようなおかしなことがある、というようなことを本で書いていますね。そういう状況では、従来は良い習慣だったとしても、まず地図を書いてから行動するやり方は合理性を失ってしまいますね。

地図を書くやり方がうまく行かなくなったからといって、その代わりに思考停止するとか、ただ考えないわけにはいきません。今度は、コンパスが向いている方向を頼りに進むやり方の時代になりました。その結果、これまでの能力に代わり、今向いている方向が良いのかどうか、その先に何があるのか、この先には崖があるんじゃないかとか、金脈があるんじゃないかとか、そういう未来予測能力が今までよりも求められるようになりました。

お客さん側での内製化が進んでいるのも、業界構造がいびつだということだけではなくて、システムの開発を丸投げするような今までのやり方は地図を書く時代のやり方なので、今の時代の事業が求めるスピードや柔軟性に対応するため、つまりコンパスの時代に備えるための積極的理由もあると思います。

この時代の変化が最初に現れたのは他ならないソフトウェア開発で、いわゆる「アジャイル」が生まれた「アジャイルソフトウェア宣言」(http://agilemanifesto.org/iso/ja/manifesto.html)が2001年に出たというのも、極めてタイミングが納得できるのですね。インターネットが爆発的に普及した95年くらいから「なんかこのやり方おかしいよね」という違和感が芽生えて、その違和感が結実したのがアジャイルソフトウェア宣言ではないかと。

そして今は、ソフトウェア開発だけでなく全産業に同じ問題意識と変化を求められていると。

再度「スキルセット」と「マインドセット」

時代の大きな流れが変わったことは、デジタルトランスフォーメーションという言葉が広く聞かれるように、もう今となっては空気感として明らかになってきました。しかし、やはり、そうは言ってもなかなか変わることは難しいわけです。それに、無理に変えるといろいろ良くないことも起こります。

ここでも、「マインドセット」は思い切って変えないといけない、でも「スキルセット」は慎重かつ着実に変えよう、というやり方が必要になりますね。

スキルセットはすぐに変われませんが、マインドセットは変われるし、まず変わる必要があります。

そこで開発合宿をして、作ってもらいたい人と開発者の間を取り払って、クラウドの能力を活用して、現在のITで本当に何ができるかを体験してもらったわけですね。従来のやり方とは全く違う世界がある、ということが体感で理解できます。まさに「Practice over Theory(理論よりも実践を)」です。

今までのやり方をすべて捨てる必要があるわけではありません。「アジャイルソフトウェア宣言」でも「左記のことがら(従来のやり方)に価値があることを認めながらも、私たちは右記のことがら(新しいやり方)により価値をおく」とあります。これからも「地図」や「計画」は必要ですが、でも時代の流れは「コンパス」です。

マインドセットが変わると、コンパスが変わるわけですね。開発合宿をしても、そんなに簡単にスキルセットは変わらなかったかもしれないけれど、ちゃんと時代に合わせてコンパスは磨かれている。

新しいやり方を実際に試してみれば、新しいやり方を活用して取り組んでいる企業がどんな凄いことをしているかは見えてくる。今までのやり方を続けていて、そういう企業に勝てるのか。なぜクラウドなのか、なぜ開発のやり方を変えるのか、なぜ丸投げではなく自社でITを理解しなければいけないのか。マインドセットが変われば、変わらないといけないことは自ずから解ってきます。

Change Location

Are you visiting HULFT.com (Japanese language) outside Japan ?
When connecting "HULFT" to Japan from overseas, please select "HULFT8".

日本国外からHULFT.com(日本語)にアクセスされようとしています。
海外から日本の「HULFT」と接続する製品をお探しの場合、「HULFT8」をお選びください。