目指す品質の共有(気持ちよく仕事をして良い結果を出すために)

自己紹介

こんにちは！Mass Kanekoです。国内メーカーで働いたり飲んだくれたりする傍らで、時々思い出したように曲を作ったりDJをしています。今度の4/23(土曜日)は15:00〜21:00、東京・早稲田の茶箱にてパーティを開催します。
eYecandy

たとえばこんな曲を作ったり。

「そんな自己紹介で本当にIT業界の人なのか…」

そうなんです。ITと言っても色々ありますが、私は特定用途の特別に作られたハードウェアの上で動くソフトウェアを開発する職…組込みソフトウェアエンジニアです。身の回りにある製品はソフトウェアが入っているものばかりです。「あのビルのエレベーター、いつも来るの遅いのよね。」それはソフトウェアのせいかもしれません。「こないだ買った楽器、音いいんだよねー」それはソフトウェアの力かもしれません。私の設計したソフトウェアも、ひょっとしたら皆さんの近くで動いているかもしれません。そんな職について、そろそろ4年経ちます。

新卒準備カレンダー2011春です
さて、この記事は新卒準備カレンダー 2011春 : ATND という、この春に新しくIT業界へ進んだ方々のために、ブログをリレーしていくという企画です。私の1つ前はbash0C7さんによる現実へと流されない - koeだめでした。私もこれまでに書かれた記事を読んで、よい刺激を受けています。このはてなダイアリーも全然使っていなかったのですが、これを機会にちょっとしたことでも開発のことをアウトプットしていこうと思います。では本題。

品質って？
システムを考える上で一番大事なのはユーザに提供する価値…なのはもちろんですが、今回はその価値を実現するシステムの出来について考えてみたいと思います。出来、つまり品質です。システムに関わるなら必ず品質に関わります。システムの品質って何かと考えると、ユーザーにとって欲しい品質と開発者にとって欲しい品質に分けられます。まずはユーザー視点。

高い品質	低い品質
アプリを沢山立ち上げても重くならない	段々もっさりしてきて終いには落ちる
キャッシュカードを表裏逆に入れちゃったけど読んでくれた	出てこなくなっちゃった…
何日動かし続けても安定してる	放っておいたらいつの間にか再起動してた
深刻なエラーが起きても自動で復旧！	電源入れなおさないとダメ

次に、開発者視点。

高い品質	低い品質
バグの原因が突き止めやすい	何が原因か調べるのに時間がかかる
どう変更すればよいかわかりやすい	どう変更すればよいか決めるのに時間がかかる
変更しても影響範囲が限定される	想定外の場所に飛び火して不具合が出る
テストコードの網羅性が良い	テストコードが無いor信用できない

ここで挙げたユーザー視点での品質は信頼性、開発者視点での品質は保守性と呼ばれます。他にも○○性というのはありますが、今回はこれら2つにスポットを当てます。

品質を上げるのは手間がかかる
(信頼性)どんな状況でも規定の動作あるいは安全な動作をする設計とするためには、色々なケースを考えないといけないです。設計上起こり得ないと考えられるケースがあったときにもユーザへの不利益を最小にする設計が必要になります。また、そのような設計としなかったために起きた問題は低頻度であり、解決するのには更にコストがかかります。

(保守性)後々で見直して、わかりやすい、変えやすい設計とするためには、アーキテクチャを良く考える必要があります。大きなまとまりの構造、小さなまとまりの構造、それらの関係を良く考えます。ここは差が出ますし、さぼると後々大変です。アーキテクチャに無頓着に作った設計を後からわかりやすい設計にするのには更に大きなコストがかかります。

「1000回に1回動かない」「1年に1回くらい落ちる」程度なのは良いのか？
信頼性はどのくらいを目指せばよいのでしょうか。

例えば携帯音楽プレーヤーを使っていたとします。買ってから1年間、故障はしていません。ある日いつものように曲を聴いていると曲名が「●×☆※▲」なんて文字化けしてました。しばらく放っておいたら「system error」と表示されました。「故障かなあ」と電源を入れなおしたら何事も無かったかのように正常動作しました。「何だったんだろう？」と思いつつも「まぁいいか」で済ませる人もいるでしょう。後々、そのメーカーの品を避けるようになるかもしれませんが、いずれにしても携帯音楽プレーヤーがごく稀に動かなくなる程度の問題です。

でもそんな程度では全く以ってダメなシステムというのは沢山あります。「1000回に1回動かない」「1年に1回くらい落ちる」程度だと…

メガバンクの預金管理システムダウン。引き落とし不能！

証券取引で誤発注を取り消したが動作せず約定。取引所に多額の損害賠償請求！

手術中に医療機器が誤った血圧を表示。投薬の判断が遅れ、患者が死亡！

ブレーキが効かずに自動車事故多発！

超有名アーティスト観客10万人のライブ。最後にキメのフレーズが…鳴らない！

これらのシステムに必要な高い品質とするためにはコストがかかります。慎重に設計し、入念にテストしないといけません。しかし、あまりにも時間をかけていたら商売のチャンスを逃してしまいます。システムが提供する新しい価値の内容によっては、少々のバグは問題にならないこともあるでしょう。後々でアップデートできることが大きな条件だと思います。

東京電力の需給がわかるアプリができました！

新作ネットゲーム βテスト開始！

画期的なライフスタイルを提案するネットガジェット新発売！

きたないけど、まともに動いている。放っておいて良いのか？
1000行のメソッド、10000行のクラス達、依存関係は無茶苦茶、コメントは嘘ばっかり。「あらまー」と思うようなコードに出会うかもしれません。でも、保守性は開発者にとっての品質です。ユーザーにとっては、システムで目的が満たされることが重要であって、それがどう設計されているかはどうでも良いことです。今の時点でまともに動いているのであればユーザにとっては全く問題ないです。うかつに手を出すとバグが出そうです。とはいえ、そのままで良いのでしょうか。

あえて、放っておいてもよい場合から考えてみます。以下3つを全て満たした場合は、きたない設計のままでよいと思います。

この先、新しい機能を追加する必要がない
稀に不具合が起きても再稼動すればよい
このシステムを母体とした派生開発をしない

しかし実際そのようなケースは少ないでしょう。いざ「新しい機能を追加する必要がある」「不具合が出たら修正しなくてはならない」「このシステムを母体として派生開発をする」となったときに困るのは開発者です。保守性は今の開発者のための品質ですが、未来の信頼性に直接影響します。つまり、良くない設計のまま機能追加や不具合修正を行うと新たに不具合を作りこみやすく、派生システムの信頼性が落ちるということです。

保守性が低いと結局後々でユーザーも困る可能性が高くなります。保守性を高めるために設計を見直すのは信頼性を失うリスクがありますが、両者はトレードオフの関係ではありません。保守性を高めることを常に意識していれば後から信頼性を確保し、両方を高めることができます。

目指す品質をチームで共有しましょう
ここまでで保守性と信頼性について簡単に説明しました。どの程度の品質を目指すかはシステムそれぞれです。目指す品質をチームで共有しておくことは、仕事の優先順位感を共有することに繋がります。

必要な信頼性はターゲットとするユーザーとシステムの用途によります。そこそこの信頼性を確保して一早く新たな価値を届けるべきならば、一定以下の小さな問題は放っておいて、早く価値を実現することに全力を注ぐ。「一定以下の問題」ってどの程度の問題か、共有できていれば早く決断して次に進めます。信頼性を十二分に確保すべきならば、レアケースも考えて、ドキュメントをしっかり書いて、他の人とレビューし、あやふやな箇所・欠陥を叩き潰します。「十二分」とはどの程度か、プロセスを守ることか、信頼性カーブがいい形になったらか。共有できていれば「これでリリースできます！」と言える。

保守性がどれほど必要かは、そのシステムが将来にわたってどれだけ変更されてゆくかによります。ベーシックモデルからエントリーモデル、ハイエンドモデルのラインナップを作ったり、日本向けに作っていたシステムを、中国向け、インド向けにローカライズしたりと枝分かれしてゆくならば…「気持ちよく開発できるように設計しましょう。それが未来のエンドユーザのための信頼性に繋がります。」のように共有できれば良いですね。

保守性は開発者が気持ちよく仕事をするための品質でもあり、その仕事によって作られたシステムの信頼性に影響する重要な品質です。私は保守性を意識しているチームは良いチームだと思いますが、システム用途によっては保守性向上(設計改善)のリスク＞リターンとされる場合もあると思います。その場合、なぜそう見積もられているのか聞いてみるのが良いと思います。

もしかすると、これらについて共有するのは簡単ではないかもしれません。「このバグは直さなくても良いですよね？」「いや、直すべきです。」とか「リファクタリングしましょう」「いや、変更量が大きいからダメです。」などと意見が合わないことが考えられます。しかし気持ちよく仕事をして、かつユーザーのためのシステムを提供するには重要なことだと思います。納得しないままでいるとストレスになりますので、時間をかけてでもお話をすることをすすめます。