アジャイル・スクラム開発はバカには無理
自分の観測範囲の出来事を見てきて、自分の中でアジャイルという概念、スクラムと呼ばれる開発手法に最終評価を下した。以降、スクラムもまとめて「アジャイル」という語で総称する。
一番平たくいうと、アジャイル開発はバカには無理、ってことだ。
目次
前置き
何度もいうが、僕はウォーターフォール (WF) 至上主義でも、二元論で話をしたいワケでもない。自分が経験してきた開発手法として、大きく WF とアジャイルの2つがあるので、その比較が多くなるところはあるが、どちらかなら完璧だ、なんて思っちゃいない。より良い仕事の仕方があるなら教えてほしい・取り入れたいと思っている。バカにはこの一文も理解できないんだろうけど、一応前置きしとくね。
今から語るメリデメは僕の主観に基づくもので、すなわち僕の観測範囲で、僕が巻き込まれた状況での話でしかない。もっと賢い人達が、適切な場所で運用するなら活路はあるのだろうけど、僕程度の年収レンジ・知能レベルの人材しかいない場所ではこのやり方はまず向かないな、という話である。
「そのデメリットの部分はこうしたらいいんじゃないの？」みたいな思いつきの指摘も要らん。散々試行錯誤してこの結果なんだよ。これだけコストかけても効果が出ない手法は、俺の中で劣っているとみなすので、コレ以上この手法を前提にして何とかしようとは思っていない。俺はこの手法を見限っているので、言いたいことがあれば自分のプラットフォームで好きに話したらいい。
アジャイルに感じた問題点
僕が感じたアジャイルの問題点をいくつかのトピックに分けて書いてみる。
「プロダクトバックログ」がアプリケーションの機能一覧でしかなく、インフラ、ネットワーク、非機能要件が可視化されない
先に言っちゃうと、僕が感じてきた問題点の原因はほとんど全て、プロジェクトを回すスクラムマスターのあらゆるスキルが不足していたことに帰結する。設計のスキルもアプリ開発のスキルもインフラ設計のスキルも顧客折衝のスキルもファシリテータとしてのスキルも全て劣っているのに、何でもかんでも自分のやりたいようにやりたがるので、傍から見ると無計画に非効率な行動を取っているようにしか見えなかったのである。
スクラムというと、「プロダクトバックログ」という機能一覧を作り、それを1個ずつ消化していくやり方をするだろう。そして、WF などと違って期限や締切を見越して全体の計画を立てたり設計したりするのではなく、プロダクトバックログ単位ぐらいで個別に詳細化して進めていくことが多いんじゃないかと思う。
内製のサービスで、1機能ずつ作っては迅速にリリースしていく、という場合なら、こういう手法で開発することで、
- 早くユーザに機能を提供できる
- 早くフィードバックを得られる
といった効果が期待できるのは分かる。
しかし、受託開発で、予めリリース日が決まっていて、実装が必要な機能もあらかた決まっていて、顧客目線でいえば「プロダクトバックログが全部完成していないと『使えるサービス』とは言えない」 という性質の案件では、アジャイル的な進め方は単純に計画検討を先延ばししているだけになってしまう。
最初にプロダクトオーナーとスクラムマスターとでプロダクトバックログ一覧を作り、コレを元に皆で開発していきましょう、という流れで情報展開されたのだが、いざ見てみたらプロダクトバックログがアプリ的な「機能一覧」でしかなく、「インフラ構築はどこでやるの？」「非機能要件の整理はどうするの？」というところが全く考慮されていなかったのだ。
アプリケーションとしての「機能一覧」資料それ自体は作るべきものだが、コレを最上位の概念として配置して開発を進めようとすると、あらゆる場面で無理が生じてくることは自明だろう。
あるプロダクトバックログ1つに着手して、「リリースする」というタスクに辿り着いたところで、初めてアプリケーションのデプロイ先となるネットワークやインフラの設計・構築をするというのか？そのプロダクトバックログだけメチャクチャ作業量重たくなると思うんだけど？というかインフラ設計って、「アプリケーションの1機能」の括りの中でやることじゃないよね？他のプロダクトバックログの中の都合も考えて設計しないとどうにもならないよね？でもそういう作りになっていた。
サーバのスペックの検討は？レスポンスタイムの計測・調整は？高負荷時の対応は？CI・CD 対応は？ログ設計は？監視対応は？そうしたものもプロダクトバックログに盛り込まれていなかった。
「実際本番リリースするとなったら、こういうタスクが必要なのは分かりますよね？じゃあコレはどこでどうやるつもりでプロダクトバックログを作ったのですか？」と聞くと、「インフラとか運用とかよく分からず考えていなかった」「でもプロダクトバックログというのはリリースする機能の単位で表現するモノだから、こうなる」の一点張りなのだ。
他のスクラムマスターがどういう風にプロダクトバックログを組み立てるのか、僕にはほとんど知見がないが、もし「プロダクトバックログというモノはアプリの機能一覧でしかないのだ」と言われるのなら、プロダクトバックログを最上位概念に置いて計画立てようとするのは愚行だろ、としか突っ込めない。
顧客目線でいえばインフラや非機能要件は見えにくいモノで、リリースされる機能は何か、という単位で話をしたい、という思いは理解できる。しかし、我々開発メンバのタスク組みを、プロダクトバックログを基に行おうとするのは、アプリケーション以外のレイヤーやリリース後のフェーズが全く見えていない、愚策だと言わざるを得ない。
インフラや非機能要件のプロダクトバックログが要りますよね、というと、「それらはリリースする『機能』 = 顧客に提供する『価値』がないから、1つのプロダクトバックログとして組むのは微妙だ」とか抜かす。じゃあもうお前の好きにやれよ。作るの俺じゃねえし困るのも俺じゃねえから。
プロダクトバックログに「全体設計」「共通設計」「基本設計」といったタスク・フェーズがない
例えば、「こういうカンジの SNS を我が社で作りたいと思う」「でも具体的に何を作るかという全量は特に決まっていない」みたいな、そういう状態から企画・設計・開発・リリースを繰り返していくような案件だったら、「全体的なアーキテクチャ」なんていうモノは定めづらいから、プロダクトバックログごとにアプリ領域もインフラ領域も改築・増築を繰り返していくしかないのは分かる。そこにイビツさが出るとしても、早く一般リリースできることにメリットが大きいだろうから、トレードオフでその負担を飲み込めるとは思う。
でも、前述のように、期限までに作るべき機能があらかた定まっていて、それら機能が密に連携しているような案件だと、やっぱり「全体設計」とか「共通設計」ってモノが必要だろう。画面デザインにしろ、フォームの組み方にしろ、コンポーネントの再利用性にしろ、「あっちのプロダクトバックログでも、こっちのプロダクトバックログでも、共通して必要になるパーツがあります」という状況は平気で出てくる。
しかし今回作られたプロダクトバックログは、複数のプロダクトバックログ (= 機能) を横断して検討が必要な事項に対応するための場面がどこにも表現されていないのだ。
それもそうで、「プロダクトバックログはリリースする機能の一覧だ」と言い張っている奴の発想なのだから、インフラのことも考えていなかったように、「これら機能群のまとまりや結合部分、全体のテイストや平仄を揃えるためのタスクは、何もリリースしないからプロダクトバックログとして作らない」という発想になるのだろう。
「動くソフトウェアを早くリリースする」という狙いを取り違えている・ビジョンやアーキテクチャを説明する図や文書を書いて共有しない
「あれ？この人スクラムマスターとしてまともな思考が出来ていないのでは？」と疑問に思ってから、その疑惑が確信に変わるのはそうかからなかった。
この人は 「1つのプロダクトバックログが完成すれば、その機能は本番リリースできるのだ」と強く信じていて、「今回のスプリントではプロダクトバックログ No. 3 は必ず完了させましょう！」とか言うワケである。
前述のように、「インフラ設計は？」「共通設計は？」といった問題は山積みで、これらに対して何らまともな回答・対策を出していないのに、「一旦、このプロダクトバックログは、そういうこと気にしないでとりあえずこの機能だけリリースしましょう！」とか言う。
「っていうかプロダクトバックログ No. 3 って、No. 2 の『ログイン』機能の後に登場する『ログインしたユーザがコメント投稿できる』機能ですよね？ログイン機能なしでどうやってリリースするんですか？」と聞くと「一旦ログイン機能はモックで逃げましょう！」とか言う。
「それって本番リリース可能なプログラムになってないですよね？」というと「ログイン機能が出来上がってから後で追加のプロダクトバックログを立てましょう！」とか言う。
…
…なんでココまでツッコミが来ていて、「先に全体の計画立ててから作業しましょうか」とか「プロダクトバックログそのものの組み方が良くなかったですね」とか思い付かないんだろうか。この期に及んで、そういう後先考えない仕事の仕方で成功が見えているのだろうか？そのビジョン俺には微塵も見えないから、見えてるなら見せてほしい。
多分だけど、こういう発想って、アジャイルソフトウェア開発宣言に書かれている、
包括的なドキュメントよりも動くソフトウェアを
という一文を完全に読み違えているんだと思う。
まず、案件の前提が見えてないんだよね。今回の案件は作るべき機能も期日も決まっているんだよ、自分達で機能やタスクを入れ替えられるような案件じゃないんだよ、ってことが分かってない。そこに、ただただアジャイルの原理原則を当てはめることだけに一生懸命で、全然顧客やチームメンバの話を聞いていなくて、全員が求めていることは却下して、誰も求めていないことばかりやろうとしている。アジャイルの表面的・形式的なことを守ろうとしたところで実態が伴っていないんだから、ただのアジャイルごっこなんだよなそれって。
でさ、今この状況において、「動くソフトウェア」を提供するためには、まずは包括的な設計が必要なんだってことが、どうにも理解できていない。プロダクトバックログ全体を通してインフラ構成を検討したり、機能間の繋ぎ込みをどうデザインしようか、って話をしたり、そしてそれらをドキュメントに起こすことでチームメンバ間の共通認識を図るべきだ。もっというと、インフラ構築や監視ツールの導入にはクラウド利用料などが発生するのだから、顧客への説明も必要。なのに 「ドキュメント作成自体は価値を提供しないから」と思い込んでいるので、ドキュメント書きたくない、まず動くソフトウェアを作りたい、の一点張りになっているのだ。お客様も「全体像が分からないから説明資料が欲しい」って何ヶ月も言ってるよね？ 俺も全体像がよく分かんないからそんなタスク切りされてもやれねえ、代わりにこうしたいとかって何ヶ月も言ってるんだよな。
プロセスやツールよりも個人と対話を、
契約交渉よりも顧客との協調を、
何で顧客と対話しないの？
…
この場合はね、ドキュメントが顧客に価値を提供してるんだよ。こんな状態で一見動いているように見えるソフトウェアが出来上がっても顧客には何の価値も提供していないんだよ。だってログイン機能がモックなんでしょ？後で手直しするところ多発するんでしょ？そんなハリボテ、設計工程で作る「画面イメージ」と一緒じゃん。
ドキュメントよりも動くソフトウェアに「より価値を置く」としか書いてないんだけどさ、コレってアジャイルを初めて聞いた人の典型的なあるある勘違いじゃん。最終的に「僕はドキュメント書きたくない人だから…」とか抜かすので、それお前個人の考えだろ？全然顧客目線じゃねえじゃんか、と思って、もうこの個人との対話を止めた。顧客はドキュメントくれっつってんのに、「自分が書きたくないから」とか、開発手法以前の問題なんだよな。仕事なんだからお前のやりたいやりたくないとか持ち込むな。顧客の要望を聞け。
フルスタックであることを求められるが、誰一人としてそのようなスキルを持ち合わせていない
今までの話全部忘れて、仮に、うまいことプロダクトバックログが綺麗に設計されていたとする。インフラや非機能要件の内容も適切に盛り込めていて、「1つのプロダクトバックログが完了すると、その機能がリリースできる状態になる」という、理想の状態が前提に出来上がっていたとする。
それでもやっぱり難しいのは、機能を実装するチームがインフラや非機能要件のことまで考えないとリリースにこぎつけられない点だ。
前述のスクラムマスターは「そういうものなんで」とサラっと言うが、この人がやってた他の案件、全然セキュリティ対策とかしてなくて穴だらけだった。自分ではフルスタックでやれてるつもりかもしれないけど、初心者向けセミナーのハンズオンで作ったサンプルプロジェクトじゃないんだから、エンジニアとしてそんなゴミみたいなモン提供しちゃダメだろ、って思って見てた。
あるサービスやツールのドキュメントを開いて、「Get Started」のページをちょっと触って出来た出来た～なんてレベルは誰だって出来ることで、そのレベルの知識をもって「自分はやれます！」なんて抜かしたらダメなんだわ。そんなの発注元の非 IT エンジニアの人達だって何日かあれば出来ることじゃん。でも彼らがわざわざ我々エンジニアに発注するってことは、その金額に見合った成果を望んでいるワケで、それはあらゆる異常系への考慮をしておくことだったり、息の長いシステムとして計画してくれることだったり、素人が考慮できないような高度なトラブルも未然に防げるような知識を動員した成果物に仕立て上げていくことが求められているワケ。
でも、そんなセキュリティ対策の「セ」の字もないような、カーゴ・カルト満載のお粗末なシステム組んで案の定バグり散らかしてるようなレベルじゃ、全然顧客の要望に対応できてない完全なスキル不足なんだよね。
…
偉そうに言っている俺も、自分がフルスタックで何でも出来るとは思っていない。ただ、「俺はこういう領域の知識がないから、実際やるなら相当な準備が必要だ」「有識者を参加させた方が良い」というような、リスク察知は出来ているつもりだ。
自分がある程度得意だろうと思っている内容に対しても、想定できる脆弱性や弱点、自分が策定した設計のデメリットなんかは洗い出した上で顧客説明をする。どんな場面でも銀の弾丸などなくて、デメリットは常に存在するのだから、それを承知のうえで、「それでも一番メリットが大きく、許容可能なデメリットに抑えられているのはこの手法だと思い設計しました」と顧客に説明する義務があるだろう。自分が発注側だったらどんな説明が欲しいかっていう、当たり前の考えから逆算して、自分が考えた過程や却下した案、メリデメの比較マトリクスなんかを作って、顧客の理解を得て仕事をするのが普通だ。
話を戻して。
「本番リリース出来ないようなお粗末なレベルなら、短時間で俺でも組める」「本番リリースを考慮するには、俺の今のスキルでは時間がかかりすぎて現実的に出来ない」っていう領域は、誰もが思うことだろう。本当にフルスタックで滞りなく開発ができるような人材は、こんな年収レンジの案件に参画しない。
少なくとも僕のいるような環境では、誰も、フルスタック開発なんか出来ないのだ。それなのに、プロダクトバックログを前提にしてタスクを進めていくと、結果的にアプリもインフラも運用フェーズも全部分からないと進められない局面が出てくる。案件の中で勉強して、自分のスキルの幅や深さを広げていく気概はあって良いのだが、顧客目線でいうと「僕も知らないんですけど、練習しながら作りましたわ！」っていうシステム納品されるの、ちょっと怖くない？ｗ
エンジニアとして学ぶ気があって、あえて困難なタスクに挑戦したいというのは素晴らしいことだが、その一方で、ちゃんと顧客の要求水準に達するように人員調整したり、タスク組みしたり、っていうのは、プロジェクトを管理する人間がしないといけないことだ。
現実的には、大抵のエンジニアは「何年か仕事をやってきた自分が未だに分からない領域というのは、相当に難しい領域なのだろう」ってことは把握していて、もしも自分がトライしてみて上手くいかなかった時の顧客へのリスクも考えるから、ホイホイと挑戦はしたがらない。自分がある程度出来る領域を、まずは抜かりなくこなせるようにならなきゃ、というところで精一杯だろう。分かる。俺も同じ考え。
でも、前述のようなプロダクトバックログの組み方で、さらに「自分達がやりたいプロダクトバックログを選んで開発していきましょう！」なんていう雑なファシリテートしかされないと、本音は「どれもやりたくねえよ」 なはずだ。だから誰の手も挙がらないのだが、その原因が分からず不思議がっているのはスクラムマスターだけ、という地獄のような状況だ。プロジェクトを管理しろ。
見積が定性的
「アジャイルに」「アジリティを高く」「サクッとやっちゃいましょう」
この辺のワードが出てきた時は「あーこりゃ2時間会議しても結果出ねえヤツだなー」と思ってる。あらゆる見積に定量的な要素がないから。
ストーリーポイントの見積の時も「開発に慣れてきた状態を想像して、かかりそうな工数を算出してください！」とか言ってて、「開発に慣れてきた状態」とかいうモロ定性的な要素を入れて見積するもんだから結果が人によってグチャグチャ。さらに自分が想像していたような工数を提示されないと「でも、コレって、8時間もかかるとは思えなくないですかぁ？」とか誘導して無理くり数字を調整したりする。実際の実績を見てみると4日くらいかかってたりするんだけど、予実を照らし合わせることもしないので、何で遅れてるんだろうーとか言ってる。意味のある数字がどこにも存在しなかっただけだろ。
ドキュメントを書く能力もない、定量的な数字で計測する能力もない。敗因はココに帰結する。
現状ほとんど WF になってる
チームメンバも顧客も意見・要望を出しているのに、スクラムマスターの一点張りで、リリース日までのスケジュールをロクに組み立てず、全体設計や運用設計のタスクを一向に可視化したがらないので、もう皆ゲンナリしている。機能間の連携がどうしても多い性質のシステムなので、やっぱり先に設計してからですよねってなってきていて、それでもプロダクトバックログの存在が邪魔で身動きが取れない感じ。だいたいプロダクトバックログを「こなすべきタスク」とみなすのっておかしいよね？ でもそこはスクラムマスターが折れないのでチーム全体の悩みの種になっている。
やっぱりシステム全体の設計をまとめてやらないと、機能間の連携や顧客側の運用面が見えないよねってことで、タスクの着手順がようやく変わってきたところ。相変わらず先々を見ようとはしていないけど、もうなんかほとんど WF じゃんって感じになってきてる。
この顧客、この案件、この要望に対して、どういう開発言語が良いかとかどういうサービスを組み合わせようかとか、そういうところはツールを比較検討するのに、こういう性質の顧客・案件に対して、どういう開発手法・プロジェクト管理方法を採用すべきかってことに対してだけは最初からスクラム一択、と考えてたのが根本的な間違いだろう。開発手法も単なる「ツール」でさ。何度もいうが WF とアジャイルを単純比較など出来なくて、使うべきでないツールを選択したのにその間違いを認めないから皆ゲンナリしてるってだけだ。
もう認めようよ。この案件においては、アジャイルというツールは劣った選択なんだよ。世界のどこかで賢い人達が賢く適切に使うなら優秀なツールなのかもしれないけど、俺ら程度の人材がこういう状況で使っても効果のないツールだったんだよ。
本当にフルスタックに仕事する気なら、特定のツールに固執する方がおかしいよね。どんな開発言語でも、どんな開発手法でも、柔軟に使い分けるのが、本当の意味で顧客目線で価値あるソフトウェアを届けるためのエンジニアとしての宣言なんじゃないの？
前提から間違っていて、その間違った前提の元に作られた土台も間違っていて、グラグラの土台の上で仕事しろって言われてる状況で、そりゃー上手くいくワケねえべや。
何が違ったらもう少しマシなアジャイルプロジェクトになったのだろう？
僕としては、今回の案件では WF に近いやり方でシステム全体の設計からブレイクダウンしていった方がベターだっただろう、と思っているのだけど、譲歩して、開発手法はアジャイルのままで、何を改善したらマシになったかな、ということを考えてみる。
- プロダクトバックログに「インフラ構築」「運用・監視」「非機能要件」の項目を置く
- プロダクトバックログを「アプリ的な機能一覧」とか「ユーザストーリーのみを示すモノ」にするのではなく、「ユーザストーリーに直接関係しないが必要なタスク」も書く表にしておけば、タスク漏れが発生しなかったと思う
- 「プロダクトバックログ」とかいうアジャイルっぽい名前に釣られて「ごっこ開発」に陥ってしまうなら、潔く「プロダクトバックログ」と呼ぶ資料を作らずに回したらいい。例えば、「マスタスケジュール」「機能一覧」「全タスク一覧 (WBS)」を分けて作り、「今回のスプリントでやるタスク一覧」を書く時に3つの資料とのトレーサビリティマトリクスを書けば良い
- プロダクトバックログを作る時に有識者を入れるべきだった
- アプリもインフラも低レベルな人間が一人で全体を俯瞰して必要な項目を列挙できるはずがない
- 汚い土台だけあると後で直すのもしんどくて「一回プロダクトバックログまっさらなとこから作り直しましょうよ」ってなるので、予めチームメンバ全員招集して考えるとか、有識者を交えて組むとかしたらよかった
- マスタスケジュールは絶対組むべき
- 機能一覧や期日が決まっている案件なら問答無用で必須。必要性が理解できないバカでも必ずやれ
- 機能やリリース日が決まっていない案件でも、「3ヶ月後どうなっておきたいか」「半年後どうなっておく必要があるか」っていうマイルストーンは絶対あるはず。会社の仕事として、何年も実りがなくて良い案件なんてないだろう
- その案件の全体的なスケジュールやマイルストーンは常に可視化しておく。変更が入る場合は変更理由がトレースできるようにしておく
- タスク間の依存関係を明記し、できるだけシーケンシャルに対応する
- アジャイルなんだし複数のプロダクトバックログを並行作業できるはずだ！と思うのは間違いだったと認めよう。そんなスキルもないし計画もないじゃんか。順番にやろうや
- 一番にやるべきことから順に、優先度順位を付けて、その順番どおりに作業する。一番大事なことって、暇なメンバが生まれないくらいコアなタスクだろうから、全員で頭使って終わらせたら良い
- もし「最重要タスク」の遂行中に、暇になるメンバが出るとしたら、タスク間の依存関係がほとんどなく、優先度が低いモノに着手してもらうのが良いと思う。「2番目に重要なこと」は大抵、「1番目に重要なこと」に依存しているので先んじて考えたいと思っても、手戻りが多くなり効果が薄い。そうではなく、「あまり見向きもされないタスク」を潰しておいてもらうことで、開発環境が整ったり、些細だけど漏らしてはいけないタスクを潰したりできるし、必要な時は最重要タスクに呼び戻しやすいと思う
- スプリントバックログ (そのスプリントでやるタスク) は、プロダクトバックログと一対一で紐付けなくて良い
- プロダクトバックログを無理矢理タスクベースに当てはめようとするからおかしくなる。プロダクトバックログとタスク一覧は別
- プロダクトバックログに縛られず、まずは「今やるべきことは何か」を列挙して、それに該当するプロダクトバックログの番号を後で探して紐付けておく、というのが良いんじゃないかしら
- 複数のプロダクトバックログをまたぐようなタスクも当然出てくると思うが、それでいいし、そうやって共通設計や機能間連携を潰していく必要があると思う
- 「手戻りが発生するのは仕方ない」と考えず、計画はじっくり精密に立てるべきだった
- 「発生するかもしれない手戻り分」の見積をしていないのに、手戻りは仕方ないと割り切って仕事していて、成果が期限内に出るはずがない
- 手戻りを発生させないように計画し予定を組むのが大前提だ。計画を疎かにできる手法だと思ってアジャイルを選んでるなら間違ってる
「期限までにおおよそこういうシステムが欲しい」と捉えているタイプの顧客目線で考えると、「プロダクトバックログ」の単位で合意形成を図っていっても、最終的にリリース OK ですと言えるのが本当に最後の最後になってしまって、不安だと思うのよね。「やっぱりこういう機能が欲しい」という後出しに対しても、各プロダクトバックログを詳細に見積もっていないから、期限と照らし合わせての取引を開発側が持ちかけづらい。
一方、WF を比較に出すけど、WF だと「要件定義工程でこのシステム全体をこう考えました！」ってモノに対して合意形成を取るので、プロジェクトの比較的最初の方に全体像を見て承認できるから顧客側の心理的安全性は高いと思う。実装中の後出し要望があっても、「それは追加要件ですね」って言いやすいし、「一度決めたことをひっくり返す」ことになるので、機能と期限の取引がしやすいんだよね。
先が見えることの心理的安全性は開発メンバにとっても同じで、「頑張り時」と「休み時」が見えない (というか存在しない) スクラムという手法は、ずっと全力で走り続けることを求められて、長続きしない。お前ら会社員生活40年はある中で、毎日ずっと走りっぱなしでいるつもりか？と。「スクラム組んで頑張るぞい！」ってやれるのはラグビーの1試合という時間枠の中だから全力を尽くせるワケで、それで消耗しきっちゃったら次の仕事できないやんかと。そんなゼロ戦みたいな仕事の仕方、俺は嫌だ。
だったら、仕事のスタイルとして、40年間平常運転で走り続けられる方が良いんじゃないか？それって、先々の計画までちゃんと立てて、ある程度先が見えているよね、そこに向かって歩んでいけば良いね、っていう開発手法の方が、気持ちも楽だし、体調・体勢も整えやすいよね。先が見えていれば、勉強の時間を取ったりもしやすいし、WF は低スキルな人間でもなんとか仕事が回せる、準備期間を持ちやすい手法だと思うのよね。
アジャイル開発となると小規模なチーム体制が多く、どうしてもフルスタックな活躍を求められがちになるけど、実際そんなスキルの高い人達の集まりじゃないんだよな。エンジニアはある程度専門性の高さを売りに出来ないといけないと思うし、専門性を高めるには分業が必須だと思うから、この程度の人材がアジャイル開発を選択してしまうと、浅い計画で考えなしに走り始めてグッチャグチャな成果物が未完成、って結果にしかならないのは当然だよな、と思う。
事前に計画を立てて、こういうスキルセットが必要ですよね、誰々はいつまでにこの領域をやりましょう、そんな風に役割分担を決めて計画的にタスクをこなせる方が、成果物のレベルは高まると思う。計画を入念に練れば、スキルアップを望むメンバの OJT をどこに差し込んで大丈夫か、みたいなことも見えてくるし。
ワーキングアグリーメントだ、エレベータピッチだ、そういう形式的なことだけやっててもしょうがねえんだわ。チームメンバが「今のやり方は無理があります、変えたいです」って言ってるのに「でも合意したことだから」とか「プロダクトバックログはこうなってるから」とか、そういうモノ持ち出して変化を嫌って反発するのって、どこがアジャイルなんだ？どこに俊敏さ、臨機応変さがあるんだ？よりアジリティ高く仕事したいんじゃなかったっけ？何チームメンバのアジリティ下げてんだよ。ファシリテーションが全て間違っていて失敗している。
きっと、WF の案件で Excel 資料をゴリゴリ作らされてウンザリした人間が、ドキュメントを軽視できると思ってアジャイルに興味持つんだろうけど、ホワイトカラーの仕事は結局ドキュメントで決まるよ。「あなたは何を考えているのですか？」「成果はどこにあるんですか？」って言われた時に、それを見せる方法はドキュメントしかないって。「コードが成果物です」っていうのは最終的な話であって、どういう思考過程を踏んだのか、何と何を比較し、何を却下したのか、そういう情報はコードに乗らない。どうしてそういうコードを書こうと思ったのか、そのコードに至る過程を見せろと言われるのは当然なので、どんな開発手法を選ぼうが、ドキュメントは書けないと話にならない。
WF の案件に嫌気が指して、アジャイルの案件を自分達で進めて失敗してみても、「所詮はツールの違いだな」「成功のための本質はココじゃないな」ってことに気付かず、対策を誤っているようでは、これから先何をやってもダメだろ。何か特定のスキルが欠けてるんじゃなくて、見る目がない、センスがないんだもん。
途中途中で書いてきたけど、アジャイルはその手法の前提に、開発者に幅広く高度なスキルを要求するので、汎用性が悪いと思った。何でも出来るスーパーエンジニア集団なら、「まーみんなわざわざ言語化してないところも分かってると思うけど、チャチャッとやっちゃっておいてくれよ」なんてハイコンテクストな会話で素晴らしい成果を迅速に出せるんだろうけど、大してスキルのないエンジニアしかいなかったら、「どうしたらいいんでしょうかねー」「テンプレートがないと作れません～」「これは誰のタスクですかー？」なんて言ってる間にリリース延期だべ。
WF が、一般的なエンジニアや非 IT 系の顧客の性に合うのは、スキルが低い人でも成果を出せる仕組みが確立されてきている手法だからだと思う。「計画どおりにやる」というのは、誰にでも分かりやすく、伝わりやすく、協業しやすい汎用的な手法なのだ。
WF と比較して詳細な計画を後回しにする傾向のあるアジャイルで、ココをどうクリアしたら WF 以上の成果を出せるものか。開発手法の追求に興味がある人は研究していただければいいけど、僕は自分のスキルの程度を自覚し、僕の観測範囲 = 会社のレベルなんかも加味して、そういうところを研究・挑戦するよりは、一定の成果が出せる安全な手法を用いて、とにかく安定して成果を出すことに注力したい。上手く行けば150点出せるけど下手すると0点続き、みたいな手法より、安定して70点台、みたいな手法の方が、見通しが良い。
新しいフレームワークばかり無理に使わなくていいよ。枯れた技術の方がノウハウも多いし、仕事仲間との認識共有も図りやすいし、楽なんだよ。枯れてても困ってないし、新しいモノを試行錯誤して得られるメリットに大して価値を感じていないんだ。顧客からしたら「それで、どっちの方が早く良い成果が出てくるんだい？」って言われて終わり。それに対して僕は、枯れてるモノ使ってた方が、早く良いモノが出せて、皆が理解できる、って答える。先進的な領域で頑張るより、汎用的で、安定して要求に答えられるやり方の方が、僕は有用だと思う。
