オルタナティブ・ブログ > 古参技術屋の見聞考察備忘録 >

アジャイルや機械学習、リーンシックスシグマなど、日々の仕事の中で見て聞いて感じた事を書き留めています。

アジャイル開発の次はやっぱり・・・

»

前々回の投稿「アジャイル開発のポリティカル・コレクトネス」では、"アジャイル開発に対して疑問を持ち始めた企業がアジャイル開発から撤退を始めたようだ"、というような内容を書きました。そして前回の投稿「アジャイル開発に対するいくつかの反論」では、"アジャイル開発はウェブベースのアプリケーションには最適だけれど、他のアプリケーション(プラットフォーム系やファームウェア)ではROI(投資対効果)がどんどん落ちてくる"とし、その理由を個人的な経験をもとに書きました。

ではアジャイル開発の次は一体何が来るのでしょうか。今回はそれについて以下の内容を独善的に書いてみたいと思います。

  1. 純粋なウォーターフォール開発と純粋なアジャイル開発は?
  2. アジャイル開発の発展形へ
  3. アジャイル開発のカスタマイズへ
  4. リーン開発へ
  5. FastWorks(リーン・スタートアップへ)
  6. Quality4.0(デジタル化)へ

個人的には降順(6から1へ)が希望する順番です(希望であって可能性ではありません)。

1. 純粋なウォーターフォール開発と純粋なアジャイル開発は?

純粋なウォーターフォール開発や純粋なアジャイル開発は昔から脈々と続いてきたので、今後も無くなることはないと思います。

最適なツールを最適な時に最適な方法で使うことが一番であるように、純粋なウォーターフォール開発や純粋なアジャイル開発も、相性の良いアプリケーションを選んで今後も使われ続けることでしょう。

ただ開発対象とするアプリケーションがどんどん変化しているので、同じ開発手法に留まることは危険かもしれません。企業の成長目標や業界の動向などを考えて、5年先、10年先を見据えた新しい開発手法の導入が増々求めらるようになると思います。

2. アジャイル開発の発展形へ

アジャイル開発の発展形はエンタープライズ・アジャイルと言われるものです。エンタープライズ・アジャイルには大きく二つの流れがあって、一つはスケールド・アジャイル・フレームワーク(SAFe: Scaled Agile Framework)、もうひとつはディシプリンド・アジャイル・デリバリー(DAD: Disciplined Agile Delivery)です。

もし今現在、組織の中のすべてのチームがアジャイル開発に熟練しており、今後すべてのチームを企業規模(人事や経理も含む)でひとつの開発フレームワークで統一したいというのであれば、エンタープライズ・アジャイルに移行することになるでしょう。

しかし、僕はSAFeに携わっているので毎日肌身で感じているのですが、SAFeは結構"しんどい"です。アジャイル開発に熟練していない組織がいきなりSAFeを採用しようものなら、そのうち組織に危機が訪れるかもしれません。歩けもしないのに、いきなりゴールのない長距離リレー競争で走らされるようなものだからです。SAFeなどのエンタープライズ・アジャイルへの移行は、強い動機と細心の計画、十分な準備が必要になります。

3. アジャイル開発のカスタマイズへ

前回の投稿では、アジャイルソフトウェア開発宣言アジャイル宣言の背後にある原則を「表面的」かつ「額面通り」に受け取って反論を試みました。反論の矛先はアジャイル開発のポリティカル・コレクトネス原理主義者たちに向かっていました。

一方で僕は、アジャイル開発の「根本思想」はもっと深くて別のところにあると信じています。

例えば原則の一つ「要求の変更はたとえ開発の後期であっても歓迎します。」について、原理主義者は「いつでも変更に応じなくてはならない」と言うかもしれませんが、僕は「納期の遅延やコストの上昇、リスクなど、その変更が顧客に与える影響を正確に見積もって、それでも顧客が納得すればその変更を歓迎するし、そうでなければ断った方が良い」と考えます。

そしてアジャイル開発の「表面的」な理解ではなく、その「根本思想」を理解すれば、アジャイル開発を状況に合わせて大いにカスタマイズしても良いと思っています。今後はきっとその方向に進んで行くはずです。

開発対象、開発サイクル、組織文化、地理的状況、顧客の要望などに応じた、様々な違ったタイプのアジャイル開発があっても良いではありませんか。(たとえ原理主義者たちが何と言おうと)

4. リーン開発へ

「アジャイル開発ってリーンじゃなかったの?」と思う人がいるかもしれませんが、本物のリーンとは違います。アジャイル開発が言っているものは「リーン・アジャイル」であって、トヨタ生産システム(TPS: Toyota Production System)を源流とするリーンとは"全く"と言って良いほど違います。(ちなみに次に述べるリーン・スタートアップも、本物のリーンとは違います)

TPSを研究したJames Womak氏らが、1996年に"Lean Thinking"という本を出版することでリーンが世界中に広まりました。主に製造業に大きなインパクトを与えたのですが、それと同時に「リーン開発」という分野が生まれました。本物のリーン(TPS)の原理や思想に基づいたリーン製品開発やリーン・ソフトウェア開発などの研究が始まり、現在でも続いています。

そして源流も内容も全く違うリーン・アジャイルが見直される今、逆に本物のリーンを源流とするリーン製品開発やリーン・ソフトウェア開発に注目が集まってきています。それだけではなく、アジャイル開発の次に来るものとして、リーン製品開発やリーン・ソフトウェア開発が有力候補として挙がっています。

僕はこのTPSを源流とする本物のリーンは非常に優れていると常々感じているだけではなく、日本人として、それが日本から生まれたことに大きな誇りを持っています。また日本人だからこそリーンを理解できる強みも感じています。さらに日本中の多くの開発組織がリーン開発を使えば、もしかしたら日本が再び世界の表舞台に戻れるのではないかと、夢見たりしています。

5. FastWorks(リーン・スタートアップ)

FastWorksはGEが使っているリーン・スタートアップ手法を基にした開発手法の名前です。

2017年頃、「GEがリーン・スタートアップ手法を使ってガスタービンを開発した」という記事を初めて読んだ時は、「はぁ?リーン・スタートアップでガスタービン??」と思わずのけぞって驚きました。というのは、僕はそれまでリーン・スタートアップはアプリ開発ベンチャー企業が使うお手軽な開発手法に過ぎないと思っていたからです。それが巨大なガスタービンとは、GEは一体何を考えているのでしょうか。

GEはその手法にFastWorksという名前を付け、以来僕はその動向を探っています。そしてFastWorksを知れば知るほど、「これは行ける!」と思うようになりました。またリーン・スタートアップの思想を理解すればするほど、リーン・スタートアップはとても応用の効く開発手法だということが分かってきました(GEがFastWorksを例として示してくれた)。

アジャイル開発の次に来るものとして、僕はFastWorks的なアプローチが増えてくるのではないかと思います。特に開発対象がソフトウェア、ファームウェア、ハードウェアなどで構成される複雑なもので、開発期間が長く、開発費用が高いものならば、なおさらのことです。

6. Quality4.0(デジタル化)へ

例えば、スマートフォンから開発の進捗具合を更新した瞬間に、人工知能(AI)が開発特性や過去の開発パターンから判断して、開発納期や生産計画、マーケティング計画などを自動変更し、さらには品質問題や開発リスクを未然に防ぐための対策(ソリューション)を自動的に施してくれるとしたら、素晴らしいと思いませんか?

IoTや機械学習(ML)、人工知能(AI)の技術が進めば、きっと将来の開発手法も変わってくるはずです。それがどのようなものになるのかは分かりませんが、今のところ、Quality4.0がそれに近いコンセプトを示してくれています。

Quality4.0は、品質やリソース、技術、マネジメントの面から、今話題のインダストリー4.0を支えるものとして生まれてきたコンセプトです。一言で言えば、企業がデジタル化(DX: Digital Transformation)されて各部署がデータとソフトウェアとIoTで結ばれれば(Connected Enterprise)、品質管理、生産管理、製品開発、人材開発など、これまでの仕事のやり方そのものが変わるだろう、というものです。

まだQuality4.0のはっきりとした定義はありませんが、それでもLNS Researchは素晴らしガイドラインをすでに提示してくれています。以下はLNS Researchの資料から借用したものです。

Quality.jpg

円の中心部の青い所は現在の我々がいるところです。DXが進みConnected Enterpriseの構築が進むと、外側の緑色の方へ広がっていきます。Quality4.0(外側の緑色)では多くの部署や多くの機能が繋がり、ビックデータやAIの力を借りて、多くのことが瞬時に行われるようになります。

製品開発(Development)はManagement Systemの中(ピザの切れ端)にあります。その部分を拡大したものが、中央の四角です。アジャイル開発もSAFeも人の"調和"に頼ったアナログ的な開発手法なので、まさにDevelopmentの下の青い所のProcess Harmonizationに当てはまります。Quality4.0に近づくためにはDXを進めて、上の緑色のところに行く必要があります。

僕の非常に限られた知識の中では、オラクルのPrimaveraP6が少し先を進んでいるような気がします。

5年後、10年後には、もっとConnected Enterprise/Quality4.0に近づいた世界が実現されていると思います。今はアナログ的かつ俗人的で、人の調和(Harmonization)に頼ったアジャイル開発が主流でも、これからはデジタル化された新しい開発手法に移り変わっていくでしょう。

Comment(0)

コメント

コメントを投稿する