色々なトラブルや炎上案件というものは間近でも耳にすることがありますが、設計や構築段階に入ってから、「○○はこうするべき」や「この設計ではOK出せません」という話しが出てきて、後戻りやいつまで経っても設計がかたまらない、、そのために余計な工数が掛かり予定通り進捗せず費用がかさんだり、本来力を入れるべきところに注力できずに大事なところの品質が結果的に低下する、ということがよくあります。
これは非機能要求について、お客様と開発ベンダとの間で共通認識を持てていないために発生していることが多いと考えられます。

このような現状を踏まえて、多くの企業で非機能要求についてのノウハウ化を図っています。また、国内の主要SI事業者にて検討会を結成し「非機能要求グレード」を完成させています。

これらのノウハウを活用することで、設計内容はもとより、SLAや責任分界点の明確化、見積もりの正確性などまで改善されることは明確でしょう。

しかし、マニュアル化されたノウハウを活用するだけでは非機能要求を十分に定義できるとは考えられません。
なぜならマニュアル化できるものは、どちらかと言えば抽象的な事項、つまりうわべだけにすぎないからです。
個別のシステムに特化した内容や、具体的な設定内容を考慮するとなると、膨大な量の項目が必要となり、とてもマニュアルとして活用できるレベルではなくなるでしょう。

現在ノウハウ化されているものが意味を成していないと言っているわけではなく、前記した通り色々な面で改善が見られることでしょう。しかし、十分とは言えません。

例えば、sendmailを使用してメールサーバを構築する際に、要件の一つに秒間20通の処理性能を必要とする項目があったとします。

ハードウェア的な性能は十分な物を使用し、負荷試験でも軽く秒間20通を処理できていたのでサービスインしたところ、何故か不定期にこのメールサーバに対しての接続を拒否される現象が起きてしまいました。
原因を調べたところ、ルーティングできないスパムメールの受信が多い時に、ロードアベレージのみ15を超えており、さらにsendmailについて調べると、デフォルトでロードアベレージが12を超えるとSMTPコネクションを拒否する動作となっていました。
CPUやメモリ使用率は余裕がある状態のままでしたので、sendmailのロードアベレージに関する設定を変更することで対応できました。

この事象はスパムメール、しかもルーティングできないメール、が大量に送られてきた時にのみ起きる現象だったため、お客様も開発ベンダも想定外だったと言えるでしょう。
しかし、問題が起きたことは事実であり、ロードアベレージに関する非機能要件を事前に決めておくべきでした。

ではこの非機能要件はノウハウ化できるでしょうか？
いえ、この設定はsendmail固有のものであり、全てのMTAが実装する設定ではありません。もちろん「sendmailではロードアベレージの設定を○○する」というような項目を追加することもできますが、同じ製品を使うとは限らず、また今まで使ったことのない製品を使う機会が多いことを考えれば、製品固有の設定は大量にあるため、ノウハウ化は厳しいでしょう。

結果的にこの問題を事前に防ぐには、担当者が同じような経験をしているか、これまでに経験してきた色々な知識をもとにこのような現象が起きることをサービスイン前に気付く必要がありました。

要は組織の作るノウハウで足りないところは個人のスキル、経験の蓄積、またその者が持つ全てから生み出される「気付き」で補い、そのレベルの良し悪しによって案件の成功率も大きく変わってしまうと私は考えます。

常に新しい製品、技術が台頭してくるIT業界にて完全なノウハウ化は不可能であり、だからこそ優れたエンジニアをいかにアサインできるかが案件成功へのカギとなってくるのです。