1on1を始めて〜の続き
で書き忘れていた。
気をつけていること
何かしら課題が出たときには最優先で動いて、よい成果が出なくても結果は報告するようにしてる。
これに加えて、毎月決まったときにやるようにしてる。今は毎月の最後の木曜日にやるようにしてる(特に木曜日に意味はない) また、たまにミーティングを被せてくる人がいるが、会社全体に影響するものでない限り断ってる。
今できてないこと
まだまだ自分の話の持っていきかたが下手なので自分主導で話してしまう。なるべく相手に考えてほしいように促すようにしてるがなかなかうまくいかない。内省を促して引き出していきたい。
1on1と別でやってること
新しく自分のチームに入るメンバーがいると、以下のことを行っている
一緒に働く既存メンバーと自分との期待値のすり合わせ
一緒のプロジェクトで働くという足元の話もそうだが、新メンバーにリーダーになって欲しいとか、既存メンバーが次のプロジェクトに移動すること前提なのかとかいう少し未来の話もすることで、既存メンバーが作業分担をしやすくしたり、新メンバーへの期待値を変に上げすぎないようにしてる。
入って初日に新メンバーと期待値のすり合わせ
新メンバーとは入社後に30分ぐらい話す。プロジェクトのことは一緒に働く人に任せるが、チームとして何を期待しているのかということをきちんと話す。ここも上記と同様に足元の話と少し未来の話をする。
新メンバーと同じプロジェクトの既存メンバーとそれぞれ30分ぐらい話す
入社後1〜2週間ぐらいしてから話すようにしてる。既存メンバー、新メンバー共にコミュニケーションを取ることはそれなりに負荷がかかるので、慣れていないこと、困っていることを聞くようにしてる。
特に既存メンバーからは新メンバーの技術的に足りないところを聞くことが多い。それをきちんと新メンバーにここが足りないと思うから補完しておいてねと依頼する。あと最初の期待値とあまりずれていないことだけ軽く確認する。
また新メンバーからは最初に躓いたところ(例えば環境構築やコミュニケーション不全なところ)を聞くことが多い。いかに新しい人が早く自分の能力を最大限発揮できるかが大切なので、次に入ってくれる人のことも考えて対策を打てるようにしておく。
ということをやると、大体MTGで一ヶ月が終わる。
1on1を始めて1年ぐらい経った
フロントエンドチームの取りまとめをすることになったので、元々サーバサイドエンジニアである自分とみんなが考えていることとズレが無いようにしたくて始めた。あと実際にサービスを開発してるメンバーと会社が考えていることの期待値合わせという意味もある。なお、会社のエンジニア全員とやってるわけではなく自分のチームでやってるだけである。また、対象は業務委託の人も含んでいる。業務委託の人を含めてよいか？という話はあるが、自分は評価者ではないということと、これによって契約が左右されることはほぼないということは念を押してる。
始める前によんだもの
この辺
ヤフーの1on1―――部下を成長させるコミュニケーションの技法
- 作者: 本間浩輔
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/03/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
手順
- 毎月、最終木曜日にやっているのでその1週間前(最近遅れた、ごめんなさい)ぐらいに1on1シートをメンバーへ送ってる。「どうすか？」と始めるのもお互いに困るので事前にアジェンダ代わりになってる。これを考えるのに今月のメンバーの動きだったり日報などを見て1〜3日かけて作ってる。
- 1on1をやる。可能な限り技術的、組織両方聞くようにしてる。細かい技術の話は逐次やってたり、最近ジョインしてくれた人が多いので話は組織絡みがおおい。
- 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
上手な教え方の教科書をよんでいる
- 作者: 向後千春
- 出版社/メーカー: 技術評論社
- 発売日: 2015/08/05
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
会社の人から借りて一通りザーッっと読んだのでメモっておく。あとでうちの部として購入してもらおう
どのような本なのか？
「教えること」を教えるための本。インストラクショナルデザイン(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
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で停止する
- 基本リトライが走る前提で処理を組むのは大前提
社内環境改善活動の話
この記事は Classi Advent Calendar 2016 - Qiita12日目の記事です。前日はhilotterによるエンジニア立ち居振舞い: 明日いなくなってもいいように仕事をする – hello-world.jp.netでした
www.wantedly.com この話を書こうと思ったのですが、既に結果は書かれてしまったのでそこに至るまでの経緯などを書きます
話の発端
現在Classi所属の社員は3人(他はベネッセ・ソフトバンク・ヒトメディアなどから参加してるメンバー)いるのですが、毎月1回副社長とランチをする会があります。その中でよいエンジニアを採用するにはどうしたらよいか？という話の中から出てきました。(ここでエンジニアとしてるのは3人共エンジニアであるため)
もちろん、会社の事業内容、雰囲気や技術で人を引きつけるということは基本的なところなのですが、それと同時に会社インフラも整備して社員を大切にしていることも重要という話をした記憶があります。
アンケートをとる
最初に3人でこういうものがほしい。というのをスプレッドシートに起こしました。椅子・本の定期購読・ウォーターサーバー・ディスプレイなどなど。これはエンジニアとしての主観だったのでそれと並行して、メンバー全員に対してGoogleフォームを使って金額が10万、20万と分けてアンケートを取りました。20万としてるのは深い理由はないのですが固定資産の都合上です。
その結果、ウォーターサーバー、無料コーヒー、お菓子などが上位に上がってきました。エンジニアからはバロンなどの高級椅子・キーボード・マウスなどが上がりやすく、他の職種からは本の購読・本棚などが上位に来てました。その結果以下のように決まりました。なおこれらはトライアルという形式を取っています。
選定・購入する
オフィスファミマ
こちらは副社長が決めてくださったので特に何もしなかったです。感謝。あと、スタバのポットサービス検討していたのですが、都度都度行くのが面倒だろうということで、オフィスファミマのカフェを頼んでます。両方共無料ではなくメンバー自身で購入してます。
ウォーターサーバー
当初はお店にあるようなショーケースにペットボトルを入れるという案もありましたが、コスト的なところを考えて最終的にはウォーターサーバーになりました。また、どこから購入するか最後まで探していました。結果、以下のような理由で 《公式》天然水ウォーターサーバーNo.1【コスモウォーター】の宅配水 にしました。
- 月額費用
- トライアルなので解約時に発生する金額を最小限にする
- 衛生面
- 自分たちで清掃するのは最小限にしたい
最初は消費量がわからなかったので水を12L✕2本頼んでいたのですがそれが2日半でなくなったので慌てて4本追加注文しました。この辺は水なので余裕持ってもよかったかもしれません。
椅子の購入
予算は30万と決めて、メンバーで実際に試し座りに行きました。その上で オフィス家具・中古オフィス家具通販のオフィスバスターズ から中古を購入しました。申し込んですぐに電話がかかってきてマジびっくりした...
運用・効果を計測する
オフィスファミマは毎週補充に来てくれるので特にやることはありませんが、カフェで使っているドリップマシンは毎朝掃除(といっても、キレイキレイで拭いてるだけ)してます。また、毎週月曜日に軽くウォーターサーバーの清掃も行ってます。この辺は最初から気づいた人がやると運用よりも最初は自分がやったほうが回ると考えているためです。5分〜15分ぐらいで終わるので朝にTwitterを見てる時間をこちらに回すだけです。
これらは月末にGoogleフォームでアンケートをとり次の改善に使っていく予定です。
今回は却下・保留にしたもの
以下のようなものは今回は却下・保留にしました。
- キーボードなどは個人の好みの差と値段が激しすぎる
- 本などは楽に申請するフローを決めないと承認する上長の負荷が上がる
公平性と区別
これはあくまでも私見なのですが、何を導入するという基準には「公平性」と「区別」が必要になると考えてます。
公平性というのは職種・契約形態に関わらず全員が平等に受けられるものを整備することです。例としては今回採択した3つとも公平性にあたると考えています。あとは通常のディスプレイなどもそうですね。弊社は椅子に座ってノートPCを使っている人が多いためこの辺を整備すると生産性が上がることは目に見えてます。これまで仕事で外部ディスプレイを使ったことがない人に対しては、どのぐらい効率が上がるのかイメージも湧かないでしょうから、とりあえず使ってみてくださいと言う形で半強制的に貸与してもよいかと思っています。
区別は職種によってある程度異なるものを整備する必要があるのではないかと考えています。例えば、デザイナーは通常のディスプレイではなく高解像度のディスプレイにするとか、マーケティングは外出が多いからWifiルータやデモ用のiPadを貸し出せるなどもあるかもしれません。現在はこのあたりはまだ手をつけれていないのですが直に整備が必要になる部分かと思います。
感想
これらは約1ヶ月〜1ヶ月半の話だったのですが、社内の環境を改善していくという目的に対してトップダウンとボトムアップがうまく働いた例かなと思います。上がお金やビル側などの複雑な調整をし、下が予算などの制約の中で持っている経験などから最適解を出せたのではないかなと思っています。環境改善は一時的なものではなく会社がある限りずっと続くものなので、メンバーのニーズや会社規模などに応じてこれからもみんなが働きやすい環境を作っていければと思います。
wantedly
こんな感じで会社を作っていくことに興味がある方は是非お願いします www.wantedly.com
明日は
kyottyyのコーポレートサイトをLinuxからS3+Lambdaにした話です
