1on1におけるゆとりの設計と実践（エンジニアリングマネージャー 1年生の記録）
前提情報
- 10Xというスタートアップで働くEngineering Manager（エンジニアリングマネージャー） です
- 2022/04にEMになりました（それまでマネージャー経験はなし）
- ソフトウェアエンジニア 4〜5名のマネージャーです
- 1on1は週1 or 隔週 決まった曜日・時間帯に実施してます（実施頻度はメンバーにより異なる）
ゆとりを大事にしたい
その昔『ゆとりの法則』を読んだことでゆとりを持つ大事さを常に意識してきた。マネージャーになった時も「ゆとりを持ったマネジメントがしたい」と思った。
1on1におけるゆとりの設計
マネージャーになるとメンバーとの1on1は大事なイベントになる。1on1にゆとりを持たせるため、以下のような方針をメンバーに伝えた。
- 1on1は基本30分で時間を取る
- ただし 私（マネージャー）の予定は1on1後の30分は予定を空けておくように努力します
- なぜなら 話が盛り上がったり、話したいことが話せないと困るので、私の予定上は最大30分は伸ばしてもいいよ！というスタンスのためです
- 1on1の実施頻度、実施の曜日・時間帯は各メンバーの希望に合わせます
これに加えて私が1on1に遅れないために1on1開始前に予定を入れない努力もしました（1on1開始 10分前にブロック予定を入れ別の予定が入らないようにするのがおすすめ）。
ゆとりの効果
時間的ゆとりを持った1on1にすることで、以下のようなメリットがありました。
- 焦らず話せる（焦って結論を出さなくて済む）
- メンバーが話したいことを最優先にはしつつ、マネージャーから伝えたいことを話す時間も確保でき、伝えるべきことの先送りを防げる（時間なくなったからまた次の1on1にしよう…が減る）
- 話す中で新たな話題を見つけたり思い出したりした場合でもその場の1on1で話せる（「まだ時間あるから私としては全然大丈夫だよ！」と言ってあげられる）
メンバーから見ても時間を気にして話される体験は気持ちよくないと思うので、焦らず話せるのが一番良い効果です。
実際どうだったか
メンバーによって差はありましたが、予定通り30分で終わるのと、時間オーバーして話すのが半々という感じでした。時間オーバーする場合は追加で15分（計 45分）話すことが多かったですが、時間オーバーの幅もメンバーの状況次第で変化するため、1時間とか2時間話すこともありました。
これにより話すべき時に話したいことを話し尽くすことがそれなりにできていたと思ってます。
ただ気をつけるべき点もあります。長時間にわたって話すことで互いに疲れてしまい、その後の仕事に身が入らないとか、結論が出ないままグダグダ話してしまったりとか。そのため時間内で話すべきことを話しきる努力は必要です。どうしても収まらない場合に「私はこの後も時間空いてるから大丈夫だけど、XXさんは大丈夫？」と言えるゆとりの準備が大事です。
おわりに
どういうマネジメントがしたいか？を考え「ゆとりを持ったマネジメントがしたい」と決心したことで、無理のないゆとりを持ったマネジメントが今のところできている気がします。
まだマネージャー1年生なので全てがうまくできてるわけじゃないですが、この時のゆとりを忘れずにこれからもやっていけるようにこの記事を残します。
Androidアプリ開発を学び直してる話
前提情報
- 2012年から9年ほどAndroidアプリの開発をしていた
- 2021年4月までJava&Kotlinを使ったAndroidアプリ開発をしていた
- ここ最近はFlutterでアプリの開発をしている
- つまり2年間ほどKotlinを使ったAndroidアプリ開発をしていない
2年間でAndroidアプリ開発は何が変わったか
変化を追う上でDroidKaigiアプリはとても参考になる。
なぜ学び直すのか
Flutterでアプリ作れるスキルがあるなら、アプリ次第ではFlutterで作った方がiOSとAndroid両方で動くものが作れるので便利です。仕事でアプリを作る場合はFlutterが第一候補です。
ではなぜKotlinを使ったAndroidアプリ開発を学び直すのか？って話ですが、多くの企業ではFlutter登場前からアプリを作って運用してきた資産が山程あります。それらをメンテナンスし続ける需要はあります。例えば副業をやりたいなーって思った時もFlutterよりKotlinを使ったアプリ開発の方がまだ多いと思います。
市場としてまだ需要がある技術なら、学び直す価値は全然あるなーと思ったわけです。転職サイトで来るオファーでも「Androidアプリ開発お願いしたいぞ！」ってやつは多く来ます。
どう学び直してるか
仕事では全くやる機会がないため、個人でAndroidアプリ作成しながら学び直してる。とにかく早くアプリを作りたいという意味ではFlutterの方が断然楽なのだが、学び直し=学習が目的なのでKotlinを使ったAndroidアプリ開発にしている。
とはいえ作りたいものがない状態では学習も進まないので、Rebuildに特化したPodcastアプリを作ることにした。
最近のデファクトスタンダードなものを使って開発している。Jetpack ComposeもMaterial 3を使って実装している。
Jetpack ComposeやNavigation 何もわからん状態からのスタートなので、Composeを使ったテンプレートプロジェクトから始めた。そこから作りたいUIを実現するために必要なものをとにかくググりながら実装するみたいな感じ。ググるとMaterial 2の情報多く、Material 3とインタフェースが違い部分が多くてコピペしてもエラー出るしわからん！！ってことが頻発して厳しかった...（今もまだある）
どんなpackageやファイル構成でどこにどれを書くのがベストプラクティスなのかもわからないので、そこは気にせずとにかく実装してまずは動くものを作ることに集中している。ある程度慣れてきたらOSSなども参考にしつつ適切にファイル分割したりしている。
いきなり難しいことをせず、ひどいコードでもいいから書きながら学ぶスタイルでやってます。
9年もAndroidアプリ開発やってきてひどいコードとかウソでしょ？と思う方向けに作っているものをパブリックに公開しました。設計や読みやすいコードを学習したいわけじゃないのでまあいいかなーって気持ちでやってます。
おわりに
学び直すって楽しいよね🌸
現場からは以上です。
とあるエンジニアリングマネージャーの一週間スケジュール
とあるEngineering Managerの一週間のスケジュールをただただ書き出してみたものです。
前提情報
- 10XというスタートアップのEMです
- 裁量労働で10時 - 17時半が基本的に働いてる時間です
- チームではスクラムを1週間スプリントでやってます
- 時々差し込みのミーティングはありますが、それは記載してません
- Gatherはバーチャルオフィスのサービスです。私がEMとして担当するチームメンバーの多くはGatherにログインいているため、基本的に私もミーティング時間以外はログインして相談・雑談などしながら作業しています
月曜日
| 時間 | 内容 |
|---|---|
| 10:00 | 仕事開始 |
| 10:00 - 10:15 | 一日の予定確認。今日やるタスク整理 |
| 10:15 - 10:30 | チームの朝会 |
| 10:30 - 11:00 | Gatherにログイン。作業 |
| 11:00 - 11:30 | エンジニアリング本部定例 |
| 11:30 - 14:00 | 作業。どこかでこどもと散歩 |
| 14:00 - 14:30 | チームメンバーとの1on1 |
| 14:30 - 15:00 | 作業 |
| 15:00 - 16:00 | 関わっている事業部の定例 |
| 16:00 - 16:30 | 開発チームでシステムメトリクスを見る会 |
| 16:30 - 17:30 | 作業 |
| 17:30 | 仕事終了 |
ミーティング時間 : 2時間45分
一言メモ : 作業時間が細切れなのでGatherでコミュニケーション取ってることが多い
火曜日
| 時間 | 内容 |
|---|---|
| 10:00 | 仕事開始 |
| 10:00 - 10:15 | 一日の予定確認。今日やるタスク整理 |
| 10:15 - 11:00 | チームメンバーとの1on1 |
| 11:00 - 11:45 | Sprint Review（スクラムイベント） |
| 11:45 - 13:15 | Gatherにログイン。作業 |
| 13:15 - 14:00 | Sprint Retrospective（スクラムイベント） |
| 14:00 - 15:30 | Sprint Planning（スクラムイベント） |
| 15:30 - 16:00 | チームメンバーとの1on1 |
| 16:00 - 17:30 | 作業 |
| 17:30 | 仕事終了 |
ミーティング時間 : 4時間15分
一言メモ : スクラムイベント祭り😊
水曜日
| 時間 | 内容 |
|---|---|
| 10:00 | 仕事開始 |
| 10:00 - 10:15 | 一日の予定確認。今日やるタスク整理 |
| 10:15 - 10:30 | チームの朝会 |
| 10:30 - 11:00 | Gatherにログイン。作業 |
| 11:00 - 12:00 | 全社定例 |
| 12:00 - 17:00 | 作業（水曜午後は全社的にNo MTG Day）。どこかでこどもと散歩 |
| 17:30 | 仕事終了 |
ミーティング時間 : 1時間15分
一言メモ : 午後は集中して終わらせたいタスクをやる
木曜日
| 時間 | 内容 |
|---|---|
| 10:00 | 仕事開始 |
| 10:00 - 10:15 | 一日の予定確認。今日やるタスク整理 |
| 10:15 - 10:30 | チームの朝会 |
| 10:30 - 11:30 | Gatherにログイン。作業 |
| 11:30 - 12:00 | チームのPdMとの1on1 |
| 12:00 - 13:30 | 作業。どこかでこどもと散歩 |
| 13:30 - 14:00 | EMメンバーの定例 |
| 14:15 - 15:00 | セキュア・バイ・デザインの輪読会 |
| 15:00 - 17:30 | 作業 |
| 17:30 | 仕事終了 |
ミーティング時間 : 2時間
一言メモ : EMメンバー同士の定例があるので、ここまでにEM同士で話すと良さそうなネタを集めることを意識してる
金曜日
| 時間 | 内容 |
|---|---|
| 10:00 | 仕事開始 |
| 10:00 - 10:15 | 一日の予定確認。今日やるタスク整理 |
| 10:15 - 11:00 | Gatherにログイン。作業 |
| 11:00 - 11:15 | チームの朝会 |
| 11:15 - 15:30 | 作業。どこかでこどもと散歩 |
| 15:30 - 16:00 | チームメンバーとの1on1 |
| 16:00- 17:30 | 作業 |
| 17:30 | 仕事終了 |
ミーティング時間 : 45分
一言メモ : 作業時間多く取れるが、金曜なので雑談多めでコミュニケーション取ることを意識してる
最近の情報収集 + 学習方法を雑に書いておく
なんとなく書いてみた
私のステータス
- 10Xというスタートアップでエンジニアリングマネージャー（EM）として働いている
- 仕事時間はだいたい10時から17時
- 家族にはこどももいるため、自由時間はこどもが起きる前か寝た後
- 土日は家族で過ごす時間
情報収集 + 学習のソース一覧
情報収集 + 学習の目的
- 仕事に活かす
- よりよい生活を目指す
- 価値観を広げる、変化させる
- 業界や世の中のトレンドを知る
- 知らないことを学ぶ、知っていることの練度を上げる
利用比率（感覚値）
2 : 2 : 2 : 2 : 1 : 0.5 : 0.5
本 : YouTube : Podcast : RSS（Feedly） : Twitter : Audible : Googleニュース
それぞれについて説明していく。
本
主に電子書籍（Kindle）。よく読むジャンルは ビジネス、IT。
仕事の関係上 最近はマネージメント、リーダシップ、チーム、アジャイル、スクラム、組織みたいな話のテーマを扱った本が多め。
オライリーのEbookもよく買って読んでいる。
Kindle Unlimitedは入ったり、やめたりしていて、多分必要ないのだろう。
電子化されていなくて、どうしても読みたい本のみ紙で買う。
購入した本はほぼブクログにまとめているので、どんなもの読んでるのかご興味があれはぜひ。
KindleはiPhoneのアプリで読んでいる。速読はしてない。複数の本を同時並行読んでいるので、最後まで読み終わらない本は多い。ただ飛ばし読みはしないので、最初から最後まで地道に読んでいくスタイル。
読書をするのは基本的に夜 または 仕事中。1ページでもいいから毎日読む心がけをしている。
月に1,2冊読み終わるくらいなペース。平均すると毎月10冊くらい本を買っている。つまり積読。
YouTube
YouTube Premiumに加入したのがきっかけで、YouTubeをPodcast的に利用する頻度がとても上がった（広告が再生されなくなったのがでかい）。
動画を見ることはあまりなく、基本的に音声のみを2倍速で再生している。
コロナの影響で勉強会やカンファレンスがリモート開催が多くなり、その録画がYouTubeにアップされる機会も多くなり嬉しい。
最近だとForkwellさんのイベント動画や鴨頭さんの動画を見ていることが多い。
音声のみなので、家事などをしてる時によく利用している。あとは、疲れていて読書する気になれない時とか。
Podcast
iPhoneのPodcastアプリを使っている。数えたら115番組ほど登録していて、20番組くらいはしっかり聴いている。
聴いているジャンルはIT、スタートアップ、デザイン、経営。
2倍速で家事などをしてる時によく利用している。あとは、疲れていて読書する気になれない時とか。
在宅になった影響で聴く頻度は前よりも減っているが、毎日1,2時間くらい（2倍速なので2 - 4時間分）は聴いている気がする。
前はとにかくいっぱい聴くスタイルだったが、最近はYouTubeもPodcast的に利用していることもあり、お気に入りの番組を重点的に聴くスタイルに変わった気がする。
RSS（Feedly）
最も長く続けている情報収集の一つ。
Feedlyのデータを見ると 468フィード購読（うち非アクティブ 187件、リンク切れが29件）している。
購読してるのはIT系の個人・企業ブログが多めで、それ以外はITメディア系。
とにかく色んな情報に触れて、気になるものを後で読むにストックするスタイル。Feedlyから内容の詳細まで見ることは1割くらい。
ストックしたものは後々仕事で取り扱うトピックに関係するものだけ掘り起こすみたいな使い方をしている。
最近おすすめのフィードはSpeaker DeckのTechnologyカテゴリのフィードです。
オラクルのブロックチェーンソリューションご紹介 /blockchain
主にIT、ビジネス情報を仕入れる場として活用している。良さそうな本の情報とかここで仕入れている。
リストをいくつか作っていて、リストを見る時はTweetDeckでまとめて見ている。
PCだけで見るようにしていて、iPhoneにはアプリを入れないようにしている。
Audible
目を使った読書を行える時間が減ったので、家事をしながらでも本のように整理された情報をインプットをするために最近加入した。
Kindleで買ったけど読めてない本や気になる本を3倍速で再生して、とにかく量を消費するスタイル。一通り聴いてみて良さそうな内容だったら、気になった部分を何度か聴き直すみたいな使い方をしている。
利用頻度に対して毎月1,500円は高いかもなーと思っているが、もう少し続けてみる予定。
Googleニュース
私生活に関係しそうなニュースが流れるように最適化させることに成功し、最近1日1回くらいな使っている。
ほぼやらなくなったこと
これまでは情報収集 + 学習方法として使っていたけど、今ほぼ使わなくなったのが以下。
- 勉強会への参加
- 仕事以外で学習のためのプログラミングをする
基本的に家族時間を優先するためにやめたって感じ。
マネージャーになったからプログラミングも不要になったとかではない。マネージャーになったのは半年前だが、仕事以外でのプログラミングをする頻度がガクッと減ったのは3年前くらい。する機会が0ではないが、年に数回程度って感じ。
自身がSlackで使ったリアクション上位 20位のランキングを出してくれるBotをnew Slack Platformで作ってみた
このエントリは 10X アドベントカレンダー2022 という企画の1日目（12/1）の記事です。
こんにちは、10Xでエンジニアリングマネージャーをしている 岡野（@operandoOS）です。
今回 10Xで初となるアドベントカレンダー企画の1日目をありがたく担当させていただきます💪
10XはStailer（ステイラー）という、スーパーマーケット・ドラッグストアなどのチェーンストアのオンライン事業立ち上げと成長に必要なすべてを備えたプラットフォームを開発しています。
なので、はじめに最近よく行くスーパーとよく買う商品の紹介をします！
最近よく行くスーパーは西友で、よく買う商品は「みなさまのお墨付き 塩味えだまめ 大容量 700g」です！
10X アドベントカレンダー2022ってなに？
株式会社10Xのメンバーが送る、2022年アドベントカレンダー企画です🎄 🎅 🎍
アドベントカレンダーは12/1から12/25まで毎日ブログを投稿していくので通常ですが、10X アドベントカレンダーはなんと12/31まで投稿が続きます！
もはやアドベントカレンダーと言っていいのか謎な企画ですが、毎日10Xのメンバーが様々なテーマでブログを書いてくれるので、ぜひお楽しみに✨
12/31 最終日は10X CEOのyamottyさんがバシッと締めてくれるのも見所です！
さてさて、本題へ
いきおいでアドベントカレンダー 1日目を担当することになりましたが、何を書こうかと色々迷いました。
考えている最中に「そういえば、去年 Slackで使われているリアクションを集計してランキング出したなー」みたいなことを思い出しました。その集計結果をまとめた記事が以下になるので、ご興味があれば読んでみてください。
前回集計したのは全メンバーのリアクション利用履歴を合算したものでした。今回は自分が利用したリアクションを集計してランキング出してみよう！と思い立ち、過去書いたPythonスクリプトを掘り出すところからスタートしました。
Python...なるほど...わからん
過去書いたPythonスクリプトはサクッと見つかりましたが問題発生です💥
私は年に数回しかPythonを書きません。つまり、Pythonわからないんですよ。なぜ去年Pythonでスクリプトを書いたのかもよく覚えてません。
でも今回もまずはPythonで書きます。
全メンバーのリアクション利用履歴を合算する実装
前回集計した時にはSlackのconversations.list APIを使いました。
コードをGitHubで公開してますので詳細は割愛します。
自分が利用したリアクション履歴の取得
SlackのAPIを眺めていたところ reactions.list というまさに求めていたAPIがありました。
このAPIを使えばいけそうと思い不慣れなPythonでコードを書き始めます。
集計範囲をどうするか
アドベントカレンダーネタだし集計範囲は2022年に行ったリアクションを対象にしよう！と思いコードを書いていたのですが、リアクションした日時が取得できないことがわかりました。
細かいことを考えるのが面倒になったので、全件取得する実装にしてみたところリアクション履歴の量が多く、1APIコールで1000件ずつ取得しても全件取得に2分程度がかかりました。
でも1ショットのスクリプトだしいいや！ってことで実装完了です🎉
アプリケーションにしたい！Slack Botにしたい！
スクリプトが完成したのが 11/28です。この時点ではまだ記事は全く書いておらず、ひたすらコードを書いてました。
にもかかわらず、「このスクリプトをアプリケーションにしたい！Slack Botにしてみんなに楽しんでもらいたい！」と思ってしまったのです。
「でもアプリケーションを書いたとしてどこで動かせばいいんだ！もう時間がない！」と悩んでいたところあるワードが頭をよぎります。
「Slack Platformだ！」
New Slack Platform
今年の9月にPublic BetaになったSlackの「次世代プラットフォーム」があります。
それが何なのかを超ざっくり説明すると、実装したアプリケーションをSlackのCloudサーバにデプロイします。デプロイ先には実行環境が用意されているためデプロイしたらアプリケーションが動きます。いわゆるサーバーレスです。自身でAWS,GCPなりで実行環境の用意が不要になり最高です！
SlackのDeveloper Relationsの方がとてもわかりやすい記事を書いてるので、詳細はこちらを参照してください。
なんもわからん...
アプリケーションを動かす環境の心配がなくなったとはいえ、Slack Platformの知識といえばDeno使う！くらいしかありませんでした。
カレンダーを見ると 11/29です。「まだあわてるような時間じゃない」仙道もそう言ってます。
まずはサンプルアプリケーションを動かすところからはじめるため、以下の記事を読みました。
サンプルはSlack CLIの操作だけ動かすところまでいけるのでとても簡単でした👍
次はよりアプリケーションを実装する上での概念を知るために、以下の記事を読みました。
「すごく詳細にまとまっていていい記事だな...Functions、Workflows、Triggers...なるほど...なんもわからん...」
アプリケーションの要件を整理する
そもそも作るべきアプリケーションの要件が決まっていないと、限られた時間の中で何を学べばいいのか定まらないことに気づき、実装したいアプリケーションの要件を整理し始めました。
リアクションランキング出してくれるBotさんの要件は以下です。
- Botさんにメンションしたら動作する
- 自分だけではなく、Botさんをメンションした人のリアクションを取得し集計、利用回数が多い順にソートする
- 取得するリアクション履歴は直近利用の最大1000件まで（1APIコールで取得できる範囲にする。それ以上取得するとBotのレスポンスが遅い）
- 利用回数が多いリアクション 上位 20位をSlackにBotさんが投稿する
Botにメンションしたメッセージをオウム返しするアプリケーションを作る
まずは "Botさんにメンションしたら動作する" の要件を実装します。
yusukebeさんが作っていたBotがまさにメンションしたら動作するアプリケーションだったので、これを参考に最初に作ったサンプルアプリケーションを改造しました。
実装できた時の喜びです！
11/30 7:59 AM 「完全に理解した」
11/30 7:59 AM。タイムリミットは近づいています...。
自分だけではなく、Botさんをメンションした人のリアクションを取得し集計、利用回数が多い順にソートする
reactions.list APIのリクエストパラメーターにuserが用意されており、これを設定してAPIコールすると設定したユーザーのリアクション履歴を取得できます。
Slack PlatformのアプリケーションはBotにメンションしたユーザーのIDを取得するような実装ができるため、それを利用しました。
あとは取得するリアクション履歴は直近利用の最大1000件までとするため limitパラメーターに1000と設定します。
これでBotにメンションしたユーザーのリアクション履歴を取得する実装ができたので、あとはAPIレスポンスをゴニョゴニョしてリアクションごとに利用回数を集計し、利用回数が多い順にソートします。
APIコールして、集計して、ソートする実装は元々Pythonスクリプトで実装していたので、それをTypeScriptで書き直す作業だったのですんなり実装できました。
利用回数が多いリアクション 上位 20位をSlackにBotさんが投稿する
利用回数が多い順にソート済みなので、そこから上位 20位を取り出すのはslice使えば楽勝です🏄🏼♀️
あとは上位 20位のランキングをちょこっと整形して、最後はランキングとしてBotさんにSlackに投稿してもらいます。メッセージを投稿する実装は公式SDKが用意してくれている Schema.slack.functions.SendMessageFunctionを使えば楽勝です😎
それ以外にも公式SDKで用意されているFunctionがあり、自身で実装しなくてもそれなりのことはできそうです。
11/30 1:28 PM 「完全に勝利した」
11/30 1:28 PM。う、動いた！
みんなに試してもらう
自分以外の人がやってもちゃんと動くか確認するために、数名に試してもらい、問題なく動いてることが確認できました。
みんな自身がどんなリアクションをよく使っているか知るためにバシバシBotさんにメンションをしてくれて、randomチャンネルはランキングの投稿で埋め尽くされました。自身のリアクションランキングだけではなく、他者のランキングを見てわいわい言い合ってるrandomチャンネルをひたすら眺めていました。
この時「楽しく使ってくれてよかった。スクリプト止まりじゃなくてアプリケーションにしてよかった。アプリケーション開発、、、楽しい😂」と心から思った瞬間でした（仕事しろ）
slack deploy
ここまで作ったアプリケーションをローカルPCで動かしていましたが、このままだとPCが止まるとBotも止まってしまうため、アプリケーションをSlackのCloudサーバーにデプロイします。
slack deployコマンドを実行するとデプロイが完了し、あとはslack trigger create --trigger-def ./triggers/mention_trigger.tsコマンドを実行するだけで、SlackのCloudサーバーでアプリケーションが動くようになります。
一連の開発体験はとても良かったので、また機会があれば使ってみようと思いました。
あなたのSlackでもリアクションランキングBotをお楽しみいただけます
今回作ったリアクションランキングBotをGitHubで公開しています。
実装の都合上 動かすために多少準備が必要ですが、READMEのSetup部分を一つずつやっていただけると、あなたのSlackでもリアクションランキングBotをお楽しみいただけます。
もしご興味があれば試していただけるととても嬉しいです！
何かうまくいかないことがあればissue等でご連絡いただければ、可能な範囲でサポートいたします。
おわりに
new Slack PlatformでリアクションランキングBotさんを作るまでの流れを長々と書きました。
細かい実装の説明をほぼ書いてないので、ご興味が方はGitHubに公開してるコードや公式ドキュメントを参照いただけると助かります🙏
明日 12/2 は @sota1235さんがとってもすばらしいブログを書いてくれるはずなので、お楽しみに😊
おまけ
10Xではエンジニアリングマネージャーの採用募集をしてます！少しでも興味がある方は、まずはカジュアル面談から話しましょう！
