開発者とアーキテクトのためのコミュニケーションガイド ―パターンで学ぶ情報伝達術

11章ナレッジと人

ソフトウェアとアーキテクチャの根本には、最終的に「人」が存在する。人がソフトウェアを使用し、ソフトウェアは人を支援し、そして人がソフトウェアを設計、デザイン、コーディングする。したがって、これらのナレッジパターンの中には、人を中心に展開されるものがあるのも不思議ではない。

相棒、チームメンバー、その他の同僚は、会社だけでなくあなたにとっても資産である。仲間たちを賢く活用すれば、ナレッジマネジメント、ドキュメント作成、そしてソフトウェアアーキテクチャ全体を改善できるようになる。

11.1　早期かつ頻繁にフィードバックを得る

多くの人が犯す間違いの一つは、フィードバックを得る前にその仕事に多くの時間と労力を投入することである。労力とお金が無駄になるだけでなく、システムのアーキテクチャ設計にも影響を与える。これは個人にもチームにも当てはまる。

もしあなたがアジャイルの経験やその背景にある理屈を理解しているなら、アジャイルが最速のフィードバックループを実現するために、早期のフィードバックを重視していることを知っているだろう。イテレーティブかつインクリメンタルな変化。大きい失敗を避けるために早期に失敗する。これらの原則は、成果物やドキュメントを作成する際にも同様に従うべきだ。

もしアイデアや設計についてフィードバックを得ていないなら、変更される要件や、現実的にそのアイデアを見直してくれる別の視点を見逃していることになる。バタフライ効果を考えてみてほしい。初期の一つの誤った仮定が、アーキテクチャを完全に誤った方向に導いてしまうかもしれない。

フィードバックを得ないことは、埋没費用の誤謬に陥ることを意味するかもしれない。人は何かに長く取り組めば取り組むほど、それに変更を加えたくなくなる。それは自分の大切な「作品」だからだ。初期段階でフィードバックを得ていなければ、その後フィードバックを求める可能性が低くなり、設計や図面などにおいて重要な意見を見逃すかもしれない。 ...