― Web Technology and Life ―

ソフトウェア設計について思ったこと

2011-05-08
『ソフトウェアアーキテクトが知るべき97のこと』を読んだまとめ、あるいは、考えたことのまとめです。

ソフトウェアアーキテクトというのが曖昧

ソフトウェアアーキテクトの役割や業務範囲がいまいちよくわからないので、とりあえず、設計を中心にやる人と理解しました。しかし、一方で、設計だけやる人と、ビジネスロジックから考えて設計に落とす人と、コーディングもするけど設計から入る人と、まぁいろいろな範囲で設計に関わる人がいるから、どこからどこまでソフトウェアアーキテクトでどの種類のソフトウェアアーキテクトがどのような悩みを抱えていてどのような理念で望めばよいかなんて、千差万別で、結局自分なりの立ち位置の信念を貫くしかないのかと思いました。とりあえず、最初の設計のみするソフトウェアアーキテクトは、だいたいなんとなくまとめると以下のようになります。

大規模環境であればこそ必要な役割

ソフトウェアアーキテクトなる職種が必要になるのは、大規模環境でたくさんの人が関わってくる時だからなので、要件定義、設計、実装、テスト、本番移行までほぼ独りでやっているぼくとしてはあまり設計に焦点を絞って考えたことがなかったからピンとこなかった。

作業内容が曖昧

ソフトウェアアーキテクトの明確なアウトプットは中間的プロダクトのドキュメントぐらいだと思った。すべてドキュメントに残すことは大切かもしれないけど、開発用のドキュメントは運用中も大規模で行われないと放置されて風化されるのがオチ、あるいは、運用中に大幅なシステム変更があったときのドキュメントのメンテナンスが大変で放置されて風化されるのがオチ。結局、コードで書いたほうが早いこともたくさんある。

コード書いていない人は信用できないということになってしまう

コードバリバリというのではなく、ビジネス的なロジックを念頭においているのがソフトウェアアーキテクトらしいが、だからと言ってコードを書かないで良いわけではない。最新のトレンドは常にキャッチアップしていないと、今さらそんな抽象化はいらないとか、今さらそんな作業は必要ないということも、考えてしまう。プログラマ(本書ではデペロッパーという標記)であり、ビジネスロジックも押さえており、というバランスが難しいことを実践しなくてはいけない。

ビジネスロジックと実装を抑えつつ設計をするソフトウェアアーキテクトがいい

個人的にいいなと思うソフトウェアアーキテクトです。ビジネス的な交渉もします、コーディングもできます、ただ中心は設計です、という感じ。もちろん、ビジネス的なところはバリバリの営業の人のほうがスキルがあるでしょうかそのサブ的な役割になるかもしれません。あるいは、コーディングのところはバリバリのプログラマの方がより最新の技術を知っていてよりよい実装が可能かもしれないので、プログラマを立てつつ実装に参加するかもしれません。しかし、プロジェクトの最終的な責任を持つのがソフトウェアアーキテクトだと思います。そんなソフトウェアアーキテクトが注意するべきことは以下の三つだと思います。

  • 最善の方法を最速で実践する意思
  • コミュケーション能力
  • デザインパターンの習熟

それぞれ本書からいいなと思った箇所を抜粋します。

最善の方法を最速で実践する意思

時と共にハードウェアもソリューションパッケージも進化しますし、ビジネス環境も変化します。技術的進化とビジネス変化のバランスを考えながら、最善の方法を編み出し、最速で実践することが求められると思います。

時の流れを見ていて特に面白いと思うのは、何が残って何が残らなkったを知ることです。優秀な人々が長期的な問題を考え、すべての要素のバランスを取って、情熱的に支持してきたパターン、フレームワーク、パラダイム変更、アルゴリズムの多くが、時間の経過とともにただあくびしか誘わないものにり果てています。 『ソフトウェアアーキテクトが知るべき97のこと』 「時間が全てを変える」p.66

コミュケーション能力

プロジェクトの中心であればこそ円滑に進めるためのスキルが必要で、そのためのコミュニケーション能力だと思います。

メンバーに全体的な視野や意思決定の理由を伝えなければ、プロジェクトは確実に破滅への道を歩みます。逆に、デベローーアたちを味方につければ、あなたがアーキテクトとして下した決定は当然のこととして受け入れられるようになります。アーキテクチャーの策定プロセスにデベロッパーたちを参加せていれば、彼らから自発的、積極的な姿勢を引き出すことができます。 『ソフトウェアアーキテクトが知るべき97のこと』 「まずコミュニケーション、そのための明快さとリーダーシップ」p.9

デザインパターンの習熟

ソフトウェアアーキテクトとして存在価値である設計能力に関して、それを裏打ちするものがデザインパターンの習熟だと思います。字面で知っているだけではなく、それは必ず経験に裏打ちされたものでなくてはなりません。今つくろうとしているシステムはどのデザインパターンが望ましいか判断できることで設計指針はほぼ決定すると思いました。個人的に理論と実践のバランスをとっていきたい分野だと思いました。

ソフトウェア・アーキテクトは、どのプラットフォームの仕事をしているかに関わらず、相互のコミュニケーションを円滑にするための手段をもたなければなりません。そのための手段の1つが、アーキテクチャー/デザインパターンによるコミュケーションです。有能なソフトウェア・アーキテクトになるためには、基本的なアーキテクチャー/デザインパターンを理科し、それらがどのようなときに使われているか、どのようなときに適用すべきかを学び、パターンを使っているアーキテクトやデベロッパーとコミュケーションをとることができなければなりません。 『ソフトウェアアーキテクトが知るべき97のこと』 「デザインパターンに習熟せよ」p.84

最後に

いろいろと本文からの抜粋/まとめと自分の考えを織り交ぜで、ぐちゃぐちゃまとめてみたものの、まだまだ設計の経験のない範囲も多く、いまいちピンとこないことも多かったなぁという印象です。まぁ、もし大規模環境で何かすることがあれば、実践の途中に読みなおして「ふむふむ」そうだよなと勇気をもらおうかと思います。

ビジネススキル update_at : 2011-05-08T15:06:23
hirobanex.netの更新情報の取得
 RSSリーダーで購読する   
blog comments powered by Disqus