複雑なITシステムの新しいソリューションを設計する必要があります。あなたの行動は？
まず、アクションプランの開発を開始する前に、管理職や専門家のベストプラクティスを理解しやすい（少なくとも一部）の図にまとめる必要があります。
以下に示す例では、常に中心となる要素を見つけなければならないことを説明する図を示しています。これは、作業全体の形式を決定する最初のレンガです。
ソフトウェア開発において、GitlabまたはGitHubをそのようなレンガとして採用し、Markdown形式をドキュメントとして使用することを提案します。1つの場所にあり、コードのように扱うことを前提としています。変更を加えることは決してありません。なぜなら、プロジェクトのあらゆるものにとってドキュメントがすべてだからです（この点については、より後で詳しく説明しません - 一般的に受け入れられています）。
- ドキュメントの陳腐化の原因となる主な要因：
- ドキュメントが誰にも書かれていない
- ドキュメントが散らばり、完全な最新バージョンをいくつかの断片から収集できない
これらの2つの要因は、上記の図で制御下に置かれています。
一部のチームでは、ドキュメンテーションへの個人貢献をあらゆる従業員が行うコミュニティが登場する可能性があります。
アーキテクト、スペシャリスト、プロジェクトキュレーターの3つの力が並行して進む必要があります。
専門家は、アーキテクトが指示したタスクを実行する必要があります。さまざまなレベルの専門家は、独自の解決策を見つけます。アーキテクトは、プロジェクトの説明形式を定義します。そして、プロジェクトをスムーズに、予測可能にし、可能な限り快適に進めるための役割とルールを担当するキュレーターです。
明確な責任範囲がない場合、開発者側および顧客側の両方で、作業は非効率的になります。
このトピックは、Gemba（現場観察）という日本のアプローチの導入です。
大規模プロジェクトを開始する際には、高レベルの図（以前に述べたレンガであるGit+Markdownがすでに配置されていることを忘れないでください）から始める必要があります。これは、すべての参加者に共通言語を話し、解釈の違いや説明の必要性を排除します。
各段階では、さまざまな分野と専門性の従業員に参加してもらいます。
顧客の間では、ソフトウェアアーキテクチャ「C4モデル」（文脈、コンテナ、コンポーネント、コード）とそのバリエーションを記述することに慣れています。これは、すべての関係者が同じ理解を持っていることを保証するのに役立ちます。
常に図のブロックに従ってください。対応するものを見つけ、作業を構築して、空白がないようにします。プロセスに変更を加える必要がある場合は、徐々に変更してください。