機能単位に見積・設計・開発をするスクラムで、共通設計・全体設計はいつどうやるの？
ウォーターフォールだと、システム全体を相手にして、要件定義 → 見積 → 受注 と案件が決まって、概要設計 → 共通設計 → 基本設計 → 詳細設計 → 実装 → テスト、と工程が進んでいく。
ほとんどの場合、「要件定義」の段階で機能・画面数・ER 図などがあらかた出揃っていて、概要設計と共通設計で調整を加え、基本・詳細設計で採用するミドルウェアに合わせて実装を見越した調整をさらにしていく、って感じになると思う。
見積や予定工数との乖離が出ないワケではないが、自分が経験してきた案件だと、メンバのスキル不足による遅れと、顧客の身勝手な一声により追加要件が発生した場合がほとんどなのよね。当初想定していた要件・仕様に対する遅れって、ほぼ起こしたことがない。なぜなら要件定義と見積の段階で、何をどう作るか見えていない部分がないから。
前職はレガシーな環境で、ウォーターフォール的な考え方が当たり前だった。一つの案件の開発期間が2年とかあって、メンバも1チームあたり20～30人は当たり前、小口案件も並行しているような規模だったが、昔ながらのウォーターフォールは、割と見積どおりに回っていた。開発のスピード感は確かになかったが、予測どおりの実績が狙って出せていて、前述のとおり、予定から遅れた経験は9割が「見積にない追加要件のせい」だった。
現職は
- 流行りのツールを導入して
- モダンな開発環境で
- クラウドがコンテナでファンクションが PaaS で (？)
- アジャイルでスクラムな流行りの開発スタイル
というのを気に入っている輩が多くて、まぁスクラム手法をやらされるワケだが、コレをうまく回せている感じが全くしない。
僕の中で原因は割とハッキリしていて、以下のような要因があるから、弊社のスクラムはイマイチパッとしないんだと思う。
- メンバ全員のスキルが、スクラム開発工程で要求されるスキルに追い付いていない
- スクラムは全員がフルスタックな働きをすることが期待されがちで、どの分野でも「自分一人で開発できること」が望まれる
- 現実は「サーバサイドはやりたくない」「フロントエンドは分からないし知りたくもない」人が多い
- 「得意分野は iOS アプリです」「フロントエンドできます」と言っている人も、フタを開けてみればスクラム開発の要求水準には全然達していない。デザインは酷い、ちょっとしたデータパターンですぐバグが見つかる程度のザル実装、それでいて遅延してる、みたいなレベルだったりする
- スクラムマスター、プロダクトオーナーに、自身の役割をこなすスキルがない
- メンバから意見を募るのに、メンバの発言内容を全然理解できない程度の技術スキル
- 言語化・文書化がド下手で、「その話を総合すると、こういうことですか？」と書き出したメモが全部ズレてる
- メンバを先導する人達がユルユルで、メンバは目隠しして歩かされている気分。おっかなくてついていく気にならない
- メンバの「やる気」に依存したスケジュールが立てられる
- SM・PO のファシリテーション能力の欠如
- 「この機能は、やりたい人が作りましょう」その一言だけで決まると思うか？というか、コレまでそういう雑な振り方じゃやる気が起こらないチームメンバであることは何度も見てきたはずなのに、どうしてファシリテータとしてやり方を変えられない？
- 「一回のイテレーションで1機能をリリースすること」に執着しすぎている
- 現実的な契約問題等で、開発環境がない、想定するツールが使えない、といった状況がある中で、スクラムマスターは「でもこの機能をリリースしたいじゃないですか？！」といって、全部モックでいいからこの機能をリリースしましょうとか言い出す
- 「そもそもデプロイ先がないんですが…」というと、「ローカルで動かしてお客さんに見せましょう」とかいう
- それって、アジャイル原則でいう「顧客への価値提供」になってるの？ ローカルで動かしてるモックアプリなんて、作ったところで機能をリリースしたことにはならないし (最終形にするには当然ながら9割以上作り直し)、優先順位の付け方がおかしい
- 原理主義的に遵守したい事柄が、現実に全くマッチしていない。「今回はリリース可能な機能はどうしてもないから、別のことをしようか」というような俊敏性・柔軟性を発揮することこそがアジャイルなんじゃないの？
- 機能単位で見積・実装・リリースと進めていこうとするので、全体設計と共通設計のタイミングがない
- 最初にシステム全体・案件全体の要件を洗い出す「プロダクトバックログ」は作っているが、それが超概算見積でしかなく、それがまた超概算にしてもズレすぎなのである。その原因は項目 2. のとおりスキル不足。プロジェクトで使う言語・フレームワークのことをロクに知らないし、知る気もなさそうなまま見積もっていて、それで良いと思っている。その人のいう得意領域も、専門外である俺が見ても素人やんと思うお粗末なレベルで、根本的に技術力が追い付いていないから、全ての作業の成果物品質が極めて低い
- プロダクトバックログがドサッと出てきた段階で根本的な誤りが多過ぎて直しきれないでいるのに、ファシリテートがヘタクソだからメンバの確認や合意を全く省略して先に進めたりする。無能な働き者
- 「プロダクトバックログの段階での超概算見積だとエグいズレ方するのが目に見えているのですが、詳細な見積はいつするのですか？」と聞くと、「イテレーション開始日にどの機能を作るか相談して、それから見積を始める」という。「詳細見積をしてリリースが難しそうだったら機能を分割したりして対応する」のだと。うん、だからもう今のこの見積がズレてるからそのまま進めるの止めようよって。何でそこは無視するの
- 見積精度が極めて低い状態で、項目 4. で述べたように「1機能をリリースすること」が重視されてイテレーションを回されるので、「前に作った機能と、今回作る機能とで、連携がうまくいかないじゃん」みたいな事態が発生して、設計から手戻りするような事態が頻発する
- そんな悪い実績があったので、「共通設計はどこでやる算段なのですか？」と聞くと、「各機能の設計段階でやるから大丈夫」という回答。いや、そのつもりでやってみたら失敗したんじゃん？同じ失敗繰り返すの止めようよ
ウォーターフォールだから上手くいく、アジャイルだから失敗する、という意味で話したいワケじゃないのだが、どうも僕が質問すると、「キミはウォーターフォール脳でアジャイルを分かってない」みたいなノリで返されてしまう。ちゃうんや、アジャイルの原則とか書籍に載ってるような一般論は別に知っとるんじゃ。そうじゃなくて、直近の実績や今この現場を見て、それで足りてると思うのか、失敗が目に見えてるじゃないか？それをどうするつもりでいるのか、と俺は問うているのだ。
- ウォーターフォールの特徴として、常にシステム全体からブレイクダウンしていくよね。リリース速度は犠牲になるけど、共通設計・全体設計という工程を設けるから、一貫性が出るよね？
- 今回の案件は特に、共通設計を先にやって、全機能の一貫性を設けておかないといけない性質の案件であることは、分かっているよね。後回しにしたら、どういう手戻りが発生しうるか、予想が付いているね？
- で、コレからやろうとしているアジャイル開発工程の中で、ウォーターフォールでいう共通設計的なタイミングは、どこに設けるつもりなのか？
- その答えが「各機能を作る時に、各機能に関連するところを設計する」なのね？
- そしたらさ、後半で着手する機能が見えていなくて、前半の判断に誤りが出る恐れが高いよね？それはどうやって事前に回避するつもりなの？
- 僕の考えは、開発手法がアジャイルだろうがウォーターフォールだろうが、「全機能の設計をより詳細にしておく」「見積精度を今より高めておく」ターンが必要だと思うよ？それ以外に何か良い案があるの？
俺の質問はこうなんだが、コレに対する納得行く答えが返ってきていない。
- 自社サービスを開発する場合で、進捗実績に応じてリリースする機能や要件を数を減らせるなら、各機能ごとに見積もるつもり、というのは分かるけど。
- 今回は開発する機能とリリース日が先に Fix している受注案件だよね？そうすると、見積予測のズレが出ては困るよね？ズレが後半に大きくなったらもっと困るよね？
- 見積予測のズレが発生する大きな要因として、「機能別に開発する」方針のために、必然的に「共通設計の完了」が後回しになり、後半になってから手戻りが発生しうるリスクがあると考えているよ。
- それに対する対策は何を考えているの？
- 僕の考えは、やっぱり見積精度を上げておく、後半で予測との乖離が発生する原因を減らしておくことが必要だと思うよ。そのためにはスクラムの原則とか抜きにして、「共通設計」タスクを持った方が良いんじゃないの？それよりも良い方法はどこにあるの？教えてください
という考えなのだが、
- メンバのスキル不足もありうるから、スクラムマスターとしてうまく先導します
- 必要があれば徹夜残業も辞さないです
という回答しか、今のところ返ってきていない。俺は徹夜残業なんか絶対しないけど何勝手に決めてるの？お前が今やってる見積精度が悪くて指摘を入れてるのに、それをそのままにしておいて後になって間に合いません残業してくださいなんて聞くワケねえだろ。
どれだけ話を聞いても、見積を精緻化するタイミングを後に遅らせていい理由と、全体設計・共通設計という工程を設けず機能単位の開発で進めていいと思う理由が、理解できないでいる。
弊社、全体的に過大評価と楽観視が強い。学生のベンチャーのノリでやってきた中小企業だからだろうな。
気が付くとプログラムが出来上がっている人はいて、技術的なスキルが皆無なワケではないのだが、言語化・文書化のスキルが壊滅的にない人ばかりで、中身が誰にも伝わらない。引き継ぎ・情報共有、いずれもまともに行われない。だから過去に A さんが調べていた内容を、今 B さんが同じように調べていたりする。A さんがちょっと前に調べてたから聞いてみたら、というと、「A さんは当時のメモが何もなくて忘れたから分からないんだって」といわれる。ホワイトカラーらしい仕事の仕方を全然してないよね。土人かな？
「モダンな手法です」「流行りのツールです」それってお客さんにとって何の価値もないよね。開発者の生産性が上がるかどうかも場合によりけりで、「似て非なる新しいフレームワークを覚え直すより、適度に成熟した有名なフレームワークを今回も使う方が品質高いですよね？」ってことが多い。「新しい技術を先んじて取り入れておくことで流行に遅れず選択肢が広がる」だのなんだのいうけど、そういうのは小口案件でコッソリやろうよ。大型案件でチャレンジする要素バカみたいに増やしてもリスクでしかないぜ。あとあんたツール選定はするけど実装もしないしコードレビューもしないでしょ。何のツール使ってたって分かってないんじゃん？プルリク見てもらったことないよ。
リリース後の運用保守コストが高くないシステムにしたいよね。一応皆そういう。でも誰もドキュメント書かないし、コミットコメントは「修正」としか書いてない。コードコメントもないし、コメント不要な可読性の高いコードなのかと思いきや全然そんなことない。不要な変数の初期化をしていたり、逆に必要な初期化を忘れていてデータが0件の時にバグるコードが混ざっていたり、技術的にも日本語能力的にもそんなレベル。時制の感覚はないみたい。
「今」「このイテレーション」にフォーカスすることで開発効率を上げる。素早く機能がリリースできる。一般論は分かるんだが、それってこの現場・この案件で必要ないんだよ。誰からも求められてないんだよ。
それより必要なのは、締め切りを守るために今足りてないモノを拾い上げることだったり、気まぐれに仕様変更どころか巨大な追加要望を口走る顧客との折衝じゃんか。いずれも、未来を見据えて逆算して投資的な行動を取るモノじゃんか。
「アジャイルはピザを囲む人数のチームでやるんですよー」知ってる、でも今回のチーム総勢20人は必要で、サブチームを分けたところで各チームが独立して走ることは不可能な性質の案件じゃんか。
「マイクロサービスなんで疎結合に作るんです」だったら I/O (API) だけは先に決めて関係者に公開できなきゃダメなんだよ。「ベゾスの勅令」のことは知らないの？
こっちの質問中に発言を遮って「それはですねー！」って語りたがる、そのモチベーションが羨ましい。俺の質問聞いてないから答えがズレてるよ。それなりに同じ案件を見てるはずなのに、そのやる気はどっから湧いて出てくるんだろう。話聞いてくんない？ベラベラ喋るなら俺の疑問に納得いく答えを返してくれない？
原理主義的な一般論はどうでもいいんじゃ。今この案件で、メンバのスキルも、顧客のアジャイルへの理解も追い付いていない現状で、そのやり方じゃ共通設計が遅れて見積乖離のリスクじゃんか？リスクが見えてるんだけど回避しようとしないの？って言ってんの。
そんな難しい質問してないよね。ウォーターフォールかアジャイルかという二元論を話したいんじゃなくて、この案件で今見えているリスクに、どう対応するつもりでいるのか考えを聞かせてくれ、と言ってるんだよ。アジャイルの原則に則った原理主義的なその思考だと、色々足りてないように感じていて、コレだけのリスクを俺は感じてるんだけど、あなたの考えで僕を納得・安心させてくれませんか？ってことなんだよ。
アジャイル・スクラムが世界的に流行しているからには、少なからず成果を出せる方法があるんだろうけど、俺は今んとこ、この会社でアジャイルやってうまくいく算段が見えてないよ。誰のスキルも足りてないし、ファシリテートが出来てないし、メンバのやる気に依存した考えばかりで仕組みがないし、メンバが感じているリスク懸念に対して説明も十分でなければ検討もされないからだよ。こんな調子でやられるんじゃ、アジャイル自体を止めた方が良い、と言いたくもなるよ。ウォーターフォールの方がリリース速度を犠牲にする代わりに最低品質を担保しやすいし遅延する要素を削る術が見えてると俺は感じるよ。「ウォーターフォールでもアジャイルでもそこは変わらなくて…」とかいうけど、既に違ってるじゃんかって。目の前も正確に見えてないし、そのボヤけた見え方で十分だと思っているから話がいつまでも平行線なんじゃん。
なんていうんだろ、「メガネかけてないからボヤけてはいるけど、信号の色は見えてるから大丈夫だよ」って言って運転してる人のクルマに一緒に乗りたいか？ っていう。
それよりは「視力検査の結果的にはメガネ着用は不要なんだけど、ボヤけているように感じるからメガネかけて確実に見えるようにして運転するね」っていう人のクルマに、俺は乗りたいなと思う。
未来を楽観視して、計画を後回しにして、上手く行った経験がない。前職でもだし、あんたらとやってきた案件でも、だ。それを繰り返したくないから指摘・質問してるんだ。俺を巻き込むなら、「その考え方でやれば大丈夫そうかもな」って少し思わせてくれよ。少しくらい日本語通じて？
