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

【会社の特徴/個性】
コンサルタント/ＰＭＯと、先進的なＷｅｂエンジニア。これらのふたつの職種の『専門性』が武器の、11年目の会社です。

コンサルタントはシステム開発の前段階。コンサルフェーズで、顧客の課題を見つけ、解決策を提案。その解決方法がＩＴで実行できるものであれば、エンジニアの出番になります。

我々は業界内では新参・後発の会社になりますので、昔ながらの会社とは差別化した戦略になります。弊社のシステムエンジニアは昔ながらの勝ち筋である『儲かる業務の知識』『大規模システム』特化のスタイルは回避し、【アジャイル】【未知の業務・仕様・先端技術への対応力】を武器とするスタンスで9年間積み上げてきました。

【顧客層/事業領域】
昨今の通信インフラの高度化や、コロナによるビジネス環境のパラダイムシフト。
BtoCを主力にしていた大手法人が変化に対応すべく『自社事業のWebビジネス化』『次世代のサービス領域への進出』などを行うための、新規のシステム開発需要（PoC含む）が我々のメシの種になっている傾向はモロにあります。

このような領域では、当然ながら、マーケティングや企画の領域でのコンサルティング需要や、プロジェクト化した後のPMOの需要。そして、先端技術を使用したシステム開発の能力に対しての需要が発生します。
社内の要素技術も、その様な需要に引っ張られ、その時代その時代の先進的なモノが中心になります。

もともと、日本は解雇制限のある労働市場である為、エンドは新規投資案件の為に社員を新規雇用しづらく、この手の新規開発需要を担当するのは、主に『ベンダー側』の我々になります。我々の場合はさらに、旧来のベンダーの守備範囲、メインストリームあたりを回避してきたため古いシステムの保守案件を得るチャネルを持っておらず、上記の新規ビジネス領域の前線を、常に新しい方向へ転戦していくような立ち回りになっています。



【要素技術】
現在の社内の主な使用技術は
・Kotlin（SpringBoot）
・Golang
・Python（Flask）
・TypeScript（React）
・AWS
・GCP
となっており、また、設立時からのアジャイル推し傾向もあって、有名Webサービスや大手上場企業エンドの概念実証開発（PoC）等に対応可能（と言うかそういう類の仕事ばっかくる）さらに自社でコンサル/マネジメント 専門の部署を持つ為、最上流から対応可能と言う、異色のITベンダーとなっております。

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


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

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



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

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

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

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

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



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

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

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





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

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

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