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

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


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

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



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

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

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



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

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


【で、そんなアジャイルチームのDevメンバーの募集】
ポジションの詳細については職務内容欄に記載します。
大規模ウォーターフォール路線とは全く違うキャリアになるけれど、これはこれで立派にメシを食っていけるベンダーのエンジニアのキャリアだと思うんだよね。
むしろ新技術対応が早く、競合数も少ない分、くいっぱぐれもねえべ。

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

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

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

【最新技術はずっとキャッチアップの世界】
学習コストの高めなReactでも1.5カ月くらいのキャッチアップ期間を見ておけば、だいたいみな立ち上がる訳ですから、いちいちエンジニアの経歴書を重視して当たり外れを繰り返すよりも、当たりと最初からわかってる自社エンジニアを、キャッチアップ期間を計算して投入した方が確実です。


【アジャイルマインド】
アジャイルはちょっと厄介なところがあって、指示待ち君がワークしない。責任範囲限定したいマンに至っては他のメンバーの負担になるという、良くも悪くも『人を選ぶ』ところがあります。

主体性を持ってエンドのビジネスと向かい合うならば、提案する、指摘する、先回りして用意する（『こんなこともあろうかと』とリアルで言える）様なメンバーで固める事がまず最初にやるべきことになるわけで。

なお、性格悪い人（ブリリアント・ジャーク）がおりますと、チーム全体の主体性が奪われ、アジャイルチームは機能しません。そもそも性格の良い人たちでチームを組まなくては、『継続的な開発』など不可能じゃんと言う話でもあります。


【主体性を持って顧客と向き合うチーム】
POと言う、顧客のビジネス側との結節点にあたる意思決定者と直接やり取りする事になりますし、ITの専門家の立場からPOに提案・提言をできるようになる必要があります。いわゆる《下請けSE》的なムーブではなく、小規模ながらITコンサル的な要素です。

Devチームメンバーに主体性が不足しますと、SMやPOがその不足を埋める役割を要求されることとなり、実態《製造リーダー化》してしまいます。このようなチームのPOの採用要件はITコンサル成分+コードレビュー能力なども求められることになりますので、ビジネス側のスキルが不足しがちです。
POのビジネス側の知見が不足しますと、開発するものの優先順位が決められず、《すべてつくる》ことに。　だったら最初から【ウォーターフォールでよかったわ】となりがち...。

と言う訳で、主体性を持ったメンバーたちを採用し、《自律したチーム》を実現することが、まず最初に重要です。プロセスとかツールは、そのあとな。

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

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

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

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

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

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

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