アジャイル開発のパイオニアが語る、成功に導くための3つの秘訣

【長瀬嘉秀氏へインタビュー】近年、アジャイル開発が注目され始めているものの、大規模開発ではウォーターフォール型が採用される傾向にあります。その背景には課題があるのでしょうか。今回、日本の開発現場でアジャイル開発が進まなかった原因を探り、これからのアジャイル開発を成功させるためのヒントを伺うべく、「エクストリーム・プログラミング入門(初版、第2版)」など数多くの書籍を翻訳され、日本のアジャイル開発のパイオニアでもある長瀬嘉秀氏にお話を伺いました。

インタビュアー:株式会社CAC Holdings 未来企画本部 池谷、鈴木

1.長瀬様自己紹介

――簡単な自己紹介とアジャイルと出会った経緯を教えてください。

長瀬 嘉秀 氏(以下、長瀬氏) 朝日新聞社の情報システム部で3年勤めた後、自分で会社を起ち上げ、コンサルティング事業に近いことをしていました。その時に「Unixオペレーティングシステム」の開発・製作をしているOSF-Open Software Foundationという開発組織のアジアパシフィック(アジア太平洋地域)のコンサルタントになり、オープンソフトウェアの業界に長く関わってきました。

その経緯から、OMG-Object Management Groupというオブジェクト指向の団体で「オブジェクト指向の設計技法を標準化しよう」という動きが起こった際、日本の代表のひとりとして携わることになりました。このOMGのプロジェクトに参画することによって、オブジェクト指向というものに大きく関わることになったことが、アジャイルに関わることになった最初のきっかけです。

2.日本でこれまでアジャイルが普及してこなかった理由

 ――アジャイルにまつわる日本の開発事情についてお聞かせください。2000年前半頃に日本国内でもアジャイルが提唱され始めたものの、その後10年間以上冬の時代が続いてきたように思えます。開発現場になかなかアジャイルが普及しなかった背景には、どのような理由があるのでしょうか。

長瀬氏 アジャイル(XP)が普及しなかった理由については、日本企業にウォーターフォール型の工程が浸透していたことが大きいと思います。ウォーターフォール型の開発では、『ここでは何をして、次に何を確認して』という細かい段取りをおこなうことが社内の開発規定で決められています。アジャイル開発に切り替えるためには、この開発規定自体を変えないといけません。そのため、開発規定からの切り替えが難しいようです。

開発規模の大きいプロジェクトにアジャイルを適用することも難しいですね。規模の小さい案件であれば、アジャイルが適用されることもありました。しかし、開発規模が大きくなるほど社内規定に縛られる要素が増えるので、アジャイルが適用できないケースも多くなってきます。その点がアジャイルを浸透させることが難しかったポイントです。

―― 欧米は2000年代の早い段階からアジャイルを提唱・活用していて、そちらの開発手法にシフトしていたと思います。なぜ、日本とこれだけの差がついてしまったのでしょうか。

長瀬氏 おそらく、アメリカではウォーターフォールの開発プロセスで失敗しているケースが多かったため、アジャイルに切り替えようという意識が強かったと考えられます。また、欧米の場合、ウォーターフォール開発に始まり、1990年代にはオブジェクト指向を用いたイテレーティブ(繰り返し)型の開発が主流になりました。イテレーティブは、アジャイルとウォーターフォールの中間の開発手法になりますね。

―― いわゆる、RUP(Rational Unified Process)という手法ですね。

長瀬氏 そうですね。RUPを主流としつつ、段階的にアジャイルに近づいた形です。日本の場合は、ウォーターフォールが浸透していたため、イテレーティブは馴染まなかったみたいですね。そのため、イテレーティブの先のアジャイルにも結び付かなかった、ということだと思います。

要するに、アメリカはウォーターフォールで失敗していたのですが、日本の場合はウォーターフォールで失敗しないような仕組みを作り上げていた。「失敗しないで利益を出しているのに、アジャイルに変える必要があるのか?」という意識があったことが、アジャイルが馴染まなかった背景にあったことだと思いますね。

―― アジャイルが浸透しなかったもう一つの理由が、オブジェクト指向の普及が進まなかったことにあると思います。知識としてはオブジェクト指向を知っているけど、活用できているプロジェクトは意外と少ないのではないでしょうか。

長瀬氏 そうですね。「オブジェクト指向」が日本で定着しなかった要因として、日本ではデータ中心設計(DOA)の意識が強かったことが考えられます。日本はデータベースを先に作り、その後にプログラムを作りましょう、という考え方が根底にあるので、無理に「オブジェクト指向」を取り入れなくてもよかったのです。日本では、そうした作り方をどの企業も行っていて、とくに大きなシステム開発などは全てDOAが行われていました。そのため、オブジェクト指向とは根本的に考え方が合いませんでした。そもそも、DOAとオブジェクト指向という開発手順自体が違うことが、アジャイルが馴染まなかった理由だと思います。

3.近年アジャイルが日本で注目を集めるようになった背景、理由、日本の企業動向

―― ここ数年は、エンタープライズ系の企業でもアジャイルという言葉が一般化してきているように思えます。なぜ、このタイミングでアジャイルが脚光を浴びる時代になっているのでしょうか。

長瀬氏 色々な企業様と話をさせていただいている限り、「そろそろ新しい開発手法を取り入れなければいけない」という気持ちが強いようです。「ウォーターフォール」だけで開発をこのまま進めていていいのか、と。たとえば、それまではオンプレミスでしか構築できなかったものが、クラウドでも構築可能になったりしていますね。スマートフォンのアプリケーションも主役になりつつあります。そのようなITの技術が変わってきていることが要因として大きいのではないでしょうか。

一方で、これまでアジャイルを取り組んだことのない人達が、アジャイルを取り入れようとしたときには多くの導入課題に直面するため、すぐには取り入れることができない、という状態でもあります。

―― 日本企業がアジャイルを取り入れようとしたときにぶつかる「典型的な課題」などありますでしょうか。

長瀬氏 まずユーザーに近いところでは、 要件を決める場面。「要件を誰の権限で決めるのか」というところで躓くことが課題です。SIer企業を絡めた従来の開発の流れでは、要件定義書が出来ている状態から始まります。一方、アジャイルでは、「プロダクトオーナー」という責任者が置かれ、その方が要件を決めてプロジェクトを動かしていきます。だからこそ、「要件の決定」「責任の所在」が難しいといえます。

2つ目の課題は、開発の仕組み(体制)が違うことです。日本の場合、SIerがユーザー企業の情シス(情報システム部)、もしくは情シス子会社が必要とするシステムを開発します。そして、開発が上手くいかなったときにはSIerの責任になります。一方、アジャイルの開発に成功しているアメリカでは、ユーザー企業が直接エンジニアを雇って、開発を進める流れが主流です。アメリカにSIerと呼ばれる存在がいないことは、日本との大きな違いでしょう。

―― ユーザー企業がエンジニアを雇うことは日本ではなかなかありませんね。

長瀬氏 その点が3つ目の課題に関係しています。欧米の場合、ITエンジニアになる方は、大学でソフトウェア工学を学んでいた方が多い傾向にあります。プロジェクト指向なども大学で学んだうえで、エンジニアとしての活動を始めます。しかし、日本のエンジニアは大学などで専門的な勉強をおこなわず、入社をしてからITの勉強を開始して、エンジニアになる場合が多い。そのため、日本のITエンジニアは文系出身者が半分くらいを占めています。

―― 教育の場の違いも大きいですよね。学生時代にプログラムを書いた経験がない新入社員が多いものの、企業も研修や教育にそこまで時間をかけられない、というジレンマもあるように思えます。

長瀬氏 大学での教育基盤が違うことを踏まえても、日本企業と欧米型のアジャイルは相性が良くないと感じますね。アメリカの企業が何故、アジャイル開発をスムーズにできているかというと、大学でITエンジニアの教育が済んでいるから、といえます。その分、アメリカはアジャイルとの相性が良いとも考えられますね。

一方で、従来のDOAの考え方によってデータベースと設計に強みを持つ方はたくさんいらっしゃると思います。そこが日本のエンジニアの強みですね。その強みを活かして、今後アジャイル開発をどう進めていくか、という議論が大切だと思います。

ここで大切なのは、「欧米型のアジャイル」と「日本でこれから構築されるアジャイル」は違うものではないか、という視点。日本のエンジニアより欧米のエンジニアの方が優れている、という話を耳にすることもありますが、そのようなことはないと思います。たとえば、品質は日本の強みといえますよね。品質のように日本のエンジニアが優れた点がわかれば、日本でおこなうアジャイルの形も見えてくるのではないかと思います。

―― 品質はとくに日本が強みとしている部分ではありますよね。アジャイルで品質を担保する開発手法が見つかればよいですよね。

長瀬氏 日本のソフトウェア開発は少なくとも「バグがあってはならない」を大前提で、全部修正してきちんと動くようにしてから提供が基本とされています。そのため、日本はソフトウェアの品質は海外と比較してかなり進んでいるはず。その評価は欧米の彼らから見ても同じ評価を得ているので、品質はもちろん強みになりますよね。

―― 日本の強みを活かし、日本独自のアジャイル開発のスタイルを構築するためには、何が必要でしょうか。

長瀬氏 まずは、顧客との合意形成。品質のためには費用と時間が必要なので、時間優先なのか品質優先なのか、を選んでいただく点は重要です。「品質が高いのは当たり前」という企業さんもいらっしゃいますが、その品質の担保には、やはり時間とお金が必要です。お互いに譲れない線の合意をしなければ、お互いに納得できない結果になってしまうと思います。

続いて、品質担保の仕組みです。アジャイルの開発手法を取り入れながら、品質を今まで通りの水準に保つための仕組みを考えなければなりません。たとえば、そこをオフショアなどで海外に任せてしまうと、日本のユーザー企業やSIerが期待するものは仕上がらないでしょう。

そして、自社のエンジニアのスキルアップも大切です。同時に、従来手法のウォーターフォール開発で担保している品質をアジャイルでも担保できる体制や仕組みを作ることが必要です。ここは多くの企業が試行錯誤している部分だと思うので、実現できれば差別化のポイントになるかと思います。品質担保の仕組など差別化のポイントを早くかたちにした企業さんがアジャイル開発でリードできるのではないかと思います。

4.アジャイルでのオフショア活用

―― 我々もSIerで、外国人の方の採用もしていたりしますが、外国人の方の場合、十分な教育がなされているので、技術に関しては即戦力として現場に配属できますよね。

長瀬氏 エンジニアのスキルという意味だと、海外の方達は基本、大学で専門的な学習をしているので、プログラムはある程度出来るという認識ですね。そのため、日本人のように入社前に必要な技術が無く、入社後に学びますという新人エンジニアと比べると、相当な差がでますね。

ただ、もちろん日本の状況を海外のエンジニアの方は、初めは良く知りません。また、海外のエンジニアはプログラマとしての能力は高いかもしれませんが、管理や品質、テストに関してはまだ知識が浅いことも多いので、担当できることを見定める必要はあります。

―― 海外のエンジニアが身につけられていて、日本のエンジニアが逆に習得できていないスキル・技術・マインドは、たとえば具体的にはどういったものが挙げられますか?

長瀬氏 プログラミング技術でみると「オブジェクト指向」の設計をしてプログラムを作るというものがあります。これに関しては、日本の学生に限らず、日本のプログラマ全体として勉強する機会がないという問題がありますし、なかなか経験する機会がないことが原因ですね。海外の学生の場合は、これを専門的に大学で勉強しているので、大学の中で「指定された方法で設計し、プログラムを作る」というのは必ず大学内で経験します。日本の場合は、初心者のエンジニアになった後、とにかく(設計書の通り)やることをベタ打ちで書き込んで、動かして終わりという状態がよく見受けられますね。

5.最新動向

―― 最近の海外・欧米でのアジャイル開発の最新動向や流行っているものはありますか?

長瀬氏 最近は「ペアプログラミング」と言いますが、「モブプログラミング」という開発の進め方があります。2人で作るのではなく、チームでプログラミングをするようなイメージで、たとえば5人くらいで集まってプログラムを組むといったことをやります。それをやる意味としては、プログラムを作る上で大事なことが「アーキテクチャ」だったり、「フレームワーク」だったり、プログラミングに付随しているものが結構あります。これを1人ひとりが別々に理解をするというのが難しいので、全員で開発過程を見ながら、こういう風に作っていって設計意図はこうで…ということを伝えながらプログラムを組みます。このセッションを1時間行い、その後全員を解散させて、それぞれプログラム開発をさせるといった開発の方法になります。

――スプリントの最初の部分だけを実行するイメージでしょうか?

長瀬氏 その通りです。それを適宜おこなうイメージです。プログラミングの時に主に行っている方法ですが、プログラミングだけではなく、プロダクトオーナーがバックログを議論する時にもその手法を用いるなど、モブプログラミングを使った開発に変化しつつあります。

6.今後の日本のアジャイルの展望

――これからアジャイル(XP)の必要性が増していく中で、ユーザー企業やSI企業は何をすべきか、簡単に教えていただけますでしょうか?

長瀬氏 ユーザー企業さんに関しては、アジャイルを採用した時に今までの開発の進行と、どう変化をするのかをきちんと理解しておいた方が良いです。たとえば一番大きな変化は、ウォーターフォールで進めていたころはSIerにシステム開発をお願いするので、責任はSIerにありました。

これがアジャイルに転換する場合は、プロジェクトのコントロール権はユーザー企業側が持っているので、失敗した場合の責任は自分たちの責任となることを理解しないといけません。そこを理解していく会社が、アジャイル開発環境に適応していけるのだと思います。

もう一つ、ユーザー企業さんとしては、自分たちで、要件を出していってそれを何なのかキチンと説明をしなければならないところが変わります。従来の手法通りのSIerに丸投げということができなくなるので、そこを理解する必要があります。当然、アジャイルなので、2週間に1度など、モノができあがってくるのでリスクヘッジが出来るというメリットはあることも理解しておくことも必要かと思います。

欧米企業はアジャイル開発をシステム開発だけに使用しているわけではなく、企業全体の仕組みの部分、商品企画もすべてアジャイルの考え方を採用しているヨーロッパの企業なども多いので、そういった取り組みも良いかもしれません。

【取材後記】
日本型のアジャイル開発を進めていくためには、「プロジェクト管理」や「品質担保の仕組みの構築」など、管理手法・ルールの確立が必要になります。また、アジャイル開発に必要な経験・スキルを保有する適切な人材も重要な要素ということが分かりました。長瀬さん、お忙しいところありがとうございました。

おすすめ記事