アーキテクトは組み立てるだけでなくて削れないとダメ

2011–04–10

間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 を読了しました。 中身を見ずに題名だけ見て購入しました。 今のプロジェクトでアーキテクチャが原因でプロジェクトの足を引っ張っているところがあって、 さらに間違いを重ねないような参考情報はないかと思っていた頃に見つけたのがこの本でした。 アーキテクチャのアンチパターンが載っているのかなと思ってたのですが、副題の方が内容を表してますね。 アンチパターンが主題ではなく、非機能要件を中心にアーキテクトの仕事の流れを説明した入門本でした。

この本は非機能要件をどのように定義していくかが主題となっています。 非機能要件を定義していく時に何をどう定義していけば良いかが書かれているので、この本を道標とすればスムーズに要件定義を進めれると思います。 今回のプロジェクトでももちろん非機能要件は定義していきました。 程度の差こそはあれ、この本に書かれていることはそこそこやってきていました。 プロセスは大きく間違っていなかったのです。

じゃぁ何が失敗だったか。 それは削らなかったことに尽きます。 機能的な面で削れるところを削らなかったり、知見のない技術をシステム構成から削らなかった反省があります。

今回のプロジェクトでは未知の技術を使用することから、要件定義期間中からプロトタイプのスケジュールがきちんととられていました。 本書でも要件定義でプロトタイプをしつこくやる事の重要さが説かれています。 やはりプロセスは間違っていないのです。 しかし未知の技術の数が多かったため、当然プロトタイプで検証すべき事柄が多くなり、十分深く検証が出来ませんでした。

削ると言っても機能的な面を削るのは難しい所で、クールな機能を並べた方がお客様に受けが良いのは当然だと思います。 そうやって風呂敷を広げないと仕事がとれにくいのは想像がつきます。 けどいったん風呂敷をひろげちゃうと、それをたたむのはなかなか難しいのがジレンマです。

本書にも削ることの大切さを、有名な挌闘家の言葉を引用して説明しています。

 完璧とは何かを足せない状態になることではない。何も削るものがなくなった状態のことだ	  

大きな機能をゴッソリ削るのではなく、代替の熟れた技術を用いながら一部の機能を実現するなど、 うまく削っていくスキルがアーキテクトには必要なのでしょう。