開発者の皆さんへ：ダイアグラムはそんなに複雑である必要はありません
開発者へ：ダイアグラムは複雑でなくてもいいです
単純に言うと、私たちは図表を過度に考えすぎています。
図表の作成は、コードのドキュメント化プロセスの重要な部分です。しかし、通常、それは煩雑で時間のかかる作業と見なされます。図表はすぐに細かすぎて詳細すぎるものになります。最も重要な詳細は複雑さの海に埋もれてしまいます。
UML図の曖昧さを減らすために、開発者はしばしば図の読み方に特定の記号や標準化を導入します。すると、図は記号でいっぱいになり、読むためにはある程度の知識が必要になります。実質的には、図の中でコーディングを行っている状態です。また、もし千ページのビジュアルを作成していないのであれば、図はコードの詳細さを表現することはできません。
「図をできるだけ正確にしたい」という気持ちは良いものですが、曖昧さを減らすどころか増やしてしまっています。これはUML自体の過度の複雑化のせいだと言えるかもしれませんが、私たち開発者もその一部です。
図に過剰な情報を詰め込むことは、意図したメッセージをぼやかし、読者を混乱させる原因になります。私たちはこれらのデメリットについてもっと意識するべきです。詳細を追求する中で、開発者はコンセプトを効果的に伝えるという本来の目的を見失ってはいけません。
図は有用な情報を含み、かつ読みやすいものであるべきです。図は、複雑なソフトウェアシステムの全体像や細部をチーム間で伝えるのに役立つべきです。そして、作成するのが簡単で楽しいものであるべきです。
共同の心構えの変化、新しい図示ツール、そして便利な統合の重視によって、図はライターと読者の間で情報を伝達する効果的な手段に戻ることができます。プロセスを再度簡素化することで、図作成を再び楽しいものにし、AI主導の職場におけるより良いコミュニケーションを実現することができます。
UMLは期待に応えなかったが、全く無意味ではない
図の過度の複雑化は、統一モデリング言語（UML）によって引き起こされました。
私自身もUMLの不手際について書いています。UML 2.2のドキュメンテーションは1,000ページ以上もあり、そのためUMLは不便で無駄な事前作業と関連付けられるようになりました。
ソフトウェア開発のための包括的な言語にはなり得なかったにもかかわらず、UMLは重要な遺産を残しています。フローチャート、ステートダイアグラム、シーケンスダイアグラム、フローチャートをコードの代替物や厳密な設計図として使用するべきではありません。それにはあまりにも多くのオーバーヘッドがかかります。
これらの図は、高レベルのスケッチツールとして非常に効果的です。UMLは、2000年ごろにシステムをスケッチするためのVoAGIとしてピークに達しました。まるでファッショントレンドのように、再びスタイルに戻ってきています。
「包括性は理解しやすさの敵である」…
これは、1990年代にUMLを広めたマーティン・ファウラーの言葉です。もう聞く時かもしれませんね！
図はシステムに関するすべての情報を捉えることはできませんし、すべきでもありません。図は、システムの使用方法の視覚化、プロセスの論理的なフローの図示、サービスの機能のマッピングなど、高レベルのタスクに最適に使用されます。図は、システム同士の通信方法を伝えるのに役立ち、システムの内部の動作方法を説明し、モデルを簡略化できる領域を特定することができます。効果的に言えば、図はブラックボックスをガラスのものに変えるのに役立ちます。
…しかし、バランスが重要です
詳細はコードのドキュメント化において依然として重要です。ただし、読者にとって最も重要な情報を優先することが重要です。詳細が不足している図は無意味になります。時には、詳細な手続きの特定の低レベルの詳細に関する図を作成したいと思うかもしれません。ビジュアルやチャートは非常に役立つことがありますが、その特定の手続きの詳細については別の図を作成した方が良いかもしれません。それにより、すべての情報を1つの図に詰め込むのではなく、意味のある方法で分割し、チームメンバーがコードの異なる部分にどれだけ深く入り込むかを選択できるようになります。
図を基本に戻すための3つのポイント
人間の行動の変化と役立つソフトウェアの組み合わせにより、図を通じた協力を増やすことができます：
図表の使用目的に関する集合的な意識の変化
図表は過度に複雑だったり、あるいは過度に簡略化されていると失敗することが多いです。しかし、図表はコミュニケーション手段でもあります。明確なコミュニケーションを目指す際に情報を削除することは直感に反するかもしれません。
しかし、情報が多すぎることが明瞭さの最大の敵です。これを共有することを忘れてはいけません。
図表を作成する前に、何を明示したいのかを完全に理解しようとしてください。システム全体の概要を示すことを目指していますか？それともコードの特定の部分に詳細に入り込みたいですか？各ビジュアルについてゲームプランを立て、明確な目的を持つようにしましょう。また、すべての情報が1つの図表に収まらなくても心配しないでください。いつでも別の図表を作成することができます。
図表作成を支援するツール
効果のない図表の一部の原因は、開発者が利用できる図表作成ツールにあります。PowerPointなどの「クリック＆ドラッグ」ツールで図表を設計することは困難です。それは特定の考え方を促す可能性さえあります：図表を作成するのに時間を費やしているなら、できるだけ多くの情報を含めた方が良いのかもしれません。
そのため、開発者は迅速かつ簡単に図表を生成するのに役立つツールに投資する必要があります。ビジュアルの作成はシンプルで楽しいものでなければなりません。これが実現すれば、開発者は特定の目的に合わせた複数の小さな図表を作成するために躊躇しなくなります。すべてを1つのビジュアルに詰め込もうとするのではなく。
より多くの統合で生活が楽になる
人工知能について言及せずにこの投稿全体を終えると思ったなら、申し訳ありません。図表作成ツールに生成的なAIを組み込むことで、開発者の生活はずっと楽になります。ChatGPTなどのツールを使用すれば、ベースラインの図表に素早く到達できます。具体的な詳細と人間らしさを追加するだけです。
また、図表作成ツールをコーディングツールに統合することもメリットがあります。図表がソースコードに近い場所に存在できるようにすると（完全に別のプログラムやウィンドウではなく）、開発者は図表自体でのコミュニケーションについて心配する必要がありません。連携が強化されれば、図表の役割はより明確になります。
将来：図表、ドキュメンテーション、およびAI
図表は、伝えたい内容に明確な目的を持つ場合に最も効果的です。これは、仕事の将来を考える際に非常に重要です。
人工知能はますます専門的な役割を担うようになります。それによって人間は、プロセスの管理、製品の拡張、新しいアイデアの考案など、自分たちの得意なことに集中することができます。プロセスが自動化されるにつれて、プロジェクトごとに人間の同僚と明確な方向性を設定することが重要になります。コミュニケーションを続けることで、イノベーションを加速することができます。
図表は、同僚との重要な詳細を伝えるのに役立ち、将来の共同作業において重要な役割を果たします。図表の複雑さとシンプルさの適切なバランスを保つことはますます重要になるでしょう。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
