10/30付で、2011年に新卒入社してからお世話になったDeNAを退職となる。(10月はほとんど有給消化していた)

大きくはゲームのサーバー基盤づくりと、コーポレート部門のシステム基盤づくりに関わっていて、後者は3年くらいやっていた。時間があるので、自分が考えたり関わったりしていたことについて気ままにふりかえってみる。ここからはすべて個人の意見として読んでいただければ幸い。

ざっくり

DeNAのような会社に特徴的なのはグローバルでそれなりに大きな組織であることと、その内外のスピード感だ。自分が就活していた2009-10年頃は、ゲームプラットフォーマーのグローバル展開の激戦を見ていた。入社後、いろいろな業務をそれに追いつかせる必要があった。諸々の業務システムは国内での業務を前提としており、主要なシステムについてはグローバル統合プロジェクトがそれぞれあった。

As-IsとTo-Beについて

はてなでバイトしていた頃はネットユーザーだけを観察していて、自分もその一人だった。はてなにもはてなグループのような業務システムといえるものはあったのだが、業務システムやビジネスロジックという概念は長い間よくわからなかった。

業務においても開発においても、油断すると現状ありき、システムありき、技術ありきで話を進めがちだ。業務の理解が雑である状態でシステムを作っても無駄な手戻りが発生することも多い。手戻りを踏む判断ができればまだいいかもしれないが、既に組み立てた業務やシステムのサンクコストが大きく、もっと最適化できるのに手を付けられない・・・というもやもやを抱え続けることにもなりうる。負債とはこういうものの総称かもしれない。

現状ありきでものを考えないようにするために、大きく業務面とシステム面で以下のようなことを揃えて考えるのがよさそうだ。

なんのための業務なのか
To-Beはどうなればよいのか
As-Isはどうなっているのか
現実的にはどこまでTo-Beに近づけられるのか
業務でカバーできるのか、システムが必要なのか
システムは作るのがよいのか、出来合いのものを使うのか
作るには誰の協力が必要なのか
作ったものの寿命はあるのか、いつまでなのか

PofEAAやDDDの本などを読み始めてはいたが、常に業務整理や設計にじっくり時間をかけられるかといえば、そんな余裕がない場合もある。これから作るものはあくまで感触をつかむための暫定であって賞味期限Xヶ月くらいで捨てるつもりがある、という前提をおく柔軟さをもつべきプロジェクトもある。

体制について

スタックとしてはPerl,PHP,Python,Ruby(Chef),CoffeeScript,GoやAWS,Dockerなどを必要に応じて使っていた。

チームにはWindowsでの開発経験しかない（Linuxがわからない）、subversionしか使ったことがない、全員が共通して認識できる言語が少ない（あるとするとPHP）などの諸々の制約があることもある。そういう状況ではできることから始めて、随時順応していくほかない。スクラムは型に沿ってやってみて、いろいろ要素を落としたりしてなお試行錯誤が続き、まあそうあるべきという気もする。

はてブやQiitaを見る限り議論し尽くされている（もしくはまだ尽くされていない）ようだが、自分の担当システムも要件が集中しすぎる肥大化問題があり、APIやQ4Mなどを通じて分割するアーキテクチャ変更を行った。開発サイクルの分離、システムごとの設計やコンポーネント選定の柔軟性と、それによる属人化やチーム構成の複雑化など諸々を差し引いて、トータルではやってよかったと思う。

CIは完全導入までたどりつかなかったが、個人的経験からすると、テストやCIを回すのは設計についての議論が共有されていることが前提である気もする。

柔軟性について

大きめの案件が一段落して運用に入り落ち着いている時期は、別の付加価値を出せるようなプロジェクトに時間を割くような調整をさせていただいた。例えば、ある程度組織が大きくなると、ハードウェア・ソフトウェア資産の活用に非効率が発生しがちであるが、電子部品を買ってきて改善のプロトタイピングを行ったりなどしていた。またSlackやQiita:Teamなど界隈でメジャーなサービスを大組織で運用するとどうなるか、実際に利用してみたり必要な開発をしたりしていた。業界や組織の流動性が非常に高いということの裏返しで、新しい問題に対する経験・ノウハウ蓄積を行っていこうとする柔軟性の恩恵を個人的に受けた。これはとくに感謝している点で強調しておきたい。

出社するということについて

働く場所については、最近のベンチャーであってもリモート派とオフィス派に意見が結構別れそうだ。自分の場合は、全社に対してオンサイトサービスを提供するチームということで朝9:30に出社していた。 ITとしては平均的というところだろうか。チームによっては朝8時に西海岸とのコミュニケーションを入れたり、メンテ時間を無難な早朝に定めているところもある。もちろん社内でもリモートを視野に入れているチームもあり、開発メンバーであればどこにいるかは関係ないと思う向きもあるだろう。だが、リモートにするとメンバーの対応状況が見えにくい分、オフィスよりも即応性が求められる。またオフィスでなら考えなくてよい画面やネットワークのセキュリティにも気を配る必要があるので、トレードオフだろう。

渋谷という立地について

入社当時は初台でNTTマンと一緒に電車を降りる生活だったが、2012年にヒカリエに移転した。そういえばLINEは新宿移転のニュースがあった。渋谷は人酔いする、汚い、うるさい、と嫌う人は結構多いが、個人的には好きな街だ。個人的にも業務的にも関係の深いベンチャーが渋谷にはいろいろあって何かにつけて集まったり情報共有したりできるのはやはりよかった。自分も頻繁にランチを主催したが、渋谷ならそれほど負担をかけずに来てもらうことができる（とはいえ、お店のノウハウはあまりなくてだいたい誰かのお世話になっていた）。開発するだけなら地方でもいいのだが、都市の効率性とよばれるのはやはりこういう側面だろう。

業務について

仕事の話を書いたことはないのだが、メンバー、あと社外で同じような問題を抱えている人と話したことを振り返りながらその未来について考えた。長くなってしまったので斜め読みしていただきたい。

組織規模やユーザーベース、戦略的に重要な提携が増えると、各種の情報へのアクセスコントロールの要求が高まる。この要求を、組織文化を損なわないように機能化していくのは簡単ではない。たとえばIRCの数百名のチャンネルで機密に近い会話が行われているとき、「ここにいる全員が、この会話を読んでよい人間なのだろうか」という疑問を全員が発している状態は不毛である。

コントロールしたい情報は立場や環境によって違う。たとえば人事に責を負うメンバーにおいては、名前や性別や年齢、給与のような個人情報、重要な従業員の入社・離職、特定の雇用形態（という概念がしばらく意味をもつとして）のメンバーは誰なのか、などがある。

組織のある一連のアクティビティにおいて、少なくとも誰がインサイダーでありそうでないのかは明らかになっている方がよい。単にある組織の境界の内部と外部で二分すればよいだけであれば、SSOを設置したり特定ネットワーク以外からのアクセスを遮断したりすればすむ場合もある。

そうでない場合はリソースによってユーザーの範囲や権限を変える必要がある。同じアクセスコントロールを複数の情報に繰り返し行いたい、そういった操作を最低限にしたいという要求から、アクセスコントロール自体が緻密にオブジェクト化されていたり、アカウントのグループを入れ子にできるようなシステムも存在する。もっとも、10人のチームではこれはナンセンスかもしれない。

アカウントそれぞれの権限のコントロールはどうするか。メンバーの信頼度や貢献度をリアルタイムに定量化できれば合理的だろうが、これは半ばSFだろう。 SFがテクノロジーをドライブする側面があるのは確かだが、もう少し現実的なものとして、雇用形態に基づくアクセスコントロールがある。

雇用制度や習慣もさまざまだ。面接即日業務開始であるような国、逆にレイオフが日常的である国で、業務日数ベースのバッファを前提にした日本のシステムを無理に適用することはできない。シーズナルワーカーが多い文化であればそれに合わせた業務・システム設計が求められる。職種や職能も同様だ。グローバル化すれば、国内であれば考えなくてよかったタイムゾーン処理も入るかもしれない。地球は丸い。

業務システムに求められる処理量には、システム（間のインターフェース）の数と、インターフェースあたりのトランザクションの量という要素がある。システムの数は組織の規模や人材多様性によるだろう。それぞれの業務ドメインとメンバーに最適化されたシステムを利用したいという要望が増える。 GithubとSlackであらゆる業務が回ればクールだが、多くの場合は夢物語とも思える。アクセスコントロールのような機能はリスクコントロールを求めるチームであれば普遍的に要望があるので、手元にある機能を組織内の不特定多数に展開するためのインターフェースも必要になる。そうであれば、組織内のAPIやWebHookの管理を強化する必要があるかもしれない。

トランザクション量はビジネススピードと考えてもよさそうだ。人事領域のトランザクションは会計領域よりは少ないだろうが、未来の組織において人員配置の変更や事業会社の増減はよりカジュアルになっていくだろう。

多くの人間が特定の組織に対して決まりきった形でコミットするという労働像は、緩やかに崩壊しつつあるという感覚がある。個人や緩やかなチームの活動が社会において占める比重は無視できなくなり、予想もできない協働の形が実現していくだろう。組織のような社会システムの境界についての理念的な話に入るのは個人的に面白いのだが、別の機会としたい。

ともかくそのような環境において、無駄なストレスと余計なリスクを組織から排除して本来の組織活動を支えるにはどうすればよいかを常に見直していく必要がありそうだ。

退職について

様々な選択肢やプライベートな事情も含めてフラットに考える時間をとれていなかった。仕事のほうは年下の新卒メンバーが育ってきて、自分依存の部分を減らせてきていた。総じてよいタイミングだった。

久々に会った人が実は貸与PCの返却に来ていてそれっきりというのはざらだし、人事データベースや業務システムのメンテも頻繁で、全社員の入社や退職を隣で見守るような業務だった。いざ自分の番となると、ほう、そんな退職業務があったのか・・となるシーンもあり、謎の感慨もあった。職業病かもしれない。

社内にいてもいろいろな事業状況の変化があって飽きないのだが、オペレーションを支えるという自分の立場から見る限り、スピード感と同時に全般的に抜かりなくちゃんとやる会社だったし、それがDeNAのよさの一つでもあると思う。 4年半、よい経験だった。そしてエンジニアとしても楽しめた。改めてありがとうございました。

今後について

退職前にベン・ホロウィッツx 南場智子の対談を聞きに行く機会があり勇気づけられた。

Startup X Talk #2～HARD THINGS 君は苦闘を愛せるか｜EventRegist（イベントレジスト）

今後のことは考えていたことはあったのだが、結局まだちゃんと決めていない。もともといろいろ半端に首をつっこんでいる（それを整理する時間をとっているというのもある）が、時間の使い方が何とも定まっていない状態は初めてなので新鮮だ。裏方に徹し、サービスなりプロダクトなりナレッジなりを残すということを怠ってきたので、そちらに軸足を寄せていきたいという気持ちもある。海外にも目を向けてはいて長旅も考えたがそれほど余裕があるわけではない。もし何かお手伝いできることがあれば、お話できればと思います。

よろしくお願いします。