papanda この数年は、「探索」と「適応」の必要性をひたすらに訴え、その実践に向けて組織に動いてもらう、そのためのあらゆる支援を行う、ということに取り組んできた。「探索」と「適応」という言葉が決して、伝統的な組織に馴染むわけではないが、他に言いようもなく、この言葉を押し通してきた。
正直なところ、探索適応という概念の普及は端緒についたばかりである（ついていると思いたい）。「探索適応がいかに伝統的な組織の現有ケイパビリティや指向性と合わないか」ということを数々の機会で語ってきたが、その必要性についてはもはや確信の域を超えている。「効率への最適化」に最適化していた組織が、かえって目の前のことに、顧客の声に対応できなくなっている、「非効率での安定化」に至っているこの現状を突破するには？ 「探索適応」という手がりは小さな、小さな「希望」になりうる。
探索適応を組織に宿すためには何かしら拠り所が必要だ。そこで、ソフトウェア・プロダクト開発の世界で先んじて育まれてきた「アジャイル」をその手立てとする。より「探索」を強調するために、「仮説検証型アジャイル開発」という言葉をつくり、気がつけばもう10年背負ってやってきている。やがて、私の主題は移り変わってきた。「仮説検証型アジャイル開発」での取り組み型、考え方を、開発業務を中心としていない組織にも適用できるようにするためには？と。
これは難しいお題だった。まずもって言葉が合わない。アジャイル、スクラム、からのスプリント、スプリントプランニング、スプリントレトロスペクティブ、プロダクトバックログ、え？プロダクト？
言葉は概念そのものではないが、概念を表し理解していくための有力な手段になる。その言葉が合わないようであれば、概念など理解しあえるはずもない。自ずと、受け取りやすそうな言葉を新たにつくっていこうとする。この数年、私がもっとも繰り返し繰り返し字を追ったのは類語辞典だったのではないかというくらい、首っ引きになって言葉と向き合った。
だが、言葉とは意外にも限りある「リソース」なのである。なぜか言葉には無限の空間を感じさえしていたのだが、その実、言葉のバリエーションというのは極めて限らえていることに気づく。概念を説明する言葉はすぐに尽きる。ここでようやく気づいた。なぜ、新たな概念を表すのにカタカナ英語が多いのか。英語を範疇に含めることで、表現手段を広げる（それでも足りないければフランス、ドイツだ）。そして、受け取りやすいようにカタカナに直す。何も気取りたいわけではない。そもそも言葉が足りないのだ。ではいっそ、新たな意味づけを念頭に全くの創作の言葉をつくってしまうか？ 余計に受け取られないのは明白だ。
「どのような概念であれば価値が出せるか」という具の話以上に、表す言葉が定まらないために、受け取りも広がりも得られず、結果として始まることがない。なんというもどかしさ。とっても乱暴に言うと、「アジャイル」が手がかりになるのは明白だ。もはやアジャイルの是非云々に時間を使っている場合ではない。とっとと先に行かねば、組織自体の「賞味期限」のほうが先にきてしまう。
よく分からなければ机上であれこれと議論をしつくそうとするより、ソフトウェア開発としてのアジャイルを実践し、その概念と仕組みと、効果と制約を学び取ることを優先してしまうほうが早い。その上で、学びを抽象化し、概念として再結実させて、自前の組織にとって必要で、適用できるものに組み替える。さあ、とっとと、この動きを取っていこうぜ！という声が届くのは、しかし、妄想の中でのことだ。現実は、From（現状）とTo（理想）を言語化し、丁寧に、慎重に、少しずつ、時間をかけて、互いに向き合いながら、じりじりと進めていく。この営みには尊さがある。分かっている、だが、私の「期限」か、組織内変革者たちの「期限」か、どちらか、あるいは両方が先に来てしまう。ジレンマ。
先の話での難所はここだ。「その上で、学びを抽象化し、概念として再結実させて」。いいかい、私達は日々、概念なるもののために言葉アソビをしている場合ではないんだ。むしろ、「非効率での安定化」のおかげで、目の前にはいくらでも仕事があるんだ。抽象化？概念化？そんなふわっとした話に向き合っているヒマなどない！…という声は、ごもっとも。ジレンマ。
だから、やらなければならない。学びを抽象化し、概念として再結実させることを。「仮説検証型アジャイル開発」では概念理解にギャップがありすぎる組織に向けて、創作言葉を用いずに、さりとて一般用語すぎて角が取れすぎたワーディングでもなく、本質を伝えるための何かを。
そろそろ、言葉の決着をつけなければ前に進めない。選んだ言葉「価値開発」であり、よりメッセージを強調して伝えるためには「アジャイル型価値開発」だった。ソフトウェア・プロダクト開発者の諸君には丸まった言葉として受け止められるかもしれない。いまさら価値かと。だが、概念を表すのに「手段が中心」であってはやはり必要性が伝わらない。中心には何を得たいのか、この文脈では伝統的な組織にとって何が必要なのか？に基づき置く必要がある。そう、「価値」だ。使い古されて、近年「意味」という言葉にやられはじめている、「価値」をそれでも芯に据えねば伝わらない。
実際には、価値なるものが最初から見えているわけではない。探索、試行錯誤をせねばならない。だが、組織にとってより重視すべきは、あるいはそのメンタリティとは、「何かを得る」ことであって、「探すこと」ではない。どうしても「学び」を中心にもってくることはハードルが高い。いやだって、それはそうだろう。すんなり学びを組織の真ん中に持ってこれるなら、この手の概念なんて必要とせず、とっくに実践していますよ。だから、今は、「何を得るのか」ここを表現しなければならない。さもなくば、「探して、それからどうするの、何のために」という議論を延々と繰り返し、そして何も動くことはないだろう。まずは目に見えている最初のハードルを越えていこう。
それにしても「開発」とは？ ソフトウェア開発の世界かとミスリードしてしまうのではないか。しかし、開発にはそもそも仏教の世界で「かいほつ」と読んで、「自分の中に本来そなわっている力を新たに起こす」という意味があるのですよ。価値なるものを自分たちの「外側だけ」探し回っても結局それは正解探しでものにならない、自分たちの「芯」にはなっていかない。価値なるものを周囲とそして自分たち自身をも含めて探索し見出す。ということで考えると、価値開発という言葉にも味わいを感じなくもない。それに、日本の組織は歴史的に「商品・製品開発」「土地開発」という具合に、ソフトウェアに限らず「開発」という言葉に親しんできているところがある。でも、それでは開発することが目的になってしまうんじゃない？ 良いんじゃない、だって、価値の開発なのだから。
このイメージを見ると、よくご存知のかたは「仮説検証型アジャイル開発」と何も変わらない事に気づけるはずだ。そう、左右の構成は変わらない。だが、一つ、この際に整理したい観点があり、織り込んでいる。それは別のところで書いた、探索と適応の織り込み方のことだ。
左が探索、右が適応、ではない。探索と適応は、左右両方において存在する。
この不一致（探索は左のみ、適応は右のみ、という誤解）を長らく許容して、実際の取り組み上で調整をかけてきたのだが、よりアジャイルに不慣れな組織に向けては、左で綿密な計画駆動をはじめてしまわないように整理する必要があった（なにしろ、このイメージの左側からさっそく始めるのだから！）。
このイメージについての解説がもう少し必要だろう。ただ、それを始めると、一冊の本の分量になるため、少しずつ解き明かしていきたい。また、中身そのもの、また問題の言葉についても、安定しているわけではない。今後調整を加えながら、磨いていくことになる。そう、これは、完成ではなく始まりなのだ。これから、探索と適応の旅を始めよう（期限を迎えるその日まで！）
