- 前提と引用記事たち
- プロジェクト開始
- ウォーターフォール的増員がなされるアジャイル
- 残業はないが、キツい＝休みが取りづらく暇がない
- 広がるチーム間格差と不和
- アジャイルの恐ろしさは「チーム全員の能力が高い」という属人性。課題はPO
- それでも、まだ失敗はしていない
前提と引用記事たち
IT技術者として2018年はほぼ丸一年、（同じ現場で）アジャイル開発@スクラムをやってきた。今回の記事は完全に技術者向けで一から説明はしないので、まずは基礎知識。
スクラム (ソフトウェア開発) - Wikipedia
その他、今まで読んだINPUT資料を。この記事を書くにあたって本も読もうと思ったのだが、現状翻訳本かつ「アジャイルは素晴らしい！」しか書いてない本が多くて買う気なくした。2019年は、日本のSE現場経験者によるアジャイル本がもっと出てきてほしい。
mendix.buildsystem.jpfrontline.fmotihateten.hatenablog.comqiita.com
アジャイルのエヴァンジェリストが見落としてる点(3) | MechaAG
肯定派・否定派混じった悲喜こもごも。今回私もやや否定的な記事だが、中立派である。
私は1次請けではなく、使われる側の立場である。「受託・ユーザー企業共に上層部が何を考えているかまでは見えていない」ことははじめに断っておく。あくまでいちメンバーとしての体験記である。
プロジェクトの概要・状況は以下。
プロジェクト開始
初期に集められた人材は「業務・アジャイル未経験可、数年以上の経験者」だった。業務・アジャイル経験者と未経験者は半々くらい。最初の1カ月はほぼ慣れるための研修のようなもので、じっくりと慣れてもらい、チームの結束を深め生産性を上げていくという意図だったと思う。アジャイル講師による勉強会などもあった。
「意識を変えてくれ、今までのやり方は通用しない」
アジャイルの本によく書いてあるような台詞の、無言の圧力があった。我々は戸惑いながらも、徐々に慣れていった。ふりかえりミーティングでは意見も出しやすくチーム仲も悪くないし、個人・所属チーム単位で見ればプロジェクトは順調に見えた。
ウォーターフォール的増員がなされるアジャイル
なぜ発注側＝ユーザーがアジャイル開発を導入するのか。それは「流行りだから」などというミーハーな理由ではなく「開発費がトータルで安く済む」「仕様変更がしやすい」からだろう。
さて、我らのプロジェクトは最初は少ないチームだったのがどんどん増えていった。これは詳細設計以降を増員してやっつけるという、従来型のやり方を踏襲しているように見えた。現在は10チームくらいに膨れ上がり、正直全容を把握できない。マスタスケジュール（スケジュール管理については最後に紹介した記事に詳しい）が押している都合もあろうが、これがアジャイル？ いいのか？ とツッコミたくなる。
仕事というのは仕事算のように、100人でやれば一瞬で終わるというものではない。こう大規模になると余計にスクラムマスターの上にいる、従来型で言うPM・統括の人が重要になってくる。が、あまり機能しているように見えない。単なる私の杞憂、勘違いであればいいのだが。現在は統括やチーム間連携が最重要課題となっている。
残業はないが、キツい＝休みが取りづらく暇がない
日々の短いミーティング（デイリースクラム）やることを決め、1時間でも手が空いたらすぐ動くというのがアジャイルの流儀。ゲームで言うと、完全に「素早さ重視」の仕様なのがアジャイル（まさにagileという英単語の通りではある）。
このプロジェクトは超絶ホワイトだしアジャイルにもだんだん慣れていったが、それでも小刻みなスプリント単位でやることが決まっていると心理的に休みを取りづらい（個々人の事前申請休日を加味して見積もり、割り振りをする体制ではあるが）。何より、日々のタスクをこなす中で暇がない。
決して「サボる」という意味ではなく、技術者にとって「暇な時間」は必要でもあるなと。自分の担当外のソースや仕様書を見たり、他チームの様子を伺ったりすることで既存バグを見つけたり生産性が上がることもあるからだ。
「飲みニケーション」は古いと言われるが、日本人の場合「ふりかえり」では出てこない本音もたしかにある。アジャイルの1チームは、基本2テーブルに収まるので飲みに向いている。少人数なら全員と話せるし、盛り上がる。ここに日本型アジャイルのヒントがあるかも。プロジェクトの予算で全額でないにしても金を出し、チーム単位で飲みに行かせるべきである（タダで飲みたいわけでは決してない）。
広がるチーム間格差と不和
最初は各チームはそれぞれ担当領域が分かれていたのだが、徐々に案件単位で分かれ、全領域をやるようになった。すると、できの悪いチームの品質に直面し、尻拭いをすることが増えてくる。これで一気にチーム間が不仲となった。後発のチームは不利な部分はあったと思うが、3ヶ月半年しても進歩がなくそれにしてもひどい。
よく言われているのが冒頭に引用した記事にもある通り、「アジャイルはエリート集団を前提にしている性強説」ということ。
「無駄なドキュメントを作らない」が通用するのも、阿吽の呼吸というか「当たり前」のレベルが高いから。相互にレビューしたり、ふりかえりミーティングで意見を出し合って成長できるのも対等な関係があればこそ。ガチガチの体育会系だと上の人間がシバキ上げるだけだし、ただの無能集団だと馴れ合って終わりである。
旧来のウォーターフォールにも問題は多い（長くなるのでここでは触れないが）し、アジャイルの良さはたしかにある。私はこの案件を聞いた時、勉強できる・面白そうだと思った。経営目線というかプロジェクト管理を自分でも色々考えるようになったし、何より1年かけてようやくブログが書ける。
ただ、日本の大企業でアジャイルがうまくいった例はあまりないそうで、やはり小規模開発か超一流軍団でないと難しいというのが私の現時点での結論。
本場アメリカは日本と違ってIT技術者がエリート職だが、中でもマイクロソフトやアマゾンなどのアジャイル開発はサッカーで言うブラジル代表のようなもの。個々の能力が高く全員がどのポジションもできるし、監督がうるさく指導する必要もない。それが日本代表の「自分たちのサッカー（笑）」ではアジャイルは不可能なのである（これはあくまで比喩であり、日本のTOP技術者11人のチームなら当然可能）。
アジャイルの恐ろしさは「チーム全員の能力が高い」という属人性。課題はPO
チーム内で担当を固定せず（スプリント・タスク単位で入れ替え）属人化をさせないのがアジャイルだが、結果的にチームメンバーの力量、そしてチーム環境に大きく依存するのもアジャイル。別の意味での属人性が存在する。
もちろん本当にダメな人は契約を切られるのがIT技術者の世界だが、それでも技術力に差があるので多少は助け合いというか、ならしやすいのが従来型ウォーターフォールというか縦割りチーム。同じ会社の先輩が後輩・若手の面倒を見るという日本企業の文化もあるが、良くも悪くもそれが機能しづらい（もちろん縦割りでもチーム間で会社が違うと、質問一つやり取りするのもエクセルベースで時間がかかってたりして最悪なのだが）。
サッカーチームに1人だけブラジル代表がいても弱いのと同じで、意識の高い人が1人いてもチームはよくならない。うまく回ればたしかに生産性は指数関数的に上がるが、逆に通常ならn倍にはなるところが1.n倍にしかならない危険も。受託=開発側はもちろん、発注側もこれらのリスクをきちんと認識する必要がある。
チーム内のPO（プロダクトオーナー）にしてもそうで、ほぼ完璧に技術も業務もわかっている人がやる前提なのだろう（というか内製の場合、そもそも同じ会社の人間）。本来は。でも日本の現実はそうじゃなく、「お客さん」の位置付けであり同じチーム感が全くない。結果、チームとのコミュニケーションにも齟齬が発生することもあった。開発初期の段階でPOは「え、今いるそれ？」といった画面の細かいことばかりツッコミがち（プロダクトバックログではなくすぐやれという）で、それが結果的に非効率につながっていた。
POが教科書通りに機能しづらい。これが日本のアジャイルの最大の弱点であろう。PO個人はもちろん、ユーザー側企業の上層部までアジャイルを理解しているかどうかが問われる。POは製品の責任者、顧客側の人間だが顧客のトンチンカンな要求は跳ね除けなければいけない。だが、上意下達の大企業サラリーマンにそれができるか。
会社全体がガチガチのウォーターフォール的なのに、プロジェクトだけアジャイルって矛盾していませんか？ 構造的・人材的な問題から日本でアジャイルが定着するまで、あと10年はかかるだろう。
それでも、まだ失敗はしていない
結局のところ、ITに限らず仕事は「やり方を変えただけではうまくいかない」という至極当たり前のまとめになる。ニュアンスは変わるが、ユーザー企業との信頼関係が第一なのも同じ。アジャイルの場合、単純な能力の高低以外の適性もある。
ただIT技術者のスキルの一つとして、経験しておくのはいいことだと思う。将来的にはアジャイル寄りのやり方が主流になる可能性はあるし。教科書的なアジャイルは日本では正直厳しいが、ガラパゴスでけっこう。日本向けのアジャイルはきっとある。
このプロジェクトについては従来型の方がよかったのか、まだ答えは出ていない。正式リリースはまだ先だが、アジャイルなのだから予定通りリリースはされるだろう。問題は品質だ。
とはいえ、まだ失敗だったというわけではない。また続編を書けるタイミングになったら、筆を取ろうと思う…このブログが身バレして怒られたりしない限りは。
