【アジャイルのベンダーのリーダー or テックリード】指示待ち・他責のメンバーが排除されたチーム

【BAMVの戦略・現在地点】
BAMVは2013年設立の独立系ソフトウェアベンダー（以後SV）です。今期で13期目になります。
SVの市場が広がりまくっていた時代となりますと、やはり2000年頃までと思われ、それよりも後に設立されたBAMVは後発のベンダーである言えます。先行の競合ベンダーに対して別の差別化軸が必要となります。
この差別化軸として、主に【アジャイル開発】【先端技術への対応力】の２つを選択しました。

人月ビジネス構造が前提となる、システム開発業界。そのビジネス構造では、
・大規模システム開発に対応。
・いくつかの業務領域に特化。
・物理サーバーを導入し、保守契約を取る。
・上流を担当し、下請けソフトハウスの人材をつかって『ぬきぬき』
と言った事ができると、儲かる構造になっています。

さて、これらの構造、大前提が『ウォーターフォールモデルによる大規模システム開発プロジェクト』となりますね。
多数の下請けエンジニアを稼働させるためには、大規模PJ、かつ、ウォーターフォールによる分業構造が必要になります。
また、クラウドサーバがメインですと、エンドに運用側を内製化されてしまいますので、オンプレサーバが好ましい。

BAMVの方針はこれらの真逆。
・小～中規模のシステム開発に対応。
・特化した業務知識がない。
・基本的にAWSかGCPを使用（2013年設立だからしゃーないねん）
・アジャイル開発で、全員が上～下まで対応。
・外注PGを詰め込みまくる事はできない。
つまり、人月ビジネス構造下で儲かるスタイルではありません。
『非』人月ビジネス構造 対応であるからこそ、競合のベンダーが少ない。需要があっても競合が少ない。　競合が少ないので、短期間で商流を上げる事ができた。
現在は、某大手SI直の案件が7割、エンド直が2割くらいの商流に到達しています。


【そのほかの特性・制限】
アジャイルを差別化軸としたことで、デメリットも発生します。
・PJ内で自走できるプログラマー以外は戦力化できない
・故にガバガバ採用で社員数を増やせない。
・技術を学習できる必要がある。（PoC等ではわざわざ古い技術使わない）
・ビジネスパートナーに対しての要求も高くなってしまう。
反面、リーダー側にはメリットともなり、【指示待ち・他責のメンバーが排除されたチーム】が実現されることとなります。


【BAMVがいまやっていること】
企業ですので、儲ける・拡大する、が求められます。この点、他ベンダーと比較して不利もあります。が、他ベンダーにない有利を活かすこともできます。

アジャイルプロジェクトでは、先進技術を選定する事が多いです。競合他社のエンジニアもその様な特性持ちが多いのですが、このタイプのエンジニアに多いのは、『話すの苦手』『提案しない』などの行動パターンです。
ふつうにビジネスがわかり、ふつうにシステムエンジニアができる人材をリーダーに配置。営業・経営との連携、フォロー体制を敷く事によって、増員タイミングなどで有利を取れることが見えてきました。
リーダーと言っても、アジャイルですので5名～7名くらいの小チームです。強力なマネジメント能力が求められる訳でもないというのも良い点です。
チームのメンバーの平均値は高めになりますので、成果を出して信用を得ると言ったムーブも比較的容易です。

このリーダーポジション。そして、技術面のけん引役、テックリードの募集記事となります。

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

【対エンドクライアントではリーダーがクライアントを牽引する。】
BAMVでは、各チームのリーダーが対クライアントの折衝の中心となります。　BAMVが重視する『クライアントニーズ』に最も近いポジションだからです。これを支援するのがメンバーの責務であり、営業などのサポート部署の責務です。自己中心的なメンバーの存在はリーダーの負荷を上げ、チームの目的達成を阻害します。そのような園児ニアのお守りを優先する必要はありません。リーダーはメンバーへの評価を行う権限がありますので、低評価つけてしまってOKです。（どのみち長期的にはいなくなります）　大手SIのプロジェクトでのいわゆる『2次請けのリーダー』と比較しますと、かなり難易度が高めと考えています。　その分、対応可能な人物の報酬は高めに設定されます。


【テックリード】
BAMVでは非リーダーの役割。リーダーやチーム全体の支援を求められるポジションです。
・成果物の品質を担保するため、開発のメンターとなり、技術的な方向性を示す。
・開発手法を提案し、開発環境を整備してチームの生産性を最大化できるようにリードしていく。
・メンバーの技術レベルを確認し、スキルアップの施策を講じる。
など

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

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

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

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

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

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

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

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