読者です 読者をやめる 読者になる 読者になる

gaaamiiのブログ

悪気なく間違ったことを書いている時があります。コメントやTwitter、ブコメなどでご指摘ください

laisoさんの転職エントリ読んだ

この辺に学びがあった。

日々のタスクとしてはiOS開発が一番人手が薄く求められていたのでしかたなくオブシー*5を書いてだらだら仕事していたんだけど、その頃から ninjinkun's diary なんかに影響され「UXとは」と独り言をいいながらその手の本や知見を得て、色んなビジネスアプリを触りながら自社製品の改善点を黙々と報告していた。 ユビレジには伝統的にというか前述のCTOが全部やってる問題があったので開発ディレクター・プロダクトマネージャーの職位がなかった。しばらくしたら歩夢さんというキラキラネームの人がやってきてプロダクトマネージャーを兼任していた。彼もフルスペックな人でビビったのだけど、なにせ会社ごと一緒になったので製品とかシステムも増えてやることはたくさんある状況だった。 なので「各自必要を感じたらなんか関係者をつかまえていい感じにやれ」ぐらいのゆるい感覚で進行管理をしており「開発者を一気に増やしてコード書いてみたけど謎の要因で1年間リリースが凍結されている。謎の要因がはたして何なのか、それは関係者をつかまえていい感じにやれ」というようなプロジェクトがザラにあった。 これが結構「クライアントサイドとサーバーサイド、ハードウェアとソフトウェア両方の知識が必要」というのにフィットしていたので助けることができると踏んだ。 やってみると爽快でコードを書かずに製品を良くできるんだ! という感動があった。今までは要求された仕様に対していかに良いコードを書くかテストを自動化するかというような価値観でプログラミングしていたので、世界が広がった。 ユビレジは「無断ユーザー訪問し放題」という性質があるのでこの頃はジャンジャン使っているお店に行ってみた。

BASEに入社した - laiso

とくにここ。

これが結構「クライアントサイドとサーバーサイド、ハードウェアとソフトウェア両方の知識が必要」というのにフィットしていたので助けることができると踏んだ。 やってみると爽快でコードを書かずに製品を良くできるんだ! という感動があった。

「製品を良くする感動」って良い言葉だと思った。

作業が遅い問題

どうしたもんか。。

開発環境

  • 工夫はしてるつもりだけどファイル検索とかタグジャンプがいまいち
    • これはすぐ改善できそう

考え方など

  • 一つの問題に集中できてない(問題を適切に分割できていない)
  • 機能とコードが頭のなかで結びついていない
    • ちゃんと記憶すれば解決
    • 製品を開発・保守する者として、記憶する義務があると考えるくらいがちょうど良さそう
  • アプリケーションコードの層分けがどうされているのかなど抽象的な理解が足りない
    • 新しい機能を実装するときに、そのコードをどこに書くか(なんとなくではなく)明確に決められるべき
    • 理解ができていない時に、関係ないところまで含めてコードをコピペしてしまうようなことがある

作業効率を上げるためには、記憶が割と大事なんじゃないかと思ってきた。

検索すればわかる、調べればわかるというのは大事なことで、ドキュメントやらコードやらをそういう状態に保つのはもちろん大事。

だけど、開発している製品について万事が「検索すればわかる」状態だと、作業の効率は向上しない。

ネット上で英語でできそうなことリスト

英語でインターネット読み書きできたらどんなに楽しいだろうなと思う。現状は読みの方でしか利用できておらず、とても歯がゆい。今の自分でも頑張れば英語でできそうなことを挙げてみる。

OSS関連

  • 自分のOSSを出して目につきやすいような工夫をする
  • 自分が使用しているソフトウェアに関して

掲示板

  • redditでコメントする
  • Stackoverflowで回答をする

スクリーンキャスト

  • 作ってみた系など

情熱があればいつかできるかもしれない

  • 英語記事の著者にコンタクトを取って翻訳に取り組んでみる

作業計測について

日報をその日の終りに雑に思い出して雑に書くの良くないので、作業時間と作業量を測りたいと思った。

作業時間

現職の開発フローで、作業時間を測れそうな対象を粒度が粗いものから並べるとこんな感じになる。

  • チケット
  • Issue
  • Pull Request

そして、それぞれ関係性がある。

  • チケットとIssueとPull Request は多くの場合1対1対1になる。
  • チケット無しでIssueとPull Requestが作られる場合はバグ修正や途中で気付いた改善点など、元々はスケジュールに無かったもの。

なので、1日の作業を計測するとしたらIssueごとの作業時間を測るのが良さそう。作業時間を測るのには、toggl buttonというChrome拡張があるのでそれを使えばいい。

作業量

では、作業量の計測対象はなんだろう。

  • Issue(閉じることができたやつ)
  • Commit
  • URL

閉じたIssueやCommitはコーディングの成果そのものなので、これを作業量として見るのは違和感ないと思う。

目に見えなくなりがちなのがコーディングする以前の調査量だ。何か作りたいけど実現方法どうしようか。よし調べるぞ。〜〜1時間経過〜〜。みたいなのはよくあると思う。コーディングはもちろん、調査も作業だと考えていいはずだ。

ではこれはどうやって測ればいいのか、と考えてみると、URLというのが計測対象の1つになり得ると思った。論文や本の参考文献リストのように、その日の作業量を表すものとして参考URLが並んでいれば、なかなかやった感があって気持ち良さそうだ。

作業時間
Issue#56 4時間00分
Issue#57 3時間30分
Issue#58 1時間30分

作業量
Issues: 2
commits: +355 −39
URLs: 38
- http://example.com/fieoajfi
- http://example.com/hgoehoge
- http://example.com/fioawjio
- http://example.com/fiaojwfie
- http://example.com/goe
- http://example.com/iofjeai

こういう数値をまとめて出せるようにしておくと、いろいろ学びがありそう。ただ、この数値で同僚のエンジニアと比較されるみたいなことになるとストレスが高まりそうなので良くなさそう。自分の作業時間見積もりの不正確さやざっくりとしたパフォーマンスを知る目的に確認するのであれば良さそう。

ライブラリのサンプルをcodepenやjsfiddleで検索すると捗る

転職して1ヶ月は内製のサポートツール周りなどを触らせてもらっていましたが、8月からはウェブフロントエンドの方にコミットさせてもらっています。Angularのデータバインディング周りに何度もハマっていて楽しいです。

フロントエンドの開発作業で、新たな機能をつくるときにはまずそれ相当のライブラリがあるかどうか調査することが多いと思います。しかしそれが見つかったとしても、僕のように頭が弱く英語力が低い人間にとって、ライブラリの扱い方をGithubのREADMEからすぐに把握するのはなかなか大変です。そのため、さっと動くサンプルを見つけることがとても重要。

そこで、http://jsfiddle.nethttp://codepen.io などといった、フロントエンドエンジニアのお絵かきサイトみたいなものがあることを知りました。ここで検索すれば、(そこそこ人気のあるライブラリなら)何かしら自分のニーズに合ったものが見つかりそうです。

f:id:shgam:20160806124829p:plain

jsfiddle.net

codepen.io

参考

qiita.com

転職3週間振り返り

転職して3週間が経ちました。少し振り返ります。 Twitterでは転職したいけど迷ってるという方も見かけるので、こういうことを(会社の迷惑にならない範囲で)こまめに振り返って伝えていきたい。

前職から変わったこと、感じてること

  • 自由が増えた(開発環境や勤務について)
  • 開発が速い(新機能の企画からリリースまでが1〜2週間とか)
  • 製品に対する反応がダイレクトに分かる
    • 一夜の障害がAppstoreのレビューに如実に現れたりする
    • 良い反応も見れる。(自分はさておき)サービスが社会のお役に立ってる感がある。
  • テスト自動化へのモチベーションが高い
  • 同僚のエンジニアのレベルが高い

個人的な課題

個人的な課題たくさんあるので技術的なこととそれ以外でまとめる。

技術的なこと

技術的なこと以外

  • アウトプット少ない
    • 自分の存在価値みたいなものを出せていなくて焦ってる
    • 明らかにこうした方がいいと思うということは共有したりプルリクで投げたりしていきたい
  • 立ち位置
    • 何エンジニアになろうとしているのかが自分でも不明瞭。
    • 正直何でもできるようになりたいけどそれでは中途半端なことになりそうでもある
  • 既存機能のデータをどこでどう持って、どのように出し入れしているのかを把握できていない
    • これがわかっていないとディレクターの方にマスタデータのcsv渡すときなんかに時間がかかる
  • 砂場を準備できていない
    • 業務で扱う技術領域で趣味プロダクトみたいなものを作って、壊せるオモチャとしてプライベートで運用していきたい( nekobito.github.io のリニューアル考えてる)
  • 時間の感覚が鈍い
    • いつまでに何ができるかという判断力が貧弱。
  • 仕様理解
    • ミーティングなどで、話についていけなくなる瞬間がある。おそらく自分でもっとアプリ使った方がいい。

関連

(他のエンジニアの方の転職その後エントリみたいなやつ大好物です)