たれみみの備忘録

たれみみの備忘録です。仕事と酒がメインになりそう。

【その3】基本設計概要 ②非機能設計

今から 4 年以上前に MBO に書いてしまった、新人ちゃん向けのメルマガが出てきた。
このメルマガも設計についてのコツみたいなものを語ったものっぽいね。

読み返してみたところ、機能編に比べたら若干薄いかなーと。
でも、このときはバリバリのアプリ屋だったからしゃーなしやで。
それか、非機能設計の内容が多すぎたからギブアップしたのかも。

なお、Azure でネットワーク増強は一部できたはず。Express Route はポート速度は上げられた。
上げるのは OK(すぐできる)んだけど、下げるのは回線を削除しないといけないんよね。一方通行。
【参考:Azure ExpressRoute の価格

月の途中でポート速度を変更できますか?
料金サイトの Q&A より

少なくともここ 3 年は非機能ばっかりやってるから、今はこっちの方が親和性高いなー。
インフラ・プラットフォーム側はほぼ非機能しかないからね。やり方がある程度決まっている分、今は非機能の方がやりやすいわ。
このクラウドの時代、瞬時にインフラ増強できるからね。電気・ガス・水道と同じ。コスト?(´・ω・`)知らんがなw と言いたいw
アプリ屋が必死になって性能改善する頻度も減っているはず。
より便利な時代になってきているはずなのに、何でエンジニアはいつも大変なんだろう???

あと・・・今の時代「アプリ」「インフラ」「運用」って分けて考えるのって難しいよね?
現職(当時)だと、上記に「デザイン」「セキュリティ」「認証」とかのチームがあるからなー。
さらにごった煮。


※以下、当時の文章。


機能設計は前号で説明しましたが、非機能設計と聞くとちょっとよく分からないところがあるかもしれません。
目に見えにくい分、お客さんも事象(トラブル)が現れてから騒ぎ出すので、なかなか設計が難しい部分でもあります。

この設計って何だろう?
どういうことをやっていけばいいんだろう?

今週は上記について簡単に解説します。

個人的な観点ですが・・・
機能設計のように目に見えるものが少ない部分ではありますが、やることはどの案件も変わりません。
画面設計や帳票設計のように案件ごとにオリジナルな部分は少ないので、やり方さえ覚えれば他の案件でも使いまわせる(かもしれない)部分ではあります。

あとは・・・非機能設計はアプリ、インフラ、運用が密接に関わってくる部分なので、ここで失敗すると手痛いしっぺ返しが来ます。
アプリだけではどうしようもない → インフラ増強しかない → コストが・・・!! というコンボをよく見てきました。
(性能とか、性能とか、ストレージ容量とか・・・)
インフラ増強で何とかできるのであれば良いのですが、例えば、Azure を使っていてネットワークの問題で要件が満たせないとなるともう最悪です。
(Azure は現時点ではネットワーク増強ができません。AWS ならできるようなのですが)


非機能設計とは


1)情報システムやソフトウェアの開発に際して定義される要件のうち、機能面以外のもの全般。性能や信頼性、拡張性、運用性、セキュリティなどに関する要件が含まれる。
→ 上記より、ここでは『非機能要件を満たすための設計』という意味で「非機能設計」と記載します。

  • 非機能設計の位置づけ
    基本設計書は要件定義書に記載されている要件を基に、要件を実現する方法を記載します。
    大きく分けて以下について設計します。

※以下、私見です!
※機能設計と同じ。

ドキュメント種類 概要
基本設計書 機能設計 システムで実施・実行する要件を実現
非機能設計 システムが担保していないといけない要件を実現


  • 非機能の決め方
    機能は、大きく分けて以下のように決め、または、決まります。
    ※これも機能設計と同じ。

    ① 顧客より提示される(顧客によって決まるパターン)
    →公共系、金融系の巨大プロジェクトでは、あらかじめ顧客側から機能一覧を提示されることが多いです。
     (顧客側のコンサルタントが要件定義書を作成)
     また、基本設計からプロジェクトに参画する場合も同様です。
     いずれにしても、ベンダーは要件定義書を確認し、過不足が無いか、曖昧な記述は無いか、不明点は無いかを確認し、再度要件を深堀り(具体化)します。

    ② ベンダーが作成(ベンダー決めるパターン)
    →小・中規模案件はほとんどこのパターンです。要件定義工程でまとめます。
     要件定義書がうまくまとまっていたら、基本設計も捗ります。
     もしそうでなかったら、上記①と同様に確認し、要件を具体化する必要があります。

非機能設計でやること

  • ①担当決め
    要件定義書の非機能要件箇所より、どのチームがどの設計を行うかを決めます。
    主に大規模案件で実施することが多いです。

    逆に小・中規模案件では、全てアプリ側で実施する場合もありますが、最近ではインフラ部分のヘルプや、運用・保守設計について運用側が設計から入って実施する流れ(分担制、協業体制)に変わってきているようです(あくまでも、この会社では)。
    以下、担当分けの一例です。

非機能設計 概要 主担当(副担当)
性能・負荷 規定人数が同時アクセスした場合でも、レスポンス遅延なくアプリケーションが応答できるよう、根拠を持って目標値を立てる設計。 アプリ(インフラ)
可用性 システムの稼働率について設計する。単一障害点が発生しないような構成やメンテナンス時間について記載。 インフラ(運用)
信頼性(完全性) セキュリティだけでなく、機器やサービスの故障等に起因するデータの減失や改ざんを防止する対策について設計する。 インフラ(運用)
拡張性 利用者が増えた際に柔軟に対応できる構成について設計する。 インフラ
上位互換性 OS やミドルウェア等のソフトウェア製品等のバージョンアップの際、どのように実現するかを設計する。 インフラ(アプリ)
中立性 特定の業者に依存しないように、一般的な技術や製品を使用し、将来にわたり市場で代替技術や技術者等を容易に調達できることを説明する。 アプリ(インフラ)
事業継続性 大規模災害発生時にどのように事業が継続できるかを説明する。主に DR。 インフラ(運用)
ユーザビリティ
アクセシビリティ
直観的に見て分かりやすい画面にするには(ユーザビリティ)、全てのユーザーが確実に情報を得られるには(アクセシビリティ)どうするかの方針を記載する。 アプリ
セキュリティ セキュリティについての方針を示し、具体策を記載する。 アプリ、インフラ、運用
テスト どのようにテストを実施するか、テストを行う環境はどこか等を記載する。具体的にはテスト計画書に記載することが多い。 アプリ
移行 何を、どこに、どのように移行するかを記載する。具体的には移行計画書に記載することが多い。 アプリ
教育 教育対象者と教育方法について記載する。 アプリ
運用・保守 監視や保守対象等について記載する。具体的には運用設計書に記載することが多い。 運用
引継ぎ 他のベンダーに運用・保守を引き渡す際に必要となる事柄について記載する。 運用


* ②非機能要件の確認、設計
要件定義書の非機能要件を確認し、実現可能であるか、設計可能であるかを再度確認します。
もし不明な箇所、曖昧な箇所があれば、顧客に確認し詳細を詰めます。