nogahighland

グチばかりですみません

転職１ヶ月

ポエム

ある程度の中企業から正社員30名程度のスタートアップに転職し、１ヶ月が経った。

いろんな文化の違いを目の当たりにして戸惑いつつも、今までの自分に足りなかった経験を得られそうだという期待を感じている。１ヶ月の間で感じてきた文化の違いをつらつらと書いてみようと思う。

良いところ

誰にも負けない強みを持っている人が多い

人数が少ないから、エンジニアはiOS / Android / フロントエンド / サーバサイド(兼インフラ)に関して自分は社内で一番これが強い！というブランディングができている人が多いと感じた。また、その自負を持って積極的にいろいろ学びに行ったり発信したりするので、とても頼りになる人が多い。

また、デザイナーがグロースなどのビジネスに強く関与し、プロダクトの哲学を形作るところに関わっているので作ろうとするものに納得感がある。ここはスタートアップでも他社より強いところだと思うし、そういう社風に惚れ込んで転職したので、エンジニアとしてももっとエンドユーザーの話を聞きに行って、深層心理上で満足できる＝良質なUXを提供するということに深く関与していけるチャンスだと感じている。

技術に対して良識がある

  • 他人のコードレビューを理由に品の悪い批判したりするようなことは無い。 Pull Requestを通して純粋にコードに対するアドバイスをしあって気持ちの良いレビュー文化が根付いている。前職ではオラオラ実装がまかり通っていた所も結構あったので、こうしたほうが良いよね、的な話がスムーズに通じるのはストレスフリーで良い。
  • 技術的負債やシステムパフォーマンスに対して日常的に課題意識をもち、対策を講じている。

知識をオープンにする

知っていること、得たことで、他人のためになることはなんでもQiita::Teamに書いている。特にユーザーインタビューをした記事は面白くて、一つの機能に対してインタビュイーの生活が深く関わった体験談が詳細に語られているのがとても新鮮である。歯に衣着せぬいいぶりも良くて、他人行儀じゃない仲間意識が前提にあるから安心して好きなことを言える文化なんだと思う。とにかく生の声が多くて、読んでいるだけで刺激にもなる。

プロダクトが少ないぶん、徹底的に最適化を考えている

  • GitHubにISSUEがたくさんあり、すごい勢いで消化されていっている。SlackのGitHubチャンネルに様々なリポジトリのコミットやレビューが死ぬほど流れてきている。

フランク

社長はじめとする創業者陣は歳が近いので、雲の上という存在では全く無い。フラットに接してくれるし、みんなも普通にフラットに接している。そんな人達でも、産みの苦しみを味わって成功したスタートアップに育て上げてきた苦労は並大抵ではないはずなので、心の奥に畏怖の念を隠して接している。

遅刻という概念が無い

朝が苦手な自分だが、今の会社では同じ出社時間でも早いほうになったっぽい。前職では電車遅延や申請休暇以外で1秒でも打刻が送れると半日分の給料が引かれてしまうというスリルがあったが、今は裁量労働制なのでちょっと疲れが溜まれば朝ゆっくりできるという安心感がある。まぁあまり朝がズルズル遅くなっていかないようにはしている。

悪いところ

結構夜遅くまで残る

前職も昔は結構平気で終電近くまで働いている人がいっぱいいいた。もちろん一人ひとりの責任範囲が広かったりパフォーマンスも高いので、無駄に仕事をしているわけではないし、残っているぶん早くプロダクトが進化している。

ただ、どうあっても夜遅くまで働くと疲れるのは事実。健康は損なわないように仕事をしたい。

深夜・休日対応

  • 悪いカテゴリじゃなくて単純に自分がなんとかしないと困るなー、という心配。
  • インフラを少ない人数で運用しているので、深夜・休日のサーバー対応なども結構発生しているよう。深酒で気絶睡眠してしまうことがよくある自分は、ちゃんと責任を果たせるようにしないとヤバいという気持ちがある。

ただびっくりしたところ

ツイッター名で呼び合う

本名とはおよそかけ離れた名前で呼び合うという文化にちょっとびっくりしている。結構シリアスな場面でもそう呼び合うのでまだちょっとむず痒い時がある。 同時に、そういう名前を自分は持ち合わせていなかったので、本名で呼ばれるとちょっと恥ずかしい。

あんまり新人扱いされなかった

少ない人数で親密度の高いコミュニティなせいか、いろいろ手取り足取り教えてくれるということも特になく、たまに困っていたら教えてくれる程度である。例えばコーヒーメーカーの使い方（粉の場所とか）、Slackの入ったほうがいいチャンネル、社内手続きのサイト、名刺の発行、夏季休暇制度、入社◯ヶ月面談等…の案内があまり無いところ。11時にB'zのBGMが突然流れはじめたときがあって、それが週１回みんなで行うお掃除タイムだとその時知った。

制度面は最低限説明があるけどちょっとギリギリだったりする。その他必須じゃない事項は自分でいろいろ情報を漁らないと永遠に知らない可能性もある。幸い漁り癖のある自分はなんとかキャッチアップしつつある。

所感

Railsも初めて触るレベルで採ってもらってまだほとんど貢献できていないのが悩みの種。自分が会社にとってプラスになったと思えるような強みを開花させていきたい。特にやっぱりサーバとクライアント（Web/iOS）触れることでのスピード感や、ユーザー体験に対するこだわりというのを活かして実のあるアウトプットを量産できることが自分にできる貢献なのかなとは感じている。

ぜひ、こういう姿になりたいと思っている。

ninjinkun.hatenablog.com

ただ、その道中で色々な刺激を受けて興味が出すぎてしまうと、とかえって路頭に迷ってしまう。 あれこれ手を出した挙句一体自分は何も身についていない。みんな凄いのに、と。

http://in.fablic.co.jp/entry/feedbackin.fablic.co.jp

「◯◯をやったほうがいい」というフィードバックが重要と思うなら、「◯◯をやめる」を見つける必要がある。

これは社内の哲学者みたいな方が書いたエントリーだけど、目が覚めるような金言の連続だった。贔屓目無しに良エントリーなんだけど、そういう思想を持った人と一緒に働けるというのは幸せなことである。

プロセスとアウトプット

仕事論 不平・不満

華々しい成果というのはその煌めきの10倍、100倍泥臭い仕事が多い。

システムという仮想世界と、大工といった実世界の違いはその複雑性が目に見えるか見えないかの違いなのだが、ユーザーからはもちろん、管理者にも見えないために「作っちゃいなよ」とか平気で言われたりする。さらに、夏目漱石が

世の中に片付くなんてものは殆どありゃしない。一遍起った事は何時までも続くのさ。

と言っていたりもするように、作りっぱなしのものなんて殆ど無い。思いついたように「機能追加してみようぜ」なんてことはざらにある。

それ自体は何の問題もない。創造性が溢れてきて具現化したくなることは、人間冥利に尽きる。ただ、作るにあたっては受け手にその責任を全うしなければいけないと思っていて、そのためには「作る」作業が効率化されているべきだと思っている。

何もコーディングだけではなくて、知識共有の習慣化だったりソースコードの標準化だったり、自動化だったりする。

  • 個同士は編隊されて合議したルールに基いて行動することで相乗効果を発揮する
    →チームメンバーがお互いのナレッジを共有しあうと、効率的だ
  • そのためにリーダーやマネージャが組織を作る
    →リーダーはそういうチームづくりを促進すべきだ
  • その先にアウトプットがある
    →そうすると早く作れるだ
  • チーム同士も個と同じ
    →チーム同士も共有するといいだ

あんまりにも状況が酷いとこんなふうになってしまうのだが、実はしれっと効率化して白鳥のように優雅に良い物を作りたいですよねって話です。

「○○性」「○○化」という言葉遣い

仕事論 不平・不満

自分は「○○性」「○○化」という言葉遣いが結構好きである。いろんな具体例がひっくるめられていて、一言で5点セット・10点セットプレゼントした気分になるからだ。 でも、これが伝わりづらいことに気づいてきた。

反復性のある手順は資料化してアクセス容易性の高い場所に置いてください。

とか言うと「何をすればいいんですか」と言われやすいことに最近気がついてきたのだ。

でも、だからといって

今教えてくれた話、他の人も必要かもしれないからどこかに書いてURL共有して

と伝えると「次に教えてくれる話」はどこにもシェアされず終いだったりする。

「ドキュメントを書きましょう」の話であれば、自分や他の誰かが残してくれたドキュメントにお世話になったり、自分が教える手間を省けた体験が無いとダメなのかもしれない。自分はドキュメント書け書けとうるさく言われたり、辞めた人が残していってくれたものに感謝しているうちにいつの間にかドキュメントジジイになりつつある。

nogahighland.hatenablog.com

500回教えられないと人は覚えないという話を読んだことがある。

これは恥ずかしながら自分もそうで、新卒の頃は先輩方には繰り返し繰り返し教えてもらって、その度初めて知ったようなアホ面を晒していたのだと思う。具体的な話を500回聞いて、その共通項が紛れなくなった時に教えられたことが抽象化されたのだと思う。

でも、新卒なら覚えることが多すぎてそうなるかもしれない。でも、いくらなんでも5人のオトナのチームメンバーと日々情報共有するのに一人500回も教える気になんてなりゃしない。3回でも大変である。

だから教えられる側もできるだけ

今教えてくれた話、他の人も必要かもしれないからどこかに書いてURL共有して

という話を

反復性のある手順は資料化してアクセス容易性の高い場所に置いてください。

というふうに抽象化して考えてもらいたいものです。

ナレッジの蓄積

仕事論 不平・不満

特定の分野に精通する一人の知識というのは狭いし、人は集中した時間をぬけ出すと忘れてしまうもの。だから、知識を組織的にストックして、いつでも引き出せるようにする。

教える側

  • 誰かに対面で共有する
  • 反復性がある作業の方法はストックとして残す
    →これをしない人が多い

教えられる側

  • 一度自分で咀嚼する
  • 課題を記憶する
  • ストックの場所やキーワードを記憶する（課題に対して検索インデックスを張る）
    →これをしない人が多い

教える側

まず、アプリなりサーバなり、ある分野が任されている人は当然ノウハウが多く蓄積されれている。それを他人に説明するのに苦労した、または教えようとすると苦労しそうだ、そんな時に 一度知識をストックしませんか？ Qiita TeamでもGoogle Documentでもいい。それさえやっておけば、２番めに教えるときにはリンクを教えれば良くなるはずなのに、と思う。

または、数カ月前経った後にそれを覚えている自信が無い時に同じことをすれば良い。

でも、一時の間を惜しむのか、これをしない人が多い。

ついでにこんなこともつぶやいたな。

脱線しまくりですいません。

教えられる側

別に「教えてもらう」という気じゃなくても、日々人と接すればたくさん教えてもらう機会があるし、流れてくる情報を眺めているだけでも情報は受信している。それを自分の身とするためには、一度大雑把にでも咀嚼していることが大事になる。一度で全てを理解できるわけじゃないから、ちょっとした待ち時間に見直してみたり、咀嚼しきれなかったパーツを電車でググッて「ふーん」とか思ってみたりする。そうやって徐々に身になっていく。

ちゃんと覚える必要がある情報というのは、言い換えれば 課題の解決策 で、課題意識を持っているから覚えておこうと言う気持ちになる。「課題」というと大げさだけれでも「なんかに使えそうかも」とかいう漠然とした課題だっていい。経験上、 絶対使える時が来るから。

大事なポイントは

  • 課題を覚えておく
  • 解決策の場所を覚えておく

という２つだと思う。

何も全てを完璧に覚えなくても良くて、むしろ人はガンガン忘れる。

でも、忘れやすいもの・忘れ難いものというのはちゃんと区別したほうが良い。ガンガン忘れていくものはディティールの話であって、咀嚼して抽象化した話というのは驚くほど高速に呼び出せるものである。

大事なのは、100%のうち1%でもちゃんと覚えておくということなのよね。