「広木さんに聞く！ 開発者体験向上のためのエンジニア組織づくり最前線vol.6」に参加した
今週これに参加してきた。ちょうど開発者体験について考えることが多くなってきていて、具体的にやりたいことを会社でも話すことが増えてきていて自分的にはタイムリーな内容だったな。 findy.connpass.com
主にこの 3 つについて話がされていた。
・良い組織文化づくり
・生産性向上
・採用力強化
"開発者体験への投資"というのは、生産性・組織文化・採用力の連関を意味していて、このサイクルが回り始めると開発者体験はブラックホール的に良くなっていき、そうじゃないところはどんどんスカスカになってしまう。。
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2022年3月29日
#エンジニア組織_findy pic.twitter.com/q2fHpWAzf6
生産性と採用に関しては自分もよく開発者体験の話をする際に話題に出していたけど、確かに文化としても良いよなと感じた時間だった。(安心して開発できるなどは生産性向上の方に含めて考えてた)
特に新しいものに挑戦ができることや、嫌だなと思うもの不満に思うものに向き合って改善ができるという文化は、働く側としては生産性の高さよりも重要に感じる。
じゃあまず何からやろうかと思うだが、話の中でCTO 協会が監修している DX Criteriaというものが紹介されていた。(クライテリアは基準という意味らしい) あるべき姿やアンチパターンがたくさん記載されていて、まずは自分たちの現状を把握するという意味でこの診断を行ってみるのは良いのではと感じた。 dxcriteria.cto-a.org
実際 DX Criteria を使って改善した話は、ここにいくつも参考のブログが記載されている。
何を持ってして開発者体験が良くなったのか？を示すのは難しいよなぁと感じていたので、このように数字で出せるものがあると OKR など目標管理にも含めやすいので助かります！ まずは DX Criteria を使って現状の可視化・数値化を行い、そこから優先度をつけて改善していくということをやっていきたい。
スマホは Brave、PC は Sidekick をメインのブラウザとして使い始めた
もともと全部 Chrome を使用していたが、最近は Brave と Sidekick をメインのブラウザとして使い始めて、もう Chrome には戻れないなという感想。
Sidekick のスマホ版のアプリがないので、Brave を使用しているが、広告が全てブロックされるのでそれだけでかなりよくなった。自分もブログに広告貼ってるけど、広告があるページなんて見たくないので、スマホで Chrome はとてもじゃないけど使えなくなってしまった。
Sidekick に関しては、Chrome の上位互換という感じの印象で、Chrome の拡張機能は使えるし設定も Chrome から引き継げるので移行は簡単。デフォルトで広告を削除してくれるし、サイドバーによく使うアプリを登録しておけたり、セッションの切り替えができる。Chrome でもプロフィールの切り替えで似たようなことができるけど、拡張機能も含めて別物になってしまうので正直使いにくかった。 特に個人的におすすめなのは、Sidekick のトップページにある検索機能。ブックマークや履歴、使用しているアプリのコンテンツなども含めて検索をかけてくれる。(表現が合ってるかわからんが) あのドキュメント(もしくは記事)どこでみたんだっけみたいな時に一気に検索かけられるので、めちゃくちゃ便利。Notion のドキュメントだったり、自分の履歴などから検索をして候補を表示してくれるので、必要なページを見つける手間が省ける。
ブラウザなんて Chrome があれば十分でしょと思っていたけど、まさか他のものを使うようになるなんて自分としては意外だった。ツールも含めて盤石に見ててても変化があるよなと改めて認識した。
前提を変える大切さ
最近仕事が忙しくて、残業ありきでスケジューリングをしてる。シンプルに量が多いので残業が発生することはしょうがない面もあるのだが、残業しないと終わらないという前提のもと取り組んでいるのはあまり良くないのではと思った。
コーチングに関わり始めてから思うこととして、できると思ってやらないとできないというのがある。できると思えていない時点で、理想像の解像度が低かったりそこに近づくために何をするべきか、何が使えるのかがわかっていない。もちろん解像度を上げた結果、それはできないものであると判断することもあるが、ほとんどの場合はそこまでにいかない。よくわからないから自信が持てない、そこに意味を見いだせないというケースが多いように思う。
なんでこんなことを書こうかと思ったかというと、週末に NLP の本を再度読んだことがきっかけだった。本の中で紹介されていた事例に、毎日ホワイトボードにその日の退社予定時刻を書くことによって、残業せずにその時間に帰るようになったチームの話があった。その時間に帰る、つまりそれまでには仕事が終わっているという前提になったことで、良い変化が生まれたという話だった。
なるほどと思ったので、今自分の中にどんな暗黙の前提があるんだろうと考えてみると、タスク量が多すぎて残業をしないと終わらないということが思い付いた。 確かにタスク量は多いけど、時間を意識したらもっと集中してタスクを終わらせられる感じもするし、タスクの順番を変えることで他の人から早めにヒアリングをしたり FB をもらったりして、余計な作業はなくせるのではないかと思ってる。そもそもやらなくても良い仕事もあるとは思う。 あと、英語に関しても話せると思うのか話せないと思うのかでかなり違いが出てくるなと感じた。これも話せると思っていると、自分ができる表現で伝えようとしたり、言葉が出てこなくても焦らずに探すことができる。逆にできないと思っていると、何も思いつかなかったり、そもそも話そうと思わなかったりする。
自分1人で自分が当たり前だと思っていることに気がつくのは難しいので、ここで誰かと話す中で気が付けると良いんだよなと思う。 また外部でコーチングを受けようかなという気持ちになってきた。
モチベーション大百科読んで内発的動機付けの重要性を感じた
図書館にあったので、全部は読んでないけどさらっと読んでみた。「自主的な行動に対してごほうびを与えると、内発的動機づけが損なわれる。」という話を読んだときに、ブログが続かなくなった理由がこれだなと思った。
もともとは Qiita で技術ブログを継続して書いていたけど、徐々にそれが継続できなくなってきていた。
自分のために始めたもので、自分の学習効率をあげたり同じ問題につまらないようにすることがメインだったのに、途中からいいねが来ることを気にするようになっていた。Qiita の仕様が変更されたこともあり、あまりいいねが付きにくくなり、そこをモチベーションにすると続かなくなっていった。
そこからはてなブログで書くようになったけど、こっちはこっちで PV 数を気にしたりし始めて、自分のために書けなくなっていたなあと振り返って思う。「外発的動機 < 内発的動機」にしていく必要があって、もっと内発的動機の解像度をあげるなり意味づけをするか、外発的動機を消してしまうか。外発的であれ動機があること自体は良いと思うので、やっぱり解像度をあげると言うのが大事だな。
なんでブログ書こうと思ったのかを考えると、思考の整理と経験に再現性を持たせるためというのが思いついた。なんとなく考えていることを言語化するプロセスによって、思考が整理されるし言語化できると次似たようなことがあった時にも同じ結果を出しやすくなる。
技術ブログも同じで、同じようなエラーで自分が詰まったり他の人が詰まったりするから、このエラーが起きたらこうすれば良いよねということを残すことで、何度も問題を乗り越えられるようになる。どんな背景・考えで設計したのかを言語化できると、次に設計する時にも同じ観点で設計するべきなのか他の観点を取り入れるべきなのかがわかりやすくなる。ちょっとずつ解像度をあげていこう。
習慣を作るときはイレギュラーをなくす
先月のコーチングでブログについて話をした。継続したいけどできないというあるあるな内容。話した内容は省略するけど、毎日継続するためにどうしたら良いかを考えて、お昼休みに毎日 5 分でも良いからやることにした。
朝は起きれないし、夜は残業をした場合やお酒飲んだらやらなくなるので、一番確実に時間が取れるのが昼だなということで、昼の時間の一部をブログ継続のために使うことにした。
最初の方はうまくいっていたけど、MTG がお昼に急遽入ってしまったりして、休憩が細切れにしか取れなかったりした。こういうケースがあると、お昼に 1h 纏まった休憩が取れなくなって、30 分 30 分に分けて分けて取ったりしている。ただ 30 分しかないと、書くところまで行かないので、毎日ちゃんとまとめて 1h 休憩を取りたい。
そんなことを考えていたら、イレギュラーなケースをなくすことって新しい習慣を作ろうとするときには大事だなと思った。よくあるのが夜何かやる予定でも飲み会の予定が入ったとか、前日遅くまで起きてて、毎日朝やってたことができなかったとか。
もちろん飲み会であれば自分で管理できるが、仕事の MTG となるとある程度どうしようもない部分がある。そうなると、じゃあどうやってイレギュラーを取り除くかというよりも、イレギュラーなことが入らないであろう時間を見つけることが結構大事だなと。そう思うと朝なんだよね。そこまで早過ぎなくて良いから、8 時からで十分だ。そうすると 7 時半には起きたい。
イレギュラーなことがあってもやろうと思えるほど、解像度を上げることも大事なんだろうなと思いつつ、なんとしてでもやり切るってのは結構エネルギーが必要なので、無理せず続けられるようにしていきたい。
やりたいことと実践する機会の2軸で判断する
ちょうどこの前勉強していた資格に合格して、次何を勉強しようかなと思い始めたのでその言語化をする。基本的に普段はやりたいことがあればそれを優先してやるようにしていたが、いくつかある候補の中に大きな序列はないなという気がしているのと、他にも判断をする軸があった方が良いなと思った。
資格取得の振り返りをする中で、「学習した内容と自分の経験を結びつけられたのがよかった」ということが出てきた。実践する場があるものは勉強したものをすぐに活かせるので、モチベーションも維持しやすいしゲームのボーナスタイムみたいなものだなーと思う。
これを軸に入れると良さそうだなと思っていて、自分がやりたいと思うものを X 軸、実践する場があるものを Y 軸 として 4 象限に分けると良さそう。
自分がやりたくて実践する場があるものは一番優先度が高いし、やりたくもないし場もないものはやらない。そうすると、ポイントになるのはこの 2 つ。
- やりたいことの場をどう作るのか
- 実践の場があるものをもっとやりたいと思えるようにする
やりたいことの場をどんどん作れるのが良い気がするが、実際には毎回そうも行かないので、1 に取り組む場合にはものによっては長期的にやる必要がある。2 に関しては、変化が早い時なんかは戦略として良いなと思う。
formrun で GTM を使う場合にはコード型フォームじゃないと設定ができない
前に調べたけど、ピンポイントに必要な情報を取りに行くことが難しかったのでメモとして残しておく。 タイトル通りで、GTM を使いたければコード型フォームを使うしかないらしい。 画面からぽちぽちして作成したフォームには GA のタグは入れられるが、GTM はだめと。GTM を使用したければコード型に変更して、自分で HTML に GTM のタグを埋め込む必要があった。
※クリエイターフォームをご利用いただいている場合、GTMは設定できません。コード型フォームをご利用ください。
