アーキテクトのお仕事
アーキテクトのモノの見え方とは？
私のプロフィールには、サブタイトルに「アーキテクトの見方」と入れています。
「アーキテクト」という言葉を聞くと、何のことかよくわからなかったり、もしくは現場から遠く離れてほとんど仕事してないような印象を持たれるかもしれません。IT業界では、システム全体の設計を考える役割を指すことが多く、技術選定をしたり、大規模なシステムの構成を整理したりする人、という説明がされることもあります。
このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。
ただ、私は、この仕事、システムを作るということの本質はもう少し別のところにあると思っています。
それは、「見えない構造を見つけて、フローを解体する」ということです。
例えば一軒の家も屋根、柱、壁など要素要素で見ていくと、全体をどうするか、ではなくここはどう？そっちはどう？など、より個別のバーツに着目する事ができます。
一見、1つの工程、タスクでも、何のためのなにをしているのか、アウトプットはなんなのかなど細かく見ていくと、より小さな工程にほぐすことができます。
そこを見つけて、ひとつひとつが検討できます。
大きな問題のカタマリではなく、小さな問題の寄せ集めとして、ちょっとずつほぐして行くことができます。
システムを作るうえでは、設計とは機能がメインであり、システムの要件とかそれをどう構成するのかなんて、ぶっちゃけ落ちなきゃいいんでしょ？と思われがちです。それはそうですが、予算も無限にあるわけでもないし。でも実際、システム要件は予算や規模感でできることがだいたいはまぁ、大枠が決まってしまうので、提案書もテンプレをちょっと直すくらい、みたいな事もよくあります。
ただし、実際の現場というかシステム導入する現場では、表面上は「在庫が合わない」「業務が複雑すぎる」「毎回トラブルが起きる」といった問題として相談が持ち込まれます。しかし実際に調べてみると、原因は単純なミスや不具合ではないことが少なくありません。
例えば、現場ではExcelで別管理されているデータが存在していたり、部署ごとに同じ言葉を違う意味で使っていたりします。営業は「注文完了」と思っていても、経理は「請求書発行時が完了」だと考えている。あるいは、物流部門では「出荷」と「納品」を別の概念として扱っている。そうした認識のズレが積み重なって、システムの外側で混乱が発生していることがよくあります。
本当の問題は、プログラムそのものよりも、「業務の用語を合わせる」とか「実際の仕事、ヒト・モノ・カネがどう流れているのか」、「前提条件とここでのゴールがはっきりしているか」など、構成要素とそのつなぎ目、つまり構造の整理整頓ができていないことにあるのです。
私は長いことそういう現場で特殊な訓練をしてきたせいで、日常生活でも「構造」が見えるようになってしまいました。
データのフロー、作業のレイヤー。今の作業でなにをどこまで担保しているのか。どこまでがやるべきことで、どこから先はやっちゃイケないのか。この作業に着手する前に揃えておくべき材料は？など。
料理の工程も似たようなもんですが、なぜ部屋が片付かないのか。なぜ家計簿が続かないのか。なぜ会議は毎回同じような進行で報告して終わり、になっているのか。そういうことを考えるとき、私は「性格」とか「やる気」なんてどうでも良くて、仕組みが整っているかを観察します。またその仕組みを整えるためのコストも想定します。
例えば家計簿なら、入力のタイミングはいつなのか。そこから逆算してレシートはどこへ集めておくべきなのか。入力後のレシートをまとめるファイルは買ってあるよね？とか。そもそも本当にその手間かけて全部記録する？お店と合計だけで良くない？とかで。
そうやって観察していくと、「問題」だと思っていたことは、実はかなり発生するべくして発生している「構造的な矛盾」や衝突、ズレだった、ということがよくあります。
なんとなくですが、この「構造を見る」とか「手順を整理する」というスキルは、本来もっと多くの場面で役立つものだと感じています。
ITの開発現場だけでなく、いろいろなお客様の業務、事業で様々なヒト・モノ・カネのフローをみてきました。
工程管理とか予実管理など、会社では当たり前にやってましたが、意外と知られてないよね？
日常のちょっとした家事でも、みんなで催すイベントでも、こういう業務管理方法を聞いたことあるだけでも、作業の流れが整理できたり、ちょっと違うんじゃないかと思っています。
そしてもう一つ、細部を見るときは細部を見る、大きく見るときは大きく見る、ということ。
一連の工程としてつながった全体として、何がインプットで何がアウトプットか、別の業務や別の作業を繋げて、全部を混ぜて問題を抱えて考えすぎていないだろうか？
例えば、ハサミを作る工程とハサミを使って何かを作る工程って全く違う、と言うか関係ないじゃないですか？大抵、もうハサミは完成品として買ってくるものだし。
ハサミを作る工程では、使う時の使い勝手を前提に作りますが、ハサミを使う時はできたもの、買ってきたハサミを前提に作業しますよね。
つまり前の工程と後の工程、ハサミという結果、で分かれているわけで、ハサミを使う工程を改善したい時にそもそものハサミを作る工程のことでは悩まないわけです。（ハサミのメーカーさんの立場置いておいて。）
このようにどこを区切って、どこにフォーカスするか、細かく下っていくときにタスク間のインプットとアウトプットでレイヤーを仕分けしていくように、視点を大きく上っていくときも、全体のインプット・アウトプットでまとめてしまって、中身は箱を閉じてブラックボックスと割り切る。大きい話をするときは中身は見ない。
もしそれで話しがおかしくなるなら、大きい区切りのインプット・アウトプットの整理が足りていないのです。
このようにフォーカスしている視点の粒度、解像度を調整し、粒度の違う話を混ぜない、解像度の違う話は分けて個別に検討する、というのも技術、です。
日々、「頑張れてない」とか「習慣化できてない」といって自分がダメなヤツなんじゃないかと思うようなことはたくさんあります。でも、その前に、「そもそもその仕組みは続けられる構造になっているのか」、そもそも『サステナブルな仕組み』になっていないんじゃないの？というポイントを見つけると、自分ができなかったのは、やる気とかじゃない、ここが整っていなかっただけなんだ、準備にひと工夫するだけで、後がとってもスムーズに行くじゃないか、などと気づくことが出てきます。これはだいぶ違うんじゃないでしょうか。
また最近はAIの発展によって、「コードを書くこと」そのものの価値が少しずつ変わり始めています。自分のやっているタスクのうち、ここだけピンポイントで自動化したい、なんて自分専用のアプリがバンバン作れるようになりました。だからこそ、これから重要になるのは、「どれだけ速く作れるか」ではなく、「どこを観察」して、「どんな構造として解体できるか」なのではないかと思っています。
このブログでは、システム開発の現場で見てきた話を土台にしながら、生活、お金、人間関係、学び、AI、情報との付き合い方、世界情勢など、さまざまなテーマで「構造を見る」という視点から書いていこうと思っています。
専門知識がなくても読めるように、できるだけ難しい言葉は使わず、それでも現場で実際に起きているリアルな感じが失われないように書いていくつもりです。
もし読んでくださった方が、「ああ、こういう見方があったんだなぁ」と少しでも目からウロコが落ちる瞬間があったのなら、とても嬉しいです。
ここまでお読みいただき誠にありがとうございました。
このSubstackは読者の皆さんのご支援によって成り立っています。新しいポストを受け取り、私の活動を応援していただくには、無料または有料の購読者になることをご検討ください。