エンジニアリング組織のサイジング

 開発組織が大きくなるにつれて、そのマネージメントの難しさを感じるようになった。
僕は巨大な組織をマネージメントする立場には無いものの、職務の一部にそうした毛色のものが少しずつ入ってきていて、これがもっと大きくなるということはどういうことなのか、を何となく意識していた。


 そんなとき、たまたまこの記事を見つけた。英語。
On Sizing Your Engineering Organizations | Kellan Elliott-McCrea
これは開発組織のサイジングをどう捉えるのかというのを真正面から語っている。世の中にはドメイン特化の具体論やツールの紹介をだらだら並べるだけのビジネス書が山のように存在する。それらはそれらはいずれも「ウチでそれが当てはまるとは限らんよなー」という感想にしかならず、僕はどんどん捨て忘れてきた。いっぽうこの記事には、そうした僕がこれまで見聞きしてきたものとは一線を画す良さがあった。組織の規模の変動、個々の開発チームのパフォーマンス向上、インフラ投資、メンバーの離職、のどれからも目を逸らさず、しかしとてもシンプルにそれら全体を捉えるこの文章は見事だと思う。


 そこで、翻訳した。よかったら読んでみてほしい。
エンジニアリング組織のサイジング | Gist
 僕は英語が苦手だから翻訳ミスはたくさん含まれているだろうけどね :P 

Team

 人不足だと言われているが、それに呼応するように労働者に求められる専門性は上がってきている。IT 業界だって例外ではなく(もともとそういう性質の分野ではあるにせよ)、中小規模のプロジェクトなど、一人で案件を抱える人が増えてきているのではないかと思う。僕はソフトウェアエンジニアで、同業者の中にはそういう一人プロジェクトを抱えている人がたくさんいることも知っている。さしずめ僕らには充実したツールが揃っている。一人でもチケット管理して、一人でもソースコードのバージョン管理して、一人でも CI を通す。デプロイ、メンテナンスも一人で出来てしまうので、外から見れば一つの開発現場があって、ちゃんと回っており、しかもたった一人のアサインで済んでいるという、とてもリーズナブルな完結状態が、そこにはあるように見えると思うのだ。

f:id:kura-replace:20181220142334p:plain

 ではそこに取りこぼされている問題は無いのか?と考えてみるに、まずは属人性の高さが議場に上げられるだろう。その人がいないと分からないことが多すぎるからドキュメントを残すことが重要だ、とか。いかにもありそうな指摘である。しかし「属人性の高さが問題になるが故に、埋もれてしまう問題というのがあるな」というのが僕の気づきであったし、それが本記事で書きたいことである。

続きを読む

嫌いなものが存在するという悩み

息子を寝かしつけるため、ベッドで横になり、いろんな話をする。
彼は先日 5 歳になったばかりなのだが、 5 歳児には 5 歳児なりの悩みがある。

彼曰く「嫌いなものがある、ということが嫌なの」だそうだ。嫌いな食べ物(例: 茄子)があって、嫌いな人(例: 弟)がいて、嫌いなこと(例: 蚊に刺される)がある。僕は初めて聞いたとき、思わず笑いそうになった。好きなものだってあるんだからそれで良いじゃないか、というとそうではないらしい。好きなものだってあるが、それは嫌いなものを消してくれるわけではないから、困る、と。とどのつまり、そういうことらしい。

f:id:kura-replace:20181002174757p:plain

=== そこでこんなアドバイスをした ===

僕「嫌いなものが、そもそも何故あるのか分かる?」
子「だって嫌いなんだもん」
僕「好きなものだってあるだろ?自分が知ってるあらゆるものを、これは少し好き、これはとても好き、これはちょっと嫌いという風に決めているのは自分なわけ。」
子「じゃあ嫌いなものが全部、無くなったら良いのに。そしたら好きなものだけが残るはず。」
僕「わかってねーな。いま好きなものだけが残ったら、その残ったもののなかで好きとか嫌いとかをまた決めちゃうんだよ。」

f:id:kura-replace:20181002175926p:plain

子「えー(´Д`;) じゃあその新しく嫌いになったものも無くしたい!」
僕「そしたらまた残ったもののなかで嫌いなものが出てくるぞ?」


子「もう嫌だ.. 僕が居なくなったら良いんや...」
僕(な、なるほどそう来るか...)

 「だがしかーし、逆にいま知らないことをたくさん知ったらどうなる?いま好きだと思ってるものより、もーっと好きになっちゃうようなものだって、あるよ?」

f:id:kura-replace:20181002175942p:plain

子「えーーwwwww」
僕「それは知りたいやろ?」
子「うん」
僕「あー、でも、いま嫌いなものより、もーーっと嫌いなものだって、知ることになるけどな?」
子「えー(´Д`;) やっぱ嫌だ」
僕「でも、それより、もっと、もーっと、もーーーーーっと好きになっちゃうものだって、ある」

f:id:kura-replace:20181002180155p:plain

子「あぇーーー!!!!!!」
僕(勝った😏)

子「じゃあそれはどうやったら知れるの?」
僕「まぁ、それは絵本を読んで。」
子「絵本はもう読んだよ?」
僕「もっと読んで。例えば、蝶が卵を産んで、青虫になってサナギになって、また蝶になるやろ?」
子「うん」
僕「それさ、ずっと見てたわけ?見てないでしょ。当たり前に知ってるけど、虫の絵本たくさん読んだから知ってるわけだろ。卵から蝶になるところをずーっと見てたら、お腹すいちゃうし、眠くなっちゃうし、とにかく無理なの。でも知ってる。絵本を読むと、自分ひとりだけでは知ることができなかったことを知ることができちゃうわけ。」
子「はー」
僕「... というわけでこの話はおしまい、もう寝ようぜ」
子「あー待って。うんこしたい」
僕(何故...)

=== というわけで息子との話は終わり ===

 ところで、企業のエンジニアリングにおいてもこれと似たようなことってあると思う。

 例えばエンジニアの視野の狭さ。アプリの設計を考えるとき、そのプロダクトが潜在的に持っている伸びしろを矮小してしまうことがある。その決定打となるのは、利用する技術の選定だとか、根の深い依存関係だとか、スケーラビリティやセキュリティへの配慮の弱さだとか、そういうかたちで現れるのだが、現れたときにはもう手遅れ、ということだって多い(だって企業はスピードが大事だから)。仮に同じだけの時間をかけたとしても、携わるエンジニアが誰であるかによって、完成品の質、もしくはそれが生み出す具体的な利益の差は非情なほど開いてしまう。

 少し立ち位置を変えよう。今度は「嫌いなものが存在するということ」に悩む姿勢そのものを肯定的に捉えてみる。それをチーム運営に apply するかたちで振り返ってみると、別の問題が見えてきたりもすると思うのだ。

 手がけているプロダクトにボトルネックがあったとして、それの解消にリソースを割くことができないというのはよくある話。しかしそれでもその企業のエンジニアリングが頓挫しないのは、ほかに手軽に解決できる問題が転がっていて、その解決がいくばくかの利益を呼び寄せるからだ。それに、そうやってチームを維持しておけば、いずれ何か政治的な力学によってそのボトルネックの解消を回避できるかもしれない。つまり「将来いつか開けるであろう広い視野」への期待が、「いま目前に立ちはだかるモンスター」を矮小化する暗示に化けるのだ。こういう楽観的な視点は、ある側面から見れば開発者として最も大切な素養の一つであることに異論は無い*1が、それによって長期的な停滞を招く可能性があることを意識しなくてはならない、とも思う。

 僕が見てきたエンジニアリングの現場というのはほんのわずかだが、そのわずかな経験を元に言うと、開発チームが問題を忌避すればするほど、そのプロダクトに関わる非開発者がどんどん離れてゆくように思う。なぜなら、問題がそもそも問題であると認識されていることは、その事柄が厄介であり重要であることの自明的な発露であるからだ。まぁもちろん僕だって、開発チームが、あらゆる問題を積極的かつ抜本的に解決する存在でなくてはならない、なんて言うつもりはない。けれど、冒頭の、息子の完全にオリジナルな悩み「嫌いなものがある」ってのは、なかなか捨てたもんじゃないなと思ったのだ。

*1:"You ain't gonna need it"(YAGNI) という言葉だってあるし(あぁもちろんそれがこの話とイコールだなんて言ってませんよ)。

承認欲求が消える瞬間

  SNS で、自分が被ったわけでもない問題についてあれやこれや批判を投稿するというのはもう当たり前の風景になった。見ていて気持ちの良いものではないが、少なからず僕だってそうだし、僕に限って言えば以前はもっとひどかった。

 僕のフォロワーでも 5 年前と今とではずいぶん性格が変わってしまった(ように見える)者がいる。日々の発言に含まれる正論の割合は立派なものだが、ときに暴力的ですらあるそれを、わざわざ目に見える形にする Twitter 的なサービスは、10 年後に今と同じ姿では居られないだろうし、Twitter に限って言うと恐らく消滅しているだろう。

 

 Twitter の心配はどうでも良い。よくある言説は「彼らの言動を駆り立てているものが承認欲求である」というレッテル貼りから始まる。僕はこれがレッテル貼りに見える。というのも、果たして承認欲求は SNS によって満たされているのだろうかという疑問が消えないからだ。どこかに「n いいね👍」「m RT」の n, m がいくらになればその欲求が満たされるという境界ラインを見出した研究結果でもあるんだろうか。「この美味いラーメンを食べて食欲が満たされました」「昼すぎまで寝たら昨晩の疲れが取れました」「ここに投資したら目標だった資産の形成ができました」「結婚相談所に登録して結婚できました」とかなら、まぁ見聞きしたことあるが、果たして強力なインフラによってリアルタイムに反応が見えるのが当たり前になった SNS で「溜まってた承認欲求が満たされました」っていう人を見たことがない。

 こういう切り口から入る話の、次の展開などどうせ決まっている。承認欲求に振り回されないための心の持ち方とはどういうものか、である。炎上歓迎タイプ、降りかかる dis をものともしない強い心を持つタイプ、気にせず受け流すタイプ、そもそも承認欲求を発生させないテクニックを習得するタイプ*1など、いろんな人がいるなぁ(ニコニコ)という感じだが、とにかく「そんなもん個々人の処世術の範囲だろ」と言いたくなるような話題に無数の解説記事が組まれ、Web のあちこちに転がっている。

 さて。承認欲求というものがありそれが満たされない人がたくさんいる、というのはその通りだと思う。字面どおり、この欲求は承認されれば満たされる。ではいかにして欲求が満たされるレベルの承認を得るのか?承認をする者が一個の人間である以上、完全に理解された上でさらに承認を受けるというシナリオは有り得ない。しかし、もし承認されたと錯覚することができたなら、承認欲求なんてものは簡単に満たされ霧散する。ではそれはいつ起きるのか?と僕の経験を振り返ってみるに、自分より頭の良い他人に自分の世界観をマルっと説明されたときに、起きるように思う。

 説明の切り口は本当に些細な糸のほつれだったりする。頭の良い人間はそのほつれを見逃さず、そこにじわっと湿り気を与えてみようと試みるものである。そしてその人の内面に浸透するかのごとく、わずかな時間で人間性を理解する。理解された側の人間にとっては、これは突然訪れるスコールみたいな体験になる。このとき「いいね👍」だとかの賛同を求める気運が生まれないのが SNS との違いではなかろうか*2

 

 承認の尻尾を追いかけていつまでも SNS に入り浸って出てこれず、流行りに乗って都度都度ピエロのように言動を重ねるというのは、ある側面から見ると知的ではあるのだろうが本質的にはとても動物的である。僕はそれを悪いとは言わないが、頭の良い他人と対話をするだけでその状態からスッと抜けだす機会をゲットできるので、そこだけ意識的になっておくと随分違うぜー、というのが今日のまとめ。

*1:順にそれぞれ炎属性、地属性、風属性、水属性である

*2:さしずめ「RT」というのは承認した側が受ける逆風のようなもだと位置付けることができて、やはりこれも要らないように思う

法人化しません

 最近、法人成りできないかなと思って電卓叩いてみたんだけど、コレと言えるメリットを見出せなかったので一旦諦めた。

 

 法人成りというのはつまり、個人事業主としてやってる仕事を廃業して会社を起こすことである。

 僕の法人成りの目的は節税にあった。だから夢がどうだとか社会に貢献だとか、はたまた社長と呼ばれて大金持ちを目指したいとかそういう話ではない。家庭に残すお金をどう最大化するかという一点がテーマである。

 Web で調べると節税をうたって解説をしている税理士さんのサイトが山ほど見つかる。だから実際に自分に当てはめて試算してみる前からこれはだいぶ得するのではないかという期待はあった。また起業を経験した人の話を聞くと「まずはドンブリ勘定で良いから一、二年やってみて、儲けとか税金とか保険とかを固めるのはその後だよ」と言われた。つまり法人化して会社を始めてしまえば後は何とかなるもんだということらしい。さらに保険屋にも相談を聞いてもらったのだけど「節税のために保険を使うというのは基本的な考え方。いくら利益を圧縮したいかで保険商品を選ぶと良い」などのアドバイスももらった。

 そういう諸々の意見にばかり気を取られて、すっかり法人化する気持ちだけは固まっていたのだけど、実際に計算してみるとそう甘くは無かったんだなぁコレが。もちろん僕には僕の、コレがこうでアレがああで、という動かし難い条件がいくつもある。それらを全て踏まえた上で、残った可変パラメータをあれこれいじっては試算を繰り返した結果がいずれも否だったというだけのことである。

 

 財務の首を締めるものには何があるかというと、まずは社会保険がある。いくらなんでも高すぎる。

 次に、法人という、僕とは別の社会的人格単位の創設と維持にかかるお金。法人税、法人事業税、法人県民税、法人市民税とかね。

 あとは生命保険をいかに損金算入させつつ保障を組み立てるかというあたりも結構悩ましい。

 もちろん、こんなものは法人を運営するという実務全体から見たら細かい話に過ぎない。経理、法務、人事など本業を囲うあらゆるものがちゃんと駆動してようやく法人が法人として生き長らえられるのである。それらをちゃんとうまくこなせるという無理ゲな仮定をしてもなお、節税という目的ひとつ達せられそうにないという結論が出たことは、正直残念だった。

 

 ところで、二つほど気づいた事がある。

 ひとつは、会社というものを取り巻く法律・税・保険・金融機関は実によくできているということ。ちゃんと利益を出そうと取り組む会社に、これらインフラは手厚く対応してくれる。

 もうひとつは、財務を疎かにする経営はそもそも無責任だということ。財務は経営者(または財務担当部署)の領域であるから、財務をちゃんと舵取りしないということは、会社を危険に晒していることに等しいのである。税理士は税の、保険屋は保険のエキスパートであって、財務の専門ではない。節税するため、保険料を支払うためにばかり経営をする会社というのは彼らのカモではないかとすら思う。

 

 何だか最後偉そうなことを書いたけど、軽い気持ちで節税のために法人成りしようとした僕の目論見は見事にポシャったので、ちょっと悔しかったゼという話でした。まだ完全には諦めてないけどねー。

ArangoDB ってのが面白いと思うんだ

 最近 Graph database が盛り上がってるように感じる。

 さて ArangoDB という DB を知っているだろうか。
 MySQL とか MongoDB とかと比べると知名度は低いものの、NoSQL、とりわけ Graph database 界隈では名が知られている。Graph database 界隈と書いたが、さしずめこの領域では Neo4j が幅を利かせている。Neo4j なら聞いたことあるって人はたくさんいると思う。

Graph databases

Neo4j

 Neo4j の強みとしては、そのクエリ言語である Cypher の読みやすさが一つ挙げられる。Cypher の紹介ページ に書かれている最初のサンプルを引用すると、こうだ。

MATCH(:Person{ name:"Ann"})-[:MARRIED_TO]->(spouse)

このクエリは「name が "Ann" である Person と MARRIED_TO で結ばれている相手を探して変数 spouse にセットする」のだが、それを SQL で表現しようとするとおおよそ直感的とは言えない join に苛立たせられるだろうと思う*1
 Neo4j は先行者であり、現在は後続の Graph databases からパフォーマンステストで叩かれまくっている。僕も試したんだけど正直、ある程度のレコード数になると遅さが目立つようになる。

Dgraph

 勢いだけで言うなら、最近いちばん盛り上がりを見せたのは Dgraph じゃないかな。
『オープンソースの分散グラフデータベースDgraphが$3Mを調達しv.1.0にやっと到達』Tech Crunch
 Dgraph のクエリ言語は GraphQL+- という、昨今話題の GraphQL を Graph database 用に進化させた言語である。Dgraph の紹介としてはこのスライド 『Dgraph - A high performance graph database written in pure Go』 Speaker Deck の 14 ページ目 〜 24 ページ目が分かりやすい*2

・その他

 他にも Graph database はたくさんあるけど紹介していたらキリが無い(OrientDB, Amazon の Neptune, GraphDB, ...)。ArangoDB の話をしよう。

ArangoDB

 ArangoDB は Graph database であることが主ではなく、あくまで Multi-Model NoSQL database という触れ込みになっている。簡単に言ってしまうと、JSON で表されるような構造化されたドキュメントを value とする kvs でありつつ、そのレコードを使って Directed graph を形成したりできる database である。

f:id:kura-replace:20180420020618p:plain

データを操作するには 2 つの方法がある。ひとつは AQL というクエリ言語を使うこと、もう一つはシェルから JavaScript を叩くことである。
 なお最新のパフォーマンス比較は↓こちら。LGTM。
『NoSQL Performance Benchmark 2018 – MongoDB, PostgreSQL, OrientDB, Neo4j and ArangoDB』

Dgraph と ArangoDB とのパフォーマンス比較をした良い記事が見つからなかったので良かったら教えて欲しいのだけど、その比較を待つまでもなく ArangoDB を推したくなる理由を次に書こうと思う。

ArangoDB を選択する理由

 データというのはプロダクトにとってライフタイムの長い性質のリソースであって、それをどういう形で持つのかというのはとても重要である。おいそれとアクの強い、信頼の薄いデータストアに置くわけにはいかない。「では ArangoDB がきな臭いか?」というとそれは判断が割れるところであろうが、少なくとも知名度を一つの尺度とするなら MySQL や MongoDB には敵わないだろう。しかしそれを踏まえてもなお検討を続ける価値はあると思う。

1. Multi-Model であること

 データの保存先として、何も考えずに RDB を選ぶ時代は終わった。とはいえ、他の選択肢として何があるかと言ったとき MongoDB しか無いというのも面白く無い。改めて「データは、それを利用するアプリケーションからどう見えるべきか?」という問いに真っ正面から向き合ってみると、それに応える有力な選択肢として Graph があると思う。アプリケーションが使う全てのデータを Graph として見るというのは無理があるが、Graph 的なデータを部分的に持つアプリケーションというのはたくさんあると思うのだ。Document は保存したいし Document 同士の Relationship も保存したい、当然 Collection を横断する SQL 的な join もやりたい。Middle size のプロジェクトに対して ArangoDB が妥当性を持つ余地がここにある。*3

2. foxx

 ArangoDB には、foxx という、microservice を作る機能が乗っている。データベース内で動く JavaScript を書くことが出来、またそれは DB のインメモリデータへアクセス出来る。DB が Microservice になるのだ。
 通常 Web アプリケーションは少なくとも 2 つの大仕事をしている。ひとつはフロントエンドに返すデータの構築*4、もう一つは何らか「形式立ったロジック」に沿ったデータアクセスである。DB が Microservice になるということは、後者の「形式立ったロジック」を DB 側に配置できるようになるということである。またネットワークオーバーヘッド削減にも寄与する。
 その他 foxx の面白さを最も的確に語っているのは公式のページだと思う。

3. 決定的な欠点が無い

 Transaction もある*5、クエリ言語もある、クラスタリングもある、プラットフォームに合わせたインストール手段、コミュニティ*6もある、開発も継続されている。だから、(我々の)プロジェクトと ArangoDB 双方の将来を考えたとき、どうしてもココが真っ暗だというポイントが無い。そう言えるものって一握りですよ。

以上、そんなわけで

日本でユーザーさん増えてほしいなぁと思うわけです。

*1:SQL を dis っているわけではない。それは時代遅れの態度だと思う。ここでは Graph database が得意とする領域がある、ということを言っているに過ぎない

*2:ただ 17 ページ目の「データモデルとして RDF triple を採用」というのはちょっと違うと思う

*3:Neo4j では全部が Graph になってしまう。

*4:例えば Rails で view の render をするとか

*5:ところで MongoDB にマルチドキュメントの ACID トランザクションが来るのは 2018 夏らしいですね

*6:Slack が過疎って無いんですよ奥さん!