常に地に足をつけて仕事をするということ
2009.02.23
こちら（北米）で仕事をする場合、一番の褒め言葉は「あいつはAccountableだ」という言葉。辞書には、Accountableには「責任のある」などの訳語が乗っているが、仕事の場面で使う場合は「安心して仕事をまかせておける」という意味。
プログラミングにしろ他の仕事にしろ、何をしていてもさまざまな「予想外の問題」が生じるもの。そういう問題への対処も含めた上で、「あの人に仕事をまかせておけば安心」と思ってもらうには、さまざまなところに予防線を張り、常に「地に足をつけた」状態で、着実に仕事を進めて行くことが何よりも大切。
今回、iPhone向けの画像編集アプリであるPhotoCanvasのリリースに関して、ひやりとさせられる経験をしたので、それを例に「地に足をつけて仕事をする」大切さを語ってみようかと思う。
PhotoCanvasはPhotoShareに続く会社の看板ソフトとして「近いうちにモバイル端末で写真を加工する人の数がPhotoShopのユーザーを上回る」というビジョンのもとに時間をかけて丁寧に作ってきたソフト。
そのPhotoCanvasのベータテスト期間中に、何人のベータユーザーから「消しゴム機能が欲しい」とのリクエストが入ってきた。私としては、Undo/Redo に機能を充実させたのだから十分と思っていたのだが、間違いだったようだ。
そこで、どうやって「消しゴム」を実装するかを考えてみたところ、かなり大幅な変更が必要。実際の作業自体は１〜２日で完了できると予想できたものの、アプリの安定度の面でのリスクが少し読みにくかった。意外にあっさりと動いてしまうかも知れないし、Undo/Redoとのからみで予想しないところでバグが生じて、それの解析に一週間かかってしまうかも知れない。
悩んだ末、「消しゴム機能」なしで1.00をリリースすることにした。商品としての完成度を考えれば、多少リリース日を延ばしても「消しゴム機能」を実装してからリリースするべきなのかもしれないが、私としては「すでにベータテストも終盤にさしかかった段階で、ひょっとすればリリースが１〜２週間遅れてしまうリスクの高い変更をする」という行動自体が、「常に地に足をつけて仕事をする」私のポリシーに反すると思えたのだ。そんなプレッシャーのもとで作業をすれば、どうしても「あわてて」仕事をしてしまい、うっかりミスの可能性も増える。十分なテスト期間をもうけることも難しい。そんな状況で良い仕事ができるとはとうてい思えなかったのだ。
1.00のリリース後に「消しゴム機能」を実装してみたのだが、実際の作業時間は予想通り1.5日程度。あっさりと動いてしまっただけでなく、派生物として「エアブラシ」まで実装できてしまったというおまけ付き。
その時は、「これなら1.00に入れることもできたじゃん」と思ったのだが、ひやりとさせられたのはその一週間後。ベータテストのテスト結果も順調で、アップルにアプリを提出しようとしていた寸前、ある特殊な状況で消しゴムを使った後にUndoをするとごく一部だがきちんとUndoされないというバグを発見したのだ。消しゴムの実装の際に「ぼかし」の機能を入れたのだが、その「ぼかし」の分だけUndoすべき部分（dirty rectangle）が大きくなることをちゃんと考慮せずに実装してしまっていたのだ。ぼかした部分のごく一部が半透明に残るだけなので、よほど注意して見ないと気がつかないバグだが、発見せずにリリースしていたら、とんだ迷惑をユーザーにかけてしまうところであった。
週末に「消しゴム機能を無理矢理1.00に入れなくて良かった」と胸をなでおろしつつ、「消しゴム機能」の入った1.01をアップルにリリースしたところである。確かに1.5日で実装できた「消しゴム機能」ではあるが、時間に追われた状況でちゃんとしたコードが書けた保証はないし、テスト不足でこのバグを見逃していた可能性はかなり大きい。
「やはり地に足をつけて仕事をすることは大切だな」とつくづく実感した私である。
accountabilityを確かにするアプローチとしては各種昨日の開発の完成と発表をしばらくずらしたり、Nightly Builds/ Unstableすることなんでしょうね。
「いい仕事をする」っていうブランドを持てると、それそのものが価値を持って歩き始めるし、肝心なところで「冒険！」せずに地に足をつける余裕をもてるようになりたいものです。
PhotoCanvas、使ってみますね〜
Posted by: icloud | 2009.02.23 at 15:38
昔流行ったマーフィーの法則に「常にバグはもう一つある」というのがあったのを思い出しました。
メーカー受託でネイティブアプリを開発していて自分だけはという思いで時々コードレビューやテストシートを端折りたくなりますが、不具合のお陰で上手く動いていたなんてこともあるので、やはり何回かに一度は思わぬ不具合にヒヤリとさせられます。お陰でいまでは旧コードをコメントで残した上でVCSを使用するといった慎重ぶりで、修正もできるだけ影響範囲を絞り込める方法を選択するようにしています。ソースが醜くなるので賛否あるでしょうが、たまに他社の不具合指摘であっさり全体を書き直してきて別の不具合を組み込んでくるのを見かけると（得てしてそうしたところは不具合を現象でしか捕えていないことが多いのでありがち）、やはりプロダクトには次善とか拙速とか、そうした手段を選択する慎重さは必要だなあと感じます。
大規模開発でクオリティ意識を共有するのも大変ですが、小人数開発で近道の誘惑と戦うのもまた大変そうですね。とくに腕に覚えのある方は。
Posted by: Tatsu | 2009.02.23 at 18:11
ソフトの宣伝エントリーを、宣伝に見せかけないところが、巧みだと思いました。
Posted by: 山 | 2009.02.23 at 19:19