A.1 可用性>継続性 継続性に関するまとめ 継続性に関する記事一覧 A.1 可用性>継続性 req-definer.com 上記の記事で紹介したIPAの非機能要求グレードに関して、小項目をちょっとずつまとめてきた。今回まとめた項目は、中項目としての継続性に分類されるも…
稼働率を決めるうえで大切なことは、業務が停止したときにどのくらい困るかを明確化すること 24時間365日稼働するクラウドサービスの場合 まとめ 結論:まずは、業務の停止許容時間を決めた後に、目標稼働率を決めよう 今回は、稼働率について紹介する。 ①稼…
インターネットがない時代 インターネットが出現した時代 スマホが出現した時代 自動コード生成ツールの出現 プログラマーの仕事の仕方の変遷 設計者と実装者(プログラマー)の境界がなくなる これからの時代に向けて スキルアップのパターンは2つある 終わり…
[No1][A.1.4]可用性>継続性>目標復旧水準(大規模災害時) 目標復旧水準(大規模災害時)についてのまとめ 結論:大規模災害が起こった時のことについて話し合っておこう [No1][A.1.4]可用性>継続性>目標復旧水準(大規模災害時) 今回は、目標復旧水準…
ベンダ選定における重要なポイントは、組織力 ベンダ選定の3ステップ ステップ1:良い要件定義書を書く ステップ2:ベンダに見積もりを依頼する ステップ3:ベンダを選定する ベンダ選定の3ステップの図説 結論:要件を定義しなければ、見積もりを依頼で…
[No1][A.1.3]可用性>継続性>目標復旧水準(業務停止時) ①RPO(Recovery Point Objective):目標復旧地点 ②RTO(Recovery Time Objective):目標復旧時間 ③RLO(Recovery Level Objective):目標復旧レベル 目標復旧水準(業務停止時)に関するまとめ 結論:…
IT業界における平均年収(dodaの募集案件ベース) 抽象的な問題解決能力とコミニュケーション能力が年収を左右する 平均的には、プログラマ⇒SE⇒ITコンサル⇒プロマネの順で年収は1.2倍ずつ増える 要件定義スキルの良い点は、そのスキルが汎用的かつ陳腐化しにく…
[No1][A.1.2]可用性>継続性>業務継続性 ①対象業務範囲 ②サービス切替時間 ③業務継続の要求度 業務継続性に関するまとめ 結論:非機能要件として、業務継続性について合意しよう [No1][A.1.2]可用性>継続性>業務継続性 今回は、業務継続性について紹介す…
職場ではPDCAを回しましょうという言葉が良く出てくるのだが、個人的には、Aという部分に引っかかっている。Aというのは、Act(改善)の頭文字なのだが、ActしたらまたCheck(評価)が必要なんじゃないのか?と思ったりする。今回は、PDCAについて整理をする。 P…
バッチ処理 オンライン処理 バッチ処理とオンライン処理の使い分け 結論:バッチ処理の必要性を吟味しよう プログラマの仕事を始めたころ、バッチ処理プログラムを作ってくれと言われたことがある。その当時は、なんとなく一連の処理をするプログラムのこと…
非機能要求グレードの問題点は、活用への障壁が高いこと [No1][A.1.1]可用性>継続性>運用スケジュール ①通常日の運用時間 ②特定日の運用時間 ③計画停止の有無 運用スケジュールに関するまとめ 結論:非機能要件として、運用スケジュールについて合意しよう…
スコープとは スコープを決める=する/しないをはっきり決めること する/しないをはっきりさせると、要件定義書の表現が力強くなる 結論:考え抜いて、スコープを決めよう 下記の記事で、QCDの議論をする前に、スコープを決めようという趣旨の記事を書いた。…
デグレードとは? デグレが発生するメカニズム 影響調査が必要な個所 デグレを防止するためにやるべきこと 結論:デグレードを防ぐために、共通変数やモジュールの振る舞いの変化に着目しよう。 システム開発で、最もやってはいけないのが、デグレードだ。こ…
システムに対する要件定義を行う際は、機能要件定義と非機能要件定義を行う。 機能要件の定義自体は、さほど難しくない。顧客がやりたいことを丁寧に詰めていくだけだ。しかしながら、非機能要件の定義は難しい。機能じゃない部分全般に対して要件を定義する…
QCDの前にやるべきこと 要件定義を事前にしっかりやっておけば、プロジェクトはもめない 結論:要件をしっかり定義し、優先度をつけ、QCDを成立させよう 仕事をしていると、QCDという単語が良く出てくる。 Quality(品質) Cost(コスト) Delivery(納期) の頭文…
要件定義書の書き方がわからない、要件定義って何やればいいの?という方もいると思うので、発注側としての要件定義書の作り方をまとめておく。 要件定義書に書くべき内容の図による表現 手順①:[作業]あるべき姿の確認 手順②:[作業]現状の把握 手順③:[作…
日本語における「定義」の辞書的な意味 英語における「要件定義」の辞書的な意味 完全に決めるのが要件定義 結論:要件定義では、完全に決める努力をしよう 日本語における「定義」の辞書的な意味 要件定義における「定義」に関して確認しておく。まずは、go…
設計者として欲しい人材 設計者に必要なのは、認識を合わせこむ力である 結論:設計者なら、相手と認識を合わせながら開発を進めよう システムエンジニアといったら、まず頭に浮かんでくるのが、設計者だ。システムに関するエンジニアはいろいろな種類存在す…
問題と課題の違い 課題を定義すると、要件を定義できる 結論:問題は「状態」であり、課題は「事(こと)」である 下記の記事で、要件定義をするには課題定義力が重要であると述べた。 req-definer.com 問題定義力ではなく、課題定義力である。どのような業種…
要件定義で失敗すると、プロジェクトはあっという間に炎上する。 req-definer.com IT業界の転職ならマイナビ IT AGENT<ご登録無料> 上記の記事でも述べているが、その原因は修正コストの大きさだ。システムが市場に出た後で要件レベルの不具合を直そうとし…
tents] 仕事柄、色々なプログラマを見てきたが、本当に色々な人がいると感じている。ぜひ次も働いてほしいと思える人や、次はないかなと思わざるを得ない人。プログラムはできるのに日本語が無茶苦茶な人、技術には明るいわりに無茶苦茶なプログラムを書く人…
V字モデル関係の記事について整理していきます。 あるべきV字モデル あるべきV字モデルにおける分業方法 あるべきV字モデル req-definer.com あるべきV字モデルにおける分業方法 req-definer.com
分業の必要性 あるべきV字モデルにおける分業方法について 会社間で担当責務を分ける場合 結論:考えた人が、自分で動きを確認すべし 先日は、自分の中で理想としているあるべきV字モデルについて整理した。今日は、あるべきV字モデルを適用して開発する場合…
ソフトウェアとは何か ウェアとは何か ソフトウェアとは、物理的な形のないウェアである 結論:ソフトだからといって、簡単に変更していいわけではない ソフトウェアとは何か 2020年度から、プログラミング教育が必修となった。プログラミングスクールも活況…
V字モデルとは何か あるべきV字モデル あるべきV字モデルにおいて、伝えたいこと まとめ 結論:自分なりのあるべきV字モデルを意識して、丁寧に開発を進めるべし 就職して駆け出しのエンジニアとなった頃、システム開発ってどのように行われるのだろうか?と…
要件定義時の修正コストは、運用後には200倍になる 大切なことは、不具合修正コストを肌感覚で意識し続けること 結論:運用後の不具合修正コストを意識して、開発を進めよう システム開発において、不具合はつきものである。今回は、要件定義工程で記載ミス…
顧客が本当に必要だったものという風刺画 風刺画は、伝言ゲームの難しさを語っている 伝言ゲーム×2回に対する対策 結論:顧客が本当に必要なものかどうか、外部設計レベルまで踏み込んで顧客に確認してもらおう 顧客が本当に必要だったものという風刺画 顧…
要件定義とは 設計とは 要件定義と設計のすみわけ 要件を定義して設計する=何をどのように作るかを決める 結論:要件定義は顧客とベンダで吟味して行われる領域で、そのあとにベンダが実現方法を任された部分が設計領域である 要件定義と設計の関係を整理す…
要件定義と受入テストの担当を分けるべきか? 担当は分けるべきではない。要件定義をしたなら受入テストの作成実施もすべき 要件定義書を作成したら、すぐに受入テストが作成できるはず 結論:要件定義書を作成したら、すぐに受入テストを作成しましょう よ…
要件定義書に書くべき内容 要件を定義するとは? 要件の段階的詳細化が重要 要件定義は、顧客とベンダでひざ詰めで行うもの 結論:要件定義書には、顧客とベンダですりあわせた要件を段階的詳細化して記載する 要件定義書に書くべき内容 要件定義書に書くべ…