非機能要件は、情報システムやソフトウェアの開発に際して定義される要件のうち、機能面以外のもの全般のこと。 性能や信頼性、拡張性、運用性、セキュリティなどに関する要件が含まれる。
日本情報システム・ユーザー協会(JUAS)が発行した「非機能要件要求仕様定義ガイドライン」では、非機能要件を以下の10種類に分類して定義している。
[A.2.6]可用性>耐障害性>ネットワーク機器 ①バックアップ方式 ②データ復旧範囲 ③データインテグリティ まとめ [A.2.6]可用性>耐障害性>ネットワーク機器 今回は、耐障害性(データ)について紹介する。ここで決めるべきことは、①バックアップ方式、②データ復旧範囲、③データインテグリティである。 ざっくり言うと、 ①もしものときのために、どのようにデータを保管し、 ②いざ障害が起こったら、どこまで復旧し、 ③データの正しさの保証はどこまでしておくか を決めておくこととなる。 ①バックアップ方式 最初に検討すべきポイントは、そもそもデータをバックアップする必要があるのかないのかである。…
[A.2.4]可用性>耐障害性>ネットワーク [A.2.4]可用性>耐障害性>ネットワーク 今回は、耐障害性(ネットワーク)について紹介する。耐障害性(ネットワーク)とは、ネットワークがどのくらい障害(例:通信障害)に耐えられるのかを示す度合いのことを指す。 サーバーと端末が通信をする場合、ネットワーク(通信網)を介して通信を行うこととなるが、ネットワークの一部で障害が発生したとしても、どのくらい滞りなく通信を継続させられるようにすべきかが、本項目で検討すべきことだ。 耐障害性(ネットワーク)に関して決めるべき項目は点存在する。 ①回線の冗長化 ②経路の冗長化 ③セグメント分割 以下、順に説明…
[A.2.3]可用性>耐障害性>ネットワーク機器 ①冗長化(機器) ②冗長化(コンポーネント) 耐障害性(ネットワーク機器)に関するまとめ 結論:非機能要件として、ネットワーク機器の冗長性について合意しよう [A.2.3]可用性>耐障害性>ネットワーク機器 今回は、耐障害性(ネットワーク機器)について紹介する。耐障害性(ネットワーク機器)とは、サーバーにおける耐障害性と同様、ネットワークがどのくらい障害に耐えられるのかを示す度合いのことを指す。サーバーにおける耐障害性については、下記参照。 req-definer.com ただし、サーバーのそれと異なる点として、サーバーはネットワーク上の端っこ…
[A.2.1]可用性>耐障害性>端末 ①冗長化(機器) ②冗長化(コンポーネント) 耐障害性(端末)に関するまとめ 結論:非機能要件として、端末の冗長性について合意しよう [A.2.1]可用性>耐障害性>端末 今回は、耐障害性(端末)について紹介する。耐障害性とは、サーバーにおける耐障害性と同様、どのくらい障害に耐えられるのかを示す度合いのことを指す。サーバーにおける耐障害性については、下記参照。 req-definer.com ただし、サーバーのそれと異なる点として、サーバーの場合は、端末から接続されているので壊れたら別系統へ速やかに切り替えなければならないが、端末の場合は、文字通り端っこの…
[No1][A.2.1]可用性>耐障害性>サーバ ①冗長化(機器) ②冗長化(コンポーネント) 耐障害性(サーバ)に関するまとめ 結論:非機能要件として、サーバーの冗長性について合意しよう [No1][A.2.1]可用性>耐障害性>サーバ 今回は、耐障害性(サーバ)について紹介する。耐障害性とは、サーバやコンポーネント(部品)が故障しても、予備の系統に切り替えるなどして稼働を継続し、どのくらい障害に耐えられるのかを示す度合いのことを指す。 耐障害性(サーバ)に関して決めるべき項目は2点存在する。 冗長化(機器) 冗長化(コンポーネント) 以下、順に説明する。 ①冗長化(機器) 機器の冗長化とは…
A.1 可用性>継続性 継続性に関するまとめ 継続性に関する記事一覧 A.1 可用性>継続性 req-definer.com 上記の記事で紹介したIPAの非機能要求グレードに関して、小項目をちょっとずつまとめてきた。今回まとめた項目は、中項目としての継続性に分類されるものとなる。ようやく11項目/283項目完了した。先は長いがちょっとずつまとめていきたい。 継続性に関するまとめ 下記に、「継続性」の11項目に関して簡単にまとめたものを表形式で記す。業務継続性として、何を決めなければならないのか?と思ったときは、参照されたい。 項番 小項目 メトリクス(指標) 決めることの具体例 A.1.1.1…
稼働率を決めるうえで大切なことは、業務が停止したときにどのくらい困るかを明確化すること 24時間365日稼働するクラウドサービスの場合 まとめ 結論:まずは、業務の停止許容時間を決めた後に、目標稼働率を決めよう 今回は、稼働率について紹介する。 ①稼働率:稼働を予定している時間のうち、どのくらいの割合稼働させられるか 稼働率というのは、稼働を予定している時間のうち、どのくらいの割合の時間システムが稼働しているかの指標だ。稼働率99%だとか、稼働率99.9%だとかの数字で表現される。あまりイメージがわきにくいと思うので、具体的な数字で計算してみよう。 例として、定時時間中のみ稼働しているシステム…
[No1][A.1.4]可用性>継続性>目標復旧水準(大規模災害時) 目標復旧水準(大規模災害時)についてのまとめ 結論:大規模災害が起こった時のことについて話し合っておこう [No1][A.1.4]可用性>継続性>目標復旧水準(大規模災害時) 今回は、目標復旧水準(大規模災害時)だ。 想定したくはないものだが、想定しておかなければならない。大規模災害というのは必ず発生する。大雨洪水で電力の供給や通信線が遮断され、システムが稼働できなくなる場合もある。地震や火災でデータセンターが破壊されてしまう場合もある。それでもいつかはビジネスを再開せねばならず、再開までの目標を決めておかねばならない。 r…
[No1][A.1.3]可用性>継続性>目標復旧水準(業務停止時) ①RPO(Recovery Point Objective):目標復旧地点 ②RTO(Recovery Time Objective):目標復旧時間 ③RLO(Recovery Level Objective):目標復旧レベル 目標復旧水準(業務停止時)に関するまとめ 結論:非機能要件として、目標復旧水準(業務停止時)について合意しよう [No1][A.1.3]可用性>継続性>目標復旧水準(業務停止時) 今回は目標復旧水準(業務停止時)だ。簡単に言うと、システムが故障した後に、いつまでに、どのくらいのレベルで、システムを復旧さ…
[No1][A.1.2]可用性>継続性>業務継続性 ①対象業務範囲 ②サービス切替時間 ③業務継続の要求度 業務継続性に関するまとめ 結論:非機能要件として、業務継続性について合意しよう [No1][A.1.2]可用性>継続性>業務継続性 今回は、業務継続性について紹介する。業務継続性は、システムに障害が発生しても、どのくらい業務を継続できるようにするのか、の程度を表している。 業務継続性に関して決めるべき項目は3点存在する。 対象業務範囲 サービス切替時間 業務継続の要求度 以下、順に説明する。 ①対象業務範囲 対象業務範囲というのは、対象業務の種別のことを表している。対象業務範囲として、下…
generated by DALL-E3 はじめに 具体例の紹介 各概念における抽象クラスの作成 量産対象となる具象クラスの記述量を減らす LaravelDataの活用 連想配列と引数のアンパックの活用 リフレクションによる内部情報の利用(黒魔術) バックトレースによる呼び出し元情報の参照(暗黒魔術) 実際の使用にあたって ビジネスルール検証におけるValidatorの活用 従来パターンにおける課題 Validatorを用いる前提で宣言的に記述する方式 オブジェクトが入れ子になっている場合の責務の所在 その他ポイント フロントエンドバリデーションとの数値ルール共有 Eloquent Model…
news.yahoo.co.jp 今回、対応を進めるにあたり、サービス内で一部語句が伏せ字になる点、特定語句を新規表現へと置き換える点を報告。後者の具体例としては「ロリ→ひよこ」「催眠→トランス/暗示」「調教→しつけ」などがある。 同人販売サイト「DLsite」アダルト表現を「ひよこ」「秘密さわさわ」などに変更 クレジットカード会社から要請(KAI-YOU.net) - Yahoo!ニュース ⇧ この対応は、悪手に過ぎる気が... アダルトコンテンツということで、影響範囲が局所的になると思われるとは言え、「ダブル・ミーニング」が汚染されてしまう気がするんだが... 今回、「ゾーニング」という概…
AWSコスト最適化ガイドブック www.kadokawa.co.jp aws.amazon.com Cloud Financial Management (CFM) AWS が提唱しているクラウド利用費用最適化を進めるためのフレームワーク、実践の4つの柱を持つ。 クラウド利用費用の可視化 クイックウィン最適化(迅速なクラウド利用費用削減)とアーキテクチャ最適化(中長期的な視点でのクラウド最適化) クラウド利用費用の予測と次年度の予算策定のための予測に基づいた計画 持続的なクラウド最適化を推進していくための FinOps 1. クラウド利用費用の可視化 クラウド利用費用に対する責任の所在を明確に…
はじめに こんにちは、検索基盤部の倉澤です。検索基盤部では、検索機能に必要なデータを生成するバッチシステムの開発や運用を担当しています。また、ユーザーのニーズやサービスの成長に合わせてリアーキテクチャを行うこともあります。今回は、リアーキテクチャを繰り返し行う中で見えてきたバッチシステムの内部設計の品質を高める・標準化するためのポイントを紹介します。 今回、バッチシステムの内部設計をソフトウェアのアーキテクチャ特性(品質特性とも呼ばれる)に基づいて説明します。 ソフトウェアのアーキテクチャ特性とは、非機能要件や品質特性と同じ意味を指しますが、「ソフトウェアアーキテクトの基礎 (Fundamen…
要件定義 やること/やらないことを明確にする 業務要件 システムの概要 ユースケース →管理者やユーザーの出来る事を図等で記載 機能要件 アプリの種類 →PCのみか?スマホはやるのか? 外部システム連携 →どのAPIを引っ張ってくるか? 機能一覧 (例) | カテゴリー | 機能 | 実装方法 | 必須 | 備考 | |:-:|:-:|:-:|:-:|:-:| |フロント機能|会員登録フォーム|会員登録 | | | | | | クレカ登録 | | | 非機能要件 インフラ構成 キャパシティプランニング →ユーザー数、コンテンツ数等の規模は?7 性能要件 →画面表示はx秒を目標etc.機能目標を…
前置き AWS Security and Risk Management Forum ~レジリエントな未来:生成AIなどの最新技術を活用したセキュリティ・リスクマネージメント~ 書いてあるとおり、生成AI等のAIを活用したセキュリティとリスクマネジメントのフォーラムに参加してきました。 参加したセッション 進化するビジネス要件とセキュリティ目標を一致させるためには? ガバメントクラウドでの賢く安全なITインフラ実現の考え方 AWSの生成AIに対するセキュリティの取り組み 医療情報という要配慮個人情報を取り扱う上で検討すべき非機能要件とは 金融機関のシステム監査とクラウドセキュリティ~監査の3つ…
書籍「System Design Interview : Mastering Basic Introduction to System Analysis and Design」を読んだので内容をまとめる。 以下の内容は、ほとんどClaude3 Opusを使用して作成している。 CHAPTERごとの要約 CHAPTER 1: SCALE FROM ZERO TO MILLIONS OF USERS システム設計における基本的な概念と、シンプルなサーバー構成から数百万ユーザーをサポートする分散システムまでの段階的なスケーリングの方法を解説。垂直スケーリングと水平スケーリング、データベースのレプリケ…
エンジニアリング戦略室の高井といいます。 みなさん、開発生産性を高めていますか? 近頃、開発生産性という言葉をよく聞くようになってきました。開発生産性について書かれたブログや技術イベントでの発表を目にする機会が増えています。これはソフトウェアの重要性が高まってきていることや、またアメリカの金利政策によってマクロ経済状況が変化したという背景が影響しているようにも感じます。開発生産性という言葉がバズワードのようになりつつあります。 誰もが重要だと考えている開発生産性ですが、それが何であるのか、またどのように改善していくのか、という具体的な話になると喧喧諤諤の議論になってしまうようです。開発生産性と…
雑に考えてみた。 フロントエンドのコードレビューを前提としているが、観点自体はそれにとどまらないはず。 かっこ内には代表的な概念を書いた。 大観点 コード 設計 機能要件 非機能要件 テキスト スコープ 中観点の例 コード 読みやすいか 正しく書かれているか 保守しやすいか(クリーンアーキテクチャ) 余計なことをしていないか(KISS、YAGNI) コーディングルールに則っているか 世間のベストプラクティスに沿っているか(DRY、SOLID など) 設計 関連するロジックがひとまとまりになっているか・適切に分割されているか ビジネス要件を書き下した構成になっているか 他の箇所と整合性が取れてい…
こんにちは。技術本部 技術戦略ディビジョンでマネージャーをしています、奥村です。 この記事では2024年1月から始動した、アドウェイズの新しい組織「技術戦略ディビジョン」について紹介します。 発足経緯やどういう事に取り組む予定かを説明できればと思います。 技術戦略ディビジョンの概要 ミッション 取り組むこと 組織変更の背景 技術戦略ディビジョンができる前の組織 インフラストラクチャーディビジョンから技術戦略ディビジョンへの変化 目標 短期的な目標 中期的な目標 長期的な目標 課題 最後に 技術戦略ディビジョンの概要 技術戦略ディビジョンは、技術本部というグループに新たに設立された組織です。 2…
はじめに こんにちは。エージェント企画統括部 エージェントプロセス&システムデザイン部 後藤です。エージェント事業の基幹システムやサブシステムの開発、保守、運用等に従事しています。 この記事では、基幹システムであるARCS(アークス)のモダナイゼーションと、クラウドリフトプロジェクトについてご紹介します。 基幹システムARCSのモダナイゼーション ARCSはdodaエージェントサービスを提供するキャリアアドバイザーやリクルーティングアドバイザーが日々の業務で利用するシステムです。お客様への価値貢献を目指し、既存業務の拡張、効率化、新業務の追加などに合わせて、システムをアップデートし続けています…
2024年2月の創作ゲームの制作進捗報告です。 ゲーム :こはくへんげ物語制作ソフト :RPGツクールMZ 進捗 キャラドット作成 設計書作成 画面デザインラフ作成 まとめ 進捗 キャラドット作成 本作の主要キャラの1人とお花のキャラドットを作成しました。 わかりにくいですが、お花は移動キーを押しても動かない設定になっています。 gif見にくいけど、もうええか…になった。 設計書作成 2月はずっと設計書を作成していました。以下は作成資料の一覧表です。赤枠は作成済み資料です。 …多くね?というのも、要件定義・基本設計したことないからとりあえず必要そうなの作ってみるか!w のノリで洗い出しをしてい…
SaaSの開発に関わる機会があり、積読していた「All for SaaS」を読んでみることにした! ALL for SaaS SaaS立ち上げのすべて作者:宮田 善孝翔泳社Amazon 前職はアドテク系のSaaS開発に関わっていてこの本は購入していたのだが、積読になったまま埃をかぶっていた。 Amazonで確認したら2年前に購入したままになっていたw 今回は開発前に実施する、事前調査やプロトタイプを作る方法を知りたかったため、Part1「SaaSを取り巻く環境」〜 Part3「事前/深掘り調査とプロトタイプ」をメインに読み進めた。(という前提のもと本記事を読んでください) 本書を読んで、事業と…
前回は要件定義のやり方について書いた。 今回はそれに付け加える感じで、ユースケース記述の話。 ユースケース記述 ユースケース記述というのは、システムがどのように使われるのかという一連の流れを書いたもの。 一例を挙げると、たとえば「ユーザがログインする」という場合なら、 ユーザがブラウザで特定のURLにアクセスする。 システムはログイン画面を表示し、ユーザにメールアドレスとパスワードの入力を求める。 ユーザはメールアドレスとパスワードを入力し、「ログイン」ボタンを押す。 システムは入力されたメールアドレスとパスワードで認証を行い、認証ができたらユーザのマイページを表示する。 みたいな。 このユー…
こんにちは、a2 です。 Go のアプリケーションのコードをモリモリ生成してくれる AI Agent を作ることができないかなと思い、試してみてます。タイトルに書いたようなことはまだ全然できてないのですが、今回はその第一歩を書いてみます。 背景 今、開発現場における AI 活用は、GitHub Copilot を使って、エディターで開いているファイルを元に近しいコードを生成したり、関数のコメントから実装を生成してもらう、といった使い方が主流かと思います。 私も、Go の Table Driven Test のコードを書いてもらえるのがめちゃめちゃ助かってます。 しかし、これはあくまでソフトウェ…