この記事で書くこと 
アジャイルというチームでサービスを開発、リリースを目指していく方法を取ろうとしたチームで過ごす中で、会社の体制や、チームメンバの出入りなどで変容していった歴史（時系列１->時系列2）の中での学び。
その学びを元にして、機能しそうな形というものを提示する。
ここでいう「アジャイル」の言葉の定義は、動作するソフトウェアを素早く開発するための
「アジャイルソフトウェア開発手法」全般を意味する。
記事を書くに至るモチベーション
・より良い仕事をチームですることの難しさをもっと色々な人に考えるきっかけをつくりたい。
・ 論語読みの論語知らず ということわざにもあるように実体験には意味があると思うので、記録として言語化してみようと思った。
時系列１
チームの中に、アジャイルへ成熟したメンバーがいる状態。
新規メンバーが参入したとしても、アジャイルへの理解が浸透しているため、教育することができる状態。
チームの開発サイクルについての取組み
スプリントは導入していない状態。
チケットをとったメンバーがリリースタイミングを調整しつつ開発を進める。
スプリントレビューの実施有無
無し
共有についての取組み
毎朝チームメンバーで困った点や進捗などの軽い共有時間がある。
週に一度KPTを行い、課題点含めた振り返りと現状把握を行う。
新規サービス開発についての取組み
まず、関係者で、インセプションデッキとユーザストーリを作成していた。
その内容を「マスタードキュメント」として位置付けを行った。
このストーリを元に、キックオフを行い他の開発者以外との認識を合わせる。
このMTGで目線を合わせた上で、開発者側が用件をB側とすり合わせを行いつつ、
見積もりを開始する。
見積もりが完了したタイミングで、再度B側含めて結果を元にミーティングを行い、リリースにむけてスケジュール感と、優先順位の変更による用件のすり合わせを行った。
迷ったときには、全員が「マスタードキュメント」に戻り、必要なもの、必要でないもの、を決めていった。
開発者に求められていたことと、権利周り。
求められていたこと
・見積もりを行うこと
・実装フェーズに入ったら、とにかくつくりきることに注力すること。
権利
・見積もりを行った上で間に合わない場合は、その時点でΒ側と調整を行うことができる。
・実装機能に対して、バグなど、リリースを意識するあまり不完全なものを本番へあげることを避ける「あげない」という技術者サイドからの主張ができる。
時系列2
チームの人数の内訳
アジャイルへ理解のあるメンバー数 < 不慣れ（関心が薄い）なメンバー数
関心が薄いメンバーがマネージメント層に入ってしまった。
関心が薄い（不慣れな）メンバーがB側の意思決定者(PO)になってしまった。
チームの開発サイクルについての取組み
スプリントを導入している状態。
１週間に一度、B側と開発側とでスプリント会議が行われる。
基本的には作成されたチケットには期限がすでに決まっている状態。
チケットをとったメンバーがリリースタイミングを確認、調整しつつ開発を進める。
差込タスクは勿論あるが、なかなかスプリント会議で決まったことは動かせない状態。
スプリントレビューの実施有無
無し
共有についての取組み
毎朝チームメンバーで困った点や進捗などの軽い共有時間がある。
週に一度KPTを行い、課題点含めた振り返りと現状把握を行う。
新規サービス開発についての取組み
インセプションデッキとユーザストーリなどの作成は行われない。
マスタードキュメントがない状態で、フワッとリリース期限をきられる。
見積もりが終わってない状態で、リリースが決まっているというプレッシャーとストレスが加わる。
開発者に求められていたことと、権利周り。
求められていたこと
・機能用件を出すこと
・見積もりを行うこと
・実装フェーズに入ったら、とにかくつくりきることに注力すること。
権利
・見積もりを行った上で間に合わない場合は、その時点でΒ側と調整を行うことができる。
時系列1と時系列2での違いはいくつかありますが、
両方を体験している人間としては、300倍くらい時系列2の方が進めづらさと、開発していくことへの心理的ストレスが強かったように思います。 
その心理的な差分は一体どこから来ていたのでしょうか？
この差分は一体どこから来るのか
アジャイルは開発者だけで完結することのできるアプローチではない
こちらが一番大きな差分だと思っています。
そして、アジャイルの難易度を適切に表現している一文ではないかと思うのと共に、
上手く機能するための本質（コアな要素）は、ここだと今自分は考えています。
時系列１では、アジャイルというアプローチの大切さや有用性をきちんとBサイドに説明できていました。
そして、それを説明することができるだけの存在感が開発チームにはありました。
ただ、B側にそれを受け入れるだけの余裕がなく、とにかくサービスを出すことを優先した場合
開発者は目の前の作業に集中する他なく、説明する機会を持つことができないまま業務にあたらなければなりません。
ましてや、開発のマネージメントにあたるメンバーが機能しない場合はさらに、開発者（作業者）はしんどい状態になってしまいます。なぜか？何を実装するのが適切か、理解や共通認識がないままリリースにむけたアウトプットを強いられているからです。
開発者と、Β側（PO/PM）と、他の部署のメンバー（営業など）がアジャイルという１つのアプローチの価値と方法を正確に理解し、それにそった動きを見せることで、初めてアジャイルは機能するようになるのです。
そのためにはきちんとした共有のための時間と手間をコストとして捉えるのではなく、必要なものと受け入れることが必要なのだと思います。
この最初の部分がアジャイルを難しく、そして世の中のソフトウェア開発で「何か上手く進まないな、、」「うーん、リリース辛い」「しんどみ。。」を産んでしまっている原因だと思っています。
最後に 
拙い文章になってしまいましたが、想いは込めたつもりです。 
組織に対して「アジャイル」というアプローチを浸透させるという一番難しい（超えたら明るい未来が待ってる）壁を超えて行けるようになりますように！ 
ソフトウェア開発に携わる人が少し不安などなくみんなで進めるようになるきっかけのようになればと思っています。
間違ってる箇所など含め、何かご意見などございましたらコメントなどいただけますと嬉しいです。
ありがとうございました。 