大手企業でアジャイルを実行するなら、内製化チームをつくろう
はじめに
大手でもソフトウェアをアジャイル開発をしたい、内製化したいというのは最近結構見る。僕は大手企業（製造業）で2019年に4名のアジャイル内製化チームを立ち上げて、現時点で12名の組織に拡大している。そこではスケールのため様々な議論をしてきたが、判断基準としては、競争優位となるコアドメインは内製して、内製するならアジャイルでやる、ということに落ち着きつつある。もちろんそれで説明がつかないことも多いけれど。
今回は、どうやってアジャイル開発を大手で導入したらいいか、という観点で、これまでの経験を交えて記事を書いた。タイトルの主語がデカいので反感を買う可能性はあるけど、色々試してみたいという想いでチャレンジしている。
アジャイル開発を始めるとき
取りうる選択肢
冒頭の判断基準からすると、アジャイル開発するなら内製化チームをつくれ、というのは逆かもしれないが、立ち上げ時としてはその選択は妥当じゃないかと思う。立ち上げ時にアジャイル開発を行う上でとりうる選択肢としては（考え得る限りは）３つある。
会社の開発プロセスを変える
会社の開発プロセスに合う範囲でアジャイルを取り込む
会社の開発プロセスから独立したチームを作る
それぞれコメントすると、
1、会社が大きいほど難しい。それに多くの人の納得を得る必要があるし、そもそも全体を変えることが良いとも限らない。
2、妥協案のように見えるが、改善すべきプロセスの方に寄せてしまい、効果を得にくい。この場合アジャイル的などと説明され成功談として流布される。（僕はいささか懐疑的だ）
3、個人的に最も効果的だと思う方法。
3は専門用語で言えばIsolated pattern（孤立チーム）という。以下の記事では、チームを切り離して違う方法で進められることを伝えると、素晴らしい事がおきる、と言われている。完全に同意見だ。
“Processes grow so heavy as a company grows. It’s hard to innovate when you’re moving like a glacier. Taking a team off to the side and telling them they can do things differently leads to some amazing things.”
孤立チーム
僕が2019年に4名の内製化チームを立ち上げた際には3の方法をとった。Dynamic Reteamingはまだ発売されていなかったが、もともと納得性のない規律を守ることが嫌いなタイプだったので迷わず孤立したチームをつくることにした。妥当な理由としては、森岡毅さんが言っているように、水は下から登らないので物理法則に逆らうような手段ではなく、勝てる勝負ができるところを探せ、的なこと（記憶が曖昧）からくる。言い換えれば、一番少ない入力で最大の出力が出るから、ということ。
偉くもない立場で孤立チームを作るのはもちろん簡単ではない。まずはトライアル的に動ける環境や、人員確保（OJT）、それまでの実績など、色々と準備は必要だった。ある程度の信頼を築いておかないと許可を得るのは難しい。こういった話は本記事の主題ではないが、過去のnote記事にもまとめている。
じゃあ孤立チームを作ればうまくいくのか、と聞かれれば、半分あっていて半分間違っている。あっている部分は、大手にとって最大の課題は孤立チームをつくることなので、後はある程度自然の摂理でうまくいくだろうということ。間違っている部分は、その自然の摂理でチームが失敗することもあるということ。その中で重要視するのはチームの健全性（継続可能性）だったりする。RSGT2024に参加していて、同じことを考えている人がいるなと思ったのは、チームの関係の質からはじめる、ということ。楽しいって大事。
自然の摂理
栄養が与えられないと植物が育たないように、適切な環境がなければ腐ってしまう。雨が続けて降らなかったり天災があったらよい実はならない。だからどれだけうまく育てるか、というところには工夫の余地がある。つまり、素晴らしい成功をおさめるチームを作りたいなら、それを支配する法則（チームやパフォーマンス、人など）に則って、継続的に成長し続ける必要がある。
うちの場合は、僕自身が土日や仕事後に本を読んで調べたことを実践したり、メンバーに共有したりしたことは、チームの成長に必要だったんじゃないかと思う。それにタフなメンバーがいたこと、好奇心の強いメンバーがいたことも必要だったと思う。どんな環境や刺激が合うかは、当然集まったメンバーによる。ただチームのメンバーが信頼し合えれば、困難は突破できると思う。チーム・ジャーニーを読んだ時、僕が言いたいことをまとめて言ってくれているように感じた。
後はもちろん心理的安全性や失敗の科学のように学習を奨励することなど、人間というドメインに関する知見も、使えるか使えないかによって成功は左右されると思う。こういった話も面白いと思うのでどこかで記事にしたい。
孤立チームである必要性
自己組織化
孤立チームである必要性は一言でいえば自己組織化であり、言い換えれば、リリースや品質、技術選定、QCD、保守運用、あらゆることにそのチームが権限と責任を持っている必要があるということである。社内ベンチャーのようなイメージが近い。
なぜ自己組織化が重要かというと、アジャイル開発チームを立ち上げるとは、文化を新しくつくることであり、そのためにはソフトウェア開発全てに関わりプロセスを改善していく必要があるからである。結局のところソフトウェアの開発プロセスのどこかを分断してしまうと、全体最適化することが難しくなり、アジリティーをもって活動することができなくなる。
割れ窓理論
「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」
システム開発も同じである。
例をあげると、うちの場合は素人集団で開発を始めたこともあり、まぁまぁ品質問題を発生させていた。その課題感からQAに詳しいエンジニアロールをチーム内で作り、その人を中心に品質について勉強してテストを見直して課題に対抗してきた。一方でそのとき、社内の別チームであるQAチームから、統合テストとか大変で面倒だろうしうちで見ますよ、という打診があった。これに対しては気持ちはありがたいが、強い意志をもってお断りした。なぜかというと、プロセスの一部をチームの外に出してしまうと、チームはそこについて関心を払わなくなるから。
テストピラミッドを想像してみてほしい。一般的な戦略は、下から単体テスト（Unit Tests）でコンポーネントレベルの挙動は抑え、結合テスト（Integration Tests）でその連動部分を抑え、最後にUIやバックエンド含めた連携を総合テスト（UI Tests）で抑えることである。ここでもし総合テストをチームの責務から外したら何がおきるだろうか。
答えは、このピラミッド全体で品質を作り込もうという意識がなくなることである。総合テストを小さく保とうという気も次第に失われていく。そもそも総合テストは面倒くさいし大変だからこそ小さく抑えたいのである。開発チームが面倒だと思うことこそ重要ではないか。だからこの境界は切るべきではない。結果として全体最適化から離れた文化が形成されていくだろう。
これば別にテストに限った話ではない。保守運用を責務から外せばコードの保守性の意識は失われるし、要求分析を外せばプロダクト価値の意識は失われる。最終的にその意識の流出はプロセス全般に伝播してアジリティーを損なっていく。孤立チームであることは非常に難しく大変なことではあるが、ある意味で修行として申し分ない内容となる。
もちろん部分的な分業で成功する事例もあるだろう。ただそれはあくまできちんとアジャイルを理解しているからこそできる芸当ではないかと思う。最初にするにしては難しすぎる。
（ちなみにここであげたうちのチームの事例は、QAのいないスクラムチームは品質の夢をみるか、というタイトルでJaSST Toyko 2024で登壇します）
プロセスを改善できる自信
プロセスは守るものであってなかなか変えられないと捉えている人はいるのではないかと思う。僕は反骨精神が強いのでよくこの点で上長とやりあった経験がある。結局、変えられない部分はどうしてもあって、何度も繰り返すうちに考えるのも面倒になってきてしまった。したがっておけば楽じゃん。
アジャイル開発をするならこれは引き起こしてはいけない。どんなプロセスも形骸化していたり改善する必要があればすればいい。変化に適応できなければ生き残れないのだ。だからこそ重要なのは、プロセスを改善できるという環境であり、自分達で変えていって作っていって良いんだ、と実感することである。だからこそ自己組織化されている必要がある。
大手であるということ
開発の素人集団
大手というとユーザー企業として開発はベンダー利用も多く、新入社員もメガベンチャーのように即戦力となる人はあまり採用されないし、システム開発について育成できる環境も十分にはない。なので素人集団になりやすいのではないかと思う。
実際にうちのチームもその状態で、やる気とバイタリティーはめちゃくちゃ高いが、なにせ開発やプログラミングにおいては素人だった。僕はまだPythonについては経験がある方だったが、JavaScriptは当時初めて触ったし、他メンバーはLinuxを大学で触っていたとか、授業でプログラミング触った程度の新人である。記憶にあるのは、当時jQueryで動的な操作を実現したときに感動したことがあって、勢いでqiitaに投稿したことである。多分チーム結成後1ヶ月くらいの時で、メンバーに共有しながらワイワイしていた。当時の技術レベルは高くなかったことが実際に伝わるのではないかと思う。
このチームでは、猪突猛進で壁にぶつかるたびに何かを改善していく、ということをただ繰り返してきた。この内容はEdgeTech+2022で講演したことがあるが、そのうち別の記事で拾いたい。短い時間で話しきれない部分もあり、どういう価値観でチーム文化をみんなで作っているのかなども紹介していきたい。
大手ならではの利点
それはスタートアップと比べて時間的猶予や予算が比較的あるということ。ベンチャーの場合、競争優位に立つためにどうしても速度を優先しなければいけないことがある。質とスピードはトレードオフにはならず、実際には犠牲になるのはチームの学習である（もしくはQCDのDか）。大手の場合、プロジェクトを遅らせても倒産はしないだろう。じゃあ大手の方がやりやすいのかと言われたら、文化や体制的に反発が生まれ得るので、一概に言えないと思う。
さいごに
製造業に所属してアジャイルを推進するために闘ってきた経験からすると、アジャイルを導入し辛いのは別に誰かが悪いとかそういうわけではないということ。みんな良かれと思って色々なことをしているし、既存プロセスを変えてアジャイルでやればうまくいくなんてのは現場や組織の事情を知らない傲慢でしかない。だからうまくアジャイルでやりたいなら、その適切な環境をつくるのがもっとも敵対せず安全にできることだと思う。
ただ個人的な想いとしては、もっとアジャイルで開発して楽しく働ける人が増えたらいいなというものはある。そうすれば自然とパフォーマンスは上がって成果にもつながると信じているから。
ある一つの成功事例で何が言えるんだ、と思われるかもしれないが、少なくとも5年間に経験した内容は多岐にわたる。チーム結成前のスクラムチームを戦略的に解散したり、メンバーの離職に伴いチームの結合をしたり、チームを増やしたり再編したり、上長や経営層と相談した（言い争った）り。
それにこういった記事を書いている目的は、こういった方法や考えが他にも通用するのかどうかに興味があるからである。読んで共感してくれた人がいれば、実践して結果が記事になる可能性もあるだろうし、相談を受けて話を聞いてみたいと思うこともある。
自分ならではの価値と考えた時に、大手製造業というアジャイルの難しいそうな領域で、ソフトウェア開発を内製化するチームを立ち上げて成長させた経験だろうと思う。今は無名ないちプレイングマネージャーではあるけれど、こういった活動や経験を通して他社から相談を受けたりコーチングに繋げたり、色々なことを実現していきたいと考えている。
この記事が気に入ったらサポートをしてみませんか？