はじめに
こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。
アジャイルって何だ？
「ウォーターフォールよりもアジャイルのほうがいいのか？」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。
ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと始めた企業も流行りが変わると今度はリーンだとか、今度は○○だといったように新しい方式を導入してみては失敗するところも珍しくありません。
アジャイル開発の専門家ですと名乗る人の話を聞いてみても、それが何なのか、けむにまかれたような説明をされてしまい、いまいち納得できないまま始めると言ったこともよく聞く話です。
一体、アジャイルとは何なんでしょうか。アジャイルに限らず、IT界隈にはバズワードとして瞬間的にブームになっては、本質もよくわからないまま新しい物好きたちによって蹂躙されて、気がついたら論争の種になっているような事柄が多くあります。私は、アジャイルとは何かという話をするときには、「不確実性に向き合うための考え方」だという説明をしています。それがどういうことなのか、かいつまんで紹介します。
実は日本にルーツのあるアジャイル
実は、アジャイル開発という決まった開発方式はありません。
ソフトウェア産業が発達するにつれて、複雑化し、政府や大企業だけでなく多くの人々が使うようなソフトウェアが求められるようになりました。そうなると最初から何を作るのか完全に決めてから開発をすると、顧客に受け入れられずに失敗するようなプロジェクトが増えてきました。そういった未来や市場を読みにくい時代にフィットしたソフトウェア開発のあり方があるのではないかという思いを抱えた人々が同時多発的に作り上げた開発ノウハウを発表するようになりました。これらを一つの宣言にまとめあげたのが「アジャイルソフトウェア開発宣言」でした。そして、そのお手本になったのは当時全盛を誇った日本企業とその背後にあると思われた東洋思想だったのです。
ベトナム戦争以後、行き詰まり感を抱えたアメリカ社会にとって、西洋文明とは違った「新しい合理性」を取り入れていきたいという思いはうねりのようになっていきました。そして、西洋と東洋の中間地点にある西海岸にとって、「アメリカ的な東洋思想」は彼らの新しい合理性というフロンティアとなっていったのです。
トヨタ生産方式にみられるような人との対話を重視して、役割をあらかじめ分けずに流動的に市場のニーズに対処するという発想は、アメリカ社会に東洋的なエッセンスを感じ取らせ、次第に経営学にとりいれられるようになっていったのです。
不確実性に向き合うこと
アメリカ社会で芽吹いた「新しい合理性」は、殊の外時代にフィットしました。グローバル化やIT化によって、昨日までの当たり前が明日は全く違ったものになってしまうという時代において、不確実なものに適応して味方にしていくという発想は、その後の発展を支える大きな力となりました。
不確実性というと仰々しく聞こえますが、要するに人間にとって「わからないこと」のことをさしています。人間にとってわからないのは、「未来」と「他人」です。わからないものを知るには、わかる人に聞いてみるしかありません。なので、実際にやってみて知識を得ようとする考え方がアジャイルの基本的な発想です。
ソフトウェア開発を進める上でわからないことは「何を作ったらいいのか」と「どのくらいで終わるのか」ということです。
何を作ったらいいのかを知るのであれば、実際に作ったものを見せて顧客に聞いてみれば正しいのか正しくないのかわかります。また、どのくらいかかるのかも、作る前に予想するよりも実際にすこし作ってみて、その実績から予測する方が精度が高くなります。「わからないものを実際やってみて確認する」というサイクルを固定するために、多くのアジャイル開発手法では、短いタイムボックスを設けて、都度振り返りとレビューを行います。これが、「未来」のわからなさに対するアジャイル的なアプローチです。
また、プロジェクトに人数が増えすぎたり、特定の業務しかしない人が増えると、お互いに知らない、よくわからない人が増えて、セクション意識が生まれたり、全体のために何をするべきなのかがわからなくなってしまいます。そうなると、「他人」がプロジェクトに増えていきます。そこで、お互いが膝を突き合わせて話ができるくらいの少人数で、会話を通じて問題を解決していきます。
アジャイル開発を何か体系だった開発プロセスなんだと考えると誤解をしてしまいます。アジャイル開発は「どうやったら、不確実性をもっと減らせるんだろう」という問いにチームが向き合うための学び方なのです。
不確実性に向き合えない日本
日本企業をお手本に作られたはずの「アジャイル」が、皮肉なことに日本でなかなか普及することも理解が進むことがないのはなぜでしょうか。
様々な国の文化的特性を数値化したものにホフステード指数というものがあります。その中にUAI(不確実性回避傾向の強さ)というスコアがあります。日本は先進諸国の中でもこのスコアが極めて高く、不確実なものを避けてしまう傾向があることがわかります。
諸行無常の思想を持つ仏教国でありながら、何かに固定的であってほしい、不確実なものは避けたいと考えてしまう文化特性は不思議に思えます。
一方、インフレ期の国家ではリスクを取ることに対して抵抗がなくなり、デフレ期の国家ではリスクを取りづらくなることが知られています。失われた２０年で、本当に失われたものは「わからないもの」に向き合う国民性なのかもしれません。
減点主義じゃない考え方
私は、学校教育のあり方も「不確実性に向き合う」ということを重視していないように感じています。学力テストと仕事の進め方を比べてみるとその違いがわかってきます。
学力テストでは、問題文の中に正解を導けるための情報が全部詰まっていることが前提です。そこから、既に持っている知識との組み合わせで答えを導きます。人に聞いたり、調べたりすることをしたら、カンニング行為だと言われてしまいます。
しかし、仕事を進めていく上では、わからないことは聞いたほうがいいし、調べられることを調べることはあたりまえのことです。もし間違えてしまっても、間違えたということから学び、正解に近づければそれでいいのです。まずは、小さく失敗しようというのがアジャイル開発の重要な点です。失敗することを恐れるあまりに大きな失敗をするまで目を背けてしまうのは、のちのち大きな痛手になります。決まった時間の中で、多くのことを学ぶためには減点主義ではダメなのです。
むしろ、自ら新しい知識を得るためには、間違っていたとしてもどこが間違いだったのかを効率よく知るための行動こそが重要になります。こう言った行動を育み推奨する要素がこれまでの教育ではかけていたように思われます。失敗してはいけないという強迫観念が不確実性に向き合うことを難しくさせてしまうのです。
エンジニアリングを問い直す
テクノロジーを用いて何かを作ることは「エンジニアリング」と呼ばれます。この何かを作っていくという行為は、物事の原理や原則を発見する理学とはまた違うものです。
何かをエンジニアリングするとは「曖昧でわからない状態」から「具体的ではっきりとした状態」に変えていく行為です。つまり、エンジニアリングとは「不確実性を削減する」という行為だと言い換えることができます。
このようにして、エンジニアリングの基本を「不確実性を下げること」だと考えると、様々なことが１つの観点で繋がっていきます。
たとえば、アジャイルのタームとして「自己組織化」というフレーズが用いられます。うまく機能しているチームを例える言葉として用いられるのですが、元々は生命科学やシステム論の用語です。これは、東洋思想との親和性がしばしば指摘される「新しい合理性」の１つです。生命や自然現象が、周囲の不確実性を吸収しながら、自らの内部では秩序を作り上げていく様子を表した言葉です。
また、プロジェクトの最初期には何を作るかもどう作るべきかも曖昧な状態ですから、その状態で「計画通り」に物事を進められるという前提に立って経営判断をするのは、逃れられない不確実性から逃げ、混乱を後まわしにしているだけだとわかります。マネージャーが管理すべきものは「不確実性」そのものなのです。
エンジニアリング組織論への招待
書籍『エンジニアリング組織論への招待』は、エンジニアリングとそれを取り巻く組織にまつわる様々な問題や新しい考え方を、たった１つの原則「不確実性に向き合う」という観点で再構築したものです。
個人の考え方を問い直す第１章にはじまり、１対１のメンターリング、１対多のチームマネジメント、多対多の組織とアーキテクチャ設計というように、ひとつずつ階段を登るように不確実性に向き合う”エンジニアリング”チームの作り方を紹介します。
なぜ、技術的負債が問題となるのか、その正体はなんなのか。なぜ、プロジェクトは炎上し、スケジュール通りに終わらないのか。なぜ、エンジニアチームとビジネスチームの連携がうまくいかなくなるのか。こうしたソフトウェア開発をめぐる様々な人間関係や組織の問題、そしてアーキテクチャの問題の根本原因にせまっていきます。
エンジニアリングを扱う経営者や開発者にとって、きっと新たな発見を得られるものになるでしょう。これは失われた２０年を取り戻す旅なのです。