見出し画像

アジャイル開発の源流とソフトウェア開発手法の発展の系譜

Satoshi | Founder & CEO of Artelligence

話題のアジャイル開発について少し説明したいと思います。「アジャイル開発」と聞くと、アメリカの頭のいい人達が考え出したソフトウェアを開発するための最新メソッドというようなイメージを持たれがちです。でも実際は必ずしもそれだけではないんですよ。じゃあ結局アジャイル開発ってどこから来たの？というお話です。

対象読者：「なんとなく『アジャイル』聞いたことがあるけどもうちょっと詳しく知りたい」人や、「アジャイルは知っているけど過去の歴史をもうちょっと詳しく知りたい」エンジニアの方などを想定しています。

世界のソフトウェア開発の手本となっている「かんばん方式」

まず結論からいうと、ソフトウェア開発の多くの考え方は、「トヨタ」の生産プロセスの影響を大きく受けています。それでは次に具体的にトヨタの生産方式 (Toyota Production Systemと呼ばれます)の何がすごいの？という話になるわけですが、少し過去の歴史を紐解いてみたいと思います。

まずトヨタの生産方式を確立させたのが、1960代にトヨタが採用したかんばん方式だといわれています。商品番号や仕入先などが記載されたかんばんという部材単位のラベルを活用し、商品の利用とかんばんのつけ外しをセットで行うことで、「リアルタイムで必要なものを必要な数だけ最小限生産する」というオペレーションを実現しています。これは「Just In Time」とも呼ばれており、時間効率化の考えの原点として「JIT（ジット）」というあだ名で色々な場面で応用されています。

画像2

そして当時として何がすごかったのかというと、従来はオペレーションの方式で「何を・いつ・どれだけ」などの情報は、 仕掛計画表、運搬計画表、生産指示書、納入指示票といった帳票の形で仕掛担当者が作って現場に指示を出していたのですが、具体的に部品単位で時間を効率化するという発想に全く至っておらず、時間管理がざるだったんですね。リードタイム（特定のオペレーションをこなすのに必要な時間）は十分に考慮されていなかったので、「まぁ概ね間に合えばいいか」というおおざっぱな目標を立ててよしなに調整していくしかなかったわけです。かんばん方式においては、最初から無駄が生まれない仕組みになっているので、常に人が存在せずともかんばんにより最適化が図られていることになります。

この過程でトヨタの生産に関する理論の体系化に多大な貢献をされたのが大野耐一さんというトヨタの元副社長の方で、1978年に「トヨタ生産方式」という名著を記されています。これは10年後の1988年に英語版でも出版され、世界中で読まれています。このトヨタ生産方式は、私がハーバード大学のMBAに留学していた2015年時点でも1年生の必修授業であるオペレーションのケーススタディとして変わらず使われてたので、今なお大きな影響力を与えている方式だと言って差し支えないと思います。

日本組織から生まれた「アジャイル開発」と「スクラム」の原点

1970年代から1980年代の日本の自動車メーカーの勢いは凄まじく、貿易摩擦を起こして米国が日本を目の敵にするほどでした。「なぜ日本の生産方式はこれほどすごいんだ」ということで、多くの米国のビジネススクールや経営者たちが日本のメーカーから学ぼうと必死に調査や研究を続けていったのがこの時代です。1980年代にはMITのジェームズ・P. ウォマック教授をを中心に研究が体系化され、「リーン生産方式」として一般名称として定着していきます。

もう一つ、より広く世界が日本型組織を注目するようになった転機の一つとして、1986年に一橋大学教授の野中郁次郎教授と、ハーバード大学の竹内助教授が発表された「The New Product Development Game」という論文の存在があります。なんと40年近く前の論文ですが、今なおハーバード・ビジネスレビューで紹介されるほどの影響力を持っています。

画像1

この論文では、日本の組織のオペレーション面だけに着目するのではなく、小さなチーム単位で自律的に学び、仕事にあたる形態を「スクラム」と表現しました。組織内のチーム連携が優れている点に着目し「学びを最大化させる」発想が組織に根付いていることを説明しました。

補足：ちなみにアジャイル開発で「カンバン」と「スクラム」が比較されがちですが、前者がよりオペレーションにフォーカスした考えで、後者がよりチーム単位での作業方法やコミュニケーションに重きを置いた考えですので、違う考えというよりは、相互補完的な関係性だと理解しています。

「アジャイルソフトウェア開発宣言」の原点

この論文に着目したのが、Jeff Sutherland、John Scumniotales、Jeff McKennaといった米国のエンジニア経験者を中心としたメンバーで1990年代に10年ほどかけてこのハードウェアの生産におけるアジャイル開発の考え方を、ソフトウェア開発の分野にも応用できないかという研究が進められました。

なぜこの研究を進めていたかというと当時、要件定義を最初の段階で固定化させてしまい建築物のような手法を応用してプロジェクト単位で管理していくウォーターフォールが主流で、その手法だけでは柔軟性に欠け、システム開発が常に長期化し、かつ無駄に肥大化してしまう傾向にあり、大きな問題となっていました。そこで2001年の従来のソフトウェア開発とは大きく異なる手法を提案したあの有名な「アジャイルソフトウェア開発宣言」に繋がっていくわけです。

ただ、日本のメーカーのやり方をそのままソフトウェア開発に応用できるかというと、勿論そんなことは無く、1990年代から2000年代にかけて色々なアジャイル開発手法の試行錯誤が続いていきます。またこの過程でスクラム以外にも、XP（エクストリームプログラミング）、ユーザー機能駆動開発（FDD）、リーンソフトウェア開発(LSD)など色々な開発手法が発展してきたのもこの時期です。

ただ個人的には、最近では、スクラムが最も普及している印象があります。

＜「アジャイルソフトウェア開発宣言」12の原則＞

・要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
・動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
・ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
・意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
・情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
・動くソフトウェアこそが進捗の最も重要な尺度です。
・アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
・技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
・シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
・チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

お読みいただけるとわかるかと思いますが、システム開発における柔軟性や対話・コミュニケーションが価値観として非常に重視されています。逆にいうと、それまでのプロセスが非常にドキュメント偏重だったということの裏返しだともいえるでしょう。

ソフトウェア開発にも生かされるToyota Way

大変ありがたいことに、Ken SchwaberとJeff Sutherlandはそのノウハウを惜しみなく無償公開してくれているので自由に使うことができます。（ぜひガンガン使い倒しましょう）

画像3

ちなみにこの宣言から既に20年以上が経過していますが、これらはソフトウェア開発における「スクラム(Scrum)」や「大規模アジャイル開発(SAFe / LeSS)」といった手法に繋がっています。ただ、最近では大規模アジャイル開発などについてはフレームワークの「商用化」が進んでしまい、資格取得やパートナープログラムの活用により、なぜかあたかもアジャイル開発の手法が誰かが保有しているかのような表現がなされがちで、発案者同士の仲たがいなども起きています。

プロダクト・アドバイザーとして日本でもいくつかの著書で有名なMarty Caganなどはこういった動きを非常に懸念していて、本来のアジャイル開発の価値を棄損しているとして警鐘を鳴らしています。あまり固定的な「フレームワーク」として運用してしまうと、本来のアジャイルの良さだった柔軟性がそもそも失われるじゃないか、というお話です。

アジャイル開発は日本が生み出したもの？

既に色々な分野で改変が進んでおり、やはりその過程で多くの人たちがベストプラクティスの試行錯誤を繰り返してきているもの「ソフトウェアにおけるアジャイル開発は日本が生み出したもの」とまで言い切ってしまうのは、やや言い過ぎかもしれません。とりわけハードウェアの生産で使われていた考え方をソフトウェアの世界に応用しようというのは大きなジャンプがあったはずで、2001年の「アジャイル開発宣言」のようなものも、それを集まって宣言するメンバーの強力なリーダーシップがあってのことだと思っています。

とはいえ、元を辿るとソフトウェアにおけるアジャイル開発で重視される発想の多くは、トヨタ生産方式(TPS)や日本の経営管理において既にあった概念と多くの共通点が見られます。「かんばん」はスクラムでプロダクト(スプリント)バックログ（ログ=部品単位で管理しよう）の考え方の基本になっていますし、「あんどん」もセキュリティシフトレフトなどで頻繁にテストして検証しようという発想に繋がっていきます。何かとマイナスな話が着目されがちですが、アジャイル開発において日本の生産方式が大きく影響を与えている点については、日本人としては誇ってよいのではないかと個人的に思っています。

止まらないアジャイル開発の発展とデュアルトラックアジャイル

一方で、アジャイル開発のプロセスは現在もその発展が終わることなく改善が続けられています。

少し近いものの異なる領域として「デザイン思考」があります。アジャイル開発はエンジニア向けに「ソフトウェアを作る」ためのプロセスだったのですが、これに加えて「顧客側がそのプロダクトが欲しいかどうか」を検証することを取り込みながら開発を進める手法として「デュアルトラックアジャイル」が注目されています。

アジャイル開発の手法が確立していくにつれ、そのプロセスが主にエンジニアだけを想定していることが問題になってきました。デュアルトラックアジャイルでは、「プロダクトを作る」ことと、「そのプロダクトが顧客にとって価値があるものかを検証する」ことを並行して進めていくというものです。これにより、デザインチームとプロダクトチームの乖離を無くして、２チーム間の連携を促進が図られています。

今後も色々な形で開発プロセスはより無駄のない生産的なものになっていくでしょう。大切なことは、そういった考えを、元々の基本と違うとか、あまり新しいものに飛びつくなとか、食わず嫌いせずにガンガン積極的に取り込んでいくことなのではないか、と思っています。

海外メソッド逆輸入のススメ

この記事の発端となったアジャイル開発ってどこから来たの？という問いに戻りたいと思います。

元を辿るとそもそも自動車は18世紀にフランスの発明家によって完成されたとも、ドイツの発明家によって19世紀に完成したともいわれており、更にT型生産方式の量産を実現したのがフォードだと言えるので、全て日本がすごいという話をしたいわけではありません。とはいえ、1960年代から1970年代にかけてのトヨタ生産方式をはじめとす日本の組織がこの分野に与えた影響というのは計り知れないものがあります。それが現在のソフトウェア開発にも生かされているということでもあるので、日本でソフトウェア開発に関わっている方々には、敬意を込めて、誇りをもって私たちの大先輩方が生み出した開発手法でもあるので、今、米国で発展と改良が繰り返されている手法についても、別にナントカマスターみたいな資格なども取る必要などなく物おじせずに逆輸入して利活用してゆきたいと思っています。

残念ながら2000年代以降のソフトウェア開発への応用という面では日本は遅れてしまった感が否めませんが、日本のイノベーションのランキングは上がっているという明るい話もちらほら出てきています。とりわけ実感としてもSaaS (Software as a Service)型といわれる標準的なソフトウェアプロダクトを主たるビジネスにしているスタートアップが大きく成長してきており、最近の日本のキャッチアップのスピードは目覚ましいものがあると思っています。

たかがプロセス、されどプロセス。トヨタが世界一の自動車メーカーになったように、仕組み化されたプロセスは事業をスケールさせる上でアジャイル開発のプロセスは非常に大きな役割を果たすのではないかと思うのです。

テクノロジーの世界は非常に移り変わりが激しいので、今後も色々なアジャイル開発の手法が発展してゆくことを願っていますし、法人研修を展開するアーテリジェンスとしても、私たち自身も常に新しい学びを得る姿勢を忘れずに、最先端のコンセプトをわかりやすく日本の中で広く普及し貢献してゆけるように努力したいと思っています。

ってこちらのツイートに結論が書いてありましたね。おあとがよろしいようで・・・お読みいただき、誠にありがとうございました。

この記事が気に入ったらサポートをしてみませんか？