目次
なぜアジャイル開発が必要とされるのか
アジャイル開発と呼ばれるソフトウェアの開発手法がある。少しずつ実際に動くプログラムで機能を作っていく手法だ。一度に作って終わりではなく、本当に必要な機能から作っていくために、小さく繰り返しながら開発しようというコンセプトだ。
アジャイル開発の登場以前のソフトウェア開発といったら、最初に作るべき機能の要件を全て決めて、一度に最終的に作るプログラムの設計をして、一斉にコンピュータにプログラムを打ち込んで、最終的に人海戦術で動作テストをする作り方だった。
ソフトウェアが、巨大で高価なコンピュータというハードウェアに付属する「おまけ」だった時代は、それでも良かった。企業がコンピュータを導入したら、それを使ったり従ったりして、労働者たちは決められた仕事をすれば良かったのだから。
しかし今や、誰もがスマートフォンを持ち、インターネットを通じてソフトウェアを使う時代だ。そして、あらゆる業界のビジネスを支える根幹としてソフトウェアは入り込んでいる。ソフトウェアは常に改善し続けることを求められるようになった。
そこでアジャイル開発だ。ユーザからのニーズに応え続けるために、事業の成長に合わせ続けるために、ソフトウェアを少しずつ実際に使いながら、改善を繰り返して開発をする手法が必要なのだ。だから多くの企業がアジャイル開発を求めているのだ。
少しばかり前置きが長くなってしまったが、そんなアジャイル開発の進め方そのものについては、今回は取り上げない。先人の書いた書籍や記事があるので、そちらに譲ろう。（私の書いた記事もよければどうぞ）
アジャイル開発の根底にあるのは、「身軽に」して繰り返していくことで、外界の変化に適応していくソフトウェアが開発できる、という考え方だ。そして、その考え方はソフトウェア開発に限らず、多くの場面に応用できるのでは、と考えている。
これまで長くアジャイル開発に携わってきた私から見て、ビジネスの場面、経営をする場面において、どのようにそのエッセンスを応用できるのか考察してみよう。
新規事業の立ち上げは、計画通りには進まない
大きな工場や沢山の人手が最初から必要な事業を立ち上げるなら、緻密な計画と、関係各位の巻き込み、盛大に集めた資金を投入して取り組むべきだろう。昔の新規事業といえば、そういうものだったに違いない。だから事前の計画が重要だった。
しかし、昨今のソフトウェアやインターネットを中心に考えられたビジネスであれば、消費者やユーザとの距離は近く、事前の設備投資もさほど必要がない。むしろ、顧客を見つけて、そのニーズを捉えた製品作りが重要と言われるようになった。
そもそも新規事業は計画通りになどいかない。私が社内ベンチャー時代に学んだことは、いくら緻密な事業計画があっても、そんな計画通りに世の中は動かないということだった。経験したことのない新規事業で、事前に完全な予測など出来ない。
計画は計画に過ぎず、実際の自分たちの経験を元に日々修正していくことこそが肝要なのだ。そのサイクルは、短ければ短いほど良い。事業がうまくいくなら、朝令暮改で上等だ。そのためにも、効率的に動ける少数精鋭のチームの方がいい。
新規事業の進行を作業のように、進捗率を見てはうまくいかない。大きなゴールはあるにせよ、そこに至るアプローチは、進みながら変えていく。前提から変えていくなら進捗率など意味はない。見るべきは、仮説検証で得られる経験値だ。
どれもアジャイル開発の考え方に近い。そう、もう気づいている人もいると思うが、新規事業にアジャイル開発を応用して考えられたのが、リーンスタートアップだ。
業務改善は、一度きりでなく何度も繰り返す
働き方の見直し、人材不足の解消など、既存業務の現場も、今は変化が求められている。それも、働き方だけの表面的な取り組みではなく、業務そのものを分析し、ボトルネックを見つけ、改善のメスを入れる。それが取り組むべき業務改善だ。
業務改善で失敗しがちなのが、現場の声を聞きすぎて、どれから取り組んでいいかわからなくなってしまうことだ。現場の抱える課題を盛り込みすぎて、とても現実的とは思えない計画になったり、システムさえ入れればうまくいく幻想に囚われたり。
ビックバンで業務改革のシステムを入れることは、現場の混乱や反発にも繋がり、うまくいかないだろう。少しずつ関係者を巻き込みながら、押し付けではなく、自分たちで取り組んでいける組織にすれば、最初は稚拙でも、いずれうまくいくはずだ。
業務改善とは、一度きりで終わるものではないのだ。ボトルネックは１つではないし、たとえ１つ解消しても別のところがボトルネックになるだろう。業務改善は、普段の業務そのものと並行して続けていくような、日常業務にすべきではないか。
そして、繰り返していくのなら、改善とシステム化と分業はしない方が良い。業務のオペレーションと開発を分離しないのは、ある意味でDevOpsと言える。そして、自分たちで改善を繰り返すときのテクニックの一つで「ふりかえり」が使える。
業務改善とシステム化を一緒にやって繰り返していくメソッドが「業務ハック」だ。業務ハックも、アジャイル開発のエッセンスを取り入れているのだ。
組織変革は、新規事業だと思えばうまくいく
大企業などでよく言われるのが、企業文化の見直しに浸透であったり、セクショナリズムの解消のため、組織変革をしなければならないという話だ。トップダウンで始まることもあれば、現場の若手が自主的に取り組むボトムアップのケースもある。
組織変革を実現するにはどうすれば良いか。これも法則や方程式のない、正解のない取り組みだ。社内コミュニティを作ったり、制度を変える取り組みなど、やるべきことは沢山あるが、どれが効果的で、どうすればうまくいくかわからない。
とかく情熱が大事、と精神論になってしまいがちだが、必要ないとは思わないが、それではあまりにも運任せに過ぎる。では一体、どうすれば良いのだろうか。とある大企業で働き方改革を担当された方と話をする機会があり、こう言っていた。
「組織変革も新規事業みたいなものですよ。仮説検証の繰り返しと、キーマンへの新規営業を続けていくんです。」
確かに、抽象的に考えれば、組織変革は新規事業の取り組みと非常に似ている。ユーザを社員に置き換えて、新しい企業の理想をプロダクトだと思えば、繰り返しながら針路を見直して進めていくのは、まさに新規事業だ。
アジャイルな組織にしたいと言いながら、ウォーターフォールで組織変革をしようとしていないだろうか。大事なことは、プロセスよりも個人との対話だ。
VUCA時代を生き抜くための、適応型の会社経営
VUCAとは、Volatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）という4つのキーワードの頭文字から取った言葉であり、現代の経営を取り巻く環境を表す言葉としてよく使われている。
私は、経営者になる以前からアジャイル開発に携わっている中で考えていたことは、アジャイル開発に適しているのはプロジェクトではなく、ゴーイングコンサーンではないか、ということだ。つまり、経営とアジャイル開発は不可分ではないか、と。
というのも、これからの事業経営においてソフトウェアを活用するか、もしくはビジネスモデルに組み込まないということはありえない。そして、経営も事業も、基本的には継続するものなのだから、ソフトウェアも継続していくべきだと考えていた。
経営も事業も、４半期や半期、長くて１年単位で評価をして、見直しをする。問題や課題があれば適切に手を打ち、その経営上の健康状態を保つことをする。現代の経営で求められているのは、そのサイクルが非常に短くなっているということだ。
日本の経済全体が成長しているなら、自社の経営目標も中長期の３ヶ年計画などを立てて、それをブレイクダウンした数字の成長をKPIとして見ていけばよかったかもしれない。しかし、今は経済も縮小し、人も減る中で、どうすれば生き残れるのか。
計画を立てて、その通りに執行するだけでなく、新しいアイデアや事業を生み出すこと、業務改善を行い生産性の尺度を変えること、世の中の変化に合わせて、経営のあり方や働き方を変えていくこと、それを繰り返していくことではないか。
変化に適応していくことが、これからの経営に求められるのだとしたら、そこにアジャイル開発のエッセンスは大いに活かせるのではないだろうか。
改めて、アジャイル開発とはなんだったのか
実は、アジャイル開発というのは、いくつかの開発手法を提唱していた人たちが集まって作ったコンセプトであり、それ自体に具体的な中身がある訳ではない。あるのは「アジャイルソフトウェア開発宣言」と「宣言の背後にある原則」だけだ。
（この日本語版のレビューをさせてもらったのは、私のちょっとした自慢だ）
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツール よりも 個人と対話 を、
包括的なドキュメント よりも 動くソフトウェア を、
契約交渉 よりも 顧客との協調 を、
計画に従うこと よりも 変化への対応 を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck、Mike Beedle、Arie van Bennekum、Alistair Cockburn、Ward Cunningham、 Martin Fowler、James Grenning、Jim Highsmith、Andrew Hunt、Ron Jeffries、 Jon Kern、Brian Marick、Robert C. Martin、Steve Mellor、Ken Schwaber、 Jeff Sutherland、Dave Thomas
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
改めて今の時代に読むと、このアジャイルの考え方はソフトウェア開発に限ったものではないし、これから益々と重要になってくる考え方と思える。
