代表の寺野は、異業界出身の営業系の経歴です。それなりにはやってきました。
しかしなにぶん当時は就職氷河期。右も左も突撃系の求人ばかりですし、また、営業の世界にも分業・アウトソース構造による「キャリアのワーカー固定化」の危機が近づいていました。自身も特定の専門分野を持つ必要があると感じ、たまたまながらIT業界へ参入する事になります。

運不運もあり、なんどか職を変える事になりつつも、IT業界内で営業として生きていく土台は作れたと感じたその時。リーマンショックが、それまで積み上げたものを押し流していきました。

その後、SES業界なども経験しますが、ここでは企業側にエンジニアのスキルを伸ばして上のレイヤーに移動したいという考えがなく。ただひたすらに頭数を増やしたい。つまり、会社と労働者の間に投資の関係はなく、搾取しあうのみの関係。そのような会社がひしめいており、そこでは営業としてのスキルを有効に活かすどころか、何かのきっかけで市場が変動すれば、自分も終わり。

「マトモな会社を引くまで転職を繰り返すよりは、自分で作った方が確実かつ低リスクだ」というのが、起業の直接的な動機です。

当然、前述の企業群を模倣しても意味は無いです。
実現すべきは、「顧客の満足を目的とし、それを実現できるだけの専門性・マインドを持っている会社を作る」こと。

ヒトモノカネコネなにもなし。会社名も『Trash-Briefing』（旧社名）。最底辺ポジションからのスタートとなりました。

旧社名の「Trash-Briefing」は、起業初期のミッションを達成すべく、採用ターゲットに訴求しやすいだろう……的な理由で名付けられています。「（市場価値的な意味での）ポンコツを集めて、組織的に戦って勝つ」的なワードをいろいろGoogleで検索したりして、それなりにゴロが良くなったやつにしました。5割くらいはGoogleさんが決めた感じ

Trash-Briefingは

• 未経験者を採用し、
• ちゃんと育成して、
• そのスキルを使って次の戦いをし、
• 全員で生き残る

ことを目的に設立した会社です。ですので採用のターゲット像は、

• 自身の職歴の市場価値が低いと認識しており
• 生存するための計画が立てづらく
• 上記に危機感を感じている
• 生存への努力をする挑戦権をまず得たい

と、考えている人物になります。まあ、昔の寺野ですよね。

そんな人を採用し、会社と労働者がお互いに投資しあえる構造を作れれば、当面の育成方法やチャネルはそれまでの経験で用意できていたので、様々な重力を振り切ってSES領域を脱出できるであろうと考えました。

SIerとその下請けの業界は、ご存知の通り「分業とアウトソース」による階層構造となっており、この業界構造は強固です。伝統的なビジネスモデルのセカンダリー・ベンダーはブランド・動員力で我々を圧倒しており、Trash-Briefingも正面からのアプローチでは、3次請け・4次請けくらいで限界に至るであろうと予測できました。

伝統的ビジネスにおける「分業とアウトソース」は、〈ウォーターフォールモデル〉と言う実績ある開発手法を前提としています。
で、あるならば、〈XP〉〈スクラム〉と言ったアジャイルの開発手法をメインに受注していき、自社の得意分野を作るならば、「伝統的なセカンダリー各社と競合しない」領域での成長が可能ではないかと考えました。

当時のTrash-Briefingの業態はまだ、SESです。営業力を活かし、仕事を選ぶことでアジャイル優先の受注を行う事は、現実的に実現可能でした。

アジャイルを実践していく中でわかってきたのは、「アジャイル開発では、スキル以前にまず、マインドセットが重要である」ということです。

アジャイル開発に求められるマインドセットとは、下記のようなもの。

• 目的は、顧客のビジネスに資する事
• チーム内の成長・協力関係が前提
• 責任範囲を過度に限定せず、主体性を持って行動する

請負契約や、大規模ウォーターフォールプロジェクトの下層部では、責任範囲を限定する事はむしろ身を守るために必要であったり。顧客と目的が不一致（納品がゴールに）になったり、立ち位置によっては顧客の目的が見えない事もあります。

しかし、アジャイル開発においては、責任範囲に線引きするマインドは、アジャイル・チームの機能不全を引き起こし、カルチャーアンマッチからの短期間での離職を引き起こすこととなります。

そのため、中途採用での安易な採用を反省し、採用基準を厳格化。また、エンジニア部門の理念の再設定なども行いました。
これらの基準等は「行動指針」等で、現在でも引き継がれています。

アジャイルのプラクティスを採用したプロジェクトは、新規で試作・開発するプロダクトや当時大発生したWebサービス開発関連の需要が多く、メンバーのスキルセットはクラウドサーバと新しい技術をメインにしたものとなりました。
加えて、アジャイルのマインドセットを持った、自社メンバー中心のエンジニア・チームは、数こそ大量には集められませんが、市場からの需要がありました。

チームで担当範囲に責任を持つケースが増え、大手SIerや上場企業エンドと直接契約も発生。　気が付けば実態として〈SESというビジネスモデル〉から脱却しており。
それを実現した優秀なメンバーが在籍するソフトウェアベンダーとなりました。

採用ハードルは維持され、入社する若手の質はどんどん向上し、彼らの育成に社内の関心が集中していきます。

「あれ？　気が付いたらゴミの要素なくね？」

死ぬほどすったもんだがありましたが、Trash-Briefingは、目的を達成していたのでした。

2019年に、BAMV合同会社へ社名変更。

次のフェーズへの挑戦が始まります。
エンジニアだけの組織（ソフトウェア・ベンダー）の弱点は、「顧客の課題解決のスタートのところに関与できない」と言う点が挙げられます。

ITベンダーに依頼がくる段階は、顧客は「課題を自覚し、解決手段としてシステム開発を自力で選択した」段階です。そのため、

• それができるエンドしか顧客にならない
• ITベンダーの営業は、御用聞きしかできない

これでは組織としてまだまだ脆弱です。

顧客に対して、ニーズの認知（As-Is To-Be）・解決方法の提案（ウォンツ／需要化）・解決方法の発注の支援を行うユニットが自社内に求められます。

また、アジャイルの文脈においても、顧客を巻き込む、プロダクトオーナーを直接支援しエンドユーザー内部の問題を解決しに行く事ができる人員がいると、強力です。

次の段階への移行の為、コンサルDivを創設。BAMVは従来のエンジニアたちからなる開発Divとあわせて、開発-コンサル両輪の体制となりました。

社名のBAMV（バンブ）には、二つの意味があります。

• Build Again Make Value　→　もう一度構築し、価値を生み出す
• BAMV（バンブ）→ bamboo（竹） → 軽量でしなやか→アジャイルっぽいイメージが連想できる／地下茎がとにかく枯れない

現在は、PoC（実証実験）を含めたチャレンジングなプロジェクトを最新技術で支える一方、Webサービスの内製化支援やIT人材の採用支援など、ソフトな面についても一社で包括的に対応できる組織となりました。

すなわち、BAMVは、現在のビジネスや社会が直面する課題を“アジャイルに”解決する「ソリューションベンダー」へと、変化・進化を続けています。

大規模プロジェクトにおけるSIerのような立ち回りはできませんが、ビジネスオーナーやプロダクト、あるいはチームメンバーと、非常に近い距離で、自分の技術と知識をぶつけあいながら問題解決を図っていく。そうした関わり方を期待するビジネスオーナー、エンジニアには、有望な会社になったのではないでしょうか。