手を入れず
定めて測って 再検討
手を入れるのは 先のまた先
R&D チームの奥村（@izariuo440）です。ソフトウェア開発をしていると遅いコード*1に出会う*2ことがよくあります。私なりの習慣で対処していますが、これまで言語化できていなかったので挑戦してみました。
この記事は銀の弾丸ではありませんが、遅いコードに出会ったときの適切な対処の足がかりとなり、解決までの時間短縮などによる生産性向上（または生産性低下の抑制）に寄与できれば幸いです。数回に分けて紹介していきます。また、具体的な高速化手法については触れない予定です。今回は前置きの部分です。
はじめに
遅いコードは、ユーザー体験が損なわれたり（使用性低下）、遅いが故に処理が蓄積して新たな処理要求を捌ききれなくなったり（可用性低下）、AWS などの時間課金型の利用料金がかさんで利益を圧迫するなど（利益率低下）、さまざまな悪い影響が出ます。できるだけ出会わないようにするべき*3ですが、いざ出会ってしまったら注意して向き合っていかねばなりません。遅いコードは、いいとこなしの貧乏神*4のようなものです。放っておくとキングボンビー*5になったりして取り返しのつかないことになります。備えましょう。
先達のことば
自分が遭遇した課題は、過去に誰かが取り組んでいることが多いです*6。遅いコードに出会ったときについても同様です。いくつか先達の金言がありますので紹介します。
計測すべし。計測するまでは速度のための調整をしてはならない。
コードの一部が残りを圧倒しないのであれば、なおさらである。
・ 鉄則1. 計測ツールを使え
・ 鉄則2. やたらに直すな（主要因を見極めてから直せ）
・ 鉄則3. 度を越した改善を約束するな
The Art of Computer Programming などで有名なドナルド・クヌース曰く、
「早すぎる最適化は諸悪の根源である」
私はこれを「手を入れず 定めて測って 再検討 手を入れるのは 先のまた先」という習慣として認識しています。
手を入れず
私もそうですが、遅いコードに出会ったとき、なんとなくこの辺が遅そうだから、とりあえず手を入れてみよう・・・とやってしまいがちです。手を入れ始めると、多かれ少なかれ時間を消費します。運良くその対処が当たればよいですが、外れたら時間だけが過ぎて振り出しにもどってしまいます。
ソフトウェア開発で極力避けたい事象のひとつとして「手戻り*7」があります。手戻りとは、複数の手順で構成される手続きを進めていったとき、ある手順で問題が発生して前の手順に戻る事象のことです。手戻りが発生すると、次の手順が予定通りに進められなくなり、プロジェクトは遅延し、開発コストが膨らんでしまうことがあります。繰り返し発生すると、チームは疲弊し、デスマーチになり、プロジェクトが制御困難になり破綻する可能性があります。自分の行動がプロジェクトを破綻させるきっかけになると考えると恐ろしいですよね。
別の観点として、Code Complete 下巻 20.1 ソフトウェアの品質特性によると、ソフトウエアには外部特性と内部特性という品質特性があります。前者はユーザーが認識するもので、後者はそれ以外（保守性、柔軟性、移植性、再利用性、可読性、テスト性、理解性）です。本記事で触れる内容は速度性能改善の一環であり、外部特性のうち効率性の改善に該当します。効率性を上げようとすると、８つの外部特性のうち５つ（正当性、使用性、効率性、信頼性、完全性、適応性、正確性、堅牢性）が低下する恐れがあります。紙面では触れられていませんが、内部特性はすべてが低下する恐れがあるでしょう。実際のプロジェクトでは、こうしたトレードオフを考慮しながら、慎重に取り組んでいく必要があります。これを考慮せずに焦って手を入れてしまうと、運良く速くなったとしても、他にガタがきてしまい、結局手戻りになってしまう、という可能性もあります。
私はこうした状況を避けたいので、遅いコードに出会ったら、手を入れる前に報連相に努めます*8。悪いことほど早く共有すべきです。自分が相談を受けたら、状況をヒアリングして整理した上で対策を検討します。
おわりに
いざ書いてみると、よくビジネスの基本と言われる「報連相」の話になりました。とはいえ、当たり前のことを当たり前にできるということはすごく大事なので、そういうものなのかもしれません。
次回は「手を入れず」の先である「定めて測って 再検討」について書く予定です。
オプティムでは、こうした習慣で働いているエンジニアが存在しています。興味のある方は、こちらをご覧ください。
*1:コードだけでなくプログラムやシステムなども含みます。
*2:自分で書いてしまう場合も含みます。
*3:経験者はこれを設計時点で考慮します。具体的な経験がない場合でも、速度性能面で痛い目にあったことがあれば注意して取り組みます。できるだけ早い段階でこれを明確にするための技術検討や実験を工程に組み込んでおくといいと思います。
*4:桃鉄に出てくるやつです。まだ可愛げがあります。
*5:桃鉄に出てくるやつです。これになると本当にきついです。
*6:こうした意識を持って日々の課題に取り組んでいくことは重要だと思います。巨人の肩の上に乗り、その先に進んでいきましょう。
*7:国語辞典にのっていない。建築用語？「やり直し」ともいう。
*8:研究開発では「いったいどこまで速くできるんだろう」という観点で取り組むこともあります。
