「急がば回れ」が重要な理由
「完璧よりも完了を」
「アジャイル・リーンに開発を」
「小さくPDCAを回す」
このように昨今ではスピード感を重要視するようなアドバイスが乱立している。
今回それらをまったく否定するつもりはないが、これらのアドバイスを誤訳したり、言い訳にして「クオリティーを犠牲にする」・「丁寧さを欠く」といったことが発生しているのもまた事実ではないかと思い、今回このテーマを記事にした。
私自身は現在CTOとしてプロダクト開発まわりを管轄しており、
実際にスピード感を重視するあまりそれが問題として発生した事象からこの記事を通して自分の反省を記事にして伝えていく。
似たような話を実際にt_wadaさんがこちらの記事で話しているので興味があればこちらもみてもらうといいかもしれない。
質とスピード
急がば回れとは？
急がば回れの意味は「急いで物事を成し遂げようとする時には、危険な方法を選択するよりも確実で安全な方法を選択したほうが結局早い」「慣れない近道を行くより、安全な迂回経路を選ぶほうが早く目的地にたどり着く」となります。
これを私は「急いでいるように思えていても結果的には時間がかかっていて、一見回り道をしているように思えても、結果的には早く目的地に辿りつくことができる」と訳すことにした。
負担を未来に押し付けるな
実際に起きた事象として、Q内の開発を行う際にかなりスケジュールが厳しい中新機能の開発や既存機能の開発をおこなっていたが、
リリースを急ぐあまりこのような思考に陥ってしまっていた。
「ここの部分のコード負債だらけでリファクタリングが必要だけど、時間がないからなんとか無理矢理実装しよう」
「デザインとちょっと違うけど、リリース優先で行こう」
「この機能リリースに間に合わなくなるから要件を減らそう」
スピード感を優先した振る舞いから生まれた思考だが、果たして本当にスピードは出たのか？
結論から言うとこれはNoだった。
リファクタリングを怠れば、リリース後エラーが発生した際に結局修正のコストが大きくなっていたり、次に機能改善を行う際に余分な時間がかかっていたのだ。
機能要件を減らした時に当初設定していた仮説が本当にうまくいったかどうかわからず、仮説検証のクオリティーも低下してしまった。
スピード感を出したつもりが将来的なスピードが犠牲になり、質も低下するということになってしまったわけだ。
思ったよりも処理できる量は大したことがない
これはPdmレイヤーで起きた問題だが、複数の問題があったときにそれら全てを今すぐに解決しなければいけないと思い、複数の課題を同時に進めて結局どれもいまいち進まないということがあった。
これは一つの課題を解決するにあたって、データ分析やインタビュー、仮説生成や検証のための設計。WHYから考えたり、Howを検討するなど案外やることが多いにも関わらずまるで今すぐに取り組めば解決できるという風に思ってしまったことが原因である。
コーディングやデザインなどのある程度ゴールが見えるものに関しては比較的見積りがしやすいため、時間がかかるかどうかというのが見えやすいものだが、ゴールをつくるような仕事の場合は見積もるのが難しいのである意味甘く見積もってしまうことがある。
「急がば回れ」を身につける
これらの経験をもとにいくつかのルールを作ってみた
1. 優先順位一位以外を無視しろ
時と場合によるが、取り掛かると決めた優先順位第一位のものに取り掛かるときには二位・三位のことをある意味忘れて取り組むことが大事である。
プレッシャーなどもあるだろうが実は今取り組んでも来週取り組んでもあまり結果は変わらなかったりすることの方が多かったりもする。
「運動会での競技を決めているときには文化祭の出し物に関する提案は全部無視する」
実際はメモぐらいはしておいてもいいが、そこで思考は終了するのが大事である。
2. 君は仕事が遅い、まずはそれを認めること
自分はもっとできるというある種の過信が焦りだったりを生むことがある。
まず自分が1日にできる仕事量を把握してそれをしっかりと事実として受け入れる。実際にやってみると想像より自分が大したことないことに気づいて落ち込むだろうが、そこからがスタートだ。
終わりに
このテーマはある意味で誤訳される可能性があるので、記事にするのが少し不安だったが、この記事を読んだ何人かの人にとって役に立てればと思い記事を書いた。
本質は「スピード感を出すことではなくスピードを出すこと」であり、
それは明日100km/h出したけど来週60km/hではなく、明日50km/hだったとしても来週以降110km/h出せたら、一年後どれくらい差がついているかは一目瞭然だろう。
この記事が気に入ったらサポートをしてみませんか？