とあるIT屋の独白

ITや経営について主に書きます

システムアーキテクチャーと組織

「システムアーキテクチャー」って、IT界隈ではけっこうよく使われるワードですが、そもそもアーキテクチャーってなんだよっていうのは、あまり深く考えたことは私はありませんでした。ただ、アーキテクチャーの考え方を少し深掘りするうちに、マーケティングワードにしてくのもあれだなと感じて、今回ちょっと記事にしてみます。
アーキテクチャーというと「設計」と同じ意味で使われがちな印象がありますが、下記にある通りアーキテクチャーには「設計思想」や「設計方法」といった意味合いがあります。設計書についてはドキュメントに残すことが多いと思いますが、思想的なところはあまり文書かされてないことが多いかもしれませんね。

www.sophia-it.com


もう少しこの思想や方法について、掘り下げているのが下記の記事です。この記事では、アーキテクチャーを「エンジニアの発想」と位置付けています。発想というと、今ではフレームワークやライブラリやインフラが充実してきているので、何か新しい技術要素を開発するというよりは、どの技術がハマるかという選択に近いかなと思います。
今思い返すと、よくこんなやり方や使い方を思いつくなぁというエンジニアの人もいて、発想はシステム開発において大事な気はします。設計書を作る前段で、この発想出しがいかに出来るかが、設計の品質にも関わるかと思います。

xtech.nikkei.com

 

では、この発想出しをどうすれば有意義になるかということで、いかに紹介されている「Design It!」という書籍が参考になると思います。良い発想には良いインプットや、またその発想が適切であるという合意も必要です。なので、アーキテクトと呼ばれる人はシステムだけでなく、ビジネスであったりビジネスに関わる人に、目を向けることも求められてきます。

iwasiman.hatenablog.com

 

もちろん、システムにもビジネスにも詳しい一人のスペシャルなアーキテクトがいれば、それでこと足りてしまう可能性はあります。しかし、会社という組織でビジネスを行ってる以上は過度な属人化は避けたいところでしょう。
エンジニアも一人一人得意分野や関心事も違うので、やはりチームで発想を豊かにする仕掛け作りが現実的な解なのだと思います。チームとなると、下記のUXの記事で触れられているような組織論に行き着くのかなと思ってて、良いアーキテクチャーを生み出すには、良いコミュニケーションや良い組織が求められてくるのかなと感じました。

a-suenami.hatenablog.com