【経験者向け・リードポジション】自社メンバーと一緒に『”なんちゃって”ではない』アジャイルチームつくろう

【会社の特徴/個性】
『アジャイルソフトウェア開発』・『未知の技術への対応力』　これらが差別化軸として機能している、13年目のソフトウェアベンダーです。

システム開発業界では、上層の会社は【専門分野】と【組織力】を有する会社がほとんどです。
このあたりは建設業界とも似通っており、ゼネコン役の大手SIerは別として、サブコンに当たるセカンダリーベンダー各社にはほとんどこの条件が当てはまります。
※専門分野は、≪金融≫などの業務知識特化や、≪パッケージ・SaaS≫などの、特定領域のシステムを安価に作る方法を有するなど、様々なモノがあります。
BAMVは2013設立と、業界ではだいぶ後発の会社となりますので、先行者とは被らないポジショニングを取る必要がありました。そこでえらんだものが『アジャイル』と『新技術への積極性』だったと言う事になります。
差別化軸は無事に機能し、現在では大手SIer直接の取引や、エンド直接の取引が主となっております。


【アジャイルのデメリット】
先行の会社がやらなかった理由はこの辺。
・小規模～中規模くらいのPJになる為、ロースキルがバコバコ入らない。
・ゆえに外注さん（BP）も稼働させづらい。
・指示待ちの人物がワークしない。
◎要求されるスキル平均が高めとなってしまうので、拡大ペースが遅い。
基本的に、【人月ビジネス構造との相性が悪い】となります。


【AI時代で有利になんじゃね？】
『指示したら、やってくれる』　指示待ち人材とAIは、モロに競合関係です。　これらの人員を抱えていない事はプラスに転換されます。
我々は、ほとんどの現有戦力が、【AIと競合】ではなく、【AIを利用】する側へ置く事が出来ます。
この手の人材を現金に変換していた構造が人月ビジネス構造ですので、その構造の破綻がけっこうな確率で起こり得ます。　もともと人月ビジネス構造下で有利な立場ではありませんから、崩壊によるマイナス影響もありません。
さらに、久々の≪技術の革新期≫と言う事になります。

【ぶっちゃけ、ここ10年、あまり技術変わってない】
Docker等のコンテナ技術、それを前提にしたマイクロサービス寄りのアーキテクチャ、相性の良い技術（Go言語など）これらの普及。
フロントとバックの分離から、フロント側での処理が増え、ReactやVueと言ったフロントサイドのフレームワークの普及。
いずれも2015年前後。　なんか新しい言われてますが、もう10年前に流行ったものです。　これではさすがに差別化が効きません。
これからは、AIに絡んだ様々な変化が起きてくることになりますが、このような市場の方が、我々は有利を取りやすいです。

1年先、2年先すら読めない時代になっていますが、常にアンテナを立て、我々の【専門分野】と【組織力】を正しく運用すれば、むしろ、いやだいぶチャンスかな...？　

【概　要】
今時は珍しい、『ちゃんとアジャイルやったら飯食えるんじゃね』派の会社の、チーム内（5名くらい）のトップかその次くらいのエンジニアのイメージ。現実にはScrumが多いので明確なリーダーポジションは無いのですが、それでも実際は自社の代表として立ち回れる人員が必要だったりします。やや年上の、そんなイメージの募集です。


【現在のScrumプロジェクトの実際。】
AWS等のクラウドサービスが浸透。DevOps等の言葉が認知され、マイクロサービスで構築される新規システムも増加。BtoBの世界でも『（ガチな）アジャイル』を志向するエンドユーザーが増加。2019年冒頭に各大手SIerも参入。新規のアジャイルプロジェクトが多数発生しています。（うちはここに刺さる事が多い）

多くはScrumプロセスが採用されますが、エンドの人員であるプロダクトオーナーが量・経験共に不足。（解雇制限の影響もあると思う）エンドの社内プロセスとの不一致、果てはベンダ間の摩擦など様々な要素もあり、すんなりと『アジャイルな』プロジェクトになる事はありません。その様な実態もあり、【プロダクトオーナー補佐】などの需要も爆増しています。



【我々のスタンス】
我々はベンダであり、多数のシステムやプロジェクトの経験を背景に、プロジェクトの実施主体であるエンド企業に対し、準委任契約で専門性と成果を提供する立ち位置になります。当然、エンドは我々に専門家としての知識・技能を期待しますし、専門家として通常要求される水準を下回る仕事をすれば、善管注意義務違反や契約不適合に問われることになります。

さらにアジャイルの専門家として振舞っていくには、エンドを支援し、アジャイルの導入やプロジェクトマネジメントそのものが円滑に行われるよう立ち回る必要があります。これらはチームの垣根を越えて行われる活動を含みますが、エンドの内部で起きている一部問題に対しては無力である為、プロダクトオーナー補佐も自社でアサイン可能な体制を志向します。

このスタンスのチームにとって、非アジャイル的なマインドのメンバーは邪魔でしかありません。

・顧客満足より自身の短期的利益を優先
・フェイストゥフェイスで話をするのは嫌だ
・責任範囲をやたらと限定したがる
・顧客のプロダクトに対して当事者意識を持てない
・指示待ちである
・設計や品質を軽視する
・言語等を個人的嗜好のみで選択する
・プロセスやツールの種類のことをアジャイルだと思ってる。

ですので、我々は自社のメンバー中心で小規模チームを構成、責任を遂行できる権限を得る事ができる体制を重視します。



【アジャイル以外のプロジェクトについて】
アジャイルプロジェクトは日本ではさほど多くはありません。（非ウォーターフォールであることを単にアジャイルと呼んでいるものは除く）常にアジャイルプロジェクトが顧客の目的にフィットするわけでもありません。そのような、アジャイル以外の多くの案件はウォーターフォールモデルが多いです。

『アジャイル』と言うキーワードで営業しているからか、社員のスキルセットがそっちに寄っているからか、広義のWebサービスやその周辺の小規模な開発案件に体制参画する様な話が多めです。

※上記は経験がそこそこあるメンバーの場合。若手は詳細～単体くらいの製造チームの話が多い気がする。





【背　景】
単純に増員です。

・しっかりとした技術的なベースを持ち、指示待ちではない同僚が多くなる事。
・上記のメンバーらと、学習会やその他の集まりで情報交換。
・仲間と同じ目標を持って動けること。
・ガチアジャイルやるとなると、他社からもそれなりにいい人がくる。（来ない事もある）
・新規が多いから、なんだかんだ環境は新しいし、AWSも使うすね。

・勉強会あり（就業時間内）
・関連会社に受託会社が2社　副業での受託開発支援（リモート）は可。だいたいJava。たまにPHP。
・自社での開発作業時は服装自由。外部の話はドレスコードがあるのは半々くらいな印象。
・社宅制度あり（入居時の負担が低くなるだけ。）
・入社時研修制度あり（Webシステム開発の基礎力が不足と言う方向け。）
・従業員に対する受動喫煙対策　あり　　対策内容：室内禁煙（喫煙所あり）