PO祭り2018 Summerに参加した

まとめてくださってるのでこちら togetter.com

最後まで参加できなかったのでもったいなかった。自分はプロジェクトのリーダーであってもプロダクトのオーナーではないし、うち自体にPOと呼ばれる職種の人はいないので、必然的に企画職の人と会話するときの考え方やチームビルディングのネタにしている

自分が自然にやっていることが正しいのか/間違っているのか、浅いのか/深いのかを確認する場としては非常に良かった。まだまだ自分は浅い部分というか、点でやってる部分があって継続的な線になっていなかった。

お気持ち

あと、話してる内容が自動で文字起こしされている精度が徐々に上がっているような気がした。最終的にどのぐらいの精度だったんだろうか

vim の cpsm built with version of Python not supported by Vim の原因がわかった

家のMacで cpsm built with version of Python not supported by Vim のエラーが出てたけどようやくわかった。

前提

brew 経由でvim, Pythonを入れてる。それとは別にpyenvでPython2をいれてる

原因

brew経由で入れたPythonのデフォルトが３になったので、pyenvで入れているバージョンと互換性がなかった。

なんでわかった？

cpsm/cpsm.vim at 8a4a0a05162762b857b656d51b59a5bf01850877 · nixprime/cpsm · GitHub 　のエラーステータスが1となっていた。その少し上に 1: cpsm module built with incompatible version of Python らしい。 で、/usr/local/bin/vim --version で見てみると、python3がONになっていて、python2がOFFになっていた。

解決策

brew install vim --with-python@2 でpython2をONにしてから、cpsmをONにした

技術的負債の代替語でサービス負債という単語を考えてみた

きっかけはエンジニア内で技術的負債というのをesaにまとめてたときに、これをどうやってやっていけるのかなと思ってた。チームで仕事をしている以上、エンジニアだけではどうにもできない部分は確実にある。

もちろん他職種に丁寧に伝えるということは非常に大切なんだけど、まず「技術」というところで心理的ハードルを下げたかった。「技術」という単語が出るとどうしても「エンジニアだけのお仕事」という感じになってしまう。その時は他施策より優先度が下がることが多い気がする。

少なくとも自分がやりたい技術的負債の返却はサービスのためになるはずなので、サービス負債の返却という単語に置き換えてみようと思う。もちろんサービスを運用する上で、「望まざる状態でそうなってしまった」ものを「サービス負債」という括りにいれて言ってもいいと思う。結果的に運用が楽になってみんながハッピーになればいい。特に攻めの施策ばかりやっていて、守りが薄くなってるところはいいのではないだろうか。

2017年振り返り

仕事

今年はここ5〜6年で時間的には一番働いているが充実感がない一年だった。自分が考えている価値と会社が求めているところが違うからだと思う。仕事では自分自身がアウトプットを出すことを求めていないみたいなので、プロジェクトやチームの政治的な部分も含めて調整役に回っている。

自分の基本的なスタンスは、自分の手でカチャカチャと機械(ではないけど)いじりしながら物を生み出すのがエンジニアとしての醍醐味であり価値だと考えている。もちろんチームで働く以上マネジメント・リードは非常に大切だが、自分にとってマネジメントやPdMを学んだりするのは上記の価値を高めるための一部でしかない。

また、エンジニアが技術も目的にしないで誰が技術と正面から向き合うのだろうかという気持ちがある。おそらくうまく言語化できておらずここ1,2年でようやく言語化できた。

自分はポエマーではないのでポエム書く暇があったらコードを書こう

あと今年の途中から採用面談をやっているが色々な人の話が聞けるのは参考になる。

健康

5月ぐらいからずっと咳が止まらなくて自分で色々やっていたがどうにもならなくて、10月頃にヤブ医者に行ったがよくならなかったので別の呼吸器科に行ったら喘息だと言われた。以前に海外に少しいたときに空気が悪いところにいたのでそれで喘息になってはいたがびっくり。肺に影のようなものがみえますねーと言われてCTの実績を解除した。結果は以前炎症していたものの名残だったらしい

ジム

お金と自分のいつもやってる運動内容から考えてコスパ的に最適な24時間やっているジムに切り替えた。ただ、仕事が忙しいのを言い訳にしていつも以上にジムに行かなくなってるのはよくない。来年は平日1日でも行けるようにしたい。

健康への投資

ジムにあまりいかなくなってるが、体調を崩しているということもあってこれまでになく健康に気を使っていたつもりだった。3ヶ月毎に歯医者行ったりしてる。が、食生活に気を使わなかったり、深夜まで起きてるので全部台無しにしてる。

買ってよかったもの

iPhone8

iPhone6 からの乗り換えだったのでSuicaやクレジットカードを全部こっちに移した毎回財布/定期券を出す手間が省けた。また現金支払いをほぼすべてクレジットカードにしたことでZaimのクレジットカード連携と合わせて支出がほぼ見えるようになった。

Butterfly Board2

会社のいたるところにホワイトボードはあるのだが、みんなが議論をするミーティングではこれを持っていくようにしている。ホワイトボードだとみんなが書き込む心理的ハードルが低いみたいで、机の上にペンを適当に放り出して置くと勝手に書き始めてくれる。黒色の0.5mmのペンが嬉しい。逆に経営会議や採用面談などあまり見せたくない情報はノートに書くようにしてる

Product Manager Conference 2017にいってきた

昨年に引き続き2回目です。2日目は仕事の都合上、途中退席でした。

2017.pmconf.jp

自分はエンジニアなのでPdMというポジションではないのですが、プロダクトを作るときの考え方とかが参考になるので行ってました。1年ぶりに行って自分や会社が変わった(変えることができたのかな？)と考えるとうーん..となってしまってもやってます 細かい資料とかは多分pmconfのページに上がるのでそっちを見たほうがよいとおもいます。

実行委員の皆様ありがとうございました。来年も期待してます！！

Dropbox Paperよい

今回も会社の人に共有したかったのでどうしようかなと思った結果、Dropbox Paperにしました。

  • 共有は楽にしたい。機密情報などは載せない
  • インターネット環境はあるのでオンラインでもよい
    • オフラインでできれば最高
  • 家の自分のPCからも見るので会社のGoogle Documentとかにはいれたくない
  • Markdownだと最高

としたときに、試しに使ってみたところ大分よかったです。 実際の画面は下

  • テキストがmarkdownでかける
  • 画面の左に目次が表示できる
  • YouTube、Twitterの埋め込みもリンクをコピペするだけで展開される
  • モバイルアプリもあるので帰りがけにおもだしたことを書ける
  • オフラインでは編集できない
  • デフォルトが編集可能になってるので少しだけ注意

実際の画像 f:id:hs_hachi:20171116004323p:plain

1on1を始めて〜の続き

hachi.hatenablog.com

で書き忘れていた。

気をつけていること

何かしら課題が出たときには最優先で動いて、よい成果が出なくても結果は報告するようにしてる。

これに加えて、毎月決まったときにやるようにしてる。今は毎月の最後の木曜日にやるようにしてる(特に木曜日に意味はない) また、たまにミーティングを被せてくる人がいるが、会社全体に影響するものでない限り断ってる。

今できてないこと

まだまだ自分の話の持っていきかたが下手なので自分主導で話してしまう。なるべく相手に考えてほしいように促すようにしてるがなかなかうまくいかない。内省を促して引き出していきたい。

1on1と別でやってること

新しく自分のチームに入るメンバーがいると、以下のことを行っている

一緒に働く既存メンバーと自分との期待値のすり合わせ

一緒のプロジェクトで働くという足元の話もそうだが、新メンバーにリーダーになって欲しいとか、既存メンバーが次のプロジェクトに移動すること前提なのかとかいう少し未来の話もすることで、既存メンバーが作業分担をしやすくしたり、新メンバーへの期待値を変に上げすぎないようにしてる。

入って初日に新メンバーと期待値のすり合わせ

新メンバーとは入社後に30分ぐらい話す。プロジェクトのことは一緒に働く人に任せるが、チームとして何を期待しているのかということをきちんと話す。ここも上記と同様に足元の話と少し未来の話をする。

新メンバーと同じプロジェクトの既存メンバーとそれぞれ30分ぐらい話す

入社後1〜2週間ぐらいしてから話すようにしてる。既存メンバー、新メンバー共にコミュニケーションを取ることはそれなりに負荷がかかるので、慣れていないこと、困っていることを聞くようにしてる。

特に既存メンバーからは新メンバーの技術的に足りないところを聞くことが多い。それをきちんと新メンバーにここが足りないと思うから補完しておいてねと依頼する。あと最初の期待値とあまりずれていないことだけ軽く確認する。

また新メンバーからは最初に躓いたところ(例えば環境構築やコミュニケーション不全なところ)を聞くことが多い。いかに新しい人が早く自分の能力を最大限発揮できるかが大切なので、次に入ってくれる人のことも考えて対策を打てるようにしておく。

ということをやると、大体MTGで一ヶ月が終わる。

1on1を始めて1年ぐらい経った

フロントエンドチームの取りまとめをすることになったので、元々サーバサイドエンジニアである自分とみんなが考えていることとズレが無いようにしたくて始めた。あと実際にサービスを開発してるメンバーと会社が考えていることの期待値合わせという意味もある。なお、会社のエンジニア全員とやってるわけではなく自分のチームでやってるだけである。また、対象は業務委託の人も含んでいる。業務委託の人を含めてよいか？という話はあるが、自分は評価者ではないということと、これによって契約が左右されることはほぼないということは念を押してる。

始める前によんだもの

この辺

d.hatena.ne.jp

ofsilvers.hatenablog.com

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

手順

  1. 毎月、最終木曜日にやっているのでその1週間前(最近遅れた、ごめんなさい)ぐらいに1on1シートをメンバーへ送ってる。「どうすか？」と始めるのもお互いに困るので事前にアジェンダ代わりになってる。これを考えるのに今月のメンバーの動きだったり日報などを見て1〜3日かけて作ってる。
  2. 1on1をやる。可能な限り技術的、組織両方聞くようにしてる。細かい技術の話は逐次やってたり、最近ジョインしてくれた人が多いので話は組織絡みがおおい。
  3. 1on1を実施した後に、上司に共有する。もちろん事前に共有するよというのは伝えてる。

1on1後

何かしら課題が出たときには最優先で動いて、よい成果が出なくても結果は報告するようにしてる。課題が出てきたときにも動かない、動いてるように見えないというのは最悪で、それぐらいであればやらないほうがマシだと思ってる。みんなは「この課題を解決したらきっともっと良くなる。ただ、自分たちは頑張ったけど解決できない(どうやって解決したらいいかわからない)から解決してほしい」という思いで言ってくれてるので、それには可能な限り答えたいと思ってる。

自分は圧倒的技術力で引っ張っていくタイプではないのでそうやって小さな信頼を積み重ねないといけない。