コンサルと連携し、エンドの課題を主体的/機動的に解決する【アジャイルチーム】のリードポジション

【BAMVの特徴】
コンサルタント/ＰＭＯと、先進的なＷｅｂエンジニア。
弊社はこれらのふたつの職種の『専門性』を武器に顧客に課題解決を提供する、11年目のソリューションベンダーとなります。


【請負とかウォーターフォールとかが抱える問題】
請負契約やウォーターフォール型のプロセスを前提とした開発では、《初期段階でつくるものがすべて決まっている》事が前提となります。この前提では、エンド内部でITコンサルの機能が要求されてしまうため、そのような人材を調達可能な大規模エンド。その案件をメインターゲットとする大規模ベンダーが有利となります。また、《エンドが決めきる》前提下では、ベンダーの営業やSEは提案力を発揮する場が無いことになってしまいます。

現実には理想通りに進むケースばかりではない為、大手SIerのPMやSEは、そのあたりの不具合を『なんとかする』能力や経験を持っていたりしますが、やはり納品をゴールとせざるを得ない為、顧客とベンダーの勝利条件が一致しない問題などが発生してきます。いずれにしても、顧客・ベンダーともに、勝ち戦とはなりづらいでしょう。



【BAMVがやりたいソリューションベンダーの在り方】
BAMVには業務改善を得意とするコンサルタントが在籍しています。
コンサルタントは顧客の様々な問題・課題を解消すべく参画することとなり、その解決では多くの場合、ITを利用した解決策を提示することになります。（別に自社のプロダクトじゃなくていい）

この際、市場が未知数な新規事業に挑む顧客であったり、変化が激しい市場に対応し続ける必要がある場合、既存の請負ベンダーやSaaSではフィットしづらいです。アジャイルチームの出番です。

アジャイルチームは、顧客のビジネスの成功を目的とし、目的に対して自律したアクションを行います。顧客のプロダクトオーナー（PO）に対して、ITコンサル的な役割（自社のコンサルと協働でOk）も担当していくことになります。これによりPOは『内製SE的なスキルセット』の必要から解放され、ビジネス側を向いて（ユーザーストーリーを重視して）開発対象の優先順位を決定することができるようになります。



【PO補佐の役割】
ビジネス部署とPOの連携が悪い場合、バックログの優先順位がうまく決められず、《納期までに全部作る》となりがちです。これを多くのベンダーはDevチームの能力や稼働で解決しようとします。（なので、なんかスキル要求が異常に高くなり、性格悪い人がチームに混入したりする）

しかし、そもそもこれはエンド内部で起きている問題です。Devのパワーで解決と言うのは脳筋すぎます。直接エンド内部に『ビジネス部署とPO』の支援を行う人材を投入しましょう。
業務課題を把握しているコンサルが残ってもいいですし、ＰＭＯを投入して仕組み化でも良いです。いずれも同じBAMVのメンバーですので、Devチーム側の課題や背景などもユーザー部署へ伝達することができるようになります。


【で、そんなアジャイルチームのDevチームのリードポジション募集】
ポジションの詳細については職務内容欄に記載します。
大規模ウォーターフォール路線とは全く違うキャリアになるけれど、これはこれで立派にメシを食っていけるベンダーのエンジニアのキャリアだと思うんだよね。
むしろ生成AIが普及したあとは人月ビジネス構造が崩壊するし。有利になると思うてる。

【リーダー・自社メンバー中心のチームのけん引役。】
商流は、中小エンド直接・大手SIer直接のいずれかとなります。
中小エンドはWebサービス運営が多く、3～7名くらいの規模感。大手SIerのプロジェクトでは、SIer、他のセカンダリ2～3社、各5名規模くらいのチームでPJ全体（20名くらい）を構成します。
大手SIのプロジェクトも、役割はその時のビジネストレンド関連のPoC案件であったり、メガベンチャーのプロダクトであったりで、大規模基幹システムなどは担当しません。（ウチじゃなく他の大手セカンダリーに発注するでしょーな。）

【テックリード・チーム内の技術的けん引役】
上記のリーダーとは別のキャリア。エンジニアチーム内での技術面におけるけん引役です。
我々はエンドではなくベンダーです。ひとつのシステムを延々と担当する訳ではありません。求められるのは『担当システムの仕様に詳しい』ではなく、高い技術的専門性を活かし、開発チーム全体に技術的な方向性を示し、開発手法を提示し、開発環境を整備してチームの生産性を最大化できるようにリードしていく役割になります。

【アジャイルマインド】
アジャイルはちょっと厄介なところがあって、指示待ち君がワークしない。責任範囲限定したいマンに至っては他のメンバーの負担になるという、良くも悪くも『人を選ぶ』ところがあります。また、性格悪い人（ブリリアント・ジャーク）がおりますと、チーム全体の主体性が奪われ、アジャイルチームは機能しません。そもそも性格の良い人たちでチームを組まなくては、『継続的な開発』など不可能じゃんと言う話でもあります。
戦略上、これらのメンバーの採用は無駄です。採用の時点でNGとしますので、マイクロマネジメントの必要性は限定的です。BPの調達も同様で、『マトモなエンジニア』以外は短期リリースしていくしかありません。
このようにメンバー採用のハードルを上げざるを得ない分、大量採用は不可能となりますが、戦略上、アジャイルから受けている恩恵も大きいので、やむなしです。


【フルスタック化する】
Devチームは5名前後の小規模チームが普通です。
5名で1つのシステムを作る訳ですので、技術的な守備範囲が広くなります。つまり、キャリアは《フルスタックエンジニア》単線になります。

【先端技術の使用】
新規システムを、わざわざ古いもん使ってつくらんもんね...。
『その時ある便利なもの』を使って開発することになるのですが、この『その時ある便利なもの』は、移り変わりが激しいです。ですので、未経験からでもキャッチアップでOKです。
と言うか、毎回キャッチアップが当たり前に要求されるのがこの領域のエンジニアと考えて頂いた方が実態に近いです。

大手エンドの次期ビジネス展開に関わるような、『これは親にも言えねぇな.....』みたいなサービスやシステムの開発をしますと、日本のビジネスの最前線で腕ふるってんだなーと言う事を実感できます。
その手のサービスがローンチされますと、やっぱり大々的に報道されたりするので、飲み会でイキリ倒す事が出来ます。（なおＮＤＡ）

ほか、顧客の課題を解決して感謝された際など、『さすがはワイやな。カッコええわ。』と言う自己満足に浸る事が出来ます。　あとやっぱり飲み会でイキリ倒す事が出来ます。（なおＮＤＡ）

ベンダーのエンジニアの仕事の良いところは、ひとつのプロダクト・環境固定ではなく、いくつものプロダクトやビジネスで成功体験・失敗体験ができることや、風向きが悪ければ『撤退』もできることですね。

特定のビジネスそのものへコミットがあるなら、そのエンドへ。
ITでビジネスに資する『専門性』そのものへコダワリがあるならば、ベンダーへ。
私はどちらも経験がありますが、自分自身をベンダー向きと考えているので、現在のビジネスをしています。

・月残業時間は平均10h程度
・育休取得率100%です

【福利厚生】
・社宅制度
・出産／育児休暇
・育児目的休暇
・看護休暇
・介護休暇

【受動喫煙の対策】
弊社事務所は屋内原則禁煙としています。
※屋外喫煙所あり