零細企業の視点から考えるウォーターフォールのメリット・デメリット

f:id:shin21sk:20160620110324p:plain

simplearchitect.hatenablog.com

確かにウォーターフォールのメリット・デメリットって無いのかもしれない。こと「自社内開発」においては。
社外のエンドユーザーが絡むと少し違った視点になるよなー、と思い零細企業の視点から「ウォーターフォールのメリット・デメリット」を考えてみました。

現場はとっくに気付いてる

零細企業のエンジニアである自分も、「ウォーターフォールって意味無いよね」って思うシーンは幾度も経験してきました。
コーディング先行で後から上がってくる仕様書だったり、仕様書自体が無かったり、コロコロ仕様が変わったり。
そもそも、「仕様の凍結」って作業は難しいんですよ。普段業務を行っているエンドユーザーは「イレギュラーを考えない」内容で仕様をまとめる事が多いです。その辺りを仕様確認しながら、少しずつ詰めていったりする訳で。最初の段階から全て洗い出せたら、それこそエスパーか何かじゃないと無理だと感じてます。

結局、アジャイルの方が良かったよね、というシーンは数多くあります。
なので、知らず知らずのうちに、ウォーターフォール開発と言いつつ「プチアジャイル」であったり「プチプロトタイプ」的な開発スタイルで補っているのが、現状なんではないでしょうか。

でも、何故ウォーターフォールが支持されるのか。
それは、兎にも角にも「相手(お客様)が外部の人」だからなんです。

日本企業の９割は中小企業

企業数の規模でみると、日本企業の99.7%は中小企業です。

www.chusho.meti.go.jp
出典：中小企業庁中小企業・小規模事業者の数等(2014年7月時点)

その全ての企業がITに明るい、興味があるかと問うと答えは否です。

中小企業におけるIT投資の重要度

出典：中小企業白書(2016) P.136 第2-2-10図
　　　全文（中小企業庁：中小企業白書（2016年版）全文）

グラフからも見る通り、「ITの活用が重要でない」と考えている企業がまだ約4割もいます。その様な企業様に如何にIT化の恩恵を感じてもらえるか、というのが自分の仕事だと思って日々取り組んでいる訳です。

IT投資未実施企業がIT投資を行わない理由

TOP1.ITを導入できる人材がいない
TOP2.導入効果が分からない、評価できない
TOP3.コストが負担できない
出典：中小企業白書(2016) P.137 第2-2-11図
　　　全文（中小企業庁：中小企業白書（2016年版）全文）

この通り、「自分たちでもどうやっていいか分からない！」と悩んでいる企業も多い訳で、「よく分からないものにどうやってお金の判断をしろと？」という悩みへ繋がります。

ここでウォーターフォールは絶大な効果を発揮します。何故ならば、「古くからある商慣習に似通っている為、顧客側が理解しやすい」という事です。大げさに感じるかもしれませんが、結構「ITを扱う人間は、何をやっているかよく分かんないから怪しい」といった懐疑的な目で見られる事があります。確かにずっとパソコンに向かってカタカタと何か入力して、一喜一憂。側から見たら怪しいですよね。
そんな怪しい人たちと取引するとなると財布の紐はキツくしてしまう気持ちは分かります。
この前もAzureで構築しましょう！という事で話を進めて、最初におこった争点が「何故、先にクレジットカード番号を入れないといけないのか」というもの。Azureでは本人確認の意味合いも兼ねてカード番号を入れないとアカウントを作れません。「何もしないうちからカード番号とかおかしいでしょ」『いえ、実際にはこの段階では料金は発生しなくてですね。あくまで利用者の確認という意味合いも（略）』
この辺りを最初に説明してもなかなか理解してもらえず苦労しました。

お財布の紐を含めたお金の話が絡むと、いついつまでに仕様書がいって、いついつに完成しますので、費用の発生はこの時期ですね、といった従来通りのウォーターフォールは、「顧客に納得させやすい」訳です。

最大にして、非常に難しい問題だと思っています。
アジャイルを含めた方針の変更には、上司を巻き込んで取り組めば良いよ！と同じく牛尾さんのブログで語られております。意思決定者がいれば、容易に変更が期待できるという事でまさに正論です。
でも社外のお客様の場合は？お客様も巻き込むのがスクラム等での常套句なのでそうなのでしょう。
となると、「ウォーターフォール受発注からの脱却」も顧客を巻き込んで行えば、お客様も不透明な部分もクリアーできるし、「なんとなく気持ち悪い感」からも脱却は可能かもしれません。
でも、「それをお客様毎に出来るのか？」と。

言うは易し行うは難し、という判断になるのは容易に想像できます。
あとは「やるか・やらないか」です。

アジャイルを前提としたお金の話

IT系でも見積もり、仕様書に関係する書籍は多く見受けられます。でも、大抵がウォーターフォールを前提とした見積もりの仕方であり、「アジャイルを前提とした見積もり」って方法をキチンと見た事が無いのです。（見積もりとかお金に関わる箇所なので、暗黙知というか企業秘密になりやすいだからかもしれません。手の内を見せることになる訳なので）

企業ですから、開発方法や言語などある程度開発者のスタイルで容認できたり、新しい事にチャレンジしてみよう！というスピリッツが認められるのは自社内である程度補える範囲だけです。スケジュールだったり、見積もりだったりといった「相手が気にする箇所」はやはり慎重になります。
「アジャイルはいいけど、実績ないよね。ここは確実に従来通りで」
何度この台詞を言われた事か。
経営者的なスタンスで物事を考えると、「リスクは押さえたい」というのもよく分かります。

アジャイル系の書籍を読んでも、「要件をヒアリングして、期間と予算を出して見積もり」という内容は残ります。ウォーターフォールほどカチカチではないにせよ、です。「だったらウォーターフォールでいいじゃん、経験値あるんだから」という声が多いんです、本当に・・・。
「経験」という言葉は、結構重いんですよね。