QCD+Sとか言うけど、まずはDを守ることが重要なんじゃねーの？
駆け出しエンジニアの頃に偉い人にこんなことを言われた。
「システム開発においてはQCDをそれぞれ厳守することが大切。中でもQ（品質）はもっとも重要だ」
製造業はQCDの三つの柱で成り立っているとされる。 Qは品質 (Quality)、Cはコスト (Cost)、Dは納期 (Delivery) を表す。
要は高品質なものを納期に間に合うように予算内で作り上げましょうってことらしい。そりゃそうだ！ごもっとも！
それから数年間、主に業務システムの開発に身を捧げたのだけど、全てを厳守できたプロジェクトにはひとつたりとも出会わなかった。
俺たちがヘボなのか？確かにそれは否めないが、こんなに皆が失敗するのはおかしいと考えるようになった。少し調べると山のように失敗プロジェクトの記事が出てくる。顧客に訴えられるものも珍しくない。
そんな時に第四の要素であるS（スコープ）の存在を知った。
よくよく考えたら、いざ顧客に「システムができたのでテストしてください」って段階になって、「あれがない」「こんなのでは使えない」「以前はこれができていた」と言われ、タダ働きで機能を追加していた。契約を盾に突っぱねることもできたが、それじゃあお客さんは幸せにならないし、システムの存在価値が下がる。対応するしかないのかと悶々とした。
そりゃあんた、スコープが拡大するんだったら、当初描いたQCDなんか守れるわけがないわ。
逆に言えば、スコープを調整することでQCDは守ることができる。と僕は考えている。
というか結論から書くと、Dの納期に重きを置く、納期に合わせて他の要素を調整することが最も安全なのではないかと考えている。
少し考えてみる。
業務システムやwebサービスの人間なので、他の領域についての知見は少ないことをご了承いただきたい。
Q 品質 (Quality) に最も重きを置いた場合
品質を担保することがシステムにおいて最重要なのは言うまでもない。
しかし、品質という言葉が独り歩きし、開発者を苦しめることも事実である。
他社のシステムを開発する場合（特に中小企業の業務システムとか）は品質の定義をできる人がいなかったりするので、そもそもどれぐらいの品質が必要か？から始める必要がある。で、キリがない、もしくは問題のないシステムを作るみたいなふわっとした約束をして地獄を見る。まあ、これは自社のシステムを作る場合でも似たようなものかもしれない。
品質に最も重きを置いた場合、満たすべき基準を定義する必要がある。
そうでないと、決裁者のお気持ち次第でいつまで経っても本番稼働を迎えない、もしくはひたすら無料で改修作業をさせられる、なんてことが起きる。
そもそも、本当の意味での本番環境と同じ条件でのテストなんてできるのだろうか？品質の担保は本当に奥が深い世界で、僕にはとてもできる気がしない。品質にこだわれば無限に時間が溶ける。コストも納期も引っ張られる。
自身が苦手なせいで品質と向き合っていないと言われればそれまでかもしれないが。
C コスト (Cost) に最も重きを置いた場合
受託開発の場合はこいつが固定されていることが多い。上回れば赤字の仕事になるので、社内のお偉いさんからも大注目を浴びる項目だ。
物凄く乱暴だが守る方法について考えてみる
契約でガチガチに縛り、当初の約束以外の機能を一切作らない。全てのシステム変更に追加料金を発生させる
金額分しか仕事しない
高額な料金を吹っかける or 従業員の給料をものすごく安くする
悲しくなってきた。
機械の自動生産と違って、ソフトウェアはエンジニアのスキルによって生産性が無茶苦茶変わる。正しくコストを見積もることはものすごく難しい。これも僕にはできる気がしない。
過去にやった仕事なら別だ。これくらいかかって作ったからこの料金です、ならわかる。これについて別の記事で書こうと考えているが、見積の神髄は「過去にやったことがある」にあると思う。
D 納期 (Delivery) に最も重きを置いた場合
順調なプロジェクトなら問題ない。
しかし、何か大きな問題が起きた場合や顧客の要望等でスコープが広がった場合、納期を遵守しようとすると地獄を見ることになる。
心身に異常をきたすレベルで働く。とりあえず間に合いました！の体裁を守るためにろくにテストもしないで無理矢理納品する。後から直すからこれは目を瞑ってね、みたいな感じでゴニョゴニョしたり。たいていは後から大きな揉め事になる。
納期は命より重い。そのくせに、顧客やお偉いさんたちは納期以外の要素も同じような重さで求めてくる。どれかひとつにしてくれ！
S スコープ (Scope) に最も重きを置いた場合
当初に決めたシステム要件から一切変更しなくてすむならそれでいい。神のような予知能力を持った発注者もしくはPdMが存在するってことだろう。
しかしそんなことはなくて。やっぱりあの機能が欲しいとか、デザインを変更して欲しいとかスコープは変動することが自然だ。それに一切対応しないことに重きを置くのであれば、誰のためのシステム開発なのだろうかと思う。
だから結局どれか一つ守るのが精いっぱいで、Dの納期を守ることが一番いいんじゃねーのって思うわけさ
ここまで書いてわかったと思うけど、全ての要素は密接に絡み合っていて、どれかに重きを置いたら他も同時に救われるとか、どれかを犠牲にすれば他が守れるといったものではない。
まーもーどうもならんから、個人的には納期を決めて、そこに向けてスコープを調整するしかないと考えている。遅れることなく、できている部分だけでも早く顧客に触れさせたいのだ。顧客の手に触れることで、次に進むべき道が見える。その循環が必要だ。
ソフトウェアはリリースしてから何度でも改修ができる。致命的な問題を起こさない品質で、その期間までに構築できる（かつ、そのソフトウェア群で顧客の利用に耐えうる）ものを、無理せず作っていけばいいんじゃないのかね。
品質については「質とスピード」で調べてほしい。
そして、決して疎かにしろって言いたいわけではなく、本当に致命的な問題以外はだいたい対応できるので必要以上にびびることはないって感じだ。プロジェクトの種類によって全く異なるが、ここでは少々のバグが起きても生命や顧客の資産が脅かされないシステムを想定して書いている。
端的に言うと納期決めないといくらでも仕事は膨張するし、いつまでたってもシステムは完成しない。納期を決めたからと言って拡大する要件のすべてを満たせるとも限らない。
なら納期に向かって実現可能な範囲で対応して世に放ってしまいましょうよと。納期遅延を起こすほど顧客の求めるハードルは高くなったりするしね。とかまあそんなところ。
十分に言葉にできなかったので後日もうちょっと言及しようと思う。
この記事は「プロジェクトマネジメントとか組織作りとか Advent Calendar 2022」の12月1日分として書きました。僕が普段考えていることを言語化しています。偉い人に怒られそうで怖いです。
次の記事はこちら