こちらの記事はDIVXアドベントカレンダー2022の16日目の記事です。

はじめに

DIVXエンジニアの高井です。

現在はGoやRailsなどを書きながら2〜3人チームでのプロジェクトマネージャーなどをしております。

こちらは弊社で使われているワークルールにフォーカスした記事となっております。

エンジニアが身につけておきたいMyワークルール3選

前提

弊社ではワークルールというものが存在します。
過去にも2件ほど、ワークルールにフォーカスした記事が書かれているようです。

DIVXのエンジニアが目指す「横着しないエンジニア」とは？ - DIVX engineer gateway

午後の眠気と戦わずに済む会社、DIVX。 - DIVX engineer gateway
 
ワークルールの設計は非常に優れていて、個人的には「習慣化しやすく汎用性の高い抽象度」がその魅力の本質だと思ってます。

そこで、その魅力を生かして、自分がいままでの過ちや経験から作ったMyワークルールを3つほど紹介したいと思います。

「結論から話す」とか、100万回くらい言われてるようなことは割愛していますが、できるかぎりどんなポジションのエンジニア、あるいはエンジニアと関わるポジションにも使えるものをピックアップしたので、ぜひ最後までご覧いただけると嬉しいです！

ではさっそく3選の紹介です。

その1：すべての言動・実装に「意図」を持つ

＜どういうときに使うか＞

2つの例を挙げて、このルールがどういったものなのかを説明していきます。

① 質問を送るとき

最近ではいろいろな会社でテキストコミュニケーションが活発になってきていると思いますが、「送られてきた文章の意図がわからない....」みたいなことや、「なんか会話噛み合ってないかも...」と思うことってありませんか？

テキストですべてを伝えるのはもちろん難しいですが、伝え方を少し変えるだけでテキストコミュニケーションはもう少し円滑になると思います。

前置きが長くなりましたが、この場合にとれる対策は

"自分は何を明らかにしたいのかという「意図」を明確にする"

です。

それによって、下記のようなメリットが生まれます。

• 質問の文章から無駄が削ぎ落とされる
• 意図の探り合いがなくなり、レスの往復が少なくなる
• 「それ聞いて意味あるの？」みたいな質問に相手の時間を使わせてしまうことを減らせる

なにかを明らかにしたいケースではなくても

「ヒントがほしい」のか「解決まで一緒にやってほしい」のか「実は質問ではなくただの相談だった」など、相手に何をしてほしいのかを明確に伝えるということが大事になってきます。

「背景」や「前提」、「解決したい課題」みたいな感じでセクションを分けるとより伝わりやすくなるかと思います。

② 実装をするとき

特に1年前後の経験だと、「それしか実装方法を知らないから」という理由で実装を進めしまったり、2, 3年の経験を積んできても「なんとなくきれいだから」「なんとなく短くかけたから」みたいな実装に陥りがちです。

似てる処理をコピペするときなども、「何も考えずにコピペする」のか「コピペ対象のすべてを理解してコピペをしている」のかで結果に大きな差が出ることがあります。（せっかく封印されていた処理をコピペして、より複雑になってしまったり）

その2：結論に対するクリティカルシンキングをする

これはかなりシンプルですね。

＜どういうときに使うか＞

代表的な例としては要件に対して設計をするとき、です。

「まずその要件をすべてもれなく実現できるのか」
「 利用シーンを明確にして、想定外の操作や入力が行われることはないか」
「逆に不要な機能はないのか」

などを考えておくことで、思わぬ考慮漏れや、不要な実装による工数の増加を防ぐ効果があるので、面倒がらずにやっておくことを強くおすすめします。

設計のような大きいスコープだけでなく、資料1枚作るときでも、自身が出した結論の粗探しをするイメージで習慣づけておくのがおすすめです。

その3：「論点の細分化」を意識する

最後です。

＜どういうときに使うか＞

こちらも代表的な例を1つ挙げると、会議の場です。

会議でも、普段の仕事での会話でも、「論点」というのは少ないに越したことはないと思っています。

特に会議においては論点（つまり議題）が増えると下記のようなデメリットが如実にあらわれてきます。

• 時間が伸びる
• 参加人数も増える

つまり会社全体の「時間という資源」が減ってしまうという結果に繋がります。

そこで、「設定した会議で取り扱うべき話はなにか」を突き詰めることで、以下のような考え方をすることができます。

「実は論点が分割できないか」
「6人招待したけど、前半の論点は実は2人だけで結論を出せば良いのではないか」

もし、参加者6人の1時間の会議でも「議題」を分割することで2人で30分(=1時間)、4人で30分( = 2時間)という分け方ができるなら、シンプルに組織全体で3時間分の時間が生まれます。（2回目の会議を6人で行ったとしても組織全体では2時間分節約できる）

ぜひカレンダーを見直して、自分が設定した会議に細分化の余地がないかを見直してみてください。

もちろん会議などの場ではなく、その1で挙げたようなシーンでも使えるかと思います。

どう身につけるか

もちろん振り返りが大事なのは言うまでもないんですが、最後に自分なりの振り返りのコツを紹介して締めようと思います。

他者の視点を大事にする

ワークルールは身につけたつもりでも実は身についてなかったり、たまに違反してしまうことが多々あります。（自分もそうです）
そんなときに、大事なのは「他者の視点を大事にする」ということです。言い換えると自分を客観視するということにもなるかもしれません。

例えば、下記のケースが発生した場合は、他者の視点を細かく取り入れることによって解決することが多いです。

• 自分が「意図を持って実装した」と思っていても、レビューで受けた質問に回答できない
• 「意図を整理して質問をした」と思っても、あまりうまく伝わらずに無駄なやりとりが続いてしまった
• クリティカル・シンキングで考慮漏れを潰したはずなのに、レビューにより考慮漏れが見つかって手戻りが発生した

これらの問題に対しては、それぞれ、細かく相手に理解度の確認をする一文を挟んだり、設計などは5割段階や7割段階で一度レビューを挟んだり、他者の視点を取り入れるアクションをするのがおすすめです。

具体で振り返る

前提として、ワークルールを身につけるには、下記のようなステップになるかと思います。

① 無意識に違反してしまう
↓
② 違反したあとに気づく
↓
③ 違反してすぐに気づく
↓
④ 違反する前に気づく（完璧！）

しかし、冒頭でも書きましたが、ワークルールはある程度抽象化されています。
そのため、②③あたりでは「具体で振り返る」というステップが大事になってきます。

「具体で振り返る」とは、そのままの意味で、振り返りをする際はその日・その週にあった「ワークルール違反」のシーンをなるべく具体的に思い出して、ワークルールと実際の行動を結びつけることです。

これにより④にたどりつくことができると思います。

おわりに

DIVXでは一緒に働ける仲間を募集しています。
興味があるかたはぜひ採用ページを御覧ください。