モバツイ最終日だった。
せっかくなので、一つの思い出だけ書いておこうと思う。こういう愚痴は今日だけにしておく、という話。
まだ、UUベースで２万人とかそのぐらいのWebサーバ１台で回していた頃。
当時は、まだ１人で開発していた。
改めて思うと、あの頃の開発速度が最速だったなと思う。
何故最速だったか？というと、
1．使ってくださるユーザーさんがいたので楽しい
2．使ってくださるユーザーさんがいたので直すべきissueが存在する
3.使ってくださるユーザーさんがいたので、責任が重い
この３つがあったからだと思う。
更に言うと、
4. 自分がオーナーだったので全責任を自分で負える
ということもあったと思う。もしかしたら、これが一番大きいかも。
また、Twitterで起きている問題はライブなので、のんびり開発環境で開発する余裕もなく、外出先の飲み屋から、サーバにログインして直でソースコードを直していた。例えば、バレンタインでTwitterが特殊絵文字を出した時には、外で素早く対応したりした。PHP + シンプルなMVCフレームワークで動いていたので、URLを増やしたり、テスト画面をコピーしてテストしてからリリースするなどは簡単だったので、そのようなスタイルで、Twitterの新機能に素早く追従することに。
また、当時は会社員だったので、突発的な修正にのんびりコードレビューなどをしてる余裕もなく、仕事の合間に素早く修正することが求められる。例えば、Twitter apiが何をトチ狂ったのか、突如、日付のフォーマットを変えて送ってきた時には、アバウトなPHPらしく、さくっと修正して対応できた。Javaのアプリはぬるぽで落ちていた記憶があって、恣意的なTwitterに適応するならPHPこそが最強だと思っていた時期もある。少々、変数の型の不整合があっても、簡単には止まらなかったから？ね。
また、写真のメール送信の機能の修正も、オンラインでやったことがある。こいつはpostfixから呼び出されるPHPだったので、ちゃんとデバッグするのが難しかったので、最強の集中力で修正に当たった。ミスれば、全メールが止まってしまうコードを、よく、その場で直したなというのはありつつも、それをやって止めないだけの集中力が兼ね備えた時期だったことは間違いない。
もしかしたら、あの頃は変性意識状態にあったのかもしれない。
別にやんちゃ自慢をしたいという思うわけではない。当然、その後サービスが大きくなってからはそんなバカなことはしないし、社員が増えてからは、当然、ちゃんとしたリリースプロセスに持っていく。そもそもサーバが30インスタンスみたいになってれば、rsyncでしかdeployする流れで、当然、staging環境ででテストしてからリリースをしていた。
その際に働く心理的圧力は、
自分がミスをしたときのコスト ＞ プロセス管理をちゃんとやることでの時間の消費
となるから、開発プロセスをちゃんとしなくてはいけないという話になるのだが、じゃあ、もっと利用者が少なかった頃は、不等号が逆だと思っていたかというとそんなことは決してない。まさか自分のミスで、サーバエラーが起きて良いだなんて思ってないし、Twitterが要因であろうとなかろうと、モバツイが落ちているときの僕の不機嫌さは家族が一番知っている。１人でも使ってくださる人がいるのならば、バグがあっていいなんて思ったことはない。
ただ、強いていうと、自分がオーナーであるという確固たる意識というのはあったのかもしれない。それは大胆さに影響する。
これが人から預かっている資産だと思う量が多ければ多いほど、慎重になっていくのかもしれない。
つまり、慎重に事を進めることによって、失われる時間というのは、そのサービスに対する主体性もしくは責任感によって変わるという理屈だ。
「バグで落ちるのはすげーいやだけど、大胆にシステムをいじることもやぶさかではない」
という状況だからこそ、
・ものすごい集中力でバグを起こさないようにコードを書ける
・大胆かつ最速に問題解決ができた
状態になれるんじゃないかとは思う。それがモバツイが沢山の人に支持された理由であるならば、「ちゃんとすること」よりも「ちゃんとしないこと」の方が正しい、のかもしれない。これはまだ当たっていないフェーズのサービスにおいては、非常に重要なことだと思う。
つまりCIだとかチーム開発手法を整えるよりも先に、ユーザーさんに支持されて成長する状態を作れ、という話だ。もちろんバグは出さずにな。
丁度、取材を受けた頃がまさにその頃だった気がする。
「休む時間もないけど楽しい」 15万ユーザーが使う「movatwitter」を1人で支えるには
ある意味、僕の開発者人生のピークがその頃だったと仮定すると、それを僕、もしくは、僕以外の人達で再現するにはどうしたらいいか？というのが目下の悩みである。
つまり「最速の開発」を実現する方法が、「ちゃんとしないこと」かつ、「圧倒的な当事者意識」の賜物であるとするならば、普通のマネジメントは、それとは完全に逆行する方向に行きがちだ。つまり、「ちゃんとしようとして」「属人性を廃する」ようなことを始めるのは、完全にスピードをスポイルする方向に行く可能性が高い。
とはいえ、僕すら知らないような変更が局地的に行われるのは辛いわけだから、それを可視化できるようにさえしておいてもらって、何やら報告はしといてもらえれば、あとは、できればノーマネジメントでみんな勝手にやってほしいという理想論がある。一定以上のスキルを持った人材の集まりであれば、カオスな状態で、それぞれの方向に向いていることが、うまくいく秘訣ではないか？という考え方だ。
まあ実際にやると、みんなが方向を見失って結果的にいいことにならず、マネジメントのミスとなるので、ほどよい制約の中での自主性をどう重んじるか？というマネジメント方法の方が良いと思っている。
