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

ＣＡＯＧ（Clarity About One’s Goal）

PMOコンサルファーム + アジャイルベンダー。一社体制による『顧客の目的を明確化し、それを関係者全員の共通のゴールとする』開発体制　アジャイル導入期の一番よくある失敗理由である、顧客事業部側とＰＯ間の様々な問題を解消する。

このスタンスの開発体制を、十分な再現性をもってエンド内に実現していく。
これが我々のミッションであり、目指すべきものです。



弊社の最終的な目的は、【現代版の終身雇用体制の構築と継続】となります。

現段階の弊社の最大の特徴は、未経験者から1年前後であるていど新規で書けるプログラマーに、1年半で詳細設計、3年前後で基本設計工程に参画できるWebシステムエンジニアに育てることが、継続性を持った形で実現できている部分になります。


この手法は、『普通のひと』から『ちゃんとした普通のエンジニア』を作る事ができます。しかしとにかく、コスト、時間、労力などはかかりますし、市場価値を得た時点での従業員のライトな離職などもたびたび経験する事になりました。

また、ここまで（スタートから社名変更まで）の６年間で、多くのものを得る事が出来ました。

多くは未経験だった現在の中核メンバーは、高い技術力とプロ意識、市場価値を持ちつつも、【現代版の終身雇用体制の構築と継続】にコミットメントし、今もその仕組みを作ってくれています。彼らがさらに若手を引っ張る側に回ってくれています。
事ここに至り、【自律したチーム】の構築が可能になりつつあります。

また、マネジメント専門部署ができました。異業界でマネジメント・事業推進の経験のある人材がメンバー構成の中心で、こちらも継続的な自社の改善活動を強力に推進する能力を持ちます。



・『自走でき、技術的基礎力のシステムエンジニア集団』
・『マネジメントで実績出した経験がある人材ばかりの集団』


これらふたつの事業部は、ＩＣＴ分野でシナジーを発揮する事ができます。このシナジーは、容易に模倣する事はできません。（時間と労力とコストがかかる。資本力だけではすぐにはできない。）さらに差別化要因として、当初よりのアジャイルソフトウェア開発志向があります。

これらの要素を兼ね合わせたものが、冒頭の【ＣＡＯＧ】と、我々が呼ぶ開発体制です。

このCAOGをサービスとして成立させていく、これからのフェーズ。
このフェーズで戦っていくために、それを常に念頭に置くために、トラッシュブリーフィング合同会社は、2019.10.15　『BAMV合同会社』へと社名を変更しました。

--------
とか言ってたら、コロナ来て大変だったのが2020
市場反転後の成長を狙う為、財務にダメージ出さぬ様に踏ん張ってきましたが、そろそろかな？

Java出身・自社所属のマトモなメンバー達と、ちゃんと自律できるアジャイルチームをつくろう。

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


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

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



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

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

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

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

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



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

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

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





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

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

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