Product Manager Conference 2017にいってきた

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

2017.pmconf.jp

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

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

Dropbox Paperよい

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

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

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

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

実際の画像 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後

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

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

会社のコンフルエンスの整理をしてる

なぜ?

会社の情報がバラバラで見つけるのにすごい大変だったため。esa調べてGoogleDrive調べて、コンフルエンス(コンフル)調べて、GitHubWikiとbacklogを調べて、情報が見つからない、間違っているということばかりだったので大分ストレスになってた。最初にコンフルを入れた人ももういないので、どういう思想でこれらのツールを使うのか?というところもバラバラになってしまってた。

以下、色々記載しているが、うまく書けてないのは自分の文章のせい。これを大体2週間半(アンケートに1週間)ぐらいで本来の作業と並行してやった。

現状把握

まずは現状を把握するために職種ごとに何をどのような目的で使っているか確認

  • コンフル
    • 会社のアカウント持ってる人全員が使える
    • ミーティング議事録
    • 運用してるサービスの仕様(全部ではない)
    • プロジェクトごとの情報
  • GoogleDrive(スプレッドシート、MS PowerPoint、PDF、Word)
    • 会社規定・契約書・申請書などの会社共通的な資料
    • 企画職が仕様を書くときに使ってる
  • GitHub(Wiki, Issue), Backlog(チケット, Wiki, ファイル)
    • 開発チケット
    • 外部に委託してる開発会社とのやり取り(Wiki, ファイル)
      • GoogleDriveは社内のみが使えるため
  • esa
    • エンジニア部署だけで使ってる
    • エンジニアの日報やTips、ポエム、申請書の書き方、仕様書など様々
  • cacoo
    • エンジニアの一部が図を書くときに使っている

課題感の確認と解決策を考える

GoogleFormでアンケートを取って自分の思ってる課題があってるのか、他にみんなが感じてる課題がないのかを全社向けにアンケートを取って確認。その結果、以下のことがわかった

課題 解決策案
ルールがわからない 思想とルールを決めた
ほしい情報(仕様とか)が探せない。毎回検索する必要がある ページ構成を考え直す
作成した情報をどこに置いてわからない ツールを整理
コンフルの議事録フォーマットがバラバラ テンプレートを決める
コンフルの使い方がわからない Tipsを作成する

大まかな思想を決める

情報をつなげる

仕様書を全部コンフルやGoogleDriveに寄せるとか色々考えたが、会社の契約書などはどうしてもDriveに入れる必要があったり、企画職の生産性を落とすわけにはいかないので、まずは少しずつ整理している。今の組織形態(職種ごとの組織とプロジェクトごとの組織というマトリクス型組織)、外部委託開発会社がいるというところを考えると、今まで使ってるツールをいきなり削除することはできない。既にある情報をどうするかというのもあるし。なので、まずはすべての情報がつながるようにしようと。なので

コンフル ---+---> Google Drive
      |
      +----> Backlog(GitHub wiki)

という、フローを決めて、まずはコンフルを見てリンクを辿っていればその情報に行き当たるようにという思想を取った。

会社組織、サービス構成に似せた

コンフルの構成を直感的にするために会社組織構成、サービス構成に似せた。 会社組織というところでは

  • 全社共通的な情報。ここはやりたいこと毎にページを切った
  • あまり組織体系が変わらない職種ごとの部署の各ページをスペース直下に
  • 来年多分変わっているであろうプロジェクトごとの組織を移動しやすいように年度ページ以下に配置する

またサービス構成というところでは

  • サービスの機能毎にページを作る
  • 運用上必要な情報をまとめるページ

ゆるいルールを決める&Tipsページを作る

厳しいルールを決めると色々つかれるので、上の思想に基づいた最低限のルールだけを決めた。 パーソナルスペースの存在が知られていなかったので個人ページはそちらに寄せる(ようにする予定) またTipsはQuickTimePlayerで取って、それをgifページに変換して動いているものを見せるようにした

コンフルのページ構成を整理する

上の思想に基づいてページを粛々と整理する。もう使わなくなった情報も出てきたので、それは新規にアーカイブページを作って移動した。ページのアーカイブ機能が本当にほしい。管理者だとドラッグアンドドロップでページを移動できるので超便利だった

テンプレートページを整理

コンフルはデフォルトのテンプレートが何種類もあるが使うのは多くて議事録とふりかえりの2種類ぐらい。なので、それ以外は一旦見せないようにした。テンプレ自体はちょこっとだけ変えた

コンフルは色んな機能があるのでやりたいことに応じてページを作った。 例えば、個人的なページをう これは前の職場でも好評だったが動画でやり方を見せると

その他細かい所

  • 言語、日時設定を日本語にした
  • ページタイトルにページ番号を入れていたが消した(ルートページのみ)

TODO

  • もっと啓蒙活動をする
    • 今の状態で何が問題なの?と思ってる人はいるとおもう(特に声を上げない人)
  • 本当は子ページまで整理したい(がものすごく費用対効果が悪いと思う)
  • GitHubWikiとBacklog wikiの使い分けをどうするか
  • esaの情報をコンフルによせる。コンフルのmarkdownがマジ使えないというのはあるけど、特に仕様とかはみんなコンフルに寄せてくれよぅ…

上手な教え方の教科書をよんでいる

上手な教え方の教科書 ? 入門インストラクショナルデザイン

上手な教え方の教科書 ? 入門インストラクショナルデザイン

会社の人から借りて一通りザーッっと読んだのでメモっておく。あとでうちの部として購入してもらおう

どのような本なのか?

「教えること」を教えるための本。インストラクショナルデザイン(ID)とは?というところから始まり、IDを構成している要素でどのようにしたら人に教えることの主役である教えられる側がうまく吸収してくれるのかという仕組みが書いてある。

感想

教育という分野で仕事をしてるので時々理念とか理想という単語をよく聞くようになったが、IDは時代時代で変わる理念・理想などを持っておらず「正しい」という概念を持っておらず、効果的かどうかが基準というところに非常に好感が持てた。これは仕事内での評価で「あの人は〜」とかの恣意的な流れではなく評価(Evaluate)するというところにもつながっていくはず。

この本仕事をする先輩が後輩に教える中でうまく行かず、先輩の上司からIDを教えてもらうという筋書きなので、同じようなシチュエーションで悩んでいる人には最適な本だと思う。なので、部下ができた人や、組織を作る(特に新卒)レイヤーの人には読んでおいて損はないと思う。

自分はエンジニアで特に後輩とかもいないので、この本で言っていることで使える部分をどのようにプロジェクトマネジメントやサービスに取り込むかというところにフォーカスを当てていた。今までは経験や口伝、上司の背中を見てやってきた部分がほとんどでその背景をわからないまま表層だけを使っていた部分があったので、そこが知識体系として背景としてまとまっていたので、自分のやり方の方向性の確認もできたと思う。

余談:メモを取りたいから1節ずつ読んでエディタにかくという方式を取っていたがこれは思考がとまるのでダメだった。こういうときは紙が良さそうな気がするので次はそちらの方法を取ってみる

FuelPHPのModelにはちゃんとデータ型を書こう

===での演算子結果がなぜかtrueにならなくて調べてたらこれが原因だった

data_typeを設定していない

<?php
class Model_User
{
  protected static $_table_name = 'users';
  protected static $_properties = [
    'id',
    'name'
  ];
}

php oil c の結果

>>> var_dump(Model_User::find(1)->id)                                                                                                                               
string(1) "1"

data_typeを設定

<?php
class Model_User
{
  protected static $_table_name = 'users';
  protected static $_properties = [
    'id'   => ['data_type' => 'int'],
    'name'
  ];
}

php oil c の結果

>>>  var_dump(Model_User::find(1)->id)
int(1)

Sidekiq

github.com

Ruby界隈はエコシステムがしっかりしてるなぁ

  • Redisが必要になる
  • クライアント → Redis ← Workerが処理
  • workerを増やすことはできる
  • workerが増えたときに同じジョブを実行することは?→Redisシングルスレッドなのでそこで担保
  • Redisが死んだときは?

    • 定期的に再接続してるから復旧したら再接続するみたい
  • タスク中にworkerが死んだら?

    • さすがにロストする
  • タスク実行中にプロセスが死んだときはどうなる?(redisに残ってる?)
    • redisに残っているというよりも、正常終了するときはredisにpushしてる
  • タスク実行中に正常終了SIGTERM投げれば正常に終了して次にリトライが走る -> SIGHUPとかSIGQUITではリトライが走らない
    • https://github.com/mperham/sidekiq/wiki/Signals をみると USR1 -> TERMをやったほうがよさそう
    • USR1を実行すると新規workerの開始を停止する。実行中workerは継続 -> TERMで停止する
      • 基本リトライが走る前提で処理を組むのは大前提