既存の機能から設計を学び、調査力を向上させて、知見を共有しよう

はてなブックマークチームの id:itchyny です。

チームのメンバー間で知見を共有することは、とても大事なことです。 特に開発エンジニア同士のコミュニケーションを増やし、お互いに足りていない知見を共有し合うことでチームの生産性を向上することは、プロダクトの成長につながります。

プロダクトの実装や設計の知見を共有するためによく取られる方法として、詳しい人が講義形式で教えるというスタイルがあります。 特に、チームに新しいメンバーが入ったときには、プロダクトの概要やコードのアーキテクチャについて説明することは一般的に行われています。

講義形式で教えるというスタイルはよく行われる方法でありながら、いくつかの課題があると感じています。 まずは説明会に参加するメンバーが、どうしても受け身になってしまいます。 説明された瞬間は分かったような気になっていても、次の週には忘れてしまうことはよくあることです。

また、オンボーディングで疲れていて、立て続けに行われる説明会に集中できていないかもしれません。 そして、発表資料を作り説明する側の負担もあります。

知見共有がチームの生産性を左右する

メンバーの知見をベースアップさせることはもちろん重要です。 しかし、知見を共有すること自体が目的ではありません。 各メンバーがプロダクトの設計指針を理解し、既存の機能の拡張や新機能の実装において、適切な設計を自ら導き実装できるようになることが最も重要なことです。 個々人がコードの設計を正しく理解して、自律的に適切な設計を行えるようになることで、チームの生産性が大きく向上するのです。

また、チームに長くいるメンバーほど不具合の原因を見つけるのが速いということはよくあります。 しかしその場所を特定するために取った手段や思考回路まで伝授するのはなかなか難しいものです。 プロダクトに詳しい人が鋭い嗅覚を持っていて、コードやログを高速に見ていくうちに原因を言い当てるという光景を見たことはありませんか。

チームメンバーが機能の実装を追って、その背景にある設計指針をキャッチアップできるようにするにはどうすれば良いでしょうか。 不具合の原因を特定するための手法を身に着けてもらうためにはどうすれば良いでしょうか。

設計の調査力を演習形式で身につける

私の所属するチームでは、この春より「設計調査会」を定期的に開催しています。 既存の機能を拡張するときも、新機能の設計を考えるときも、不具合の原因を調査するときも、最終的には個人の調査力が問われます。 こういった調査力を、演習形式で身につけるという趣旨のミーティングです。

会の時間は一時間、同じチームのエンジニア数名で行っています。 集まってから「今日のお題」を考えます。 サービスの機能や、実装の仕組み、特定のマイクロサービスなど、どんな軸をお題にしてもかまいません。 会が始まってからお題を決めるのは、予習できないようにするためです。

お題が決まったら、25分ほど時間を取って各自の調査を行います。 同時編集できるwikiを使いながら、調査した手順や分かったこと、ソースコードやドキュメントのリンクなどを各々が書き込んでいきます。 時間の制限がある状況で実装の確認をしたり、ドキュメントや過去のissueから仕様を素早く把握する瞬発力が養われます。 みんなで仕様をきれいにまとめるのではなく、人ごとに調査結果をスピード重視で書き込んでいくのが良いでしょう。

会の後半では、各々が調べた内容や手順を発表します。 ここでは主に調査の手法、機能の仕様、実装箇所などについて議論します。 また、仕様の策定経緯、ドキュメントの不備、理想的な設計や技術的負債について議論しても良いでしょう。

実際に設計調査会をやってみると、ページの機能からコードにたどる手段や、その後コードの中を探っていく様子が人それぞれで勉強になります。 調査時間が限られているので、今回はここから先は追わないといった枝刈りの判断も大事になってきます。

この会で発見された古いドキュメントを整備したり、調査した機能の不備を修正するタスクを立てたりすることもありました。

既存の設計を知ることが次の設計に役立つ

既存の機能や設計について調査することは、日常の業務で必要になることです。 サポートの対応や障害発生時など、機能の仕様や構成を調査する瞬発力が求められる場面も少なくありません。 既存の良い設計を知っていることで、新しい機能を設計するときにもプロダクトに合ったものを導くことができます。

設計調査会は、その日にお題を決めて、各メンバーが能動的に調査を行い、その手順や実装箇所、設計や技術的負債について議論する会です。 講義形式の会とうまく組み合わせながら、メンバーの調査力や瞬発力を養い、開発力や生産性、障害対応力につながる良い方法だと考えています。

最初はサーバー側のエンジニアが集まって始めた会でしたが、ネイティブアプリのエンジニアや、企画職でも開催できるフレームワークです。 ぜひ、参考にしていただければ嬉しいです。