DX成功のカギをにぎる「アジャイル開発」。手探りで取り組みはじめている企業が増えていますが…うまくいかない、エンジニア側とケンカになってしまうという話、よく聞きます。
今日は、そんな症状に非常に効き目がよい本をご紹介します。
『エンジニアリング組織論への招待 著者：広井大地 出版社：技術評論社』
この本を読むと「アジャイル開発手法だけ取り入れてもダメ」で、まさに組織全体を作り変えなければいけないことがよく理解できます。
なぜダメなのか。それは、そもそもITエンジニアとビジネスマンはまったく違う生き物だからです。なぜ違う生き物なのか。それは、そもそもITエンジニアという職業が産まれるに至ったルーツが、ビジネスマンのそれとはまったく違うものだからです。
そのようなルーツや、具体的な解決方法についてくわしく網羅されている一冊です。ご興味いただけるよう、ここではポイントだけかみくだいてご紹介します。
アジャイルとは？(カンタンなおさらい)
アジャイル開発とは？の詳細はググるとたくさん出てきます。開発手法の詳細を知りたい方は他ページをご覧いただいたあと、戻ってきていただくとして…
こちらでは、そのアジャイル開発がなぜうまくいかないのか (なぜエンジニアから「アジャイル開発の意味わかってない」と言われてしまうのか) について、本書から得られたポイントをお伝えしていきます。結論、アジャイル開発の「手法だけ」取り入れるのは、人間に鳥の心臓を移植手術するようなもので、うまくいかないのです。
アジャイル開発とは、カンタンに言えば「顧客とエンジニアが、開発・相談を繰り返しながら少しずつシステム開発していくこと」です。専門的な説明とはかなり表現が異なりますが、大体そういうことです。
従来は「顧客とエンジニアで一度計画したシステムを、途中で相談などをはさまず一気に開発すること」で、途中変更が効かない柔軟性に欠けるウォーターフォールと呼ばれる方法でした。
これまで、アジャイル開発は小規模開発に有効、ウォーターフォールは大中規模開発に有効、とそれぞれ一長一短あるという風に言われていました。DXレポートにもそのように解釈できる記述がありますが、ITプロジェクトのリサーチを行っているSTANDISH Group の2015年の調査によると、実は、どういった規模の開発であっても、アジャイル開発のほうが成功率3倍・失敗率1/3という統計が出ているそうです。
DXの成功率3割。アジャイルの浸透率3割。
日本のDXは約7割失敗する。
この約7割という数字、実はアジャイルの普及率に影響しているかも知れません。
●世界のアジャイル普及率が60～95％
●日本のアジャイル普及率は30～40％
世界ではアジャイルが普及しています。政府の電子化が進んだヨーロッパでは、政府からのシステム開発案件はアジャイル開発の契約形態でないと受注できないそうです。日本では考えられない状態です。
実際、日本は世界でもっともアジャイル導入がむずかしい国という調査データもあります。なぜ日本ではアジャイルが普及しないのか。直結しているのが、日本のITエンジニアの約7割がシステムインテグレーション業界に所属し「納品形態」で仕事をしており、アジャイル開発を実践できていないからですが、本質はそこではありません。「日本の企業はアジャイル開発の思想を受け入れられないから、ITエンジニアの7割がいまだシステムインテグレーション業界に追いやられているという」という風に捉えるべきです。
ではなぜアジャイル思想を受け入れられないのか。よく言われているのが「日本人は対人リスクを避けるから」という理由です。
アジャイル開発は、エンジニアとビジネス側が対話を重ねながら、お互い柔軟に協調し合いシステム開発を進めていくという概念です。当然、対話を重ねる中で衝突もあるため、アジャイル開発とは対人リスクを織り込んだ開発方法と言えます。
海外の場合、小さい頃からしっかり自己主張することを基本としており、コミュニケーション上衝突することを普通のこととして受け止めています。また雇用規制がゆるいため、なにかあれば即解雇されるのも普通。つまり、対人リスクをすべて自分で処理することが普通です。余談ですが、アメリカでは対人リスクの自己処理能力を上げるために、一人一人がマイ・メンターを持っているという話を聞いたことがあります。稼ぐ人ほど、何人ものマイ・メンターを持っているようです。
日本は反対で、対人リスクをなるべく避け、同調主義。上司に対して給与交渉をしているシーンなどあまり見かけません。「がんばっていれば誰かが見ていてくれる」という、自己アピールをあまり良くとらえない考え方が根底にあります。
つまり、対人リスクを織り込んだアジャイル開発という手法は、日本的ではないという話になるのですが…本当にそれだけがアジャイル開発が普及しない理由なのでしょうか。
アジャイルが受け入れられないというのは、対人リスクの話ももちろんありますが、もっと根本的な部分、エンジニア側のスタンスと、ビジネス側のスタンスが折り合わないところに要因があります。
相いれないビジネスマンとエンジニア
ビジネスマンとエンジニアが、相いれないのはなぜか。
それは、エンジニアが「人間性の自由を獲得するために産まれた職業」だからです。
ビジネスマンも、人間性の自由をないがしろにしているわけではありません。ですが、大前提は利益の追求。そのために与えられた役割をまっとうする義務が生まれ、どうしても企業の歯車的な存在になってしまいがちです。エンジニアとは、そんなビジネスマンのあり方・人間性の不自由さにメスを入れる存在とも言えます。
エンジニアがどのようなルーツを経て「人間性の自由を獲得するために産まれた職業」なのか。本書の主題ではないのですが、このことを理解することで、アジャイル開発の手法だけ取り入れてもうまくいかない理由が理解できます。
エンジニアは、ビジネスロックンローラー
PC・エンジニア・アジャイル開発が産まれた経緯についてザッとお話します。
まず、PC・エンジニアがどのような経緯を経て生まれたのかについて。
1960～70年代にベトナム戦争が勃発し、カリフォルニア州で反戦運動が起きます。若者は逮捕されるリスクをおかして徴兵拒否。アメリカの価値観を疑うようになります。
そんな中、ヒッピーと呼ばれる反体制・反権威・自然主義的な人々が生まれます。彼らが「セックス・ドラッグ・ロックンロール」をツールとし人間性の解放を訴え、社会問題に発展。
とくにドラッグに対する規制が厳しくなっていく中、代替ツールとして注目を集めたのが、東洋思想。インド哲学・チベット仏教・禅は、自分の内部にある神性に目覚めるという、人間性の解放と類似したコンセプトを持っていました。
中でも、禅の武芸・芸事における「基本的な型を繰り返し繰り返し練習・実践することで、あるとき一気に全体を理解するというプロセス」に共感が集まります。西洋文明的な「合理的な理解」よりも、経験・体験で理解していくという、アジャイル開発に通じる価値観もここで醸成されます。
そんなヒッピーたちを社会に引き戻していく原動力になったのが「パーソナルコンピューター」です。それまでコンピューターは、軍隊などで使われていた権威・権力の象徴でした。このコンピュータが小さくなり、個人一人一人が使えるコンピューターとして登場したのがパーソナルコンピューターです (以下PC)。ヒッピーたちはPCを、全地球規模で個人同士をつなぐ脱権威・人間性の解放を実現するためのツールとして利用しはじめます。
こうした流れを経て生まれたのがエンジニアという職業であり、世界のIT一大拠点、カリフォルニア州北部のベイエリア地帯・シリコンバレーです。
つまり、エンジニアとは、ギターをPCに持ち換え、現実世界全体をロックンロールする存在。現実世界を脱権威化することで、人間性の解放を目指す存在だったのです。根本的な部分で、権威主義の組織とは対立する存在であることがわかると思います。
余談ですが、Appleはこういった経緯・ルーツをうまく捉え、ただのビジネスツールとは一線を画す製品をリリースしているからこそ強い共感を集めているのだということも理解もできます。ミッション経営が流行っていますが、重要なのはミッションワードではなく、時代背景をどれだけ捉えることが出来ているのかなのでしょう。
アジャイルは、エンジニア保護ガイドライン
アジャイル開発のルーツについてもお話します。
こうしてエンジニアという職業が生まれ、企業のソフトウェア開発の仕事が発生しはじめるのですが、ここでさまざまな悲劇が起きます。ビジネスの慣習に従いスケジュールドリブンでソフトウェア開発を進めたことで無理が生じ、結果、プロジェクトは炎上。エンジニア達は高稼働・現場の混乱に苦しめられます。
優秀なエンジニアは自由と反権威的な思想を持っており、この状況を「ビジネスなんだから普通だ」とは捉えず改善に動きだします。人間性の尊重、そして禅から学んだ「合理ではなく、経験・体験で物事を理解していく」思想を反映させた「軽量ソフトウェア開発プロセス」が産まれていきました。
軽量ソフトウェア開発プロセスとは、すべてを計画しつくしてその通り開発・完成させるのではなく、変化を前提とし短い工程を繰り返しながら、開発と対話を重ね課題を解消・改善していくという開発プロセスです。
軽量ソフトウェア開発プロセスには「スクラム」「リーンソフトウェア開発」など、さまざまな型が産まれたのですが、それぞれの型の提唱者が集まり発表したのが、2001年の「アジャイルソフトウェア開発」という概念です。
つまり、アジャイル開発は「ウォーターフォールよりも優れた開発方法」として産まれたわけではなかったのです。ビジネス側の、ソフトウェア開発に対する無理解からエンジニアを守るためのガイドラインとして産まれたモノだったのです。アジャイルとウォーターフォールを比較するな、という意見はこの辺りから来ています。
ですが、冒頭お話した通り、結果として開発の精度も上がりました。ビジネス側の監視のもと、画一的で納期に縛られた開発しか出来ないウォーターフォールのやり方から、アジャイル開発の宣言によって解放されたエンジニアは、人間性を取り戻し、自主性をいかんなく発揮することが出来るようになりました。
アジャイルを受け入れるか、DXを捨て権威主義をつらぬくか
エンジニアという職業は、
●その根本・ルーツに「人間性の解放」という存在意義を持っているということ
●権威主義的なビジネスの世界とは相いれない側面をそもそも持っているということ
アジャイル開発は、ビジネス側とエンジニア側がお互いWin-Winな関係性を築けるよう策定された概念でありつつ、
●エンジニアが、ビジネス側の無理解に潰されず、活き活きと働けるようにするための概念・ルールであるということ
●エンジニアもアジャイル開発も、反権威主義から産まれた存在であるということ
つまり、アジャイルを受け入れるということは、人間性の開放に賛同し、人を機械の歯車のように働かせる権威主義的な企業スタイルを全面的に廃止しなければならない、という側面も持ち合わせているということです。
この話を理解すると、経験が長いエンジニアほど古くからある有名大手企業ではなく、新進気鋭のベンチャーを選ぶ理由がわかる感じがします。
アジャイル開発なくして進まないDXですが、DXとはつまり、組織の「権威主義から、人間性の自由獲得への脱却」のことを指しているのかも知れません。今後、DXに対応できなかった企業というのは、社員を権威の元、歯車として働かせている企業であるという証拠になります。そういう企業から社員がどんどん離れてしまうことこそが、デジタルディスラプターよりも怖いことなのかも知れません。
組織全体を変えていく (本書ではリファクタリングと言っています) 方法と、その背景・理由が詰まった本質的な一冊です。「エンジニアが読む本かな」とスルーしてしまいがちなシンプルな表紙なので、まだ読まれていない方も多いと思います。ぜひ、ご一読を！
参考
『エンジニアリング組織損への招待 著者：広井大地 出版社：技術評論社』
執筆者
リビルダーズ編集部
