Communication sciences

コミュニケーションとは、情報伝達である。

開発におけるコミュニケーションは目的ではなく、情報を伝達する手段の一つだと考える。では、一人で開発している場合は不要だろうか。一人で開発していても必要だと思っている。極端な話で、一人で今だけ開発しているなら不要とできるだろう。今だけでなく、継続して開発していく場合は、未来の自分に対してコミュニケーションが必要になる。

情報を効率良く伝達するためには、情報を構造化して記述していくことが望ましいと考える。これは繰り返しの記述を避けることにもつながるし、構造化しづらいのであれば、扱っている情報の整理が必要であるサインかもしれない。Wiki に代表されるような形式で構造化できると良いと思っている。

情報の中に課題やバグと呼ばれるものを扱うときは、 Issue Tracking System や Bug Tracking System が有用だろう。これはその課題やバグごとの状態管理、共有のしやすさが非常に優れていると感じる。口頭やメール、静的ファイルの共有と比較すると尚更である。

さて、これらの情報をどのように記述するのかは、関わっているチーム、メンバーによるだろう。情報伝達なので、意図した内容が伝わらないと意味がない。これにはレビューを繰り返していくしかないだろう。なのでレビューをしやすい環境作りが重要であると考える。

ここで究極の情報伝達とは何かと考えると、テレパシィだろう。何も伝えずに伝わる。こういったテレパシィの類は実現可能だと考える。経験に裏打ちされた先読み、直感的なもの、サッカーや将棋、演奏のアドリブなんかはこれに近いものがあるのではと思っている。これらは相手あってのもので、知識を詰め込むというよりも、体験の共有によって、蓄積した経験が回答へのショートカットを生成し得る。これはパターン認識なのだろうか。であれば、デザインパターンと呼ばれるような型を学習することで知識を詰め込むことで到達可能だろうか。

情報を構造化する前段階のメッセージのやり取りに関しては、対個人でやり取りするよりもスレッドやチャネルといったテーマごとにやり取りできると、その時点で構造化の第一段階をクリアしている。各テーマごととなっているので、やり取りする内容がそこに属しているのか、新しいテーマなのではと意識することにもなるので、情報が混ざって埋もれるようなケースを回避しやすくもなる。

これらの実現のために利用しているもの

- Redmine

- Slack

- Bitbucket

どのレベルにおいても Redmine は有効だと思う。

Slack はメッセージのやり取りに関して優れている。

Bitbucket はリポジトリと密に連携しているので、コードを起点とできるプロジェクトであれば Redmine よりも手軽に始めることができる。Redmine のリポジトリ連携はプラグイン次第だが弱い。