| @労働

海中ビデオデッキ

職業プログラマーになって 8 年の間に随分とジョブホッピングを繰り返してきたが、どこの会社でも評価が良くない。上司（非技術者であったことがほとんど）からは全く評価されない。なので在職時に昇給したということはほぼない。ペパボ時代にエンジニア評価制度が導入されてシニアエンジニア1になったときにががっと給料が上がったことはあったけど、あれは直属の上司ではなく技術責任者から評価されるという仕組みだったのでイレギュラーケースといえると思う。その後は転職時に増えた以外では全然給料が増えたことはない。据え置きが続いたりむしろ下がったことすらある。

しかし一度退職すると、同じチームの同僚や隣のチームの偉い人とかから良く思われていたことが判明することが多い。戻ってきてほしいとか、いなくなって困ってるとか。当然社交辞令の部分もあると思うが、全く役に立たないクソ野郎だったらそんなことを社交辞令で言われることもないはずなんで、ある程度は評価されていたといえるんだと思う。

なぜ在職中に上司から評価されないのか考えると、当時の上司がやってほしいと思ってることをやらないからだと思う。自分はチーム全体で効率が良くなるようにツールをあれこれしたり bot でガチャガチャやったりとか（ Developer Productivity の向上）が好きなんで、自分の動きは会社がやりたいこと、上司がやらせたいこと（売り上げが増える何か、アプリのダウンロード数が増える何か）に直接寄与していないよう見える。

前職や現職で新しくプロジェクトが動き始めるときに何は無くともユニットテストを実行できる仕組みと Docker や CI 環境の構築をガガっとやってて、誰もがテスト書いて Pull Request 出して CI パスしてからレビュー依頼してデプロイも確認環境には自動でじゃんじゃんデプロイされて（ Continuous Delivery ）、誰も（新人やプログラマーでない人含む）が簡単に本番にもデプロイできる仕組みを作ったという自負がある。こういうのは直接売り上げは増やさないけど開発サイクルを早めたりチームの生産性を高めたりしていると思うが、1秒でも早く依頼したソフトウェアを納品してほしい人からはなんか勝手なことをやってるように見えるし、それが当たり前になると特にありがたみを感じられない種類のものなので評価の対象となりにくい。問題が起こって仕組みが使えなくなったときに初めてありがたみがわかる。なので在職中には評価されない。少なくとも上司からは。

加えて、自分には理想主義的なところがあって、訳の分からない指示が来たときに「そもそもそれいまやることですか」とか「会社がやるべきなのは違うことじゃないですか」と言ってしまう。そもそも論を言うので、ミーティングに参加していても荒れたり脱線してしまったりして「こいつ今これ言うのかよ…」みたいな冷たい視線を浴びることがよくある。場をかき乱す発言をするので「こいつはわかっていない」という烙印を押されてしまう。

評価が良くないと、長く同じ会社に留まり続けるメリットが得られず転職を繰り返してしまう。正直なところ転職は面接を受けに行ったり、給与交渉をしたり、退職を打診したり、仲の良い同僚と別れたり、有給がリセットされたり、人間関係を作り直したり、健康診断の履歴が失われたり、ローンを組むとき不利になったりでしんどいことが多い。できる限り同じ職場で働き続けることがハッピーだろうなぁとは思うんだけど、会社から評価されないのは不満が溜まるし、自分のような人間（間接的にだが結構会社の役に立ってる）が評価されないのはその組織にとっても良くないと思えて転職するという選択をしてしまう。良くない。会社が自分の評価を良くせざるを得ない状況に持ち込めるくらいに腕力（プログラミング能力）や胆力（度胸）をつけなければならないんだろうなぁとは思ってる。

※ なおこの記事は退職エントリーではありません。

  1. 今にして思うと当時の自分は全くシニアではなくジュニアだった https://portalshit.net/2018/10/02/we-should-hire-junior-engineers ↩

| @読書

Ruby on Railsの生みの親、デイヴィッド・ハイネマイヤー・ハンソンの勤務先37シグナルズの本。CEOのジェイソン・フリードとデイヴィッドの共著です。とても共感しながら読むことが出来ました。個人的に響いた部分を箇条書き。

計画をやめる

  • 計画を予想に言い換える。誰にも未来のことを計画するなんて不可能。
  • 計画はあらかじめ立てるのではなく、やりながら立てる。やっていないと情報が集まってこない。

最適な規模

  • 無意味に拡張しない。規模の拡大はコストも増やす。
  • 働きすぎるのは馬鹿。ヒーローになるな。

自分たちが必要なものをつくる

  • 37シグナルズの Highrise は自分たちが必要性に駆られて作った。

まずつくる

  • アイディアは実行しなかったらアイディアのまま。
  • 金がないとか時間がないとか言い訳にならない。ベストな状態で始められることなんてない。本当に実現したいことだったら金や時間は自分で工面をつけるもの。

金を借りない

  • ウェブサービスとかは特に金が必要ない。
  • 他人の金が入ると感覚がおかしくなるし、長期的な視野を持てない。

なんでもまず自分たちでやる

  • 会社の規模はコンパクトに維持し続けるべき。
  • まずなんでも自分たちでやってみる。できなかったら人を雇う。

スタートアップという意識を捨てる

  • スタートアップには甘えがある。
  • 他人の金で好きなことをやるなんて幻想。
  • 最初から利益の出せる企業を目指すべき。
  • exitのことを考えるとユーザー本意のサービスが作れなくなる。

制約を利用する

  • 優れた作家は制約のもとで創作していた。シェイクスピア、ヘミングウェイ、カーヴァー。
  • 一度にサービスに携わる人間は一人か二人に限定し、機能は絞る。
  • 芯から作り、本質的でない細かい部分は後回しにする。

副産物

  • 企業は自分たちが気づかないうちに副産物を生産している。木工所はおがくずを売った。37signalsはGetting Realという本を副産物として売った。

すぐリリース

  • 不完全な状態でも最低限な条件をクリアしたらすぐにリリース。

会議をやるやつは馬鹿

  • 会議は時間の無駄。やっても7分。
  • 会議には準備が必要だが、十分に準備することは不可能。
  • 1時間の会議に10人が参加したら、10時間の生産性が犠牲になる。会議にそんな価値はない。
  • 会議は新たな会議を生み出すだけなので不毛。

一人で作業する時間をつくる

  • 電話とかメールとかシャットアウトする時間を作らないと生産性は上がらない。
  • せめて一日の前半か後半のどちらかは一人作業モードに設定すべき。
  • 連絡手段は電話やチャットなど即時対応式のもではなくなるべくメールにする。

そこそこの解決策

  • 完璧な解決を求めようとしない。そこそこの手段で済む問題にはそこそこの解決策を。問題があれば後から良くすればいい。

タスクは分割する

  • 長大なタスクリストは気が滅入るだけ。
  • 100のタスクを10ずつに分解すれば心理的に楽になる。

はまったら人に見てもらう

  • 意固地になって無駄に時間を費やすとコストに見合わなくなる。
  • はまったら他の人に冷静な視点でレビューしてもらう。

寝る

  • 睡眠不足は創造性を損なうし、士気が低下する。間違いも犯しやすくなり、他人に不寛容になる。いいことは一つもない。

真似ない

  • コピペコードは理解が伴わないから、いつまで経ってもオリジナル作者にかなわない。

社員が一緒の国に住んでる必要はない（デイヴィッドは入社当初はまだデンマークにいたらしいです）とか他にも面白いところもあるんだけど、英語がしゃべれないとこの辺は僕らには当てはまらないですよね。あと会議を極力しないってのは理想だと思うけど、受託開発というかホームページ制作みたいなお客さんがいる仕事してたら打ち合わせはしないといけないわけで、なかなか難しいでしょう。

でも電話や会議などは確かに生産性を損ねていると思う。電話なんていきなり日常業務に割り込んでくるわけだから。電話は予約制にして欲しい。何日の何時に電話したいのでお願いしますみたいな感じでメールしろや。

雑談の排除とかも大事ですよね。僕はなるべく仕事中は雑談しないようにしてる。だからといって生産性が高いかと問われれば疑問なんだけど。でも雑談とか会議とか打ち合わせとかやって仕事した気になってる人は多いと思う。例えばこの本では人の雇い方のパートで、仕切り屋を雇うなみたいなことが書いてある。仕切り屋は会議好きで、自分の仕事を作り出すために会議を開きたがる。まったく何の価値も生み出さないのに、会議に参加することで会社に貢献しているふりをするわけですね。こういうのは本当に最悪。

37シグナルズの発想は、ピュアに作り手だけで会社を動かそうという風に読めました。広告とか営業とか意味ないというか、頼りにしないという考え方。本当に良いものを作って自分たちのファンになってもらえたらサービスを使ってもらえるようになる。特にウェブサービスとかはそうですよね。広告とかPRとかは金ばかりかかって効果がないということに気づかないと。有名な雑誌や新聞に取材してもらうことも否定していますが、折角ユーザーと直接結びつけるのがウェビサービスを提供する企業のメリットなんだから、そこにいちいち旧メディアや広告屋を介在させる必要はないですよね。またセールスマンを省きサポートも極力エンジニアが行うことで顧客の要望が直に作り手のところに伝わる（とはいえ本書では逆に顧客の要望には応えすぎるなとも書かれてはいます。その辺は買って読んでみてください）。

シンプルに、極力自分たちで会社を動かそうとすることで、大企業が抱えるいろんな問題が回避できるというのがこの本のエッセンスでしょう。Railsはお触り程度のことしかやってないですが、CakePHP（RailsのPHP移植版）越しにそのすさまじさというかすごさは実感しています。こういうすごいフレームワークがあるいまは、本書で掲げられていることは単なる理想や夢物語ではなく十分実行可能なものであると感じます。自分たちだけでなにかをやることが十分に可能。

とにかくなにかつくってみよう、と思わせられる本でした。Ruby on Railsの勉強を本格的に始めてみたいと思います。