最近忙しかったのでKPTした

４月末～６月上旬までかなりタイトなスケジュールのプロジェクトを担当していたのだが、そろそろ終わりが見えてきたので個人的な仕事の進め方に関するKPT

Keep

• １番リスクが大きくて難しい所の作業を１番最初にやることで心理的な余裕が確保できた
  • 他のタスクも優先度の高さと技術的難易度を優先して進めることであとで設計を見直したりする余裕を確保することができた
• 労働時間を延ばさないと間に合わないことが分かっていたが、終業を延ばすのではなく始業を平均2時間ほど早めて対応した
  • AMはmeetingが殆どないので集中して作業する時間が取れたので１日全体で見たときの作業効率がかなり高まった
  • 終業を延ばさなければいけない場合であってもAMに貯金があるのであまり終業は遅くならなくて済んだ日が多かった（退社時刻は平均して21時前後、1番遅い退社が23時過ぎだったと思う）
• 色々あってプロジェクトの途中でリリース時に積むべき機能量の折衝をしないといけなくなったが、他のメンバーが判断できるレベルの十分な説明はできた（と思う）
  • プロジェクト始まる前にこれができればbetterだったが今回は色々あったので仕方がない

Problem

• 5月中旬ぐらいまではうまくやっていたがその辺りから精神的・肉体的に疲弊してミスが増え生産性が落ちた
  • 「ちょっと疲れてきたかな？」と思った辺りで無理をしない、疲れを残さない対策を講じるべきだった
• プロジェクトの全貌を掴んでいない状態から作業に入ってあとから出てきた追加タスクにうまく対応できなかった
  • 「ちょ、それもやるの！？」みたいなのがいっぱいあとから出てきたが、これは自分ではどうにもならなかった気もするが今考えたら早い段階でプロジェクトの全体像を全員が正しく共通認識として持つように提案をすべきだった
• プロジェクトの目的とスケジュールがなぜ決まっているのかを正しく認識していなかったので感情的に納得できないまま自分が作業しておりストレスを感じながら作業していた（プロジェクト序盤
  • 最初に聞いておくべき。自分が入社する前から存在していたプロジェクトで回りは暗黙の了解みたいなので知ってたようだが、それを知ってそうな人全員に問いただせばこの辺は分かったはず。

Try

• 自分が理解できてきない部分はプロジェクトが動き出す前にステークホルダーに確認すべきだった
  • とはいえ、仕事なので理解できなくてもやらなくてはいけないケースもある。そこは大人になって対応したい。（とは言え今回は自分が入社前から決まっていたことなので特殊ケースだと思う）
  • こういう事態を防ぐためにもプロジェクト発足時から積極的に不明なことはクリアにしていくようプロダクトマネージャーやプロジェクトマネージャー、経営陣に働きかけていきたい。
• どんなに余裕がないときでも適度にサボる
  • 仕事しすぎた
  • 仕事しすぎると生きてるのが楽しくなくなって「なんで生きてるんだっけ？」「自分ってこの会社で何がしたいんだっけ？」的な哲学的なことを考え始めて時間を浪費してしまうのでよくない。
• 自分が忙しいからといってイライラしない
  • ごめんなさい
• 自分がだけがつらいと思わない
  • 考えてみれば今回のプロジェクトは色々あって関係者全員が何らかの形で辛かったのではないかと思う
• リソース不足かどうか？は常に気を配り、足りなくなる前にヘルプを出す
  • 今回は割とギリギリのタイミングでヘルプを依頼して間に合った感じだがもっと早くヘルプの声をあげていても良かったのではないかと思う。
• プロジェクトの進め方についてよくないと思う部分は積極的に改善案を出す
  • 全くの新機能が追加された上にサーバサイド、ios、webの整合性を完璧に取った状態でリリースしなければならないプロジェクトはまだ会社としても経験値が低い。やり方は都度考えていく必要がある。

コード改善 meetup #1でLTしてきた

コード改善 meetup #1 というmeetupが新たに始まると聞いて、エモい話ばかりブログに書いてる身として参加するのが義務であろうと思い、LTしてきた。

発表スライドはこちら。

speakerdeck.com

内容としては大して書いていない。これまで自分が所属してきた開発組織で体験してきたことをベースに、コードレビュー運用で起こりがちな問題と、それに対処するためのちょっとしたtipsを紹介した。

このmeetup、工夫されていた点として、単に発表者が発表して終わるだけではなく、その後発表された内容について参加者全員がディスカッションをする時間が確保されていた。

自分の発表の内容は、大抵どこの組織でも共感されやすい内容だったこともあったのか、いい感じに盛り上がって、

• 「わかる」
• 「うちも同じような問題がある」
• 「うちは書いた人以外が全員でレビューしてる」
• 「全員はつらくない？」
• 「書いてるものによる？」
• 「うちはそもそもレビューの文化がない」
• 「ところでみなさんのチームって何人ぐらいのチーム？」
• 「レビューコメントのつけ方ってすごく気を遣うよね。絵文字を積極的に使うとか」
• 「レビューでdisり合いしてるんだけどそれでもうまく行ってるので特に気を遣ってない」

など様々な質問や意見が飛び交った。

参加者のバックグラウンドはSIerや自社サービス会社など異なっていたようだが、どの開発チームも同じような問題は多かれ少なかれ抱えているようだった。

他の発表についても色々な議論が飛び交って面白かった。その一部については参加者の一人の方がまとめてくれているのでリンクしておく。

blog.mogmet.com

この手の答えが出ないテーマをもとにディスカッションするのは面白いのだが、うまく自分が感じている課題を整理して参加しないとただ「うちもこういうのが大変でさ～」「うちもだよ」という不満を共有して終わってしまう危うさもあるように思う。

建設的な議論をするためには「つらい」とか「しんどい」という私情をこらえて、問題を客観的かつ広い視点で捉えて議論する必要もあって、今後参加する時には気を付けていきたいと思う（そういう意味では今回は非常に参加者の皆さんは建設的な議論をされていて大変よかったと感じた）。

勉強していること2016年4月版

• 4月に入ってから完全に勉強が停滞してしまったので５月に入ってから立て直している
• 花粉症・睡眠障害・肩こりなどの体調不良がずっと続いていた上に、新プロジェクトが始まったりして時間が確保できなくなっていたが、５月連休に入る頃には立て直した

CS

• ヘネパタ本は読み進めていくうちに前提知識が不足していると痛感し、一旦置いておいてパタヘネ本を読む方向に変更。上下巻買うと8000円以上とか結構痛い出費だが圧倒的に読みやすい。

Elixir

• 進捗なし

Golang

• 仕事で使う可能性が出てきたので趣味ではなく割と業務時間も使って勉強し始めた
• web apiの実装に使うというよりは重たい処理をするworkerやbatchの実装に使う想定

筑波大学大学院コンピュータサイエンス専攻 専攻公開・入試説明会に参加した

筑波大学のキャンパス来た。緑多くてよい。

www.cs.tsukuba.ac.jp

基本的に、筑波大学の学部向けの説明会だったようだが、学外の人間も参加できたので話を聞いてきた。

筑波大学の特徴として、

• 国内大学のCS専攻としては講師の数がかなり多い
• 講師が多いのでCSの分野でカバーしている範囲がかなり広い
• 希望すれば同じく筑波にある産総研の研究所で指導を受けて研究ができ、筑波大学の単位として換算される
• 社会人特別選抜枠があり、定員は1回の入試で1名〜2名だが、過去においては6人受験して5人入学してたりすることもあるので定員を超えて採用することもある模様 www.cs.tsukuba.ac.jp
• enPiT（Education Network for Practical Information Technologies）のビジネスアプリケーション分野での提携大学で、PBL（Project-Based Learning）形式での授業がある
• 留学生とか企業からの研究生受入が盛んなので社会人が入学しても違和感ないらしい（説明会会場にいた４回生に聞いてみた）

仕事に依存しすぎない方がいいなって思うようになった

エンジニアとして働いていると、どうしても「面白くない」と感じるような作業もやらなければならないことがある。1から10まで、コードの詳細レベルまで明らかに内容がやる前からわかる単純作業などが自分の場合は該当する。明らかに繰り返しの作業になっているものはできるだけDRYに寄せるようにリファクタリングして、そこで自分の技術的な満足は満たすように努めているが、いかんせん時間も無限にある訳ではないし、すでに大量のコードベースが存在している場合にはリファクタリングも時間がかかる。それにリファクタリングより優先度が高いタスクは山のようにある。だから大抵はリファクタリング自体をタスクとして計上することはなかなかできない。

自分はリファクタリングは好きな方だ。コンピュータサイエンスのバックグラウンドがない自分には、計算機的に良いパフォーマンスが出せるコードを書くよりは、可読性やメンテ性の高いコードの構造を考える方がまだ幾分とっつきやすいというか身に着けやすい領域だったからだと思う。

ただ、リファクタが得意です、だけだとソフトウェアエンジニアとしてはそのうち使い物にならなくなるだろうな、とかなんとか。そういうことを30歳になったことを境に考えるようになった。綺麗なコードに書き直すという作業は一円も価値を生まない。いくら技術的負債満載だ、と言われても、ベンチャーの世界では価値のあるサービスを最適なタイミングでリリースすることに心血を注ぐ必要がある。良い機能をリリースして、ユーザーからの信頼を高め、新しいユーザーを獲得し、投資家からの注目を集めることこそがベンチャーにおいては重要だ。それに比べればコードの良し悪しなんてのは二の次三の次の問題だろう。

とは言え、たまには飽きて本当にやる気がなくなることがある。そういう時は自分は以下のように考えるようにしている。

1. 仕事は仕事、趣味は趣味である。満足できないならプライベートで満たせ。

これは自分も20代半ばのころに陥っていたのだが、例えば高度な欲求である「尊厳欲求」や「自己実現欲求」を仕事という手段だけで満たそうとしないことである。

仕事は「自己実現のためにするものだ」というようなことを考えている人もいるかも知れないが、幸いなことにソフトウェアエンジニアは仕事以外でもPC一台あればコードは書ける。しかもタダで。多くの人に使ってもらえるソフトウェアを書きたい、という場合でも余暇の時間のOSS活動でそれを実現できるチャンスがある。githubだってタダで使えるんだし。あと新しいことを勉強したければいくらでもネット上に学習リソースが転がっている。考えてみればこれほど恵まれているこというこは他の分野ではなかなかないのではないだろうか。

自分の過去の転職理由は、おおむね「優秀な人と仕事をして自分を成長させる機会を作りたい」とか「スーツでExcelな環境ではなくバリバリコードが書ける現場で技術を高めたい」みたいなものだった。

しかし、今考えれば、それは少し間違っていたようにも思っていて、別にそれらは転職という手段を使わなくても実現できた訳だし、転職自体がそれらを実現できる銀の弾丸という訳ではない。逆に、転職というか仕事自体だけに解を求めてしまうと、仕事で行き詰ったときに活路が見いだせなくなってしまう、が、仕事はしないと自分の食い扶持がなくなるので辞める訳にはいかない、みたいな絶望と強制力の狭間で苦しむみたいな状況が発生してしまう。

幸いにして今の職場は割と自由度が高いので割と自由にやりたいことをやらせてもらっているが、過去においては何をやっても全く何も変えられない時もあって（当時の自分の未熟さも関係していたが）、そういう時に仕事以外に自分の欲求を満たす代替手段を仕事以外に持っていないのは、やはり危うい状態だったと言わざるを得ない。

なお、最近はrailsをちょっといじる程度のショボいgemを3つぐらい作った

2. 仕事の目的は金銭を得ることが目的であり、それ以上に得られるものがあったらラッキー、ぐらいに考える。

仕事に対しては、もちろん自分のベストは尽くすが、求めるものとしてはこれぐらいの意識でいた方がよいのかなと最近は思うようになった。

学生時代から「日経ビジネスアソシエイト」とかを愛読していてやたら意識が高かった新卒の自分に怒られそうだが、結局仕事のポジションはその辺に置いておいたほうが、心理的な安定性を考えるとよいのではないかと最近は思う。

先に書いたことと関連するが、仕事以外でいくらでも「得る」方法はあるのである。だから、仕事がうまくいかなくても他のことでカバーする、という体制は人生において重要なのではないかと考えるようになった。

だから仕事に多くは求めない。逆に、金銭以外で得るものがあったとしたら、それはとても幸運なことだと思った方がいい。仕事がつまらん？ちゃんと給料出るんだからいいじゃないか、と考えることも時には必要だ。新卒当時の俺よ、分かってくれ…

3. 仕事がつまらんのはお前が悪い

一方で仕事がつまらんのは自分が悪いのではないか？という視点を持つ。自分が面白くする努力を怠っているのではないか？という感じに。

一例だが、「今の仕事で改善できることはないか？」という視点で自分ができることを探し、実際に改善するために動いてみると、それを改善するとこと自体が結果的に自分の満足につながるケースもある。

実際、今の会社に入ってから、所属したチームの仕事の進め方を色々変えてみたのだが、その改善自体が自分にとってはそれなりに面白いものだった。これまで当たり前にやってきていたことがないとどういう問題が発生し、それを改善するためにこの手段は必要だったということの再認識にもつながったし、逆にそれを阻害するものは何なのかという発見もあった。だから、もう一度同じことを導入するときはもっと上手くできそうだという自信にもつながった。

ハイコンテクストな仕事とローコンテクストな仕事

追記

書いてからしばらくして読み返してみたら「ハイコンテクスト」と「ローコンテクスト」の使い方逆じゃないのかもしれないと思った。「仕事の成果を説明する」ためにハイコンテクスト文化の中で技術的な要件は抜きに、実現するビジネス要件だけの説明が求められる仕事と、ローコンテクストな文化で技術的に細かいところまでかなり突っ込んで説明が求められる仕事、という意味合いで分けたつもりだったが、「要件が細かく決められる」とかそういう観点だと意味が逆転するような気がした。いずれにせよ日本語に存在しない概念は使うもんじゃないと反省した…

以下本文↓

---

自社サービス会社のエンジニアがやるのはだいたいハイコンテクストな仕事のような気がする。私だけだろうか？

少なくとも私が今まで仕事で携わってきた仕事はすべてが「特定のビジネスに特化したシステム」だった。つまり、Aサービスを動かすためのシステム、B企業の社内だけで使われる業務システム、とかそんな感じだ。

そういう仕事で作るwebアプリなりバッチなり画面なりは特定のビジネスモデルとか業界の慣習に特化しており、そういった要素に関連するコンテクストが多分に盛り込まれる。プログラムのソースには業界用語もたくさん含まれてくる（余談だがRestaurantのスペルを正確に綴れるようになったのは飲食業界向けの仕事をするようになってからである）。

ハイコンテクストな仕事において、ビジネス要件は常に毎回異なる。全く同じものを２個作るほど余裕がないというのもあるしそもそも無駄なので我々エンジニアは概ね反対するのだが、サービス開発の場合、要件には常に新しいビジネスモデルや機能が反映される。 その要件を噛み砕いて、予算・スケジュール・人的リソースなど、いろいろなものをパズルのように組み合わせて開発していく。それがハイコンテクストな仕事の特徴といったところか。

時に、知り合いのとあるエンジニアが「サーバーサイドの仕事はDBとjsonを変換する仕事」と言っていた。

REST APIを実装する場合、極論すればそうなのかもしれない。 もちろん、どういうレコードを取得してどのようにjsonを作るかというビジネスロジックは毎回異なるし、やるべきテスト内容も変わってくるわでなんだかんだで毎回苦労しながら実装している。 だから、個人的には毎回違うことをやっているなと思っていたのだが、見え方によってはDBとjsonを変換している、というシンプルな言葉で表現することもできるのかもしれない。

逆に、シンプルな言葉で表現されない、複雑で変化の多いエンジニアの仕事はなんだろうか。

自分の少ない経験から考えると、真っ先に思いつくのは研究職。それこそメーカーの研究所で開発しているような人たちは、コンテクストのレベルは様々だろうが、少なくとも特定の問題だけでなくローコンテクストな普遍的な問題も取り扱っている気がする。

この場合、求められるスキルは、誰かから与えられる要件を噛み砕いてそれを実装するスキルよりは、自分で問題を定義して、その問題を解くためにあれやこれやのアプローチをして解決していくスキルのような気がしていて、それは多分自分がやっている仕事の仕方とはだいぶ違うんだろうなぁということはなんとなく想像がつく。

考えてみれば自分はそういうローコンテクストな仕事をしたことがなかった。すべて誰かに決められた要件に従って開発をしてきた。

• 横顔でも人物を特定できる顔認識アルゴリズムを考える
• 特定の匂いをデジタルデータ化してまったく違う場所で再現する方法を考える
• 大量のデータをほぼリアルタイムに処理する分散処理基盤のアーキテクチャを考える(Apache sparkがすでにあるやんというのは置いといて）
• AWSのVPCのようなprivateなネットワークでの利用に限定したlinuxサーバ間のデータ通信に特化した効率的なネットワークプロトコルを考える
• 現代のマルチコアで大容量キャッシュを積んだCPUアーキテクチャに最適化するコンパイラを開発する
• 大量のjsonをやり取りすることに特化した新しい通信プロトコルを考える

というような比較的ローコンテクストでいろいろなアプローチが考えられるような仕事をすると、一体どういう世界が見えるのだろうか。 いつかはそういう仕事もしてみたいが、コンピュータサイエンスの学位すら持ってない自分にできるのだろうかという一抹の不安はありつつも、一方でいくらでも勉強するための資料はあるので余暇の時間の独学でなんとか突破できないかということもいろいろ考えている。

トレタに入社してから3ヶ月経ったので所感など

本日で3ヶ月間の試用期間を終了し、正式雇用になった。

上の写真はトレタのオフィス。いつもはエンジニアがカウンターの上にPCを置いて立って仕事したりしている。

年度末という訳でもないのだが、いい区切りなので、入社してからの3ヶ月でこれまでに自分がやったことを振り返っておく。

やったこと

開発フロー整備

• サーバーサイドチームのslack channelを作った
• 開発支援用のhubotを導入して以下のpluginを入れて開発支援に使うようにした
  • hubot-reviewer-lotto
  • hubot-deploy-builder
  • hubot-cron
• サーバーサイドチーム定例会を導入した（ついでに議事録のフォーマットも決めて定例会までに各自の進捗を記入しておく運用にした）
• 一人だけが担当していたレビューをチーム全員で分担してやるようにした（前述のhubot-reviewer-lottoで公平に割り当てている）
• 不定期だったデプロイを週1回決まった曜日の決まった時間にやるようにして、いつまでにマージされたPRがいつdeployされるのかを明確にする１周間単位の開発フローを整備した
• 既存コードのspecの書き方が微妙だったのでrspecガイドラインを書いてrspec3な書き方をメンバーに啓蒙した（あとDRYにして再利用性を高める方法も）
• jenkinsで[ci skip]ってcommit logに入れたらbuildをskipするplugin入れた(GitHub pull request builder pluginを使ってなかったので）
• CI時にCoverageレポートを残すようにした

Railsのコード整備

• Bugsnag入れてRailsのエラーをslackに通知するようにした
• rails-erdを導入してER図を生成してesa.ioに置いてあるdocumentに貼り付けた
• bulletを導入してスロークエリを駆逐した（あまり無かったけど）
• specでviewの内容をほとんどチェックしていなかったのでrspecのconfigでrender_views = trueにしてviewでエラー出ていないかだけでも検知するようにした
• 多言語対応のサポートのためにi18n-tasksを導入してlocaleの設定漏れを検知できるようにした
• ローカル環境でメール本文をチェックする方法がなかったのでletter_opnerを導入してブラウザでメール本文を確認できるようにした
• config/*.yml系の設定ファイルを整理してRails.envごとにどの値が使われているかわかりやすくした
• json生成にjbuilderを使っていたのでactivemode-serializerを導入して新規に作るjsonについてはこちらを使うようにした
• やたら時間がかかるspecを特定してファイル分割したりテスト内容を最適化するなどして高速化した
• 時間帯とか条件に応じてたまに落ちるspecを修正した

機能開発

• sidekiq-cron + SNS + SQS + shoryukenで非同期で複数サーバでの分散処理を行うバッチを書いた
• 特定のmodelが更新されたらsidekiqでSNSにpublishするconcernを書いた
• Bugsnag入れて見つけたバグを結構なおした
• 管理画面がいろいろ危なかったのでsubmitボタンにdata: {confirm: '消していい？'}とかdata: { disable_with: '送信中...' }みたいなのを入れまくって安全にした
• 管理画面からシステム系の設定を色々いじれる画面を追加した
• 手運用でサポートしていた社内業務のいくつかを管理画面からできるようにしてエンジニアの負担を減らした

その他

• 新機能の要件定義や設計
• 営業同行して、実際の営業でどのようにお客様にトレタを説明しているかを見せてもらった
• サービス連携している他社との打ち合わせに出て連携部分の仕様調整とかをした
• 「SEOみたいにwantedlyの求人タイトル変えてみたら何かいいことあるかも」という雑な提案をして文言変えたらちょっとPVと応募が増えた
• slackに黄色い象さんのアイコンを追加した

仕事以外

• shoryukenをいじっていてqueueの名前にsymbolを使うと挙動がおかしくなったので簡単なPRを出して無事マージされた(これが人生初のOSS contributeになった)
• railsのソースを読んでいて思いついたgemを2個納品した github.com github.com

commit logや日報を見ながらまとめてみた。

この3ヶ月という期間だけ見ると、受託開発をしていた頃と比べるとコードを書く量は減った印象で、代わりに開発体制の整備やこまごまとしたコードの整備をしている時間が結構長かった。自由にやらせてもらえたので「これやっといた方がいいな」と思うことは一通りやっておいた。

トレタのサーバサイドチームは現在正社員3名 + 業務委託1名の計4人のメンバーで開発している。 自分が入る前は3人だったから、まだチームとしての開発体制が確立していないようだったので、今後人数が増えても破綻しないように開発フローの整備もやらせてもらった（というか勝手にやったw）。3ヶ月あれこれやってみて、今はだいぶ以前と比べるとチーム全体のスループットが上がったのではないかと思う。今後も継続して開発チームの仕組みづくりの改善をしていきたいと思う。

自分が入社する少し前まで、トレタは主なクライアントであるiPadアプリの機能開発やUI改善を中心に開発が行われてきたが、今年に入ってからはサーバサイド側で完結する開発タスクが増えてきている。サービスの成長と開発チームとしての成長の両面に貢献しながら、気を抜かずにこれからもがんばっていきたい。

トレタは3,000万人の予約を支えるRailsエンジニアやインフラエンジニアやiOSエンジニアを募集しています。

www.wantedly.com www.wantedly.com www.wantedly.com