「うちは特殊だからスクラムは合わない」は本当か？
こんにちは。kubopです。
よく「うちは特殊だから、難しいからスクラムは合わない」というお話しを聞いたりします。
これって本当なんだろうか、本当に特殊なんだろうか？難しいからスクラムが適用出来ないのだろうか？と歩いていて思いました。
私はいくつかの企業を転職して経験していて、だいたい5社ほど、カジュアル面談など含めたら数十社から「うちは特殊、難しい」「教科書通りのスクラムは合わない」という話をちらほら聞き、そうなのかなぁ？なぜかな？？と疑問に思いました。(批判する意図はないです。
疑問に思う一方で「確かにそうなのかもなぁ」と考える自分も自分もいました。
しかしながら、これらのことをちゃんと向き合って分解して自分なりに考えてみようと思います。（合ってるかは不明ですw
何が特殊で、難しいのか？
確かにシステム開発の仕事はどれも特殊であることが多いし、難しいです。
ステークホルダーからの要求や、社内の限られた資産内で解決しなければなく、利用ツールも時間も限られているからです。
効果などを調査する必要もありますし、自分の知らない技術を使って解決することもあります。
このように、大まかにシステム開発を捉えると「特殊で、難しい」というのはどの企業も当てはまるような気がします。
ですが、ひとつひとつ要素を分解してみると、一部当てはまり、一部は当てはまらないのではないかと思いました。
本当に特殊で難しい部分と、そうではない部分を切り分けて考えることができれば、よりシンプルにシステム開発という仕事を捉えられるような気がします。
人
まず特殊で、難しいものの代表として人、特に人によるスキル差です。
ある分野に詳しいが、ある分野に対しては啓けていないといったことが往々にしてあります。全員がGoogleエンジニアのようなスキルを持つわけではなく、徐々にスキルアップし成長し、しかもその成長速度は人それぞれという特徴があります。
ドメイン・機能
多くの企業が共通のドメインを持ち、同じ機能を持ち、サービス特性を持っている場合、それはマーケットフィットを狙える商品ではありません。他の企業にはなく、珍しい機能があり、珍しいドメインだからこそ価値が生まれるためです。
銀行のシステムもあれば、メディアのシステムもあり、医療のシステムもありますし、それぞれのシステムでの機能差は確実にあります。
組織・チーム
組織やチーム構成は、ある程度ベターなプラクティスや組織論のようなものを書籍でいくつか見かけることがあります。
ある種の型があり、多くの企業が共通して適用している可能性が高いもので、知見がさまざまなところにあります。
利用技術・アーキテクチャ
Goを使っている企業、Rubyを使っている企業、さまざまな技術を使っている会社がたくさんあり、多くの人が利用するツールや言語にはコミュニティが存在し、知見がインターネット上にたくさんあります。
開発・デプロイのプロセス
リリーストレインやそれこそスクラム開発、カンバン、XPなどさまざまな種類が存在し、それに関する知見はインターネット上にたくさんあります。
そもそも特殊で難しいものと、特殊で難しくできるもの
基本的に特殊で難しいものは、ドメインになるような気がします。
これは配られたカードで戦うしかないものです。所与の条件です。
ビジネスを変えない限りドメインはコントロール不可能です。
人も採用によってコントロール可能かもしれないのですが、基本的にコントロールすることが難しいです。勉強会、スキルアップなどを含めると時間経過によってコントロール可能になっていく可能性はありますが…
一方、組織・チーム、利用技術・アーキテクチャ、開発・デプロイのプロセスはコントロール可能のように思えます。
これは料理でいう素材の有無や種別ではなく、調理方法に近いです。
しかしながら、コントロール可能な故に独自性が発達しやすく、システム開発を難解にする要因になっている気がします。
例えばスープを作るにしても、裏漉しをする、パセリを刻むのではなくすり潰す、などレシピによって独自性を持たせることが可能だからです。
何がスクラムと合わないのか
特殊で難しいもの、を複雑な問題を抱えるドメインと、予測不可能な人と考えた場合、スクラムが合わないとするのは何故なのでしょうか。
スクラムの定義
スクラムの定義として、スクラムガイドには以下の記述があります。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織 が価値を⽣み出すための軽量級フレームワークである。
これを読むと、スクラムは複雑な不確実性の高い問題を抱えるドメインに対する解決策の1手段だということがなんとなくわかります。
スクラムを構成するのは、作業 に必要なすべてのスキルや専⾨知識をグループ全体として備える⼈たちである。また、必要に 応じてそうしたスキルを共有または習得できる⼈たちである。
スクラムにおいて、人がスキルを習得し、それを支援するような動きが推奨されていることがなんとなくわかります。
スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されなければ ならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、 検査を⽀援するために、5 つのイベントでリズムを提供している。
ふむふむ、進捗状況を検査されるのであれば、人による成果物の差分もある程度埋められるかもしれない。
スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。スクラムチーム は、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。スクラムチ ームとステークホルダーは、作業や課題を公開する。スクラムチームのメンバーは、お互いに 能⼒のある独⽴した個⼈として尊敬し、⼀緒に働く⼈たちからも同じように尊敬される。スク ラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。
スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から⽣ まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
あれ？特殊で難しいことの対抗手段としてスクラムがあるのでは？
スクラムガイドを読んでみて、スクラムとは複雑な問題を抱えるドメインと、予測不可能でスキル差がある人の問題に対してのソリューションを与えているような気がしてきました。
特殊で難しいからスクラムを適用できない、のではなくて特殊で難しいからスクラムを導入する、が正解なのかもしれません。🤔
私たちが自分でものごとを「特殊で、難しく」しているかもしれない
スクラムが特殊で難しいことの対抗策である場合、スクラムを導入できない原因は一体何なのでしょうか。
恐らくそれは、上述した「調理法」を自ら難しくしているからなのではないかと思いました。
キメラ化
私たちはインターネット上にある、様々な知見に触れることが多いです。スクラム、ウォーターフォール、クリーンアーキテクチャ…様々な原則があり、日々のシステム開発に役立てています。
しかしながら、それらを完璧に理解した上で運用したことはないんじゃないかと思います。自身でも気がつかないうちに手法のキメラ化をしているのではないでしょうか。(私もそうです。
それはもしかしたら、時間の制約があるかもしれないし、人の制約があるからかもしれません。難解すぎて学習が難しいことも原因かもしれません。
アーキテクチャに関しても同様で、ある記事ではこの構成がよく、ある書籍ではこの構成がよい、ならば組み合わせたほうが良いといったような形で導入されているかもしれません。
そのようにして、手法のキメラ化をすることで、ものごとはより難解で複雑で、特殊で独自性に富んだものになってしまい、改修が難しくなってしまっている可能性があります。
サンクコスト
このようにして行われた手法のキメラ化は、なかなか捨て去ることが出来ません。これはサンクコストと呼ばれます。
サンクコスト（埋没費用）とは、「すでに支払ってしまい、取り返すことのできない金銭的・時間的・労力的なコスト」のことです。
そして、「サンクコスト効果」とは、「すでに支払ったコストを取り戻そうとする心理効果」です。サンクコスト効果の影響を受けてしまうと、サンクコストに気が取られ、合理的な意思決定ができなくなります。
私たちは、このサンクコストの概念により、これまで積み上げてきた独自の手法に囚われてしまい、新しい概念や、はたまた伝統から離れ、さらなる独自性を築きます。
その結果、自己強化型ループに陥り、さらに複雑性を増してしまうでしょう。
基本に立ち返ることの大切さ
手法は独自性がなくても良いかも
ある地域に向かおうとしたときにあらゆる手段が考えられます。
人によっては新幹線を使うかもしれないし、ある人は飛行機で、徒歩で、自転車で向かうことがあるかもしれません。
しかしながら目的地としてはどれも同じで、手法とコストの違いでしかありません。それであれば、わざわざ自分で開拓するよりも、多くの人が通った道を安全に駆け抜けたほうが得です。
再現性のあるものを着実に行い、多くの人が知見をもつ方法で行ったほうが相談もできて安心です。
私たちは巨人の肩の上に乗る小人のようなものだとシャルトルのベルナールはよく言った。私たちが彼らよりもよく、また遠くまでを見ることができるのは、私たち自身に優れた視力があるからでもなく、ほかの優れた身体的特徴があるからでもなく、ただ彼らの巨大さによって私たちが高く引き上げられているからなのだと。
守破離
手法をキメラ化するよりは、一つのフレームワークを「信じて」基本を勉強し導入してみるほうが良いかもしれません。
同一言語でも、プロジェクト毎に色々なフレームワークを使って開発するよりも、一つのフレームワークで統一感をもたせたほうが参入障壁が低くなったり学習コストが下がるといったこともあります。
スクラムを使ったら成功するのか、といわれればそうではないのですが、これはどの道を選んでも同じことだと思います。
スクラムはある程度導入実績があり、成功体験もあると思いますが、逆にキメラ化した独自性の高い手法の成功確率は、未知です。
守破離とは、茶道や武道などにおける師弟関係のあり方の一つと言われています。
「守」=伝統を守ること。
「破」=守を破り、他で学んだことを実践すること。
「離」=守と破を大切に、そこから離れて新境地を作ること。
まとめ
今日はてくてくと歩いていく中で、特殊で難しいからスクラムは合わないということをどう考えれば自分で納得できるかなと考えていました。
「うちは特殊で難しい」という話を聞いて違和感を感じました。確かに仕事は難しいものではあると思うのですが、部分的にそうで、部分的にそうではない可能性があり、分離して考えることで不確実性を取り除くことができるのではないかとモヤモヤと考えました。
「うちは特殊で難しい、だからスクラムは導入しない」あるいは「教科書通りのスクラムはうちには合わない」と思っている方がいらっしゃるかもしれないですが、改めて何が合わないのかということを考えてみて、基本の型に立ち返ってみることも良いのかもしれません。
スクラムは銀の弾丸で何でも解決できる万能薬というわけではありませんが、不確実性に対抗するフレームワークのひとつで、これについて学んだり研究している方が多くいらっしゃいます。
教科書通りのスクラムを導入することで、もしかしたら彼らのような巨人から多くの知見を得られるかもしれません。
この記事が気に入ったらサポートをしてみませんか？