CAOG開発 clarity about one's goal（目標を明確にすること） アジャイル導入期のお客様の多くは、実際にシステムを利用するユーザーとプロダクトオーナー間、さらにはアジャイルチームとの目標の不一致などから発生する、プロジェクトの機能不全に陥りやすくなります。 この課題に対しＣＡＯＧでは、コンサルティングセクションのＰＭＯが、システムを利用するユーザーのニーズを明確化、プライオリティ設定支援、ＰＭやＰＯを含むＩＴプロジェクト側の構成員と、お客様との間の橋渡しを行い、ＰＯやチームに対してプロジェクトの目標が明確に伝達される構造を作り、関係者のゴールを共通化します。 エンジニアリングセクションのアジャイルチームは、自社のＰＭＯとも連携しチームの垣根を超えたコミュニケーション関係を構築していきます。 顧客の真のニーズを解消するシステムの開発を目的とし、使用しないシステム機能など、不要な機能の排除を行い、より快適に利用できるシステム構築を重視します。 自律したチームとして、強力にアジャイル開発を推進します。

会社全体の共通目的は「現代型終身雇用制度」の成立と維持。 おそらく我々の世代は70歳まで仕事をする事になるでしょう。40を超えると市場価値の低下が始まり、転職もままならなくなる本業界の技術者にとっては、致命的な事柄といえます。 自分達とその家族だけ助かればいいので、そのための仕組みを『ふつうの素質のひと』の『ふつうの努力』と『組織力』で作りにいこうと言う目的をもった集団です。 開発会社としての特性は、Webエンジニアの【技術】と、それを【短期間で育成するスキーム】が競争力の源泉とななります。このスキーム下では、未経験からだいたい３年ほどで比較的あたらしめの技術を持つ基本設計者を生み出すことができています。 今後は蓄積した技術力をビジネスに変えていく動きを始めるフェーズに入って来ており、その一環でＰＭＯの事業部が対エンドの営業を開始。 目指すスタイルは、エンドの発注側に業務/ＩＴコンサルをアサイン。 まず顧客の業務の改善案を策定、改善方法を提案していきます。解決方法は自社への利益誘導を重視せず、顧客にとって最善な方法を選択するでOKです。（外部サービスもOK） システム開発が必要として、要件が変わりそうもないならば請負で。流動的な環境であるならば、準委任契約でアジャイルチーム・コーチの参画となります。 これらの経験は自社の新規事業にもそのまま流用可能であるはずで、中長期的な戦略の、多角化路線での武器となります。 上記を実行可能なスキル/マインドを、技術者育成の目標地点としています。

BAMV側のカラーは、【ちゃんと準委任をやる】です。 一括請負や多層構造により培われる考え方は、『責任範囲を限定し、リスクを黙殺し、顧客満足よりも納品を目的とする。場合によっては成果に責任を持たない』です。環境の問題である為致し方なくはありますが、これではアジャイルプロジェクトのチームは機能しません。 弊社のアジャイル重視のスタンスは、生存のための戦略です。他のSI指向のベンダとは文化は異なるものである必要があります。アジャイルチームの考え方とはすなわち。 ・目的は顧客満足である。 ・顧客に対して成果を明らかにし、責任を持つ。 （但し権限がある事） ・リスクを理解し、向き合う。報告する。提案する。 ・チーム内での役割・責任範囲を限定しない。（準委任契約である事） ・プロジェクトに対して、当事者意識を持つこと。 ・振り返りと改善を行う事。 これがそのままBAMVの価値観。行動指針となります。 解雇制限のある日本の場合は、エンドユーザーが高度なIT人材を抱え込むという事は難しいです。ですので、我々ベンダ側の専門性が輝くことになります。エンジニアだけではありません。PMO・ITコンサルタントであれ。営業であれ。全社で重視する価値観となります。 設計力・技術力やIT知識は我々にとって最大の武器で、軽視する事は決してありませんが、ただのイキリプログラマーや本質や用途を無視するモダンガー等は自己組織的なチームを阻害し、最良のアーキテクチャや設計を遠ざける存在です。　弊社には必要ありません。 新規ビジネス側の価値観は、まだこれから決まっていく形になります。 こちらは請負契約の率が高くなりますが、SIerモデルとの差別化は必要です。すべてが同じとはなりませんが、大部分は近しい考え方となるかと思います。（主たる参加者の合意で、顧客満足を第一目的とすることで一致している。） こちらはより厳しく低質なエンジニアを排除する方向性である為、例えばイキリやモダンガーはやっぱり不要と言うカラーがすでに打ち出されています。

【コンサルティング/アジャイル開発】 のあたりを正面に打ち出して営業しておりますので、エンドの前衛的な新規ビジネス関連システムや新規サービスの開発、ＤＸ的なビジネスモデルの革新に関わるプラットフォームの開発など、既存のマネジメントライン外の需要にぶつかる事が多く、開発でも【自律的なチーム】を求められることが多いです。 ※むしろ顧客側がスクラムをやりたがるケースも多い。 【チーム規模】 だいたい弊社メンバーが3～5名程度。パートナーさんが1～3名くらいの体勢。 大手エンドでＳＩと組む場合は、さらに全体で15名～20名くらいの規模が多いです。 スクラムの場合は5名くらいですが、プロダクトオーナー不足とかで15名とかってこともあります。 スクラムマスター経験者はいるので、必要あればここも弊社から投入します。 【ミッション】 エンドの新規ビジネスや、既存ビジネスの革新に関わる新規投資に食いつくわけですので、それらのビジネスの成功が、そのまま我々の勝利条件になります。（そのビジネスが儲かり、規模が拡大していくと、我々も良いポジションを抑える事になる。） 企画段階に関わる場合は、システム開発の専門家側として、責任や前向きの意思を持っての発言が求められます。（問題点も指摘しなくてはいけない） また、BAMV自体が成長しなくてはリターンがありません。増員枠の確保・なども同時に行っていきます。このあたりはソフトハウスらしい立ち回りになり、SES的・派遣的なスタンスを好む方ですと、カルチャーアンマッチなケースが多いです。 【商流】 権限を有し、主体的に立ち回れる商流である必要があります。 ・エンド→BAMV ・エンド(大)→SI→BAMV と言うパターンがほとんどです。 【最近の主な開発環境】 　■Kotlin（Spring Boot） 　■Go 　■Python（Flask） 　■Ruby on Rails　 　■React　Vue　(TypeScript)　 　■AWS 　■GCP 　■Git 　■などなど ・エンドが所謂メガベンチャー系の会社さんですと、Kotlinが多い印象。 ・小規模なWebサービス運営ですと、PythonやRuby 　プロダクトが当たって、速度が要求される個所が出た場合、GO ・その他、そのプロジェクトの背景などに合わせて技術選定されている印象です。