はじめに
業種や分野を問わず「全体を見てシステムアーキテクチャ設計できる人が少ない」というような話はよく聞きます。
私も決してそういう設計の上級者でも何でもないのですが、長いエンジニア人生の中で、平均的な人よりはちょっとだけ多くそういう設計をする機会には恵まれてきたように思いますし、何よりお仕事とは関係なく趣味でオレオレアーキテクチャは沢山作ってきましたので、一体全体システム設計だとかアーキテクチャ設計だのを学ぶのの何が難しいのかというのを勝手気ままに考察してみたいと思います。
世の中には、シンプルで美しいアーキテクチャもあれば、複雑怪奇な継ぎはぎだらけで二度と触りたくないシステムまで様々です。後者をに関しては、設計した人を「システムアーキテクチャ設計できる人」と呼んではまずいケースも多々あるので、まあそういうのも含めて考察してみようと思います。
![コンピュータアーキテクチャ[第6版]定量的アプローチ](https://m.media-amazon.com/images/I/51guTT4yixL._SL500_.jpg "コンピュータアーキテクチャ[第6版]定量的アプローチ")
システムアーキテクチャ設計できる人が少ない理由
能力的な問題
まず人それぞれ得意不得意は必ずあります。私がいくら勉強しても英語が話せないとか、人の顔と名前覚えられないとか、絵心がさっぱりでダサいプレゼンしか作れないとか、まさにそれだと思ってます。個人的には、向かないことをわざわざ労力掛けても仕方ないので適材適所で分担すればいい話だとは思っています。
で、私の経験上、世の中には 全体はよくわからないけど部品なら作れるよ と言う人がそれなりの数いらっしゃいます。
でそういう方々にうまいこと得意分野を割り当てていって、ゴールを目指すスキルに長けている人をプロジェクトマネージャーと呼ぶわけです。
が、ここにちょっとだけ罠があって、「部品は作れるよ」という方々の中には 100点満点近い部品を作れる人もいれば、指摘や指導を繰り返してやっと60点のギリギリ及第点の部品を作れる人まで様々です。 少なくともソフトウェア開発の現場でのソフトウェア部品の個人差による品質バラツキは顕著にあるかと思います。
人間が一度に把握できるスコープは人それぞれですので、どうしても部分しか見れない人はここで壁にぶつかりがちな気がします。
一方でシステム設計できるように育っていく人は、部品がどう使われるのか、その外側の要件も視野に入れているので、部品に求められる要件の意味や行間まで考えて100点近い部品を作ってくる人が多いように思います。
スキル習得機会の問題
もう一点は、折角能力があっても、スキルを伸ばす機会がなかなか手に入らない事です。開発に携わる人間で ゴールを決める 工程に携われる機会は決して多くはありません。多くの場合は、誰かの決めたゴールを達成するための部品 を任される機会しかないのが実情でしょう。
そして私の知る範囲で、よくある２つの課題があります。
- 全体像を教えてもらえることなく、ただ部品を作ることだけを指示されるケース
- そもそもスキル習得にならない悪い見本のようなシステムの部品開発を指示されるケース
でしょうか。
特に前者は聞けば教えてもらえることもありますが、 NDA だったり組織の縦割り行政だったり、政治的理由で情報を教えてもらえないケースもあり、何に使うのかわからないまま部品を作らされるというケースがあります。
また後者も、これをそのまま受け入れてしまう人も多いのですが、それだとそれ以上成長できなくなってしまいますので、まだ、システムのダメさ加減を愚痴りながら仕事してるエンジニアの方が、全体の事を考えてる分マシなのかもしれません(まあ、愚痴るだけで終われば同じことなんですが)。
あとは最近だと、「AI が作っちゃうのでよくわからないままスキル習得に終わってしまうケース」なんてのもあるのかもしれません。
どうあれ「個々の技術を磨きながら、全体を設計する能力も磨く」という事を阻害してしまっています。
ダメな設計はなぜ生まれてしまうのか
どこかの銀行のシステムの例を挙げるまでもなく、ダメなシステム開発と言うのは大小いっぱいあります。FPGA用の回路設計だって例外ではありません。
多くのダメなシステムは、正しい最終イメージがアーキテクトの中で出来上がっていないのに、部分から作っていって破綻するようなケースが多い気がします。
全体を見せてもらえない／全体を見る能力がない、などの制約下で、とにかく部品を作ってくっつければなんか出来上がるだろう(というか闇雲でもなんでも前に進む以外にやれることがない)、ぐらいのノリでどんどん作ってしまったんじゃないかと言うぐらい行き当たりばったりでカオスなシステムと言うのは、まあ残念ながら世の中にあります。
要するにグランドデザインがちゃんと出来ておらず、ゴールがどこにあるかあいまいなまま作っているので、ゴールまでにあと何を作れいいのか、どちらに向かえばいいのか、あとゴールまでどれぐらいかかるんか、などがわからないまま、目の前にある課題だけが課題として上がっていく状態です。
で、作った部品の数だけで進捗管理してるから、100個作ったのにくっつけても動かない状態になった後は、進捗率が 99% のまま工数がどんどん伸びていくというあの状態ですね。納期を過ぎた後、ひたすら疲弊しながら人海戦術でデバッグして、ぎりぎり60点の合格ラインで納品するわけです。
逆に、正しい最終イメージが頭に描けるだけのスキルのアーキテクトが居る場合、あとゴールまで何が足りていないのかちゃんと把握できますし、仮にゴールが見えていない場合も ゴールが見えていないというリスク を正しく認識できるので、ゴールの位置を確認するための作業 なども正しく計画に組み入れていけるわけです。優秀なアーキテクトの居る組織ではおおむね 80点ぐらいのシステムを毎回きっちり約束通り仕上げていきますし、そのような組織の中で適正のある若者の中からは次のアーキテクトも育っていくわけです。
美しい設計はなぜ生まれるのか
ここで、経済的合理性は一旦おいておいて、100点に近い設計を考えてみます。
建築にせよ、機械にせよ、ソフトウェアにせよ、半導体プロセッサにせよ、美しいと思える設計 というのは少なからずこの世に沢山あります。美しいものはシンプルです。美しいものは機能性が高いです。美しいものは長持ちします。美しいものは時代を超えて美しいです。
もはや、お金の為に作るというよりは、匠がある種の芸術の領域に片足突っ込んで、自己満足の為に作らないと作れないような領域なのかもしれませんが、まあ確かにそういうものはあるように思います。
そして経験上、美しい設計を作っているアーキテクトは、驚くほどなんでも知ってるし何でも良く見て ます。例えばプロセッサアーキテクチャ設計で巨匠と言われるような人たちは、トランジスタレベルのロジック構造から、演算器やキャッシュの構成、メモリの特性まで熟知して、それらも極めてタイトでピーキーな部品として設計できる能力まで有した上で、最新のAIの学習モデルから半導体製造工程まで熟知してて神業みたいなアーキテクチャを設計しています。
私なんかは見ていてポーカンとなるだけなのですが、ほんと凄い人たちは凄いのです。
ここでおもむろにハッカーと画家のミケランジェロがシスティーナ礼拝堂の天井画の全ての像を自分自身で描くと 主張した話なんかをふと思い出したので、私見交じりに書くと、きっとミケランジェロの描く100点満点の作品には、100点満点の部品が揃っている必要があったのではないかなと想像してみます。
ここで言う100点満点の部品とは、例えばプロセッサを作る場合、そのプロセッサアーキテクチャ用に専用部品を作れと言ってるんじゃなくて、拘りたい部分に関してちゃんとトランジスタレベルで無駄のない綺麗な設計になってる汎用部品たれという話です。
で、冒頭の話に戻りますが、芸術観点で拘ったシステムが作りたくても、商業として部品開発者の中には 60点の部品しか作れない人がどうしても含まれてしまいますので、ミケランジェロは一切合切そういう要因を排除して拘りたかったのかな、なんて考えてみたりもするわけです。
どうすればシステム設計力が身につくのか
小さなゴールを自分で置く
一番の王道はこれじゃないかと思います。大きなゴールは初めから置かれているケースがほとんどと思いますので、自分の裁量の範囲で自分の小さなゴールを置く事です。
特にソフトウェアでは、要望された仕様を満たす部品の設計や実装方法、アルゴリズム選択は無数にある場合が多いですので、自分なりのゴールを置いてより自己満足度の高い部品を作ることを心がけることだと思います。
何よりも自分でゴールを置くという事は、完成形をイメージするという事であり、なぜそれを選択したのか一つ一つに自分なりの理由を見つけ、開発中もあと何が足りていないのか考え、不足を埋めながらゴールを目指すことができます。
そして少しづつ、大きなゴールを任されるようにポジション取りをしていくという事が重要に思います。
趣味で設計する
で、実はこっちが個人的にはメインだった気もしていて、なかなか「王道でアーキテクトが育っていくような環境をずっと維持できてる職場」と言うのは決して多くはないです。
となると仕事と言う枠を気にせずに自分でオレオレアーキテクチャを設計してみるというのが実はとても重要な気がしています。いくらでも大きなゴールを置いて挑戦することができますし、失敗しても誰も困りませんし、面白いものが出来ればOSSで公開したり、ブログ記事を書いたりすればいいわけです(笑)。
なんでもかんでも自己責任と言われてしまうこのご時世、ある程度は職場に頼らずに自分のスキルには自分で責任を持たないといけないのかもしれません。 まあ、さすがに「この先この職場環境だと能力を活かす環境が来そうにないな」とあれば転職なども選択になったりもするのかもしれませんが。
研究開発の場合どうなのか
研究の場合、「まだ誰もやってない未知のことを確認する」というのがメインタスクになります。要するに「やってみないとわからない」ので「ゴールも分からないし、進捗管理何てできるわけないじゃないか」というのもまあ、一理ある意見かとは思います。が、一方で、だからこそアーキテクト的な能力が問われることも多い気がします。
研究を行う場合、必ず何らかの仮説をもって実験を行う事になります。実験の結果仮説があっていることもあれば間違っていることもあります。
一方で、仮説を立てた以上は、正しかった場合のゴールイメージは立つはずです。そして仮説が正しいことを証明するための美しいシステムとは何か、どうすればそこにたどり着けるかを考える事は、仮説が間違っていた場合の証明もまた最短で行う事になります。
研究を一連のシステムとして、研究計画を立てて進めていく際にもシステム設計力やアーキテクト力みたいなものは同様に問われてくるように思う次第です。
おわりに
今回もかなり抽象的な駄文にはなってしまいましたが、新しいものを作るときに「そのゴールを想像してグランドデザインができる能力」と言うのは、大小問わず、研究するにも開発するにも重要な事ではないかと思います。
一方でそれらの能力は 意識的に取りにいかないと身につかない し、悪い環境にいても身につかない ので、そうなりたいと思った人がそれなりに自分で自分を育てるという事をやらないと身につかない能力なんだと思います。
「馬を水辺に連れて行くことはできても、水を飲ませることはできない」ということわざがありますが、組織も簡単に育てられる人材じゃない気がしていますし、昨今の組織は自分で育てるよりも、即戦力を中途採用したがる時代になっています。逆に言えばアーキテクトを目指す人にはリターンの大きい時代ではあるかと思いますので、是非頑張っていただければと思う次第です。
