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