アーキテクチャーの重要性について
新しい会社で働き出して、約1週間立ちました。
当然ながら色々と今までとは異なる事がありますので、記憶力の低下したおじさんには厳しい感じもしております。
今週、部員の方一人一人と少しづつですがお話しさせていただき、改めて感じた事があったので、今回はそれについて書こうと思います。
私はソフトウェアのエンジニアとして長年暮らしてきましたので、ソフトウェアの切り口で考えますと、「アーキテクチャー」というものがあります。
ソフトウェアでアーキテクチャーというと、そのアプリケーションやライブラリ、もしくはもっと大きく考えるとシステム全体の「構造」的なものという事ができるでしょう。
辞書を引いてみると、
- 建築学。また、建築様式。
- 構造。構成。組織。
- コンピューターの特性を決定するデータの形式やハードウエアの機能分担などを含めた、コンピューターシステムの基本構造。
と出てきました。
まず、ソフトウェアの分野のアーキテクチャーの話をしますと、同業者の方なら当然ご存じな事で、今更いうまでもないのでしょうが、その対象の開発物をソフトウェア的にどのように組み立てていくかという考え方やその考えを実現するための部品の定義、部品間のやり取りの仕様などを全体的に考えて設計していくことを指すことが多いと思います。
要望されている仕様や機能、性能をどのように実現していくかをある意味決定づけるかも知れない大事な作業です。
家を建てることに例えると、恐らく、木造在来工法で建てるか、2X4で建てるか、はたまた軽量鉄骨で建てるか、みたいなことなのかも知れません。
ソフトウェアを作る場合に大事なのは、ソフトウェアは一度作り上げた後が大変だということです。
今の時代、ソフトウェアが関与していないものを探す方が難しいほどソフトウェアは色々なところで活用されています。
そしてそれらはほぼ全てのものが作られて利用されている時点においても、それらを改修したり、機能を追加したり、変更したりしなくてはならない運命を伴っています。
「いやいや、組み込みのソフトは製品出したらほぼそのままですぜ」というエンジニアもいるかも知れません。
私も元々組み込みソフトのエンジニアでしたから、そのような意見もわかります。
実際に私が若かった頃作った製品の組み込みソフトウェアはおそらく世の中に出した後に変更しないといけないことは数回程度しかなかった気がします。
しかし、現在は多くの組み込みソフトウェアの乗った製品もネットにつながり、その製品単体で機能するというだけではなく、外界との接続を伴って、もしくは何か別のものと連携して機能を実現しているものが多くなってきています。
そうすると、自分の製品は問題なくても、例えばネット上に脅威が存在する事が分かった時点でその影響を受けるかも知れないため、その対処を施す修正をしないといけないかも知れません。
そうでないとしても、過去の製品のソフトウェア資産（コード）を利用して新たな製品を作ることも多々あります。
そういう意味では、ソフトウェアの構造である「アーキテクチャー」を考えて実施することはとても重要で場合によってはその後数年にわたってその会社や製品の品質やコスト、開発期間に多大なる影響を与えるものだと私は考えています。
そんなソフトウェアアーキテクチャーですが、当然将棋の定石のようなデザインパターンというものが世の中にはあります。
先人たちが苦労したり、失敗したりしたことを元に改良したり、発明したりしながら、さまざまな課題をできるだけスマートに解決できる可能性を高める取り組みをしてくれてきた結果だと思います。
まぁ、私自身もそれらを全て網羅的に勉強したわけではありませんが、とても有効なものもありますし、使い方が難しいものもありました。
自分の要望している課題をうまく解決できないことも当然あり、それらデザインパターンが全てであるわけもなく、万能でもないのだと思います。
しかし、重要なのはそれらを使いこなすと言うよりも、それらに触れてなぜそのようなことを思いついたのか、どうしてこのパターンを使うと課題が回避できるのか、と言うことを自分なりに考えて、パターンそのまま使うだけではなく、自分なりにそれらを活用しながら生産性を高める努力をすることではないかと思うのです。
しかし、この作業はそう簡単ではありませんし、普通の開発現場では限られた人的資源とコスト、開発期間など、リソースの制約があるので、このアーキテクチャーの考察や設計に時間をとることはなかなか難しいのではないでしょうか。
もしかしたら本当にソフトウェアを事業の中心に据えている会社ではそれらは当たり前に行われているのかも知れませんが、少なくともキヤノンにおいてはこれらアーキテクチャーなどの設計に十分な設計と検証をとる時間はなかったと思います。
この作業はきちんとやらなくても製品はできてしまいます。
そして、苦労すれば、その後のメンテナンス等もなんとかなる場合もあります。
目に見える成果として出にくいので、評価もされにくかった部分があると思います。
でもそのせいで、後輩は苦労する事があるし、その後の製品がスムーズに出せないこともある。
少し機能や性能を改善すれば活路が見出せそうだけど、それすらできないと言う場面ばいくつもありました。
残念です。
そして、転職した会社は一応ソフトウェアを生業にしている会社です。
でも1週間見てみて、今の時点ではやはりこの会社もアーキテクチャーまで考慮して開発作業ができているとは思えませんでした。
今回の会社は現在は受注業務が中心になっていますが、クライアント企業の無理な要望に苦労しながらパッチを当てながらなんとか納期に上げることに多くの労力を使わないといけないようです。
開発期間も短く、とても全体を見ながら設計できる環境ではない気がします。
日本のソフトウェア産業がなかなか難しい状況にあるのも、この辺の作業に対する感度の悪さが少なからず影響している気がします。
世の中ではみずほ銀行のシステムダウンの問題や情報漏洩で騒がれたりしますが、これらも結局はそれらの土台であるアーキテクチャーをどのくらい考えて作られ、運用に移っているのか、そのあたりは現場はわかっていても経営層には伝わらない、そんな現状があるのではないでしょうか。
今回はソフトウェアのアーキテクチャーについて思うところを書きましたが、実は組織や会社自体も「アーキテクチャー」がとても大事ではないかと、ここのところ考えてました。
特にキヤノンでは組織の立て付けをあまり大事に考えてない気がしてました。
今度はその辺の「アーキテクチャー」について書いてみたいと思います。
