June 10, 2011
ネットサービスもそこそこの規模になると、後回しになっている、あっちゃこっちゃに細かい問題が積み上がってきます。
継続改善というサイクルの中で、改善していくわけですが、じゃぁこれをどのように処理していくか？という考え方の話。
一番最悪なのは、とにかく目についたものを全部直そうと言う考え方。
もはや維持フェーズに入っている事業担当の方なら、是非、どんどん直してくださいって話なんですが、多くのケースではそうではなく、未来に向かって、前に進むべきタスクが存在しているハズです。
事業の優先順位と連動せず、現場の開発者の判断で、気になったところを直していくと、必ず時間がかかります。見積もりには、判断ミスをするとか、考える時間やソースコードを検索するような時間が往々にして入ってませんからね。かつ、修正範囲が大きくなって、新しいバグの温床になることも少なくありません。
必ずスケジュールを切って、優先順位を作るというプロセスを入れないと、変な言い方ですが必ずしも今、直す必要のない不具合に時間を費やすことになります。
これらの作業に本当の意味でかけられる時間を
①<--------------->
とすると、特に管理することなくマイクロタスクを行った結果かかった時間は、
②<-><-><-><-><-><-><-><->
になってしまったりします。
これ一見、「直さなきゃいけないものが直ったんんだからいいじゃないか」と思うかもしれません。
まぁ現場は普通そう思います。
ところが、もうちょっと広い視点でみると、この積み重ねが、結果的に時間の自由を失い、明日作らねばならないイノベーションを阻害していることがあります。
ちょっとしたロスの積み重ねは、死への第一歩だと思うようになりました。
現場で愛着のある製品に対する話だと、やはり理解するのは難しいかもしれませんが、しっかり議論をすれば、良いモノを提供したい、などの理念は共通してくるハズです。
だからこそ、上司への
「報告・連絡・相談」
が大事なんですね。チームのフォーメーションをより広い視点で見る仕事でお給料をもらっている監督役に判断を求めてから実行する、というのは、コードを目の前にして、専門職としての仕事をしている現場の人が、「今、やってはいけないこと」で時間を無駄にしないためにやることだと思います。
ちなみに、海外のとあるベンダーのバグに対する考え方
「現在出しているバージョンにある不具合があったとしても、売り上げが落ちていないなら、それは市場に受け入れられたものと判断されるので、直さない」
んだそうです。
日本人の、ましてエンジニアには到底受け入れられなそうな発想ですが、結果的に、世界を席巻しているのは彼らだったりしますね。そこは意識した方が良いと思います。
それらの時間を、明日のイノベーションに使って、一発逆転すれば良いわけです。
こういうのを個別最適、全体最適とかいったりしますかね。
これが良いかは、その都度の話ですが、いずれにせよ企業なのですから、時間の使い方は、個人の判断ではなく、ユーザー視点とマーケティング視点とを見た上で議論をして決定したいものです。
何故そんなことをしなきゃいけないかというと、時間は有限だから、この一言に尽きます。
p.s. この辺の解決には、スクラムの開発手法を入れてフレームワークで解決するのが良いかもしれませんね。
p..s.2 もう一つの理想論としては、
①<--------------->
のつもりの不具合一覧が、
②<-><-><->
ぐらいで終わることです。もちろん正確に。これだったら全てをゆだねます。
多分、革新的なあのサービスやこのサービスは、こういう感じだったんじゃないかなぁ。本当はこれ希望。ノーマネジメント万歳。
p.s.3.見積もりですが、自分は、自分がこうだと考えた見積もりに対して必ず15%か20%上乗せして計算します。根拠あるわけではありませんが、実績がそんな感じだったからです。他人だったら、もっと上乗せすることになるようです。