イントロ
Vol.8 まで特定の技術にフォーカスして記事を書いてきましたが、ここではPJ内でのコミュニケーションについて以下記載しようかと思います。コミュニティガイドラインに照らしあわせて、純粋に技術的な内容ではないので迷った部分もあるのですが、過去の開発PJ内での経験を元にプログラミング、システム開発に役立つものとして記載します。
現在は、SlackとGitHubのプルリクエストでのやりとりをメインに、時々対面での打ち合わせで開発をしています。GitHubのIssueやConfluence上のコメント機能を使うこともありますが、基本はSlackとGitHubです。ドキュメンテーションは、ConfluenceとG Suiteです。
それ以前は、SI案件かつ顧客企業とは別の場所で開発していたので、Redmineのチケットでのやりとりをメインに時々メール、電話、対面での打ち合わせを実施していました。開発内部は、顧客企業向けとは別にRedmineのプロジェクトを立てて、やりとりをしていました。ドキュメンテーションは、ExcelとPowerPointです。
トピック整理
過去のPJ内でのコミュニケーションを整理してみました。
- アナログ
- 対面での会話
- 電話
- TV会議、Web会議
※デジタルなコミュニケーションではあるものの、その特性からアナログに分類しています。
- デジタル
- メール
- プルリクエスト（GitHub）
- チケット、Issue（GitHub）
- Wikiのコメント機能
- チャット（Slack）
アナログ
アナログコミュニケーションですが、PJ開始当初や初めて仕事をする相手とは信頼関係を築く上で重要だと思います。単に情報のやりとりをする上では、デジタルのコミュニケーションで事足りるし、むしろデジタルの方がメリットがある部分も多いと思います。
ただ、言語化できない部分からしか知り得ない情報もあると思います。チームをまとめるリーダーであれば、チームメンバーの表情だったり、話し方だったり、そういった部分から気持ちを推し量る。この気持ちを推し量るという意味だと、自社開発であれ、SIであれ、非エンジニアとのやりとりで重要な部分だと思います。
プログラミング、システム開発というロジカルな作業ではあるものの、関わっているのは人なので、感情面での考慮に意識を向けることは、結果的に良いプログラミング、システム開発につながると考えています。
100％の置き換えとは思わないものの、オンラインミーティング（TV会議、Web会議）等の活用でも充分に代替できる部分だと思います。
信頼関係構築、感情的配慮、この２点が開発PJ内でのアナログコミュニケーションのポイントだと思います。
デジタル
デジタルコミュニケーションの特徴としては、コミュニケーションが記録されることだと思います。記録されることで後から検索して確認できるし、リアルタイム性が必要とされないトピックは、開発メンバーの都合に合わせてやりとり出来ます。
特に前者は、コミュニケーション自体に再利用性があることで、開発の生産性に貢献していると思います。例えば、よくあるのが開発環境の設定で「Aという事象が起きたんだけど、解決方法知らない？」というパターンです。聞かれた本人が知らなくても、Slackで検索かけたりすると割と出てきたりします。
StackOverflowだったり、ネットで検索してもいいと思うのですが、起きた事象によっては、検索の母集団が開発PJ内の方がより早く、場合によっては、ネット上の情報を噛み砕いた上での解決方法が出ていたりするので有効かと思います。
メールベースのコミュニケーションだと「Aさんのメールボックスにはあるけど、Bさんのメールボックスにはない」ということが発生するので、コミュニケーション自体の再利用性が個人に限定される割合が高いと思います。
SlackでもDirect Messageを使っていたり、Privateなチャンネルを使っていると似たようなことになるのですが、ここらへんは、開発PJ内でのコミュニケーション指針だったり、啓蒙をすることで防げると思います。
また、Slackのようなチャットツールが導入できなくても、Redmineのチケットのコメント機能を使うことで、コミュニケーション自体の再利用性を高めることは可能だと思います。実際、以前のプロジェクトでは、Redmineのプロジェクト内に「対顧客」「開発内部」でのやりとりがまとまっていたので、再利用性が高かったように思います。
今考えれば、Slackのチャンネル、もしくはスレッドがRedmineのチケットという関係にあったように思います。コードレビューもRedmineのチケットにコミットを紐付けることで実施していたので、これがGitHubのプルリクエストに相当するように思います。
ドキュメンテーションとの関係
再利用性という面では、適切なタイミングでやりとりの内容を整理してドキュメンテーションする必要はあると思います。ただ、過度なドキュメンテーションは、開発の生成性を低下させます。また、ドキュメント化するということは、常にメンテナンスの必要性とセットで考えなければならないと思います。
劣化したドキュメントによって不要なコストを払うことになる、のも開発の現場でよく見てきました。ドキュメント化する際は、デメリットも考慮した上で判断しなければいけないと経験上感じます。必要最小限のドキュメンテーションと再利用可能なコミュニケーションの資産化が今、開発の現場に求められていることなのかもしれません。
振り返ってみて
あるシステムを作る場合、そのシステムは、複数の機能から成り立つと思います。そして、その複数の機能を開発する上でそれぞれにコミュニケーションが発生すると思います。仕様の検討から技術調査、開発時の確認等、様々なやりとりが発生します。
使用するツールは、Slackであれ、Redmineのチケットであれ、特性や必要に応じて使用すればいいと思うのですが、コミュニケーションの単位と前述の再利用性を意識することは、開発・プログラミングの生産性に関わってくると経験上感じています。
コミュニケーションの単位は、「どんなトピックに対してどういったメンバーでコミュニケーションすべきか」という部分です。Slackでいえば、チャンネル作成をする時に考えることだと思いますし、Redmineでいえば、チケットを作成するときの通知範囲かと思います。
ここが意識されていないと、ノイズ（＝不要な通知）が増えて開発の邪魔をして生産性が落ちるし、後からやりとりを探すのも手間がかかったりするな、というのは、これまでの経験上よく思います。
必ずしもその関係性はイコールとはならないと思いますが、ソフトウェアを設計するのと同様にコミュニケーションも設計することは、良質なソフトウェア開発につながると思います。