最近、アジャイルを一言で表すならば、”群れる”だと思います。

アジャイルではSwarmingという用語で語られており、何かに群がっている様を示しています。アジャイルの文脈では、特定粒度のプロダクトなり機能を群がって改善を進める様子を示す。モブプロなどもその一種だと思います。

“群れる”の本質は、何かの対象に対して集団が相互作用（協力）しながらも自然と同じ方向を向いて、前に進んでいるということであり、個々がそのメリットを体系的に理解していることが大事です。本能的に「ひとりで進むよりも皆と協力して”群れ"ながら進んだ方が死なない」と判断できることである。

生物学的に見ても、強い敵が目の前に現れたとき単独で行動するよりも、統一された集団行動によって、1対1では敵わない敵に勝てるかもしれないということを本能的に知っているのと同じです。 アジャイル周辺のプラクティスの多くは、群れて作ることでうまく開発できることを体系的に知らせる仕組みが多くあると思います。 それは昨今のリモートの時代でも変わらない。 逆にリモートになってチームの状況が微塵も変わらないのであれば、それはアジャイル開発をしていない。もしくはチームメンバーが見えていない。

物理的な距離によるコミュニケーションの差異はどこかしらででていると思います。 今回は、そもそもの"群れる"という観点でアジャイルを見てみるのと、リモートチーム時代にどうやって変化し対応していったかを事例を交えてお話できればと思います。

事業の成長、開発組織の成長においても、イテレーティブさを担保することは非常です。事業という不確実性の高いものをグロースさせる作業に対して小さく失敗しながら、イテレーティブ（反復）に施策をユーザーに提供していきます。

その施策を実行する組織として、どのように「小さく失敗するか」を考え、どうやって「失敗できる」環境を作り出せるかは、事業・組織双方の成長において欠かすことはできません。
実現するためには、事業戦略・データドリブン・組織文化といった幅広い部分に適応する視野を持ちつつ、ビジネスサイド、エンジニアサイドともに連携して、事業を一緒に作っていかなければいけません。

今回は、事業を作り出す開発組織においての「失敗」をどのように考え、実践しているのかを事例を交えながらお話していけたらと思います。

DevOpsの領域だけでは対応しきれない、プロダクトのグロースの部分をData-Drivenの考え方でどういうふうに開発プロセスを補完していくかについて述べていきます。

LeanStartupのBMLループを開発プロセスとして各ループ遷移(Learn→Idea,etc...)の中でどういったことを意識しながらData-DrivenとDevOpsの考え方を使ってプロセス設計していくかについて、KGI,CSF,KPIの設定からビッグデータ基盤・データ分析基盤、優れた指標などDMM.comの事例を用いりながら説明していくます。

チームとして、良い『開発プロセス』を設計することは重要です。
ROIを高めながら、どうやってプロダクトを『最速』でリリースし、仮説検証を『高速』で繰り返せるかを常に考える必要があります。
そこで、重要なポイントとして気づいたのは、EBM(Evidence-Based Management) の概念におけるT2Mの部分『プロセスの見える化』と『ムダからの解放』です。
今回は、理想の開発プロセス(EBM(Evidence-Based Management) to 『Lean x Scrum』)から、VSM x SIPOC分析による『プロセスの見える化』の実現から分析プロセス。
そして、見える化することでわかる『ムダ』の解放をどのような工夫で行ってきたかをお話できればとおもいます。