システム開発と3種類の雑

f:id:tbpg:20170312235556p:plain

「システム開発において雑でもいいのでスピードを上げることが重要」という話をちょくちょく見かけます。
この文脈における 雑の定義 や 雑を適用する領域 ってみなさんどのあたりを想定して話しているのだろう？
と思ったのでざっくり整理してみようと思います。

私の前提

経験としてはSI'er下請けの立場でウォーターフォール型のプロジェクトのプログラマとして従事した経験が1番長いです。
個別のモジュールを担当するプログラマだったり、チーム全体の課題管理・レビューなどをするチームリーダーなどを経験しています。
全体的なシステム設計などアーキテクト的なことはやっていません。

現職では自社のシステムを開発しています。
明確にアジャイルをうたっているわけではないですが、
やり方はアジャイル開発に近いです。

副業でWebサービスの開発をお手伝いしています。
こちらも明確にアジャイルをうたっているわけではないですが、
やり方はアジャイル開発に近いです。

この範囲で体験した事をベースにまとめますので、経験値や想像力の足らない範囲も多くあると思います。
自分の意見が一般論だという気はありません。
また、以下にまとめる内容は「こういうことを考えている人がいるのかな？」という視点で書いています。
特に私が主張する意見ではありません。

ソフトウェア開発のお仕事の前提

仕事としてソフトウェア開発をしているということは、そのシステムのユーザーに対して価値を生み
その対価としておちんぎんを頂いているということになります。

その仕事はどういったものか？
誰のどんな問題を解決するためのものか？
コストパフォーマンスを加味してどういった意思決定をすべきか？

という点は意識しておいたほうがよさそうです。

趣味プロジェクトならばひたすらリファクタリングしているのも良いかもしれませんが
おちんぎんを頂いている以上、ビジネスのコンテキストを理解した意思決定をし、できるだけコスパがよくなるように振る舞うように努力したいところです。
（努力してもおちんぎんに反映されないじゃないか！みたいは話があるかもしれないですがそこは置いておく）
そういった点がこの記事をまとめている理由でもあります。

とあるおとぎばなし。
とあるプロジェクトに非常に技術力が高い開発者の「おほげ」がおりました。
「おほげ」は担当したサブシステムの設計を無断で「よりよい設計」にしました。
確かに設計品質は向上し、このシステムが存続するのであれば長期的なコストは下がります。
しかし、「おほげ」の独断による変更と突貫で開発したことにより統合テスト時に綺羅星の如く数多のバグが舞い降りました。

すごーい！

そのバグを修正するために100名を超える開発者が影響を受けます。
終電・休日出勤・・・うつ病になった人がいてもおかしくないですね。
確実にその期間関係者を不幸にしています。

システムは無事リリースされたものの、すぐにリプレースされたため
「おほげ」が独断で行った長期的な保守コスト低下の効果も特に発揮されませんでした。

「おほげ」は技術力だけみると優秀かもしれませんが、
コストパフォーマンスとしては最悪でしたとさ。
めでたしめでたし。

雑の種類

意図的な低品質

多少不具合があってもいいから早めに仕上げて欲しい、というようなもの。

例えばテストをしないでいいからどんどん仕上げて、とか
異常系に対するケアは雑でいいので正常系がきっちり動いてくれればいいよ、とか。
受け入れテストを省くとか。

このあたりは ビジネス要件 の問題と実際に 担当する人の開発の仕方 が影響しそうです。

例えばビジネス要件次第では、別に異常系にコストを割くぐらいなら正常系できっちり動いてくれればいいよ、
ある程度システムが存続する見込みがついてからきっちり作ってくれればいいよ。
という話もあるかもしれません。

開発の仕方についてですが、開発者によってはテストをしなくても8-9割動くよという人もいるかもしれません。
また、バグがでてもトラブルシュートの瞬発力が高く瞬時に解決できるため、
そのあたりのリスクを多く見積もらない人もいるかもしれません。

逆に私はそういった才能はないので自動テストをして、自動でカバーできないところは手動テストをします。
それをしなければ要件を満たしたものを作り終えたと言える自信がないためです。
そのため自分ではこの雑さを発揮することはできなそうです。

不要な最適化

これは YAGNI 的な話ですね。
まだ必要になるかわからないが過度に設計の抽象化に凝る。
まだ必要になるかわからないが過度にパフォーマンスを求める。
とかそういう話。

技術的負債

意図的な設計判断として、現状ではビジネスのスピードを優先するために
設計の改善を控える、などの判断を意図的にする。俗に言う技術的負債を作ること。

不要な最適化は必要になるかわからないもの。
技術的負債は必要だけど先延ばしにするもの。
という違いのために項目を分けました。

あくまで意図的に選択するものであって、未熟な人が書いた保守性の低いプログラムはこれにあたりません。

まとめ

簡単ではありますが3種類の「雑」について考えてみました。
雑さについて語られる際にその具体的な内容が語られないまま炎上しているのをみます。
反応が大きいということは関心も強く、課題としての重要度も高いだろうということで掘り下げてみました。
個人的にも「よい雑さ」を手に入れるのは有益だろうし、他の方の「具体的な」意見を聞いてみたいなという思いもあります。

この話題はビジネスサイド（経営側）と開発者サイドでのやりとりが見られるわけですが、
双方が話している「雑」はどれを指しているのでしょうね。
例えば経営者が「開発者が凝りすぎてスピードが遅い。もっと雑でいいから早く作ってよ！」と思っているとき
具体的にどの例を指しているのでしょうね。もしくはここの例以外かもしれないし、
ひょっとしたら必須でやらなければならないものが省略可能なものに見えているかもしれません。