昔Wantedlyに書いた記事の2025リライト版の記事です。

アジャイルってこういうメリデメあるよね。
世の中にはこういう需要ありそうだよね。
そこに対してこうビジネスしたいね。

みたいなやつをまとめておこうと思って書いたやつ。BAMVに発注を考える人、BAMVに応募を考える人。社員。その辺の方向け。
ぜんぶやると長くなるので、ここでは内製チームの採用・育成の課題と、そこへのソリューションの話に絞ろうかな。

みんながアジャイルに求める”機敏”さ

大規模な基幹業務システムの開発・リニューアルや、その運用。すべてではありませんが、これはあまりアジャイルでって話にならないですよね。優秀な情シス部門が大手のSIベンダーに発注。クラウドサーバの普及もあってか近年は、運用部分をエンドクライアント側で巻き取っちゃう話も増えているそうで、エンドさんたちも運用の内製化を進めており。外注・内製をうまく使い分ける時代になってきたと感じます。

さて、情シスに依頼し、作るものを決めきり、契約を詰め、SIベンダーに発注する。確実性が高く、システムの品質も担保できる理想的な流れではありますが、機敏ではない。

事業部サイドとしては、刻一刻と変化していく市場と向き合い、競合を出し抜き、場合によっては新たなマーケットの開拓も必要です。このような環境に『確実さ』を求めることはできない。もっと機敏に、小さく行い、小さく失敗する。そういうことを気楽に・安価に繰り返したい。このような小規模・高回転の需要に関しては、確実ではあっても既存ベンダー型のシステム受注・開発の流れはフィットしない。

このような背景があってか日本においては、事業会社側がアジャイルに積極的、ベンダー側が非積極的（又は、アジャイルの名で変則ウォーターフォールモデルを売り込もうとする。）と言う環境が続き、特に近年においては社内に内製開発部隊を用意、機敏に開発需要に対応させようと言った動きがみられます。

アジャイルの内製体制つくるとはいうものの、難しい。

BAMVはベンダーの立場ですので、事業会社に比べてエンジニアの育成では有利なポジションです。しかしながら10年以上やって思う事は、とにかく大変。各チームメンバーに求められる要求水準が高い！維持も大変。正直な所まだ納得いくレベルではありません。世の中、デメリットなどの情報はあまり語られないので、会社さんによっては『アジャイル詳しいです』みたいなコンサルの勧めでなんとなくでスタートしてしまい、採用・育成上の課題にぶつかりまくり、そのたびに消去法で弥縫策を打っていく。その結果できたのは園児ニア保育園でした。なんてことが本当によく起こります。

ネット記事などでよく見る理想論ではなく、アジャイル組織作るを10年やってみて、こういう制限が必要だな。この理想はこの現実で実現できないな。こう対処・回避しなきゃ。みたいなのが溜まってきたので、それを下記に記載していきます。　まあ、アジャイルのデメリット・ハードルですね。

マインドセット重視の採用が必須

『まずスキル』じゃないです。『まず人格。』プロジェクトの目的に対して主体的に行動できる人物でなくてはいけません。
アジャイルの手法はどれもだいたい『管理・監視』が苦手です。（scramなど、リーダー不要と言われたりする）　と言うか、この面はウォーターフォールが優秀。ガチガチに管理されないとワークしないタイプの人物がアジャイルに参加しますと、管理側の負担と要求能力が跳ね上がります。（監視をする為には相手のタスクを把握、実行できる能力がなくてはならない）管理する為の手法とは言えないアジャイルでは管理限界も低いですから、このようなスーパー管理者が大量に必要になることとなり、優秀な管理者が少ない・離職する。と言う状態を引き起きします。

さて、経験者採用において特に採用しやすいのが、このウォーターフォールの下流で管理されることでワークする人物たちの層です。彼らは、ウォーターフォール、SIer、常駐、管理、SESなどに、強い恨みを持ちがちで、事業会社のアジャイルチームなど絶好の逃避先に見えることでしょう。ですが、アジャイルチームを実現するならば、彼らの採用はできません。（採用したら本当にマズイので、これを書いてもぼくは損しないのです）ただし、新卒・未経験層においてはマインドセット重視の採用もまだまだ可能です。また、最初から人格が把握できているジョブローテーションでの社内調達なども案外悪くないかもしれません。ただし育成の仕組みは必須になります。

テクニカルスキルの素養も軽視できない

よく言われる、『アジャイルではシステム一本作れるレベルの人しか使えない』と言うのはウソです。これはチーム内に協調性のないメンバーが多い場合、チーム内でスキルの相互補完性が発揮されない。いわばチームビルディングに失敗している状態で発生する問題です。こうなりますとメンバー個人への属人性も高くなっていき、発言力も強くなり、コスパも悪化していきます。本来のアジャイルチームはチーム全体でスキルを持ち寄り、結果的に一本のシステムを作れるだけのスキルセットが揃っていればOKです。前項の新卒社員の育成等も可能です。
が、やはり限度はあります。

アジャイルチームが投入される目的は、市場実験的なPoCであったり、変化に対応しながらの継続的な開発となりがちです。当然、新しい技術や実験段階の技術を使ってみると言う事も多くなります。技術はだいたい新しい方が安く上がりますしね。と、なりますと、アジャイルチームのメンバーは次々に登場する技術に対応・学習し続けていくと言う事になります。ここに抵抗を感じてしまうタイプですと、向いているとは言えません。　また、プログラミングは個人ごとの適性の差異が大きく、適性に乏しい人物ですと学習コストが跳ね上がってしまう現象が起きます。プログラム未経験者の大量採用を行ったが、1年で半分が離職してしまったなど、よく聞きますが、多くの場合、この適性不足が主な原因です。採用時にはこの適性をしっかりチェックできる必要があります。

技術力高くても、自己中は獲っちゃダメ

技術的な感度が高く自身のキャリア構築に関心の高い活動的なエンジニア。このタイプ、一見いいんですが、実はけっこう使い方難しいです。アジャイルチームのメンバーが優先的にコミットメントするべき先はあくまでビジネスに資する事であり、自身のキャリア構築じゃないんです。このタイプ、プロダクトで使用する技術や環境、ポジションなどで訴求すれば比較的容易に釣り上げられる為、10年くらい前に人材ビジネスの広告などでもてはやされましたが、すぐにいろいろと副作用が見えてきました。

【経歴書駆動の技術選定・作り逃げの発生】
積極性も学習量もある彼らに技術や環境の選定を任せた結果、プロダクトの目的にフィットした選定よりも彼らの経歴書の価値向上が優先されてしまう。事が多々あります。目的に合わない技術が使われてしまうので、運用コストは高くなりますし、作業量も多くなります。　で、さらなる経歴書の価値向上と報酬を求め、転職します。彼らには悪意は無いのですが、視座が限定的であることが多く、広告などで形成された価値観を持ちがちで、ビジネス的な背景やプロダクトの目的を優先しなくてはいけないのだという認識自体がありません。
ほか、これはエージェント経由のフリーランスなどでもよく発生する話です。彼らの取引先はあくまでエージェントですので、その先の一時的な取引先である事業会社と彼らの利害が一致しない訳ですね。その次の契約を考えた場合、経歴書を優先する判断が実は合理的となります。彼らも事業者ですから、自身のビジネスを優先します。

【保守性・継続性の軽視】
例えば『アジャイルはドキュメント作らない』なんて誤解は完全にこの文脈かなあと思います。長く維持せず、捨てる想定のシステムであるならばさほど問題ないと思いますが、継続的にシステムやチームを維持していくのであれば、改修やバージョンアップ。人の入れ替えやなども現実的に発生します。ドキュメント未整備のまま人が増えたり入れ替わったりしますと、新参入のメンバーは『どこになにがあるかわからない』『影響範囲がわからないので毎回調査から必要』などなど、ものすごくパフォーマンスが発揮しづらい状態からのスタートになります。
後発のメンバー側へのスキル要求を上げることで対応する例はよく聞きますが、時間経過で要求スキルはどんどん高くなり、調達コストや人員のやりくりの上で非常に無駄が大きくなっていきます。先にいるメンバーへの属人化が進み、上記の作り逃げ退職発生の際などには高額の報酬で残ってもらう調整をする羽目になったりと。トータルでとんでもない損失を生み出すことになるでしょう。それに対してドキュメントを作らないメリットは『作成する時間が不要』と、たいして無いので、だいぶ非効率寄りのスタンスと言えるかなあと。もちろん新卒を育成するにも向かない環境となります。

【チームの相互補完性の喪失】
自己中なんだから、助け合ったりしません。自分のタスクだけやります。自分個人のタスクは完璧に遂行されます。他の新規メンバーが質問してもなかなか返答くれません。新規メンバーの生産性は落ちます。落ちるので、先行メンバーの評価は相対的に高くなります。先行メンバーのなかには助けようとする人もいたとします。その人は新規メンバーを助ける分、余計に稼働します。自身のタスクにも影響出るかもしれません。余計に稼働した部分はチーム外からは見えませんので、助けた分、評価が下がります。損をするので助けなくなります。　こうなるともう終わりです。そのチームからは助け合い・スキルの相互補完性が失われ、『システム一本作れるレベルの人じゃないとワークしない』状態が現実に発生します。ここでも調達コストや人員のやりくりの上で問題が発生します。もちろん非効率。育成にも向きません。

プロダクトオーナー役がいない

難題です。　
まず、日本ではあまりスクラム等が普及しておらず、経験者がおりません。また一般に、スキル要求が高い職です。ビジネス側の要求を背景から理解し、優先順位を調整し、次に、Devチーム側と対話し、システムの都合も考えて開発の優先順位に落とし込んでいかなくてはいけません。開発チーム・自社のビジネスサイド、双方の知識が必要になるとされます。加えて日本には解雇制限もあり、高額な人材ながら簡単に採用して解雇してとはできません。
たたし実際には、プロダクトオーナーはアジャイルチームの一員ですので、チーム内からのスキルの補完を受けることができます。ビジネスサイドの要求を理解・調整できる人物がアサインされていれば、システム開発側の優先順位はDevチームのメンバーと共に検討していくでＯＫです。アジャイルに不適なメンバーでチームを構成した場合、管理側の労力・求められる能力が跳ね上がる現象がここでも頻発しており、ゆえに、異常なハードルのプロダクトオーナー募集の求人が飛び交う。紹介会社側もそういうもんだと思ってしまっている。と言うところでしょうか。

そんなこんなでいろいろ難しい

アジャイルチームは、プロダクトや事業にコミットメントし、他部署との連携も含めた対話を重視。継続的に改善活動を行う集団です。それらに対してモチベーションを持てるタイプの人材がそろっていなくてはいけません。　自己中心的・経歴書を最優先とし、協力・対話を好まない人材が多数となりますと、アジャイルはまったく機能しません。これらは採用の時点で注意されなくてはいけない内容ですが、このようなマインドを兼ね備えた技術的に問題の無い人材となると、大手企業の採用ターゲットともバッティングし、採用の成功はとても困難になります。
素晴らしいマインドセットを有する優秀な部隊を作ったとしても、離職をゼロに抑えられると言う訳ではありません。
ベンダではないエンドユーザーに当たる立場の方々が、これらのハードルを乗り越えて、自律的なチームを構築・維持していくハードルはかなりのものとなるのではないでしょうか。中途半端なことになると大変で、コストだけが無限に流れていく事にもつながります。

適正な内製・外製比率と、ベンダーによる内製化支援

で、解決策としてこの辺を提案するよと言う話になる訳ですが。
なんかよく内製化を支援しますみたいなこと言ってるベンダーいますが、お前ら内製化するって言うと嫌な顔すんだろ。どういう動機があるんだよ。って普通思いますよね。ぼくも他社のコーポレートサイト見て、よく同じこと思ってます。BAMV（というかアジャイルの会社？）の動機は下記の様なものです。

BAMVが内製化を支援する動機

アジャイルのベンダーの泣き所で、開発終了、安定したシステムの運用フェーズに、有識者として開発者1名をロックされてしまう問題があります。
アジャイルのベンダー各社、それぞれの工夫・対応を行うところでして、リモートでの請負契約にするなどの方法もあるのですが、いずれにしてもこの有識者1名が退職してしまうと大変なことになる為、BAMVとしてはできればやりたくない仕事です。
BAMVとしては、クライアントの社員様、少なくとも2名（退職対策）に運用を引き継げる体制を作り、開発終了したシステムから撤退。他の需要にリソースを振り分けていく方が建設的で、クライアント様としてもベンダーロックインが発生せず、コストも抑えた形で運用していけますので、WinWinなのかな。と。

PoCこそ外注でいい。

運用は必要人数が固定的で、費用も継続で発生します。外部ベンダーにここを握らせますと少なからずベンダーロックインが発生し、ベンダーから巻き取る・ベンダーを交代させるなども困難に。割高な外注費が延々と発生。システムリプレイスをしようにも、既存システムの情報はロックイン中のベンダーが握っているという状態になります。これはやはり非効率。基本的には社員様で対応可能な状態を作りたいところです。
反面、実験的なプロダクト、需要があるかやってみないとわからないプロダクトなどについては、作った後にすぐ捨てるパターンも発生します。このようなスポットの需要に関しては、増減が容易な外部ベンダーのアサインが効率的かと思います。結果的に需要があったら運用に乗せるでよいのです。
BAMVのような外部のアジャイル・ベンダーは、このような需要に投入するのが良いですよ。と、ポジショントークしておきます。

やりかたはいろいろ

最終的にどういう形に持っていくべきかで、取るべき手段も変わります。
冒頭から記載しましたように、機敏さを持った完成されたアジャイルチームを作りたいという話になりますとオオゴトで、採用フェーズからの支援が必要になるかと思います。プログラミング適性の判別などについては弊社サイドで手法を持っていますので、この手法の提供なども可能です。逆に、適性不問で送り込まれた人材を次々に送り込まれましても、こちらが成果を提供することは難しいかと思います。また、多数の人材を育成するとなると、また別のビジネスになるかと思います。我々としてもWinWinとは言えない構造になりますし、お受けいたしかねることも多いのかなと。運用担当を少数名用意したいという事であれば、事業コミットの有無を優先して採用できる若手層や自社内人材を、適性判断の上でチームに投入。スキルアップと共にシステムを把握させて置くという事ができますね。前述しましたが、離職対策で最終的に2名体制が必要です。

まずはお互いの勝利条件を把握し合いたい

世の中の企業はそれぞれ目的があり、それぞれの手段で目的に向かって邁進しています。　ただ単に取引をして、2社間の利害が一致することはそうそうないと思いますが、相手方の置かれている状況や勝利条件がわかれば、互いにWinWinの構造へ向かうよう調整し合うことができます。逆に互いに相手方の利益を軽視、自身の利益を追求する形になりますと、囚人のジレンマのような状況に陥りやすい。それでは効率的とは言えません。　前提にWinWinが無ければビジネスは継続しません。

アジャイルは、プロセスやツールよりも対話を。契約交渉よりも協調に価値を置きます。内製化支援のような中長期のミッションには、このような思想のベンダーが必要です。

まとめ

分量が大きいので、①採用・育成編 と言う事で分けて記事を書きましたが、これでも長くなりましたね。
記事を読んで感じられた方も多いのではないかと思いますが、アジャイル開発の文脈で世の中で語られていることは誤解や思い込みがかなり多いですし、思い込みで進めてしまうと、とても非効率な状態が発生しがちです。

我々も大企業と言うわけではなく、リソースに限りがある為、常にお役に立てますというわけではありませんが、これを書いているのは営業側ですので、ご相談へのご対応は容易です。まずはお気軽にお問い合わせいただけますと幸いです。

BAMV合同会社 コーポレートサイト お問い合わせフォーム

TEL：03-6424-7968　　担当者：寺野・園生