チーム・組織が「効率化のための最適化を続けてしまう」問題　今までとは違う判断を下すのに必要な“エンジニアのちから”

DXは“変える”ことに意味がある

市谷聡啓氏：巷で聞くDXという言葉。（この単語を）「そんなに好きじゃない」という人もいるかもしれません。僕もそんな信じていないですが、この言葉に意味があると思うのは“変える”ということなんです。

「最適化への最適化」路線。いつから始まったかわかりませんが、みんなが無意識のようにやっている感じを意識的に止める。そういう機会として捉えることができる。そういう意味では、DXという言葉には利用価値があります。

というと、「なんだ、DXか」「うちには関係ない」「うちみたいな創業5年の組織には関係ない話」と思う方もいるかもしれません。

しかし残念ながら、この最適化のモメンタム、最適化の力学、最適化の勢いは、あらゆる組織に宿ると思っています。そもそも組織が続いている状態、生き残って続いている状態、世の中に認められてユーザーにちゃんと認められている状態にあるのは、自ずと最適化を踏み出しているからです。

最適化しているからこそ、効率よく仕事を進められて、ユーザーが期待していることが再現できて価値を提供できる。「たまにできます」ではなく、ちゃんと再現できなきゃいけない。それをやろうと思ったら、そもそも最適化が必要なんです。問題なのは、「脇目も振らず、最適化の最適化を続けてしまう」という流れです。

一歩でも最適化に踏み出すと、望まざることですが、チームや組織は徐々に固さを得ます。固くなるから再現できるというか、もう一度いい感じにできる。開発ができる、サービスが提供できる。どんどん固い部分を作ることが最適化なわけです。

すると、最適化を目指すことと、「こういう時はこういう判断をしたらいい」という、ルールでは見つけられないような別の可能性、ほかにあり得た選択肢や可能性のようなものが自ずと除外される。最適化とほかにあり得た可能性は、トレードオフの関係にあるんです。

最適化への最適化問題を回避するために求められる動き

先ほどの最適化への最適化問題を回避しようと思うと、チームや組織にどんな動きが求められるか。最適化とほかにあり得る可能性を探ることの間を、チームや組織が振り子のように動けるかなんです。そんなことができますかね。

その動き方がなかなかわからないから、みんな効率化への最適化を推し進めている。そういう組織に振り子のように動く。場合によって、今までの判断とは違う判断を下すとか行動を取っていくためには、そういう動きができなければいけません。そこで私がたどり着いたというか、思っているのは、「エンジニアのちから」が必要だということです。

エンジニアが必要という話を何周も違う文脈で繰り返し、誰かが言ったり考えたりする。私も何周か回って、エンジニアのちから、技術が不可欠であることにたどり着きました。

「エンジニアのちから（技術）」とは何か

ここでいう技術は、個々別々の具体の技術のことではありません。AIやIoT、データ基盤、フロントエンド、バックエンドの技術といった個別の技術は重要で、それがないとままなりません。でも、そのような技術以前の身体的な技術が、チームや組織に必要だと言っています。

エンジニアが日常的に取り組む動き方が、先ほど言った身体的な技だと思っています。自分の体を思うように動かすことです。

例えば、バグがあればよく調べます。「何が起きているんだろう」とまず問題を整理しますよね。場当たり的な対応はしません。原因を追求して、原因を解決する策の仮説を立てます。ひょっとしたらAプラン、Bプラン、Cプランの3つくらいあるかもしれない。「一番筋がいいのはどれだろう」と、よさそうなものをまず試してみる。プランを立てて実行する。最初のプランがだめなら次のプランを試すことによって、結果から次の判断や行動を決めたりしますよね。

組織でこれができていないのではないか、ということです。よく注目されるのは「何をやるか」。どんな改善や組織の取り組みをするかという施策であり、やるべきことはいろいろあると思います。それらを考えることも大事ですが、それ以上に重要なのは、先ほどのように、思うように自分たちの体を動かせるようなチームや組織になっているかです。

「そんなの自分たちのことだから当たり前でしょう」「できるでしょう」と思われるかもしれませんが、意外とどうでしょう？　スプリントプランニングで考えたことが、果たしてスプリントレビューでどれほど叶っているのか。もちろんイレギュラーなこともあると思いますが、ちょっと考えたら、準備したら、場合によっては乗り越えられたかもしれないこともある。自分たちが思っているようにやるのには、意外と技が求められるんです。

チーム・組織では“より”実践は難しい

それを1人ではできるかもしれない。でもチームだと難易度が上がります。みんな思い思いにやっているから、チームを思うように動かすことは意外と難しい。

もっと難しくなるのは組織です。部署あるいは50人くらいのベンチャーであれば、組織丸ごと自分たちが思い描くように動こうとすると、難易度がはね上がるわけです。

それは、一人ひとりが持っている認識が違うからです。一人ひとりが持っている認識はさまざまですが、多くの場合は現状を維持しようとするモメンタムが働く。なぜなら今までそうしてきたから。「みんなそうしているし、前例やルールがあるからそういうことなんでしょう」と自ずと判断する。それを乗り越えるというか、そこに向き合わなければなりません。

それが組織レベルになると、認識や組織の常識になっていき、1人の人が変えることは意外と難しいのです。

それは経営でも無理です。経営者の判断やコミットメントがないからうまくいかないという話を聞きます。それらは組織を変えていくのに必要な条件ではありますが、それさえあれば組織が変わるかというとそうではない。そんなことができるなら、日本中の組織がとっくに変わっているし、DXみたいな言葉は要らないわけです。

組織やチームには、いろいろな生身の人間が存在している。組織図を描いて、そこに箱と線を描いてある人に伝えれば、全部みんなに同じ粒度や深さで伝わる。そんなわけはない。我々はそんな単純なものではないんです。だから、1人の人間が（変えるために）突き動かすのは難しいんです。

ファイブフィンガー3（FF3）の罠を抜けられるのか

となると、「これは変えようがないのではないか」と気づいてしまうわけです。これは困る。本当に組織は変われるのか、ファイブフィンガー3（FF3）の罠を抜けられるのか。

結論から言うと、私は勝てる勝負だと思っています。それは、今日本の組織が置かれている状況は、20年前のソフトウェア開発と同じだからです。

20年前のソフトウェア開発は、まさしく効率への最適化一択でした。

仕事の手戻りが起きないように、工程を置いて決めたことにする。そして、決して工程を後戻りしない掟を作ってやる。先に行って「これじゃない」となってやり直しをする頃には、時間もお金もなかった。

そんなことをやっていた時代は過去のものにしていい。“デスマーチ”という言葉がありました。それでもとにかくやらなきゃいけないけれど、「とにかくやれ」と言うのは不条理だし、やっていることは非効率なのではないか。非効率でもとにかくやらなきゃいけなくなると、人をどう扱うか。機械的な扱い方にならざるを得ない。

アジャイルが思考停止を変えていく

その中で生まれたのがアジャイル開発であり、アジャイルに対する期待です。アジャイルそのものは、みなさんには言わずもがなだと思います。

アジャイルソフトウェア開発宣言は4つの価値観を示してくれました。

アジャイルが思考停止を変えていく。思考停止、あるいは効率化への最適化とは違う選択肢になり得る存在ですが、よく見るとその中身にはいろいろなアジャイルがあるんです。

チームで仕事をするためのやり方としてのアジャイル。探索や適応など、何かサービスを作る時に必要なアジャイル。あるいは組織運営としてのアジャイル。アジャイルの方法を支えるアジャイルマインドのような構造があります。

チームで仕事をするためのアジャイルは、アジャイルを回転させようということです。状況をよく見て計画を立てて、短い期間で実際に進んだ結果から適応していきましょう。

このサイクルを回した結果、得られるものはいろいろある。フィードバックに基づく開発によって、目的に適したシステムに近づけていく。つまり、速く回転させることによって、早くアウトプットが生まれる。“早く”というのは、1週間や2週間でアウトプットを生み出すことです。そのような距離感の中でフィードバックを早く回収できれば、間違ったものを作り続ける状況を避ける可能性が高まります。

そういうところを基礎とした上で、さらに次のアジャイルがあって、だんだんそのアジャイルの難易度が上がるというか難しくなっていく。

「プロダクト作りには何を作るべきなのか」を、仮説立てて検証してアジャイルを作っていくことが求められているので、こういった動き方も取らなければいけなくなります。

そういう複雑な動きをしていくためには、どんな価値観が必要なのか。

価値観や判断基準がバラバラなままだと、複雑な仮説を立てて検証してアジャイルを作るような複雑な動きは取りようがない。だから大事です。

（次回に続く）