【ベンダーのリーダーポジション】指示待ち・他責のメンバーを抱えなくていいリーダー。

【SESでは経験できないポジション】
家を建てる時に、『職人さんを派遣してほしい』と言う施主はまずいません。求めるのは『完成した家』です。システムの世界でも同じで、システム開発会社に求められるのは完成したシステム。または、施主を導いて完成したシステムを作れるシステム開発業者であって、大量の派遣労働力と言う訳ではありません。工事を受注した工務店の棟梁。そんなののIT版が、このポジションです。


【成果物の品質・納期に責任を持つ】
ですので会社からのミッションは、『頭数抱えて毎月160ｈ怒られない様に耐えろ』とかではありません。まずは自チームの成果物に対して、会社として責任を負わなくてはいけませんので、そのリード役がミッションになります。　アジャイルですと準委任契約が基本になりますが、契約の種類による変わりはありません。請負であれ、準委任であれ、法的な責任は発生しますし、プロジェクト管理義務も負います。と言うか、できないなら会社ごと切られます。

【上記が実現できるチーム】
当然、メンバーもガバ採用じゃダメです。
特にBAMVの場合は他のベンダーとの差別化の為、中小規模の新規開発、アジャイル開発の要素を選んで専門性を蓄積してきた流れがありまして、新規開発の文脈では『未経験技術でも調べて使える』『未知の業務・仕様でも積極的に把握できる』アジャイルの文脈では、『クライアントの目的に対して主体性を持って参加できる』『責任範囲を過度に限定しない』と言った要素が求められます。これらの要素が採用活動に跳ね返りますので、やたらとハイスピードで人員が増えることはありません。このあたりが、【指示待ち・他責のメンバーを抱えなくていいリーダー。】と言うワードにかかってきます。
リアル少数精鋭の傾向は会社が損をする要素ではありますが、大量にSES人材を集めて稼ぐタイプのベンダーは大手が多く、正面から戦いを挑むルートは選べません。（選べば、大規模PJの下請けポジションに固定されることになる。）


【会社のポジション】
上記の差別化の甲斐もあってか現時点で、規模・社歴のわりに、大手SI直取・エンドユーザー直取のポジションにはいます。
大手SIの案件では、メガベンチャーのサービス開発の他、その時の新規投資トレンドにかかわるサービスのPoC、アジャイル内製化体制の構築支援などが多くなります。PoCに関しては専門家としての視点からの提案も求められ、大手企業がメディアリリースを行う対象の開発となったりもしますので、それなりの立ち回りが要求されます。エンドユーザーに関しては、メガではない規模のWebサービスの開発などに参加することが多く、こちらとPoCなどのケースに関しては、インフラ側の知見も要求されることになります。（クラウドサーバ前提でOK）


【各チームのミッション】
チームによってクライアントもその背景・ニーズも変わりますので、ミッションは異なります。
『クライアントニーズ』を重視し、これの解消のためにチームをリードすることになります。クライアントに満足を提供する責任を負う反面、その分の権限を活かして、自社の成長に寄与します。この《WinWin》の実現が目的と言って過言ではないです。自社の若手のアサイン枠の確保やBPの投入など重点目標は変わりますが、結局アジャイルチームなので、BP含めてポンコツ入れてもチームへの負荷がワリに合いません。『良いBPをひいきする』などを営業と連携して行っていくことになります。

【3～7名くらいの規模のWebシステム開発チームのリーダーポジション】
きょうびのWebシステムの開発体制ですので、1チームの規模はこんな感じです。（10名超える前に二つに分けたりすると思う）インフラ専門のメンバーはおりませんので、基本的にはアプリのチームとなります。
シチュエーションは様々ですが、クライアントの『実現したいこと』に対してチームや自社のリソースを前提に提案したり、技術調査をしたり、見積もりしたり、チーム内にタスクを割り振ったり、進捗やリスクの管理をしたり、レビューをしたり、他チームと調整したり、営業と連携して増員したり。やることはだいたい皆さんのイメージ通りなのではと思います。コードを書く部分は若手に振りがちなので減るとは思いますが、大規模とも違うのでゼロになったりもしないという感じでしょうか。


【対クライアントでは中心になる。】
BAMVでは、各チームのリーダーが対クライアントの折衝の中心となります。　BAMVが重視する『クライアントニーズ』に最も近いポジションだからです。これを支援するのがメンバーの責務であり、営業などのサポート部署の責務です。自己中心的なメンバーの存在はリーダーの負荷を上げ、チームの目的達成を阻害します。そのような園児ニアのお守りを優先する必要はありません。リーダーはメンバーへの評価を行う権限がありますので、低評価つけてしまってOKです。（どのみち長期的にはいなくなります）　

【技術と営業は常に対等で】
どっちが上でも、会社はクソになる印象ですので。これは決めですね。

【どうやってリーダーの役割のハードルを下げるか】
１チームごとの規模はさほどでもないので、その面での難易度は下がるとは言え、自前のシステムの運用とはワケが違います。
一人のリーダーに『顧客折衝』・『技術的面でのチーム牽引』・『管理能力』など、すべてのものを求めるのは、採用や育成などを考えた場合、非現実的と考えます。
SEとして問題の無い技術レベルは求めますが、『技術的面でのチーム牽引』は自社のテックリードに。『管理能力』や『若手のフォロー』は、それができるメンバーに分担し、リーダーは『クライアントニーズの把握』『必要な調整』を重視するポジションとできればと思います。（そこまで高度な要求のPJがどんだけあるかと言うのもありますが。）


【要素技術的には今風のシステム開発】
開発対象はサービスが多いので、基本的にクラウドサーバ上でのWebシステム開発。そうでないものも作りはほぼ一緒です。
マイクロサービス的に疎結合な形の構成となっており、コンテナの上に載ってます。（k8sを我々で構築したり設定したりと言う事もあります。）
トラフィックが多いものが多くありますので、APIまわりをちゃんと作るなり負荷分散を考えるなりは必要ですし、速度も考えたりします。
ただし、マイクロソフト環境はあまり経験が無く、会社として取りに行くことはほぼないです。ダメとかではなく、強みが無い感じ。で、使用する言語も下記のようなものになります。

〇サーバ
・AWS
・GCP
・クライアントのプライベートクラウド

〇バックエンド
・Kotlin（SpringBoot）
・Go
・Java（SpringBoot）
・Python（FastAPI）
・Ruby（RoR）

〇フロントエンド
・TypeScript（React / Vue）

基本的に、メンバーもぜんぶやります。

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

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

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

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

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

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

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