質と土台、そして実直さがスピードを授ける

// フェイスブックのエンジニアで史上ベスト3に入ると
// いわれる Evan Priestley氏への質問
// 「どうやってプログラミングを覚えましたか」
// に対する本人からの答え (翻訳)
http://ktamura.com/epriestley.html

自分は Facebook って利用したことないのですが...
この記事のとある部分にとても共感を持ちました。
それは、

「質=スピード」を念頭にソフトウェアを書いてきた

の部分。
自分は、「質」の部分を「土台」と表現してきました。

土台がしっかりしてないといざってときにスピードでない

考えている方向性としてそんなに遠くはないように思えます。
自分は「質」というところまで踏み出せなかったけど。

スピードを得るために意外に思うかもしれない大事なこと、
ちょっとつづってみようかと思います。
#
# 「質と土台」
#
やはり「はしょることがスピード」と思われがちです。
つまり、質は落とす、土台も作らない、いきなり前に進む。
確かに前に進まないと不安になりがち。
なので自然とそういう風になってしまうもの。ただ...

はしょって前に進むのは最初だけ。
はしょった分だけ後でブレーキになる

開発フェーズで「質」を落として進めるだけ進んで、
テストフェーズがなかなか進まない。
(「開発なんとか、テストで赤字」という典型パターン)
テストまではしょる。リリース後一年二年と苦しくなる。
苦しいのが随分先だから実感が湧かない...また繰り返す。

なんの土台も作らず開発を進める。
土台を作らない分、先に進める。コストも掛からない。
人が多くなってきた。ささいなコストが何倍にも膨らむ。
テストやリリース後のトラブルでログも見れないなんて...
いくらログを分析しようとする実直さがあっても、
ログがない、ログが貧弱だとどうにも先に進まない。
単純な原因のトラブルで何時間も何日もコストをかける。

あまり考えたくない状況ですが、開発現場を見て回っていると、
これが当たり前にように日常として存在しているかなと。

もちろん、質ばかり追えばいいわけじゃない。
巨大な土台を作るのに資源を使い果たしてもしょうがない。
ただ、はしょるならはしょった分のデメリットを別の方法で
しっかりと担保しないといけない。はしょるのは仕方ないに
しても、何もせずそのリスクが消えるなんてことはない。

仕方がない、と言ってもそれは人の勝手な都合であって、
論理の神様はそんなこと知ったこっちゃない。
遠慮なく「失敗」を授けてくれるでしょう。

やはりここでも、ちょうどいいバランスが求められる。
ただ、そのバランスを考えるのをやめて、それらを捨てて
先に進むプロジェクトが多い気がします。人は見えない
メリットにお金を払うことがなかなかできないから。

プログラムの質はプログラマの質と直結する部分があります。
でも、プログラマの質を上げることにお金をかけることを
躊躇する場面をしばしば目撃します。土台を作るという
概念すらなく先に進もうとするプロジェクトも珍しくない。
#
# 「実直さ」
#
コミットコメントを書かない。書かない分だけ前に進める!?

プロジェクトが行き詰まってきたとき、
バージョン管理はその威力を発揮する。
リポジとリーのヒストリーとにらめっこすることも。

コメントが書いていない。コミットした人に聞かないと
わからない。コミットした人も覚えていない。
コミットした人はすでにこのプロジェクトにいない。
一つ一つ差分を見ていくのは時間がかかること、
でも見なければ何もわからない。
コミットコメントを仕組みとして必須にしたいと思う。
でも、根本の問題はそういうことじゃない。
コミットのたびに面倒でもしっかりコメントを残す、
足跡を残す「実直さ」があれば、いざってときのスピードに。

切羽詰まった場面でのプログラム修正、
おもむろにコメントアウトされたコードがある。
なんだこれは...消して良いのか、参考にして良いのか?
以前のやり方?将来の拡張のためのコード?
一時的に動きを確認するのにコメントアウトコメントアウトするとき、
「一言でいいからコメントアウトの理由を書いてくれれば」
悩む時間など無いのに。実直さはどこへ...

意外なスピードのもと、実直さ。
「仕組み」ではどうしてもできないこともあるわけで。
 -> フレームワークやアーキテクチャのできること

今の面倒は、後の面倒に比べれば遥かに小さいもの。
日常の「実直さ」が後の面倒を少なくしてくれる。
つまり、いざってときのスピードに。
#
# まとめ
#
作業の見積もりをする立場の人であれば、
これらの工数(と役割)を忘れてはいけないでしょう。

o それぞれの質を向上させる準備
o 土台を作るコストとスキル取得
o 実直さを広めるファシリテーション

アーキテクトであれば、これらを実現する
スキルを身につけておく必要があるでしょう。

ディベロッパーであれば、自分の実直さで「後の他人」を
助けることができるということを知る必要があるでしょう。
(後の他人は自分かもしれない)

ビジネスにスピードが求められる時代。
だからこそ、作り手として大事にしたいこと。

さて、自分も気をつけないと...