「SMSを使う場面があるからレビューの長さを140文字以内に制限したいんだ。ちょっと変えるだけだよね？⁠」⁠、ソフトウェア開発の現場でこんな要望を受けることはよくあります。

カスタマーサポート向けのSaaS（Software as a Service）を提供するIntercomのブログにて、「⁠高品質のソフトウェアを提供しよう思うのなら、ちょっと変えるだけなんてことはありえない」という主張とともに機能の全体像をしっかり検討し、その価値と見積りのバランスを熟考することの重要性が説かれていました。

冒頭のような場合、経験の浅いプログラマは熟慮することなくif文を追加して数分で対応してしまうかもしれませんが、ソフトウェアやサービスの質を高めることを目指すのであれば、考えることは山ほどあります。

• レビューが140文字を超えたらどうなる？
• エラーはどこにどんな文言で表示する？
• 文字数制限の理由をユーザにどう説明する？
• エラーの見た目は誰がどのようにデザインする？
• クライアントサイドでもエラーチェックをするべきでは？
• JavaScriptが使えない場合はどんな動作になる？
• ユーザ視点だと、現在の文字数が確認できるカウンタがあったほうがよいのでは？
• 実装後にはテストをしなくては
• 最後はデプロイもしなくては

こういった判断は、経験豊富なプログラマであればその場で行えるものがほとんどですが、すべてのプログラマがそうとは限りません。機能の全体像がよく検討されていない場合、2分で終わりそうに思える作業が2時間の作業になってしまうことはよくあります。そして、2分の見積りであれば「良い価値」があると思えた機能も、2時間の見積りになるのであればスコープから外すことが妥当なこともよくあります。

新しい機能に賛成するのは簡単です。コーディングはたいてい簡単にはいきません。そして、メンテナンスは悪夢になります。高い品質のために努力しようとするのなら、「⁠ちょっと変えるだけ」などあり得ないのです。

URL：http://insideintercom.io/there-are-no-small-changes/

著者プロフィール

安藤祐介（あんどうゆうすけ）

9/14に東京で開催されるPHP カンファレンス 2013に向けて準備におおわらわです！

Twitter：yando

小倉純也（おぐらじゅんや）

合併や買収で終了していく海外のサービスを動態保存してコレクションしたいのですが、良い方法はないでしょうか。

Twitter：junya

溝畑考史（みぞはたたかし）

日本に向けて出張する可能性が出てきました。

Twitter：beatak