From: 松田航
新宿本校にて
「とりあえず動くようにしてくれ！」
多分、先週の日曜日に、僕がもっとも発した言葉です。
リリース直前のアプリケーションがあり、これがなかなか完成しない。そのため、リリース日当日に、スタッフのエンジニアにそんなことを言っていたのでした。
いや、今思っても最悪に近い言葉ですね。僕自身もコードを全力で書いていたため、若干焦り気味だったのでしょう。
ちなみに、PM（プロジェクトマネージャ）がコードを書き始めると大体残念な結果に終わるプロジェクトが多いので、極力書かない方がいいです。全体に関係のない、API叩いてデータ取ってくる、とかそういう箇所だけやるのなら影響範囲が小さいのでOK。
で、話を戻すと、「とりあえず」という発言はそれはもう、リスキーで、情けない言葉です。
ちゃんと失敗する
アプリケーションの不具合は発見できるのが早ければ早いほど、その後の修正は少なくて済みます。他部分への影響が小さいのですから、そりゃそうですよね。だから、単体テストをいかにしっかりと実施できているかが、最終的に安定稼働するアプリケーションになるかどうかを分けます。
問題点が早くに発見できるのは、最終的にすごく健全で、堅牢のソフトウェアができることを意味して言います。だから問題を発見できるようにすべきなのです。
だから、「とりあえず」動かすのではなくリリース前であれば尚更、エラーを表示させてちゃんと失敗をすべきです。
作り始めは全力でエラーを表示
とにかく作り始めた段階ではエラーは目立たせるべきです。PHPのCakeフレームワークのエラー表示など素敵です。赤字のバーが上部に表示される形ですね。自分でゼロからアプリケーション作る場合でも、あれを表示させてもいいくらいです。
エラーをウェルカムしましょう。エラーが出たときにいちいちへこまずに、
「よし、また一個素晴らしいプログラムに近づいた！」
になったと思うべきです。完全に思い込みましょう。自分のストレスを減らすためにも。
つい先日、エンジニア向け本の中で20万部を超える大ベストセラーになった奇跡の書「なぜプログラムは動くのか」の著者、矢沢さんに講演を行ってもらいましたが、講演の中で、こんな話が出ていました。
「コンパイラやエラーそのものを大切に扱いましょう。彼らはあなたをマンツーマンで叱ってくれるいい先生です」
まさしくだと思います。
予測できない問題への対応
予測できないような問題に対応できる方法はとても大切です。ソフトウェアの品質が本当に試されているのは、何か問題が起きた時です。
誰でもミスを犯します。仕事を進めていく中で愚かなミスがあります。人間ですから。でも、そのミスをなるべく早く見つけることができれば、後からの問題は激減します。
- 間違いに気づいたら、とりあえずの処理をしない。納期の問題で仕方がなかったら、少なくとも、メンバーのに状況を共有する。wikiにあげてもいいですし、slackで発言してもいいでしょう。
- 解決策を提示しよう。時間リソースが足りずに、自分が解決できなくても、こうすれば解決出来るという道を見出して、メンバーに共有しましょう。できれば、そのメンバーのリソースで適用可能な対処法を提示できると、その人は重宝がられます。極端な話ですが、ある新規のプログラムを作成していて、OracleにDBを変えれば、大丈夫。というような解決策は、まぁ残念な訳です。
- 早く相談する。相談する相手がいれば、相談することです。プロマネでもいいですし、技術のメンターでも構いませんし、仲良くなった技術者に「今度おごるから！」と叫んで協力してもらってもいいです。早めに相談することがデスマーチから遠ざかる道です。
きちんとミスをするのがリスク回避につながる！
またどこかで書こうと思いますが、breakのひと文言だけで、60億円の損失を発生させた例もあります。
真っ青になるなんてものじゃないでしょう。
ちゃんとミスしましょう！
とりあえず、動けばいいとか言わずに！
松田
