Kengo's blog

Technical articles about original projects, JVM, Static Analysis and JavaScript.

私は何がやりたいのか、あるいは何がやりたくないのかという話

最近「で、君は何をしたいの?」という問いをいただきます。やりたいことややりたくないことは社会人としての6年間で変化があったので、これを期にまとめておきます。

学生時にやりたかったこと

学生時代に今の会社を選んだ理由は3つあります。

  1. ユーザ数が多く、得られるフィードバックの質と量が期待できた
  2. 製品を持ち、それが社会に与える影響が大きいと思えた
  3. 経営陣が提唱する理屈・哲学に納得・共感できた

学生時代にほそぼそとフリーソフトウェアの開発と公開を行っていた経験から、フィードバックこそがソフトウェアを向上させるという考えを持っていました。エンタープライズかつ独立系を選んだ理由はまさにこれで、他社に比べて多少技術に劣る*1としても日本で最も良いフィードバックを得る会社を選んだという自負がありました。

3もまた重要で、経営陣の言うことの多くは確かに重要かつ差別化要因になると思えました。それらを身につけることで、社会を生きる上での思考基盤構築の一助にできると考えました。

なおソフトウェアの業界を選んだのは、放っといても自分が開発周りのキャッチアップに時間を使ってしまうことから、これをオフだけでなくオンでも使わないと時間効率が良くないと考えたためです。

やりたかったことと実際のギャップ

期待と実際には当然ギャップがあるものです。また学生時代に空想していたものと実際のプロフェッショナリズムには若干の乖離があります。そしてここ数年のSNSの進歩で変わったものもあります。例えば:

  1. リリースからフィードバックまで、フィードバックからリリースまでの速度感が大切(PDCAサイクルのスピード)
  2. 社会に与える影響と充実感・使命感は相関しない
  3. 一般ユーザ向けのサービスでも多くのフィードバックを得られる時代になってきた

私にはaがけっこう大切で、仮説を検証するスピード感がサービスの質向上ひいてはユーザの幸福を実現する鍵のひとつという考えを持っています。ここは昨今のデータサイエンティストブームに共感するところで、ロジカルかつ定量的な検証を行えるところは素晴らしいと思って見ています。Yahoo!さんの爆速も共感します。

cは就活時にはあまり予想していなかったことです。私はTwitterの利用開始が遅かったこともあり、この未来を予測できませんでした。mixiしか知らない当時では予測は難しかったと思います。

働いてはじめて見えてきた要素

当時は見えていなかったり、見えていてもそこまで重要視していなかった要素もありました。大きなものでは以下が挙げられます:

  1. 周囲のプロフェッショナリズム、スキルセット、思考プロトコル
  2. 新人教育のコスト
  3. 開発体制や目的意識浸透のコスト
  4. 時間の使い方

周囲について

1.は最近 id:m2ym さんがわかりやすく表現されているので引用します。

私の場合「PRベースの開発をしましょう」と言ったときに「はーい」とか「XXの方がYYの観点ではいいよね」とか返ってくるチームだと良いなぁという感じです。「じゃあまず講座開いて全員にわかるようにしてください」とか言われるとググれよという気持ちになりますし、相手が非新人かつ他社経験がある人なんかだと「なんで今までそんなことも知らずにやってこれたの!?」という気持ちになります。

新人教育について

大きめの企業だと新卒採用での大人数採用をするので、新人教育が必要になってきます。私は教える側の立場になることが多く、それなりの方針は持てるようになりました。最近はマネージャとしてチームも持ってます。

ただ、方針を持って効率や成功確率が上がっても、教育に時間と資源がかかってストレスになるのは変わりません。IT系大学の卒業生なら教育が不要かというとそんなことはなくて、CSRFを知らなかったりVCSを使ったことが無かったりする*2ので、どんな人でもそれなりのコストは掛かってしまうという覚悟を持っています。

この辺はBOXENやGit hook、静的解析ツールといった様々な自動化ツールの恩恵を受けるべき場所だと思っています。改良の積み重ねでだいぶマシにはなったものの、知識はどうしても伝えなければならないのでコストをゼロにはできていません。

私の場合は特に、アマチュア開発者でも知っているようなこと(だと自分が思っていること)を開発を志望して入ってきた人に教えなければならないという状況にストレスを感じることが多いです。gitコマンドを使えないとか、セキュリティの基礎とか、英文資料に怯むとか、「まずログを読む」という基本中の基本*3とか。
例えば「せんぱいのいうとおりにしましたがうごきません!たすけてください!」(まずログ読めって)、「ジーッ……カタカタ……ジーッ……ふー」(screenやtmuxはおろか複数ウィンドウすら使わず単一作業しかしていない、処理が終わる間ぼーっとしている)、「うおおおおおカタカタカタカタ」(ctrl-Rとaliasと~/.ssh/configこの前教えたよね?)みたいなのが結構ダメージあって、自分の心の狭さにびっくりすることもしばしばです。

開発体制や目的意識浸透について

テクニカルなことは「周囲について」で述べたので、これは周囲が技術レベル的に問題がない場合でも発生する問題のことです。 例えば企業理念に沿っていない行動やチームとしての優先事項がわかってないように見える場合、何度言っても大切だと自分が思っていることが伝わらない場合、明らかな非効率が何らかの理由で維持されている場合が該当します。

ただこれはどこに行っても発生しうる問題で、結局マネジメント側がぶっちゃけ論というか腹をわって話す機会をどれだけ誰とどう設けるか、そしてそこから感じた必要性にどれだけリソースを割くかという話のような気がしています。ひとまず自分のチームでは1on1を厚くして、上司には条件反射的に文句を言う(ことで現場のギャップや潜在ニーズを伝える)ようにしています。リソース調達ができる立場になれば、また違った視点があるのかもしれません。

時間の使い方について

周囲の同僚や知人を見ていると、家庭を持った人が「守るべきもの」を得た代償に「自己研鑚の時間」や「かつての働き方」「輝き」を失うケースが散見されます。伸びてる人を見渡すとみんな独身だったとか、昔とった杵柄で頑張ってるけど所々水漏れ起こしてる先輩とか。これらを失うと当然失敗も増えて収入も伸びなくなって、なのに出費は増えるというけっこう辛そうな状況になるようです。20年もすると笑い話になるんだろうなということはさらに上の世代を見ればわかりますが、目の前10年くらいがだいぶ辛いのは間違い無さそうです*4

もちろん例外なく負の状況に陥っているかというとそんなことはなく、むしろ足腰がしっかりしてより輝いたという人もいます。この違いは今まで時間のつぎ込みで何とかしていたツケを喰らうかどうかではないか?というのが今の仮説です。

そして今の私の強みが「プライベートでも仕事でも技術に没頭して時間を使える」ことに少なからず立脚していることを考えると、このまま行くことは危険であろうという結論になります。プライベートで使う時間を減らすこと、時間をより効率的に使うことが喫緊の課題で、それが今年の目標に反映されています。

やりたいことと、やりたくないこと

以上を踏まえると、今やりたいこととやりたくないことは以下になります。

  • やりたいこと
    • 自分以上の専門性を持つプロとの協業
      • 教えてばかりの立場からの脱却
      • インフラエンジニア、デザイナ、品質を科学する専門家、データサイエンティスト etc.
      • そうした領域について自分で考えたくないという意味ではなく、専門家といい刺激を受けつつ建設的な議論をしたいという意味
    • 充分なコミュニケーション
      • ほぼ「時間に余裕がある」と等価
      • 不満を同期や知人だけでなく、上司や部下や利害関係者にもぶつけて議論できるだけの雰囲気と文化が必要
    • ユーザからの高速なフィードバックが期待できる
      • サーバからのフィードバック(ログ)は当然として、人間からのフィードバックこそほしい
      • リリースサイクルの速さが充分に高速で、PDCAが高速に作用できる
    • 自分が当然だと思っていること=アマチュア開発者やOSS開発者の常識が通じる
      • OSSを積極的に使っている、製品(の一部)がOSSである
      • contributeに対して変な意識を持ってない、息を吸うようにPR送れる人と働ける
    • Englishが標準語である環境での勤務
      • 世に転がっているドキュメントを「見といて」と言えるのは大きい
    • 土日を技術キャッチアップに費やしても費やさなくても良い環境
    • 機能についての議論、ユーザに提供する価値についての議論
  • やりたくないこと、あるいはどんな時にストレスを感じるか
    • 新人教育
      • GitやJavaの基礎を知らないとか、そのレベルからの引き上げをやるのはストレスが大きい
      • 業務知識も自分でキャッチアップできる人を手助けする(コツやリンク集、参考書籍の提示)くらいに抑えたい
    • 通勤に時間がかかる、通勤時の快適さが低い
    • よくわからない独自の開発体制を頑張って保守る
      • OSS開発者としての常識が通じる環境を基本的に死守したい
      • 独自運用はビルドツールなどの自動化手段によって普段の作業の延長として行えることを担保し、常識を壊すこと(特に手運用の導入)は避けたい
    • クソースをマシなコードに変えるための議論

まとまらない部分もあるので、引き続き考えようと思います。

*1:後にこれは誤解であることが判明

*2:日本、中国そしてインドの大学に共通する話で、開発で必須な知識の保有率はアマチュア開発者の方が高いと思う

*3:これを持っている新人に会ったことがない

*4:こう考えるのはルームシェアしている同居人の影響も大きそう