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