DXの鍵を握るアジャイルマインドとは
前回「DX（デジタルトランスフォーメーション）の鍵は、デザイン思考とアジャイルマインド」という記事を書きました。デザイン思考についてはこのサイトで様々な角度から取り上げていますが、「アジャイルマインド（アジャイル思考）」とは何か、疑問に思った方も少なくないかもしれません。
「アジャイルマインド」で検索してみるとイロイロな解説が書かれています。
「それはアジャイル・マニフェストのことである」「顧客第一の考え方のことだ」「勇気を持って今を変えていくこと」「失敗へを恐れずにまずやってみること」「『私は知らない』から始めること」「とにかく素早く短時間で回すこと」・・・。
何でもあり的な（笑）感じもしなくはありません。
そもそも何故、「マインド」なのか。例えば「ウォーターフォール開発」をするにあたって、「ウォーターフォール・マインド」を身につければならない、といった議論はあまり聞かれませんよね？ 個人的には「ウォーターフォール・マインド」ってなんか涼しげな響きで好きですが。今のような気候のときは特に。（笑）
ウォーターフォール・マインド？
アジャイルという手法は存在しない
これは誤解している人も多いと思うのですが、アジャイル開発という手法はこの世に存在していません。
「ウォーターフォール開発」は、Winston W. Royce（1970年）や、Bell and Thayer（1976年）の論文がその起源と言われており、1988年に制定された米国防総省のソフトウェア開発規格「DOD-STD-2167A」などでもその仕様が定められている手法です。
一方で「アジャイル開発」という言葉は、XP（エクストリーム・プログラミング）というソフトウェア開発手法を提唱したKent Beckや、スクラムを創設したJeff Sutherland、Ken Schwaberといったメンバーが集まり、2001年に「アジャイルソフトウェア開発宣言」を提唱したことに始まります。
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。「アジャイルソフトウェア開発宣言（2001年）」
一般にはこの「宣言」を行うためにユタ州スノーバードに集まった17人（Snowbird-17と呼ばれています。）がそれぞれ開発した手法、XP、スクラム、クリスタル、カンバンなどを「アジャイル開発の手法」とみなすことが多いようです。
しかし、もちろんこの17人だけが、このようなやり方を開発・提唱したわけではもちろんなく、「宣言」以前にも多くの人がこのような手法の開発に携わってきました。
その歴史は、実は「ウォーターフォール開発」よりも古く、「アジャイル開発とシステムズエンジニアリング（SE）」の記事にも書いたように、1960年代には既に「反復進化型開発(Iterative and Incremental Development: IID)」「継続的インテグレーション」「テスト駆動開発」など現在のアジャイルの各手法と変わらないシステム開発手法が行われていました。
また「宣言」が出された2001年頃のシステム開発環境はと言うと、ウォーターフォール開発を推奨していた上記の「DOD-STD-2167A」はすでに廃止され、1994年に規格化されたソフトウェア開発標準「MIL-STD-498」では、「Grand Design」「Incremental（漸進的）」「Evolutional（進化的）」「Reengineering（製品中心から顧客志向、プロセス思考への再構築）」「Reverse Engineering（プロトタイプ製造を行ってから後に設計を行う）」など現在アジャイルで行われている手法やプロセスが定められています。
アジャイル開発とは「価値創造型開発」
そうなると、アジャイル開発とは何か、今までの反復進化型開発（IID）とは何がどう違うのかという疑問にぶつかります。この答えが「価値」あるいは「価値創造」です。
「アジャイル開発宣言」をみると、「価値」という語句が何度も使われていることに気づきます。これを理解するためには、2001年という時代背景を考える必要があると思います。
2001年といえば・・・
かつてコンピュータは「電子計算機」と呼ばれていたように、高速かつ正確に「計算」をしてくれる機械でした。そしてソフトウェアはその「計算手法」を決める仕組みのことを指しました。
1980年代までの「メインフレーム」が主流の時代、システム開発とは今まで手と紙でやっていたことを素早く正確にやってくれるための「仕組みづくり」といってよいでしょう。したがってコンピュータから出力（アウトプット）されるものは、帳票であったり財務諸表であったり、あるいはワープロの文章であったり、「手（ペン）と紙」で作ったものと「価値」が変わるものではありません。
「下町ロケット」ではありませんが、「コンピュータ制御の機械が作った部品」と「職人による手作りの部品」どちらに価値があるか、そのやり方だけで価値の有無を決めることはできません。
つまりコンピュータ化、システム化されたからと言って、何か新たな「価値が創造」されたものではないわけです。
しかし、90年代のいわゆるIT革命以降ではGAFAの提供するプラットフォームに代表されるように、あるいは最近のAIやIOTもそうですが、システムは「新たな価値」を提供するためのものへと変容します。
つまりシステムは、それまでの「価値」をコンピュータに置き換えるのではなく、新たに「価値を創造する」ためのものとなったのです。
「価値の置き換え」ならば、すでにゴールは存在しているわけですから、わざわざアジャイルなどせず、ウォーターフォール開発のような「計画管理型」の開発様式が向いています。しかし「新たな」すなわち「今までにない」ものを開発しようと思えば、「計画管理型」のように今まであったものを「要求」や「要件」という形で示すことは困難です。
かつてヘンリー・フォードは、”If I had asked my customers what they wanted they would have said a faster horse.”（もし私がお客に欲しい物を訪ねたら、彼らは「もっと早い馬がほしい」と答えただろう。）と言いました。
またスティーブ・ジョブズも”Our job is to figure out what they’re going to want before they do.”（私たちの仕事は、顧客が何を望んでいるのか、彼らよりも先に理解して形にすることです。） と言っています。ジョブズがマーケティング調査などを嫌っていたのも有名な話ですね。
AIの分野でもかつての「エキスパートシステム」は予め答えを定め、機械に逐次的（計画的）に知識を教えていきますが、今の「機械学習」はそのやり方とは全く違いますよね。
未開の場所に「価値を創る」というのは、ウォーターフォール開発のように、計画立てて決められたようにやっていくということは不可能に近く、市場などの反応をみながら何度も試行錯誤を繰り返しながら創っていくしかありません。
参照記事
アジャイルは振り返り（レトロスペクティブ）から始める
図の左のIIDと、右のアジャイル開発の違いはまさにそこで、手法（例えばRUPとスクラムのやり方）自体の違いは実は重要ではなく、新たな価値を創造するというマインドがアジャイルの本質だと考えます。
「まず要件をまとめてください」というエンジニアは、DX時代取り残される
システム構築が、アナログ作業の「価値の置き換え」ですんだ古き良き時代は、エンジニアの仕事は「（要件定義で）決められたことを正しくつくること」でした。
ソフトウェアエンジニアであれば、「プログラム言語」の知識やスキルをたくさん持っていることがその人の「価値」でした。
しかし、DX時代の今、エンジニアには「決められたことを正しくつくる」から、顧客と共創して「ビジネスをデザインする」能力が求められます。
ビジネスのモデリングは、顧客など誰か別の人がやって、自分はその人が「要件定義」にまとめるのを待っていれば良いというウォーターフォール型のエンジニアの「価値」は今後下がることはあっても、上向くことはないでしょう。
ローコードやノーコード開発の普及が拡がると言われる今後はなおさらです。
いわば「地図なき道」を進む探検家のようなマインドがエンジニアには求められるわけで、これが「アジャイル・マインド（アジャイル思考）」が必要とされる理由だと考えます。
もちろん、マインドだけ、徒手空拳で対応できるわけもなく、ビジネスとシステムをつなぐスキルやメソッドも必要なのは言うまでもありません。
参照記事
生産性が4倍になる自主経営メソッド、アジャイル仕事術
アジャイル思考でビジネスモデルをデザインするフレームワーク
「アジャイル」は元来システム構築のための方法論ですが、DXの必要性が言われて以降、ビジネスそのものを「アジャイルでデザインする」というのも浸透してきたように思います。
ただスクラム、XPなどアジャイルのフレームワークをそのままビジネス構築に適用するのはもちろん無理もあります。
弊社では、「Agile Development with ICONIX Process」などの著書を持つDon Rosenberg氏の方法論である「ICONIXプロセス」をビジネスモデルデザインに応用したフレームワークを開発し、2021年の「日本ビジネスモデル学会」の論文誌で発表しました。
ICONIX for Business Model Design
DXの推進、自律組織やプロダクトをデザインする手法のセミナー
日本能率協会主催「DX時代に求められる「３つの思考法」入門セミナー」開催
