【スキルチェンジ応募可】先進的な技術を使用するWebサービスの新規開発部隊へのメンバー参画

【本求人で想定しているポジションの役割】
システム開発ベンダーのメンバーポジションです。
BAMVは『小～中規模・新規開発・アジャイルソフトウェア開発】のあたりに専門領域を持つソフトウェアベンダーです。プロジェクトは大手SIerの直接2次請、Webサービスエンドの直接一次請のポジションとなります。

【2次請けの場合】
エンドはメガベンチャー系、または、新しく始まる投資トレンドに関連するプロジェクトが多いです。特に後者のケースはまず大手SIerに話が行きますし、このようなPoC案件に対応出来るセカンダリー・ベンダーも限られます。こうして我々に依頼が来ます。ド新規のシステム開発の場合は関連システムがほぼ無いので、使用アーキテクチャはこちらで提案する事が多くなりますし、単純に効率の関係から古い技術は選択しない傾向が高いです。

【1次請けの場合】
前提として、我々で体制を組める規模のプロジェクトとなりますので、大規模エンドである事は少ないです。 BAMVの特性も影響してWebサービス関連のプロジェクトが多いです。

【共通の要素】1次・2次は、いずれもベンダー側で体制を取り、担当範囲に責任を持つ事が要求されます。チーム単位でリーダーを中心に品質・進捗・リスクを管理し、開発を阻害する要素が排除されるようユーザに働きかける義務があるとお考え下さい。（自社担当範囲に関するプロジェクトマネジメント義務を負っている認識で良いかと思います。）責任範囲はクライアントの種類によってもやや変わり、メガベンチャーや大規模エンドでは自前のクラウド運用部隊を持っている事が多いですが、それ以外の多くのクライアントでは、弊社サイドがクラウドサーバー側まで担当する事が多くなります。　

【テクニカルスキル上の守備範囲】
上記の関係から、スキル面の守備範囲もフロントエンド～クラウドサーバのある程度まで要求される事になります。フルスタック路線の方の方が合うかと思います。（最初っから全部できる必要はないです。）

〇サーバー
ほぼクラウドサーバになります。マイクロソフト系も手を出していないので....
・AWS
・GCP

〇バックエンド
高トラフィックのサービスもありますので、その様なAPIの作成や負荷分散などの経験が求められることもありますが、基本的にイマドキのよくある構成と言う認識でOKです。
ほとんどはマイクロサービス（的な）思想で疎結合化されており、コンテナ等の概念の理解は必要です。言語は毎プロジェクトごとに違いますので、『ひとつ言語できるから、ほかもやったらできるやろ】の精神でOKです。
・Kotlin（SpringBoot）
・Go
・Java
・Python(FastAPI)
・Ruby(RoR)

〇フロントエンド
フレームワークは入って覚えるでOKです。バージョンアップなども我々で対応しますので、やったことないのでできませんだと困ります
ReactやVueは初見ハマりますので、0.5～1.5ヵ月ほどのキャッチアップ期間を見込みます。
TypeScript （React / Veu）

【自社チームにメンバーとして合流する】
商流は、中小エンド直接・大手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%です

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

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