アーキテクトのように考える
ほかに 28 言語で読めます
English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
モジュール1／7：Data Architectコース第1章「データアーキテクトのように考える」。各モジュールは単独でも読めます。 前へ：章の概要 · 次へ：データモデルは骨格である
このモジュールが答える問い： 作ることと設計することの違いは何か、そしてアーキテクトは実際に何をしているのか？
私はキャリアの大半を、ビルダーとして過ごしてきました。
出発点は開発者です。Salesforceに移る前はJavaや.NETで仕事をしていて、何年もかけてシステムを設計し、コードを書き、プラットフォームを連携させ、アーキテクトを教え、アーキテクチャをレビューしてきました。
けれども、その道のりで学んだ最も大切な教訓の一つは、優れたビルダーであることと優れたアーキテクトであることは、必ずしも同じではないということです。
ビルダーはこう問います。
これをどう作るか？
アーキテクトは、別の問いを立てなければなりません。
そもそもこれを作るべきか？
なぜこの方法で作るのか？
ほかにどんな選択肢があるか？
これが大きくなったら何が起きるか？
失敗したら何が起きるか？
そして、今日下している判断のうち、3年後に「もっとよく考えておけばよかった」と思うものはどれか？
予約を扱う小売業のプロジェクトに入っていたときのことを覚えています。私は尋ねました。1店舗あたり1日に何件の予約がありますか？ 次に、店舗はいくつありますか？ 週に何日営業していますか？ すぐに、初年度だけで数百万件の予約になることがわかりました。プロジェクトの最初にアーキテクトが尋ねるのは、こういう問いです。
この考え方の転換こそが、このコースの本当のテーマです。
設計図を手にしている人
Section titled “設計図を手にしている人 ”アーキテクトを教えるとき、私はこのたとえを何度も使ってきました。
建設現場を思い浮かべてください。コンクリートを流し込む人、電気配線をする人、配管を取り付ける人、壁の骨組みを組む人、ほかにも何十もの専門的な仕事をする人たちがいます。彼らは自分の仕事に非常に長けている必要があります。
けれども、誰かが設計図を手にしていなければなりません。
その人は、それぞれの部分がどう組み合わさるのかを理解している必要があります。プロジェクトのある部分で起きていることが、別の場所で問題を生んでいるときに、それに気づかなければなりません。
それがアーキテクチャです。
テクノロジーの世界では、アーキテクトとは単に一番物知りな人だと思い違いをすることがあります。本当はそうではありません。プラットフォームを知っていることは大切ですし、技術的な深さも必要です。しかし、アーキテクチャは雑学クイズではありません。
アーキテクトの仕事は、ときに不完全な情報と相反する要件のもとでよい判断を下し、その判断がもたらす結果を理解することです。
それはまったく別のスキルです。
要件をそのまま受け取らない
Section titled “要件をそのまま受け取らない ”アーキテクトに最初に身につけてほしい習慣の一つは、シンプルです。
「なぜ？」と問うこと。
誰かがこう言います。
オブジェクトをもう一つ追加する必要があります。
なぜですか？
この項目を取引先にコピーする必要があります。
なぜですか？
このデータをすべてSalesforceに保存する必要があります。
なぜですか？
これは、扱いにくい人になれという意味ではありません。提案された解決策をすぐに実装するのではなく、実際のビジネス要件を理解するという意味です。
要件は、しばしば設計の姿をしてやって来ます。
「新しいカスタムオブジェクトが必要です」は、必ずしも要件ではありません。本当の要件は「この情報を別に管理する必要がある」かもしれません。この二つは同じではありません。
本当の要件がわかれば、選択肢を検討し始められます。新しいオブジェクトこそが正解かもしれません。その情報は既存のどこかに属するのかもしれません。あるいは、そのデータをSalesforceが持つべきではないのかもしれません。
アーキテクトは、ビジネスが必要としていることと、それを実現する一つの提案された方法とを切り分けなければなりません。
ある営業アプリケーションを手がけていたとき、お客様には複数の承認があり、それぞれに承認者と日付がありました。最初の依頼は、承認者2と承認者3を、それぞれの日付とともに商談の項目として追加することでした。掘り下げてみると、承認は2件や3件では収まらないかもしれないとわかりました。そこで承認を子オブジェクトに移しました。依頼は「項目を増やすこと」でしたが、要件は「承認が何件になろうと、すべてを記録すること」だったのです。
要件の先まで考える
Section titled “要件の先まで考える ”「なぜ？」と問うことから、二つの習慣が生まれます。どちらもこの章の後半でそれぞれ一つのモジュールを使って扱います。
答えはたいてい一つではありません。Salesforceには問題を解く方法がたくさんあり、そのうちいくつかはほぼ即座に誤りだとわかります。うまくいく方法の中から選ぶこと、それがトレードオフの技術です（モジュール4）。
そして、与えられた要件がすべての要件ではありません。「夜間のロードが半分しか成功しなかったときにも動くようにしてほしい」と言う人はいませんが、それでもそれは要件です。私はすべての設計を3つのレンズで見ます。今日のために作る、明日に備える、失敗に備える（モジュール5）。
建物の設計をアーキテクト（建築家）に依頼する人のことを考えてみてください。火災報知器やスプリンクラーを付けてほしいとも、地震で倒れないようにしてほしいとも頼みません。言わなくても仕事の一部として当然あるものだと思っています。私たちの世界も同じです。エラーをうまく処理してほしい、ログを残してほしい、何かが失敗したときに復旧できる方法がほしい、と頼む人はいません。そのうちどの仕組みが設計に必要かを見極め、組み込むのはアーキテクトの仕事です。
考えた筋道を見えるようにする
Section titled “考えた筋道を見えるようにする ”アーキテクトは、部屋に入ってきて「こうします」と宣言するだけではいけません。
なぜそうするのかを説明するのも仕事です。私は、検討した選択肢と、そこにあるトレードオフをステークホルダーに理解してほしいと思っています。経営層に40ページの設計書を渡せということではありません。同じアーキテクチャを、開発者に、ビジネスに、経営層に説明できるということです。同じ判断について、それぞれ違う会話をするのです。
そのための方法は、建設現場で設計図を手にしている人と同じく、明確な設計図と指示です。データアーキテクトにとって、その設計図の中でも特に重要なものの一つがデータモデルです。
なぜその判断が下されたのか誰も理解していなければ、いずれ誰かがそれを元に戻してしまう可能性が高いでしょう。しかも、その人にはまったくもっともな理由があるかもしれません。元の判断を誰も説明しなかったのですから。
アーキテクトがすべてを作る必要はない
Section titled “アーキテクトがすべてを作る必要はない ”もう一つ、難しい転換があります。特に開発からアーキテクチャに入ってきた人にとってです。
すべてを自分の手で作る必要はありません。
私は今でも、物事が非常に技術的なレベルでどう動いているのかを理解するのが好きですし、その土台は大切です。しかしアーキテクトになると、責任は自分の実装よりも大きくなります。すべてを自分で作る必要はありません。実際に作る人たちに、正しい方向性と正しいパラメーターを与える方法を知っている必要があるのです。つまり、その人たちの作業を導けるだけの理解、提案された実装がアーキテクチャ上の問題を生むときにそれを見抜く力、そして細部と全体像の間を行き来する力が必要です。
あるときは、クエリやAPIやデータモデルの奥深くまで入り込みます。
またあるときは、一歩引いて、そもそもそれをやるべきなのかを問います。
そして、作っているのが人だけではないことが、ますます増えています。AIがあれば、アーキテクトはオブジェクトやコードや画面を生成するツールと直接やりとりしているかもしれません。そのとき、方向性、パラメーター、ガイドラインを受け取るのはAIであり、それらをうまく与えることは、ますますアーキテクトの責任になっていきます。この話にはモジュール7で戻ってきます。
それが、ビルダーからアーキテクトへの道のりの一部です。
あなたの仕事は判断を下すこと
Section titled “あなたの仕事は判断を下すこと ”結局のところ、アーキテクチャとは判断のことです。
簡単に変えられる判断もあれば、そうでない判断もあります。
ページレイアウトは変えられます。表示ラベルは名前を変えられます。
しかし、根本となるデータモデルを誤って選んだり、何十ものシステムが依存し始める識別子を公開したり、重要なデータのマスターコピーを間違った場所に置いたりすると、考えを変えるコストはずっと高くなります。
それがアーキテクチャ上の判断です。そしてこのコースが集中して扱うのは、まさにそういう判断です。
データアーキテクトとして、あなたは情報をどう構造化するか、どこに置くか、どう成長するか、どう移動するか、誰がアクセスできるか、そして企業のほかの部分がそれをどう理解するかについて判断を下すことになります。
テクノロジーは大切です。
しかし、Salesforceのすべての機能を知ることが目的ではありません。
目的は、どのツールを使うか、いつ使うか、何と引き換えにしているのか、そして次に何が起きるのかを見極める判断力を養うことです。
それが、アーキテクトのように考えるということです。
そしてここから、データアーキテクトのように考え始めることができます。
ここでアーキテクトが決めること
Section titled “ここでアーキテクトが決めること ”- その依頼が本当の要件なのか、それとも要件に対する一つの設計案なのか。
- 何かを作る前にどの問いを立てるか：作るべきか、なぜこの方法か、ほかに何ができるか、成長したり失敗したりしたら何が起きるか。
- どの判断がアーキテクトの判断で、どの判断が作る人たちに属するのか。そして、作る人たち（人であれAIであれ）にどんな方向性とパラメーターを与えるのか。
- 開発者、ビジネス、経営層のそれぞれが理解できるように、判断をどう説明するか。