結構社内向けの内容。
対エンドで提案する内容とか、各社員が説明できるように、資料的なもんを用意してくれって言われたので、まずはテストっぽい要素もふくめつつ。とはいえ、対外的に見せられるようにはしなくてはいけないかなあ。

あとまあ、そろそろパクるのが不可能に近い感じになったと言うのもあるか。（適合するメンバーをそろえて、育成するのは、めっちゃ時間かかる。カネや規模だけでは、競合は追撃できない）

１．アジャイルで内製開発をする。とはいうものの。

昨今、クラウドサーバの普及や、コロナや急激な円安による市場変化に対応すべく、内製開発へ舵を切る事業会社様が増加しております。なかでもアジャイルの内製化体制構築の需要が増えておりますが、実現にはなかなかにハードルがあります。

・アジャイル開発経験を持つ、対応できるエンジニアの採用が難しい。

かなりブランドか採用力が無いと無理な気がします。
また、アジャイルで成果を出す人材は、『主体性』があるタイプに限られます。アジャイル経験があり、対応できそうなスキルを持っているだけでは不足と言うのが実情です。

・チームメンバーの長期固定化が必要。

もちろん、離職が問題となります。
技術的な感度が高く、自分のキャリアの構築に関心の高いエンジニアほど、離職率は高いです。
特に初期構築時に、最新技術などで釣り上げた人材に関しては、技術が古くなる・高度な作業が減った、などのタイミングで離職する危険が高まります。しかし、システムは、時間経過で古くなります。
環境面の充実で離職率を下げようという考えもありますが、ハーズバーグの二要因理論(動機付け・衛生理論）などで考えた場合、衛生要因側で離職を防御しようとしているにすぎず、また、時間経過で効果が下がります。何より最悪の問題が飽きる事です。固定的なメンバーとシステム。淡々とチケットを処理する日々。これをクリアするのはなかなかのハードルです。

・チームのマインド設定が難しい。

アジャイルチームは、プロダクトや事業にコミットメントし、他部署との連携も含めた対話を重視。継続的に改善活動を行う集団です。それらに対してモチベーションを持てるタイプの人材がそろっていなくてはいけません。　自己中心的・経歴書を最優先とし、対話を好まない人材が多数となりますと、アジャイルはまったく機能しません。これらは採用の時点で注意されなくてはいけない内容ですが、このようなマインドを兼ね備えた技術的に問題の無い人材となると、大手企業の採用ターゲットともバッティングし、採用の成功はとても困難になります。

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

難題です。　
まず、日本ではあまりスクラム等が普及しておらず、経験者がおりません。また、要求が高い職です。ビジネス側の要求を背景から理解し、優先順位を調整し、次に、Devチーム側と対話し、システムの都合も考えて開発の優先順位に落とし込んでいかなくてはいけません。
開発チーム・自社のビジネスサイド、双方の知識が必要になる訳です。
加えて、日本には解雇制限もあり、高額な人材ながら、簡単に採用して解雇してとはできません。
スクラム等の手法が日本で普及しない原因のひとつに、私は解雇規制の存在を挙げます。

などなどです。

特に、ベンダではないエンドユーザーに当たる立場の方々が、これらのハードルを乗り越えて、自律的なチームによる開発を実現するのは難しいのではないでしょうか。中途半端なことになると大変で、コストだけが無限に流れていく事にもつながります。（こうなって断念した会社さんも多そう）

これらの問題を解決し、コストとパフォーマンスのバランスを取った状態と、アジャイル開発の内製化そのものを支援をするのが、弊社の『ＣＡＯＧ（Clarity About One’s Goal）』と言うサービスです。

２．アジャイルの開発体制の構築（CAOG）とは

《CAOG：顧客の目的を明確化、関係者全員のゴールとする。》


CAOGは、BAMVのスクラムマスター・アジャイルチームのほか、コンサルタントの投入により、クライアントのプロダクトオーナーを支援。マーケ/営業等ビジネス部署の勝利条件や優先順位が、開発チームにちゃんと伝わる組織構造を構築する手法です。

アジャイルチームがうまく回るようにできても、クライアントのシステム・弊社のチームがお互いロックインされてしまう状態はお互いによろしくはなく、クライアントがシステムの継続的運用を自力で実行できる内製体制の構築の支援も行います。クライアントは外部ベンダに依存することなく、市場や競合に対応し続ける力を得る事になります。

〇対策・アジャイル開発経験を持つ、対応できるエンジニアの採用が難しい
ご予算は必要ですが、こちらで採用と育成の支援を行います。
もともと弊社の強みは採用と育成の能力です。育成を前提にできるので、エンドが採用するターゲットの経験量を新卒～ロースキルくらいに落とすことができます。その分質を重視。（と言うか中途だとベンダ仕事に対応できなかった人がわんさか来てしまう。マインドが重要なので、これはとてもまずいです。）
質の高い新卒や未経験者は、半年ほどで開発チーム内で戦力となり、3年ほどで主体性を持ついっぱしのエンジニアとなります。ペアプログラミングなどを駆使。良質の未経験者をパワーレベリングします。

〇対策・チームメンバーの長期固定化が必要
開発の量は時期によっても変動するはずです。離職もゼロと言うのはまず不可能です。（どんなに良い会社と社員の組み合わせでも、絶対に発生するもの。）実現可能性を考えた場合、過度な固定化よりも、入れ替えは前提としつつも、対話を重視する、主体性のあるメンバーで固め続けるというのが現実的な解になるかと考えます。
弊社のメンバーは、お互いいつものメンバーですし、コミュニケーションコストが低い状態でスタートできますが、とはいえ弊社メンバーのみ（フル外注）の体制も良くありません。システムが弊社にロックインされる事態となります。
離職を想定し、最低限2名のクライアント側のエンジニアが必要です。システムを知っている社員を常に確保できている状態にしておかなくてはいけません。（将来的にプロダクトオーナーの候補ともなります。）
必要があるときに、数を調整することができるのが外注の利点ですし、それを活かしたプロジェクト運営ができます。解雇規制のある市場に適応したやり方です。

〇対策・チームのマインド設定が難しい
この問題は採用の時点で7割くらい勝負が決まります。チーム内でのクライアント社員様の育成を前提とできれば、採用ターゲットを新卒～ロースキルくらいまで落とせますので、その中からマインド・コミュニケーション・カルチャーが合う人材を採用するのがベストかと思います。半年間の契約社員や派遣社員のアサインからスタートできれば、より安全でしょう。
あとは、弊社のメンバーや、スクラムマスターが、マインド面含めアジャイルに対応できる人材に育成します。

〇対策・プロダクトオーナー役がいない
プロダクトオーナー業務そのものは本来、外注が難しいポジションです。ビジネス側の背景がわかり、ビジネス側と開発の優先順位に関して調整ができる方をアサインして頂き、責任を持って頂く必要があります。即戦力を中途採用できればベストですが、なかなかそうもいかないので、以下3パターンを提案します。

1.ビジネス側の方にPOを担当して頂く。（開発Mgr役をPMOで支援する）
1番最悪なのは、IT側の事情が全てまかり通り、『結局なにも動かない』事ですが、その次くらいにマズイのが、ビジネス-IT間で優先順位を決められず、『全ての要求を決まった時期までにやる』状態になる事です。こうなると仕様も削りようがありません。仕様を削らないアジャイルよりは、ウォーターフォール・請負で外に出した方が、たぶん早くて安いです。

ビジネス側の事情・背景が分かりませんとこのあたりの調整は難しいですし、IT側の事情をビジネス側に伝えて調整する必要もあります。ビジネス側の有識者の方にPOをお願いし、BAMVのコンサルタント（POA）やスクラムマスターで支援していく必要があります。

ハッキリ言って、ITよりはビジネス側の背景わかってる人の方が、仕様削るにしても、ビジネス側の都合で非効率が発生するとして、それを許容するべきかどうかにしても、コストとリターンで判断可能だったりと、POらしく活躍してくれると思います。

なお、ビジネス側でそんなに都合よく主力層の人の手が空くかと言えばそう言う事はないでしょうし、たまたま手が空いてるからと意思のないYesManを置いてしまうとやはりそのプロダクトは地獄にしかならないので、その様な場合は次善案として下記になるかと。

2.BAMVコンサルタントがPOを代行する
ビジネス側の背景はわからないので苦労します。苦労しますが、YesManではありませんし、ビジネス側の方に信頼される・期待されるところまで持って行ければ、うまく回り始めるかと思います。
しかし仮にうまく回り出したとして、BAMVコンサルタントははあくまで外部の人間です。プロダクトの責任者として権限を振るうのは基本的には問題がありますし、1件に張り付き続ける訳にもいかず、永続的な継続も難しいです。あくまで下記までのつなぎとなるかと思います。

3.新しく雇った社員をPOまで育成する。
先の対策でエンドユーザー側が雇用した新人を育成するという選択肢です。
そのシステムで育っているので当然にそのシステムには詳しいですし、自社のビジネス側の背景を把握し、勝利に導いたり、『信頼される・期待される』 事も、本人にとって直接的にメリットがあります。
ベストな選択肢かと思いますが、時間はかかります。
なお、POの他、運用面を握るSREなどのポジションも、クライアント側で人材の柱を立てておきたいです。アプリ側は外注主体で良いかなと思います。（自社で開発請負とかするなら別だけど）『作るものはないけど雇用しているから作らなくてはいけない』とか、その結果『黒字化を難しくしている』とか、あまり賢い状態とは思えません。

３.契約とか

基本的に準委任契約となります。
一括請負契約の場合、開発範囲が契約段階で固定されるため、アジャイルの利点のひとつである『不要なものを作らない』が不可能になります。（作るものと納期が決まっているものは、ウォーターフォール型・請負契約で行うべき案件。スクラム等の適用は非効率です）スプリント単位で請負契約をする方法もありますが、契約周りの手続きが煩雑となり、逆に人的なコストが読めなくなる為、推奨できません。

最初期は、弊社のメンバーが中心となって開発を行うことになると思いますが、開発の目的と予算の兼ね合いが成り立つのか、見積もりの作成からスタートになります。
開発対象がほとんど決まらないケースでは、まずは開発チームよりも業務/ITコンサルを１名投入した方が、不一致な開発スタイルや不要な開発自体を排除し、トータルコストを削減できるかと思います。
必要であれば、提案依頼書（ＲＦＰ）の作成・適正な発注先の選定まで支援できます。

採用業務に関しては、それ自体でコストが発生するものである為、別途の委託契約が発生します。
ターゲットや期間、人数によって難易度も費用も変わりますので、これは都度ご相談。いきなり莫大な人数を採用する事は無いと思いますので、さほど高額なことにはならないと思います。（そもそも常識外の成功を採用で産むと言う話でもないし。）

社員育成支援に関しても、チームの状態や人数によって難易度が変わります。こちらの費用は別途は不要ですが、それなりに弊社チームメンバーのリソースを消費しますので、その影響はご理解いただくことになります。



・費用感
弊社は、このＣＡＯＧの、オープンにできる導入実績を増やしていかなくてはいけない段階です。
下記の費用感で対応致します。
Dev メンバー　　　60～80万/人月
スクラムマスター　100～120万/人月
PMO・POA　　　 80～180万/人月

なお、スクラムマスター・ＰＯＡは、必ず必要と言うものではなく、『必要に応じて投入。』と言う形が良いかと思います。ベストな状態は、彼らが不要な状態です。
時間経過・環境変化でまた必要になれば、また投入すればよいです。

・育成
最低2名は雇用して頂きたいです。（1名だと、辞めてしまった時に詰む。）
未経験からで戦力になってくるのに半年。主体性を持って行動できるまでに3年くらいを見てください。
既存の方を投入する形でも良いですが、スキルが高くとも協調性の無い方、経験があっても基礎がほとんどない方等を投入しますと、アジャイルチームではなかなかワークしません。それよりは、事業にコミットメントしたマインドを持つ新卒・未経験者の方がだいぶ効率が良いです。

4.つか、BAMVてどんなしごとしてんの

これもよく聞かれる。しかし、ＮＤＡもあり、答えづらい！
イメージできるくらいの情報を載せます。

まず、コンサルタント/PMOのメンバーと、システムエンジニア（プログラマ）のメンバーがおります。
コンサルは、課題解決力を重視した採用基準で、いわゆる異業界で成功した『仕事ができる人』がたくさんいる感じになります。
コンサルタントは、高額なコンサルの様に専門分野を尖らせたタイプではなく、業務～ITまでを幅広く支援。課題感をお感じの段階から参画すれば、問題の特定や解決策・実行策の提示。発注の支援までカバー。必要であればPMOと連携してシステム開発の終了・評価まで支援します。
PMOは各要素技術に寄った能力や知見などはＳＥ出身のIT-ＰＭＯには劣りますので、少し得意な領域が変わり、エンドユーザー様と開発ベンダ様の間の立場であったり、エンドユーザー様内の多種調整業務。課題の発見と解決策の提案、施策の推進や管理などが得意分野となります。

ＳＥは、プログラム適性と、アジャイルに関わる要素、主体性やコミュニケーションスタイル等を重視しての採用傾向となります。後発のソフトウェアベンダーの立ち位置ですので、昔から人気の金融系や、基幹業務界隈は回避。（てもあしもでんよ。）
新規のビジネスなど、市場や競合への素早い対応が必要なクライアントの、サービス開発やPoC（概念実証）が、主な顧客層と業務領域になっております。

・大手エンドの新規事業領域サービス開発（PoC）
・大手Ｗｅｂビジネスのコンテンツ開発
・特に特化している業務知識はない
・新規開発メインな為、クラウドネイティブなスキルセット

主な要素技術は下記となります。
・Kotlin（バックエンド開発）
・Go
・Python
・React
・AWS
・GCP

顧客・技術の特性から、ＱＣＤのバランスは品質に寄っています。（というか、追加開発する前提のものだと、そうした方がコスト・デリバリの面で安上がる）超小規模短納期開発には不向きです。
また、REST・マイクロサービスを前提とした開発経験がほとんどで、超大規模開発のアーキ・マネジメントには向きません。

中規模くらいのエンドさんの、新規事業に関連するシステム/サービス開発などに特化したスキルセットと言えるでしょう。（そうしないと、だいたい強力な競合か、やたらと頑丈な競合がいるんですわ。）

----------------------------------------------
その他の記事へは、下記リンク先が記事一覧となっておりますので、そちらからどうぞ。

INDEXへのリンク