アピールポイント
【BAMVの特徴】
コンサルタント/ＰＭＯと、先進的なＷｅｂエンジニア。
弊社はこれらのふたつの職種の『専門性』を武器に顧客に課題解決を提供する、11年目のソリューションベンダーとなります。
【請負とかウォーターフォールとかが抱える問題】
請負契約やウォーターフォール型のプロセスを前提とした開発では、《初期段階でつくるものがすべて決まっている》事が前提となります。この前提では、エンド内部でITコンサルの機能が要求されてしまうため、そのような人材を調達可能な大規模エンド。その案件をメインターゲットとする大規模ベンダーが有利となります。また、《エンドが決めきる》前提下では、ベンダーの営業やSEは提案力を発揮する場が無いことになってしまいます。
現実には理想通りに進むケースばかりではない為、大手SIerのPMやSEは、そのあたりの不具合を『なんとかする』能力や経験を持っていたりしますが、やはり納品をゴールとせざるを得ない為、顧客とベンダーの勝利条件が一致しない問題などが発生してきます。いずれにしても、顧客・ベンダーともに、勝ち戦とはなりづらいでしょう。
【BAMVがやりたいソリューションベンダーの在り方】
BAMVには業務改善を得意とするコンサルタントが在籍しています。
コンサルタントは顧客の様々な問題・課題を解消すべく参画することとなり、その解決では多くの場合、ITを利用した解決策を提示することになります。（別に自社のプロダクトじゃなくていい）
この際、市場が未知数な新規事業に挑む顧客であったり、変化が激しい市場に対応し続ける必要がある場合、既存の請負ベンダーやSaaSではフィットしづらいです。アジャイルチームの出番です。
アジャイルチームは、顧客のビジネスの成功を目的とし、目的に対して自律したアクションを行います。顧客のプロダクトオーナー（PO）に対して、ITコンサル的な役割（自社のコンサルと協働でOk）も担当していくことになります。これによりPOは『内製SE的なスキルセット』の必要から解放され、ビジネス側を向いて（ユーザーストーリーを重視して）開発対象の優先順位を決定することができるようになります。
【PO補佐の役割】
ビジネス部署とPOの連携が悪い場合、バックログの優先順位がうまく決められず、《納期までに全部作る》となりがちです。これを多くのベンダーはDevチームの能力や稼働で解決しようとします。（なので、なんかスキル要求が異常に高くなり、性格悪い人がチームに混入したりする）
しかし、そもそもこれはエンド内部で起きている問題です。Devのパワーで解決と言うのは脳筋すぎます。直接エンド内部に『ビジネス部署とPO』の支援を行う人材を投入しましょう。
業務課題を把握しているコンサルが残ってもいいですし、ＰＭＯを投入して仕組み化でも良いです。いずれも同じBAMVのメンバーですので、Devチーム側の課題や背景などもユーザー部署へ伝達することができるようになります。
コンサルタント/ＰＭＯと、先進的なＷｅｂエンジニア。
弊社はこれらのふたつの職種の『専門性』を武器に顧客に課題解決を提供する、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案件であったり、メガベンチャーのプロダクトであったりで、大規模基幹システムなどは担当しません。（ウチじゃなく他の大手セカンダリーに発注するでしょーな。）
【アジャイルマインド】
アジャイルはちょっと厄介なところがあって、指示待ち君がワークしない。責任範囲限定したいマンに至っては他のメンバーの負担になるという、良くも悪くも『人を選ぶ』ところがあります。また、性格悪い人（ブリリアント・ジャーク）がおりますと、チーム全体の主体性が奪われ、アジャイルチームは機能しません。そもそも性格の良い人たちでチームを組まなくては、『継続的な開発』など不可能じゃんと言う話でもあります。
戦略上、これらのメンバーの採用は無駄です。採用の時点でNGとしますので、マイクロマネジメントの必要性は限定的です。BPの調達も同様で、『マトモなエンジニア』以外は短期リリースしていくしかありません。
このようにメンバー採用のハードルを上げざるを得ない分、大量採用は不可能となりますが、戦略上、アジャイルから受けている恩恵も大きいので、やむなしです。
【フルスタック化する】
Devチームは5名前後の小規模チームが普通です。
5名で1つのシステムを作る訳ですので、技術的な守備範囲が広くなります。つまり、キャリアは《フルスタックエンジニア》単線になります。
【先端技術の使用】
新規システムを、わざわざ古いもん使ってつくらんもんね...。
『その時ある便利なもの』を使って開発することになるのですが、この『その時ある便利なもの』は、移り変わりが激しいです。ですので、未経験からでもキャッチアップでOKです。
と言うか、毎回キャッチアップが当たり前に要求されるのがこの領域のエンジニアと考えて頂いた方が実態に近いです。
【リーダーポジション経験のしやすさ】
アジャイルのDevチームは、5～7名くらいの体制が多く、弊社は立場上、それぞれのチームにリーダーの役割を担う社員を配置しなくてはなりません。若手であっても上がつかえてポジションが無いという事にはなりづらい業態です。
また、プロジェクト”チーム”自体は継続的（いちいちチームを解散するコストの方がでかい）で、3～6ヵ月規模のシステム開発を次々にこなしていくか、既存サービスへの改修・リファクタリング・追加開発などを担当していく長期的なスコープのものが多いです。
自社の現在のチームリーダーより、対クライアント経験・レビュアー経験などを引き継いでゆき、スムーズにリーダーポジションへ移行できます。（既存リーダーは別PJの開拓に行きたいので、利害は合う）
商流は、中小エンド直接・大手SIer直接のいずれかとなります。
中小エンドはWebサービス運営が多く、3～7名くらいの規模感。大手SIerのプロジェクトでは、SIer、他のセカンダリ2～3社、各5名規模くらいのチームでPJ全体（20名くらい）を構成します。
大手SIのプロジェクトも、役割はその時のビジネストレンド関連のPoC案件であったり、メガベンチャーのプロダクトであったりで、大規模基幹システムなどは担当しません。（ウチじゃなく他の大手セカンダリーに発注するでしょーな。）
【アジャイルマインド】
アジャイルはちょっと厄介なところがあって、指示待ち君がワークしない。責任範囲限定したいマンに至っては他のメンバーの負担になるという、良くも悪くも『人を選ぶ』ところがあります。また、性格悪い人（ブリリアント・ジャーク）がおりますと、チーム全体の主体性が奪われ、アジャイルチームは機能しません。そもそも性格の良い人たちでチームを組まなくては、『継続的な開発』など不可能じゃんと言う話でもあります。
戦略上、これらのメンバーの採用は無駄です。採用の時点でNGとしますので、マイクロマネジメントの必要性は限定的です。BPの調達も同様で、『マトモなエンジニア』以外は短期リリースしていくしかありません。
このようにメンバー採用のハードルを上げざるを得ない分、大量採用は不可能となりますが、戦略上、アジャイルから受けている恩恵も大きいので、やむなしです。
【フルスタック化する】
Devチームは5名前後の小規模チームが普通です。
5名で1つのシステムを作る訳ですので、技術的な守備範囲が広くなります。つまり、キャリアは《フルスタックエンジニア》単線になります。
【先端技術の使用】
新規システムを、わざわざ古いもん使ってつくらんもんね...。
『その時ある便利なもの』を使って開発することになるのですが、この『その時ある便利なもの』は、移り変わりが激しいです。ですので、未経験からでもキャッチアップでOKです。
と言うか、毎回キャッチアップが当たり前に要求されるのがこの領域のエンジニアと考えて頂いた方が実態に近いです。
【リーダーポジション経験のしやすさ】
アジャイルのDevチームは、5～7名くらいの体制が多く、弊社は立場上、それぞれのチームにリーダーの役割を担う社員を配置しなくてはなりません。若手であっても上がつかえてポジションが無いという事にはなりづらい業態です。
また、プロジェクト”チーム”自体は継続的（いちいちチームを解散するコストの方がでかい）で、3～6ヵ月規模のシステム開発を次々にこなしていくか、既存サービスへの改修・リファクタリング・追加開発などを担当していく長期的なスコープのものが多いです。
自社の現在のチームリーダーより、対クライアント経験・レビュアー経験などを引き継いでゆき、スムーズにリーダーポジションへ移行できます。（既存リーダーは別PJの開拓に行きたいので、利害は合う）
給与
| 年収 | 360万円 〜 500万円 |
|---|---|
| その他給与（各種手当） | 昨年度賞与実績〇報酬モデル ・初級PG 経験0～3年 276万～360万 ・メンバー 360万～500万 ・リーダー 400万～700万 ※一時的な製造リーダー担当時なども含む ・テックリード 550万～650万 〇コンサル転向時 ・Tier３ 360～500万 ・Tier２ 500～700万 ・Tier１ 700万～ |
労働時間
| 勤務形態 | 固定時間制 |
|---|---|
| 勤務時間・曜日 | 月曜日 10:00〜19:00 火曜日 10:00〜19:00 水曜日 10:00〜19:00 木曜日 10:00〜19:00 金曜日 10:00〜19:00 その他（※勤務時間詳細を参照） |
| 勤務時間詳細 | 状況に応じてある |
| 休日・休暇 | [正社員] |
勤務地
| 勤務先会社・事業所名 | ＢＡＭＶ合同会社 |
|---|---|
| 勤務地住所 | 東京都 千代田区 |
福利厚生・社会保険等
| 待遇・福利厚生 | 男性も育児休暇取得実績があります。（過去2回）交通費支給,健康診断,社会保険完備,社宅・寮,資格取得制度,資格手当 |
|---|---|
| 受動喫煙対策 | なし |
求人会社/エージェント情報
| 種別 | エージェント |
|---|---|
| 会社名 | 株式会社FTヒューマンキャピタル |