💬

今年の抱負『もっと言語化しよう、共有しよう』

2024/01/08に公開

アジャイル

ドキュメント

idea

解決すべき問題がうまく定義付けられた時点で、問題の半分は解けたようなものだ。
A problem well defined is half solved.
チャールズ・ケタリング (アメリカの発明家)

問題を明確に書き留めれば、問題は半分解決したことになります。
If you write the problem down clearly, then the matter is half solved.
Kidlinの法則

明けましておめでとうございます🎍年末年始はしっかり休みました。しっかり休むといつもは考えないことが浮かんできたりして有意義な時間になりますね。

2024年は「もっと言語化しよう、共有しよう」と思い、言語化やその共有について考えてみました。

言語化のメリット

そもそも言語化とは、事象や概念を言葉で表現することです。
言語化のメリットを理解して言語化と向き合っていきましょう。簡単にメリットをまとめてみました。

あいまいなことが明確化される

言語化するだけでも次のようなメリットがあります。

対象を十分に観察するきっかけになる。
分からない、決めていないことを「分からない」「決めていない」と認識できる。
意外な事実に気づくことがある。

他の人と共有できる

言語化されると、それを他の人と共有できる状態になります。そして共有には次のようなメリットがあります。

他の人が言語化したものを自分が考える土台にできる。
気がついていなかったことを認識するきっかけになる。
お互いに言語化・共有することで認識の違い・ズレがはっきりとする。
- 認識の違い: 認識が違うこと、違うことだけでネガティブな意味はない。
- 認識のズレ: 同じ認識であることを期待されているが実際はズレている。（厄介）
しっかり言語化したものが共有されていると質の高い議論ができる。

なぜ課題を言語化・共有しないのか

課題があると感じたら通常は言語化して対応方法を考えて行動します。しかし課題の言語化、あるいはその共有を避けてしまうケースがあります。

忙しい、すぐに対応しなくても困らない

忙しい、すぐに対応しなくても困らないという理由はあるあるではないでしょうか。

言語化することで課題の理解が深くなり、対応する方法や予定を考えることができるようになります。チームの課題であれば、すぐには自分で対応できなくても共有しておけば、誰かにフォローしてもらえる可能性があります。

分かっていても、忙しすぎると後回しにしてしまいますよね。

課題の共有と心理的安全性

チームに課題を共有することを避ける理由として、次の理由が考えられます。

自分の責任だと思っているため、共有したら責められるかもしれない
課題を共有することが相手を責めているように受け取られたくない

これらの理由は、心理的安全性と深い関係があると思います。

以下の記事は心理的安全については分かりやすく解説されています。勘違いされやすいポイントについても触れられています。

https://diamond.jp/articles/-/330163

喧嘩するほど仲がいいという言葉がありますね。お互いを深いところで信頼している関係では、どんなことでもコミュニケーションできます。そしてコミュニケーションが発生するからこそ喧嘩のようになってしまうこともあるわけです。

開発チームの場合、喧嘩はマズイですが白熱した議論ができる関係はいいですね。鋭い意見を交換しながらも相手を責める意図はなく、プロジェクトを進めていくためにそれぞれが自分の考えを表明できる関係です。

心理的安全性が低いチームでは、メンバーは課題や意見について「これを共有すると誰かと気まずい関係になる可能性があるな、それは面倒だから共有するのは避けよう」と考えてしまうかもしれません。

心理的安全性を高めることで課題がスムーズに共有されそうです。どのような方法によって心理的安全性を高めることができるのかについては、他の記事に譲りたいと思います。

問題解決のための言語化

問題解決の糸口が見えないときに、試してみたい方法を紹介します。

ラバーダック・デバッグ

おもちゃのアヒルに話しかけて、コードを説明するというデバック方法です。話しかける対象はクマの人形でも何でもOKです。問題の解決のためには十分な問題の把握が不可欠です。冒頭で紹介したチャールズ・ケタリングの言葉を思い出しましょう。

解決すべき問題がうまく定義付けられた時点で、問題の半分は解けたようなものだ。

コードを読みながら分かっていることをアヒルに向かって言語化することで情報を整理します。あるべきコードについて説明しながら実際のコードとのズレを明らかにします。

私はおもちゃのアヒルに話しかけたことはありませんが、バグに苦しんでいるときほど独り言が増えますね。自分で自分に説明しています。

デバック目的以外でも、抱えている問題についてアヒルに説明することで解決の糸口を掴むこともできそうです。

トーク・スルー

ラバーダック・デバッグは、ものに話しかける手法ですが、トークスルーは人に話を聞いてもらう方法です。

聞き手が必要なのでラバーダック・デバッグよりもコストが掛かるというデメリットがありますが、聞き手のスキルによってはより早く解決策に辿り着ける可能性があります。

私は学習塾で勉強を教えていました。問題が分からないという生徒には、「どこが分からないの？」と質問して、取組んでいる問題がどのような問題なのか説明してもらいます。その過程で生徒が自分で問題を理解するというのはよくあることでした。

開発チームで実践できる言語化

言語化のメリットは個人でもチームでも大きなものだと思います。開発チームにおいては、言語化する習慣やスキルはプロジェクトを円滑に進めるために欠かせないでしょう。

開発で実践できそうな言語化ポイントを考えてみました。

注意するべき振る舞いやコードに感じている課題について、実装するときには分かることでも、コードを読んだ他のメンバーにはすぐには分からないかもしれません。コメントを残して共有しましょう。

あとで注意を向けるべきコメントを見返せるようツールを導入しておくと便利です。

Todo Treeは注意を向けるべきコメントをハイライトしたり、それらを一覧表示する機能があります。

Issue

私はタスクと課題を言語化するための場所としてIssueを使っています。

リポジトリを変化させるタスクはすべてIssueにして、チケット駆動で開発しています。私がどのようなタスクに取り組んでいるのかはチームメンバーにいつも共有されています。

また、私はとりあえず課題に感じていることがあればIssueをオープンします。するとメンバーからどのような対応方法が考えられるか、また対応するべきかどうかなどコメントがもらえます。もし2〜3ヶ月対応できずに放置してしまうような場合はクローズします。また自分でIssueに書いた課題について数日経ってから読み返してみると、課題の評価が変わって「対応するほどのことではないな」と思うケースもあります。そういった場合もクローズします。とりあえずIssueに書いておけばクローズされた課題でも検索できます。

PR

PRを書くタイミングは、いろいろなことを言語化するきっかけになります。

私はPRを書きながら課題に気がついてIssueをオープンすることが多いです。PRを書きながら気がつくIssueは、リファクタリングしたいポイントやREADME、Design Docに書いておきたいことなどがあります。

またPRを書いてみて、PRよりもコメントに書いてある方が分かりやすいと思う内容なら、コードにコメントを追加してコミットします。

README

READMEは、プロジェクトに参加したメンバーがまず知りたいことについて書きます。

目的のファイルはどこにあるのか
新しく追加するファイルはどこに置けばいいのか
カスタムスクリプトがあるなら、その目的や使い方

言語化が不十分な場合は特定タスクが属人化しやすいので、既にいるメンバーにとっても有益なものです。

Design Doc

Design Docはエンジニアのためのドキュメントです。コードの断片を読むだけでは全体を把握しにくい内容について書きます。以下は私が書くDesign Docの内容の一例です。

アプリケーションの目的、仕様
アーキテクチャー
キャッシュ戦略
採用しているMVCなどのモデル
複数パッケージに分けて開発している場合はそれぞれの役割
認証処理の詳細やS3のキー設計など

Design Docに書く内容は他の記事も参考にしてみてください。エンジニアが知りたいこと、周知しておきたいことなら何でもOKだと思います。

「象、死んだ魚、嘔吐」

「象」は口に出さないけれど全員が知っている真実。
「死んだ魚」は、放っておくと事態が悪化する悩み。
「嘔吐」は、人々が断罪されずに胸の内を話すこと。つまり「ぶっちゃけ」。

「象、死んだ魚、嘔吐」というのは振り返り手法の１つです。

メンバーがオープンマインドの姿勢で日々の作業に取り組むことができていれば、知識や課題の共有についても自然に行われるでしょう。しかし、なぜ課題を言語化・共有しないのかで課題の言語化の壁となる状況について書きましたが、そういった状況で言語化されていない課題を洗い出すための手法と言えます。

課題について一人で抱えているうちは周りの人が協力することができません。しかし言語化して共有することでみんなで考えることができるようになります。プロジェクトにスピードを感じないのに具体的な課題が見えないようであれば、象、死んだ魚、嘔吐の振り返りが価値を発揮するかもしれません。

技術記事

ZennやQiitaのようなプラットフォームなどで知識を共有するために記事を書きます。また、私は知識の整理のために記事を書こうと思い立つケースが多いです。

開発チームのタスクとしてそういったプラットフォームで技術記事を書いたことはないですが、公開できる内容の記事であれば社内向けのドキュメントとして書くより公開するために記事を書いた方がよいと思います。公開する記事を書くときは自分やチームのためにドキュメントを書くときよりも注意深く事実を確認すると思います。そのためより信頼できるドキュメントに仕上がります。

また、公開することでよりたくさんの人に読んでもらうことができます。そして間違ったことを書いているとコメントで教えてもらえることがあります。自分の記事によって間違った情報を拡散しないように責任感を持ってメンテナンスすることが大事だと思いますが、公開することでよりたくさんの人にレビューしてもらえる状況になるので公開した方がお得です。

まとめ

今回、記事としてまとめてみると課題の共有と心理的安全性はとても深い関係があると気がつきました。これも言語化による収穫ですね。

2024年はたくさんアウトプットする年にしたいと思います。最後まで読んでいただきありがとうございました。