初めまして。ほりさんと申します。大きなところから小さなところ（親方日の丸な大企業から本当に創業1年未満のベンチャー企業までまで）までいろいろな企業を経験して、2020年の夏より現職におります。
新卒で最初に入った会社が大手SIerの中のITコンサル部隊、その後WEB制作の大手、ベンチャーを二社経験して、小振りなメーカーでいわゆる「一人情シス」を4年半経験、その後転職するも勤務形態（シフト勤務）の説明不足からくる勘違いもあって4か月でそこを退職、約6年ぶりにITソリューションを「提供する」側に返り咲いて今やく1.5年というところです。
【①Agile（Scrum）は実のところ初学者でした。】
ウォーターフォール型開発であれば最大規模4億円、工期2年半という大規模なプロジェックとのPMを経験したことがあるのですが、Agileとの関りは現職に入るタイミングで初めて、というのが実際のところでした。英語については読み書き問題なしなのでオフショア開発というところはどうということはなかったのですが、現職の求人情報に記載されていたAgile（アジャイル）という単語は聞いたことがあるものの実務に携わったことがないので、面接対策として薄めの関連書籍を丸一冊、一日掛けて読んだというのを覚えています（笑）
変化に強い開発手法、利便性や収益の上がる最小の単位で良いので小刻みにリリースを積み重ねていち早く現実の市場から自ら作ったシステムに関してのフィードバックを得て機能改善を繰り返していく、ということは理論的には非常に今の世界にマッチしていて、「自分がずっと手掛けてきたウォーターフォール型の問題点これで全部解決じゃん！」くらいに心躍った記憶がありますが、入社してみて実際にAgile（Scrum）をSIerという身分で実践してみるといやはや色々現場では起きる（笑）
もちろん、私がAgile初心者であるということによる部分はあると思いますが、この道10年以上という人でもどうやら共通で抱えている問題のようなので、私なりに直面したケースと対応策といったところをこちらにまとめておくことはとても意義があると考えて書き始めることにしました。
【②Scrumチームはどこにある？】
まず、私がAgileのプロジェクトに参加して最初に気付いたのは、「PO（プロダクトオーナー）」というとても重要な権能の人がスクラムイベントの必要なものにしっかり参加してくれるということが非常に稀であるということです。SIerという立場でAgile開発に関わると、発注者であるクライアントがPO、スクラムマスターが開発側のメンバーと取りまとめるリーダー的な立ち位置、そして開発者としてSEが複数名でチームを組んでいる、というところまでは一応体制図としては出来上がっていて、とりあえずここまではOKなんです。
しかし問題は、Agileは「チームで」「一つの」「プロダクト」を一丸となって組み上げていくという手法であるところ、発注者であるクライアント＝PO様が旧来の受発注型の体制の概念を引きずっていることが多く、「システム開発プロジェクトってせいぜい週一くらいの業者とのミーティングでこちらの要件を口頭で伝える（ヒアリングに対応する）くらいの負荷で、あとは業者さんが良しなにやってくださる」という見方をされていて、スプリント計画会議だったり、バックログリファインメントだったり、レビューだったりレトロスペクティブだったりというイベントの数々を2週間の単位で繰り返す、1コマあたり余裕で2時間を超えるような会議に引きずり出されるということを全く想定していない、という状況にしばしば遭遇するということ。
なぜこのようなことに度々直面するのかなと考えたところ、アジャイルというチーム体制はどうやら「WEBを主体としたソフトウェアサービスを提供することを事業のメインとしている企業がその社内で取り入れる仕組み」であるということです。具体的な現実の企業でいえばフェイスブックであったり、Google（特にGmailとか）であったり、日本ならサイボウズであったりMixi（SNSプロバイダーとしての）とか、こういった企業が自社のサービスの立ち上げから半永久的な継続的な改善活動を行うというケースでワークする体制であるということ。
我々SIerに声を掛けてくれたクライアント側で、システムの要件が固まっていないので良かれと思ってウォーターフォールよりもアジャイル型のプロジェクトの方が適してあるであろうと考えてそれで開発プロジェクトを始めるというのは良いのですが、結局工期の間に一度もリアルな市場にリリースしない（真の意味でのエンドユーザーの目や手に触れることがない。実物のフィードバックを得られない）、スクラムイベントに全然お客様が来てくれない、POというのは「たった一人の人間」であるべきと教科書には書いてあるが、日本のある程度の規模の企業でシステムの仕様をただ一人の人間が決められるということはほぼないため、POという「会議体」になってしまって開発側からの問い合わせの一つ一つに機動的な回答が得られない、ということに往々して直面します。
システム開発を社外に委託している＝システムやアプリ自体が事業の柱とまでは言えないビジネスモデルの会社⇒となるとシステム開発に掛けられるリソースは限られてくる、となりスクラムの「ひとつのプロダクトの開発に全力で取り組む」ということができないため、SIer（受注者）とクライアント（発注者）という二つの正反対の立場がある状態でスクラムチームを組もうとすると、スクラムが念頭に置いている熱量（システム開発プロジェクトへ取り組みの度合い）と実際のスクラムプロジェクトの運営に必然的に歪みを生じてしまうのではないか、と思うのです。（だからどうしてもPOがスクラムの全イベントに参加するほどの優先度になって頂けない）
【③フルスタック・エンジニア】
エンジニアの人的資源というのは特に労働人口の減る一方の日本ではいまや本当に「枯渇」という状態であるというのが正しい表現だと思います。なので、エンジニアが重要な経営資源である会社ほど「うちの会社がどれだけエンジニアにとって働きやすい会社であるか」ということをアピールして来ます。（しかしこの「枯渇」という問題意識が共有できているのがエンジニア仲間同士のみであるというところに日本の残念なところがあります。高い技術を持ったITの専門家の地位だったり扱われ方が大して高くないというのは日本のとても不思議な、ガラパゴスなところです）
なので数多あるITの分野でも例えばJavaだけはできる、ネットワークだけはできる、データベースだけはできる、というだけでも希少価値がありそれだけでも食べていけるのですが、こういう専門分野を複数持っていて、価値を生む・利用できるアプリケーションだったりシステムだったりを一人で組み上げてしまえるというエンジニアとなるとさらにレアな人材になってきます。
Scrum開発でそのチーム内にいる開発エンジニアは「フルスタック・エンジニア」を前提にしており、たった一人でお客様の開発要件を嚙み砕いてシステムの機能に落とし込めるし、コーディングできるし（WEBのHTMLもJavaも）デザインもできるし（Photoshopとか）、バージョン管理もできるし（Gitとか）、SQLも読み書きできるわ、こういったものが動く環境をAWS上に作ってしまえるわ、という人間を3人とか5人とか揃えてチームにする、ということになっています。
こんなスーパーマンを集めてチームにする人件費ってお幾らですか？と言いたくなります（笑）
【④仕様変更を歓迎する？】
スクラムの教科書には「プロジェクトの終盤であっても仕様変更を歓迎する」とある。どうもこれが曲解されているようで、「アジャイルっていつでも変更できるんでしょ？」と言われてしまうケースがよくあります。正確には「ウォーターフォールに比べて軌道修正しやすい」であり、例えば2週間のスプリントで一生懸命開発している最中に「ごめんやっぱりこれが優先」と言われて作る側が即応するのが結構大変なのはウォーターフォールもAgileも一緒です。
【⑤システム開発に魔法の杖は存在しなかったようだ】
散々愚痴を述べてしまいましたが（笑）それでもAgileはこの半世紀ほど続けられてきたシステム開発の問題点をなんとか現場のエンジニアの皆さんが克服しようと試行錯誤して編み出した方法論であり、旧来のやり方に比較してスマートであることは間違いありません。しかし、その概念の理解とそれに基づく実践と、しかもその実践というのは日々日々「低きに流れ」ないように自己チェックして是正してという継続が必要です。
こちらでは、私がプロジェクトの現場で遭遇するリアルな「スクラムを阻んでくれる」事象に対してどう取り組んだかというお話をしていこうと思います。