- 追加された行はこの色です。
- 削除された行はこの色です。
#author("2023-01-08T13:05:09+09:00","default:irrp","irrp")
→見積もり・発注
→ドキュメント作成
→詳細設計
→アルゴリズム
#contents
*サブトピック [#o7e924f6]
-要件定義
--要件定義書の一般的な項目
-基本設計
-ビジネスプロセス管理
*一般 [#e7318f5b]
-[[システム開発の成果物・ドキュメント｜知っておきたい開発工程ごとの成果物を一覧で紹介！ | システム幹事>https://system-kanji.com/posts/system-deliverable]] 2022.10
-[[GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita>https://qiita.com/yoshii0110/items/32f93e0c8d24cb3207f7]] 2022.6
*アーキテクチャ [#ua38b434]
アーキテクチャって何？という素朴な疑問にはなかなか答えづらいが、一般的には、設計時の大きな方向性や方針を意味する。要件は実現しようとする機能の内容に重点を置くが、アーキテクチャは機能の実現方式に重点がおかれる。
-[[「ソフトウェアアーキテクチャの基礎」本はアーキテクトが読むべき本だった: プログラマの思索>https://forza.cocolog-nifty.com/blog/2022/09/post-808092.html]] 2022.9
-[[SOLIDを代替する設計原則、CUPIDについて - Qiita>https://qiita.com/devneko/items/b9d8c734099f5e2b510c]] 2022.9
-[[The Software Architecture Chronicles – @hgraca>https://herbertograca.com/2017/07/03/the-software-architecture-chronicles/]] 2017
--[[DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together – @hgraca>https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/]] 2017
-[[アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ - Qiita>https://qiita.com/fuubit/items/dbb22435202acbe48849]] 2019
--[[Architectural Decision Records | adr.github.io>https://adr.github.io/]]
-[[アーキテクチャと設計は全然違う⋯ただしあなたの想像する”違い”とは多分全然違う【輪読会発表紹介】 - エムスリーテックブログ>https://www.m3tech.blog/entry/software-architecture-chap2]] 2022.6
-[[「ソフトウェアアーキテクチャの基礎」を読んだので、その要点 - Qiita>https://qiita.com/e99h2121/items/1844f5ed8da453a6dfb0]] 2022.3
-[[アーキテクチャに関してのありがちなギモンに答えていく - Qiita>https://qiita.com/SDTakeuchi/items/14b0a227f1bf30c71f66]] 2022.2
-[[DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien>https://digitalsoul.hatenadiary.org/entry/20100131/1264925022]] 2010
-[[ソフトウェアアーキテクチャの歴史>https://scrapbox.io/tasuwo/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%81%AE%E6%AD%B4%E5%8F%B2]] 2019.7
--GUI アーキテクチャの話.MVC, MVVM,
-[[ソフトウェアアーキテクトが知るべき97のこと>https://ソフトウェアアーキテクトが知るべき97のこと.com/]]
** クリーンアーキテクチャ [#b9c3c60d]
-[[Hexagonal Architecture and Clean Architecture (with examples) - DEV Community>https://dev.to/dyarleniber/hexagonal-architecture-and-clean-architecture-with-examples-48oi]] 2022.8
-[[PythonでLayered ArchitectureとClean Architectureを使ってカレーと肉じゃがを作ってみた - Qiita>https://qiita.com/c0ridrew/items/41f0566b676d8092a9fb]] 2022.7
-[[「Clean Architecture」を読んだので、その要点 - Qiita>https://qiita.com/e99h2121/items/6cd719b6b871d1c3d03b]] 2022.2
-[[最速でアプリケーションアーキテクチャの答えであるクリーンアーキテクチャを理解する - Qiita>https://qiita.com/izzonn/items/c06492a3e4bdc58b4ca8]] 2021.12
-[[Clean Architecture の勘所は『鎖国』だ。>https://qiita.com/t2-kob/items/02a76572693130c9a66e]] 2021.8
-[[クリーンアーキテクチャをミニマルで実装可能な形にした Simple Clean Architecture という考え方>https://qiita.com/genki-sano/items/4538383c7b52ba19ebe6]] 2021.6
-[[実装クリーンアーキテクチャ>https://qiita.com/nrslib/items/a5f902c4defc83bd46b8]] 2020.5
*基本設計 [#p99f0dd0]
-基本設計は大雑把な設計、詳細設計は細かい設計だと思っている人がいるが、それは誤り
-基本設計は、システムを外から見たときどういう動きをするか（＝外部設計、What）を決めるもの。詳細設計は基本設計で決められた動きをどうやって実現するか（＝内部設計、How）を決めるもの、と考えるとよい。基本⇔詳細という言葉に惑わされず、外部から見たときの動きについての話なのであれば、どんなに細かいことでも基本設計に書く。
-[[「設計」で大事なのはこれだった！半年間で40本レビューして分かった 5つのポイント - Link and Motivation Developers' Blog>https://link-and-motivation.hatenablog.com/entry/2022/10/05/181858]] 2022.10
-[[GitHub - karanpratapsingh/system-design: Learn how to design systems at scale and prepare for system design interviews>https://github.com/karanpratapsingh/system-design]] 2022.8
-[[いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Sr. Product Manager @ Mercari｜note>https://note.com/fmkpro1984/n/n09a2f5b01f33]] 2022.8
-[[令和時代のシステム開発では、どのような設計書を書くべきか>https://thinkit.co.jp/series/9344]] 2020.7
-[[リトライと冪等性のデザインパターン>http://frsyuki.hatenablog.com/entry/2014/06/09/164559]] 2014.6.9
-[[システム分析アプローチを後輩と話した件>http://getlife.hateblo.jp/entry/2014/04/09/041606]] 2014.4.9
--POA,DOA,SOAの比較
-[[上流工程-設計>http://itpro.nikkeibp.co.jp/article/COLUMN/20060831/246890/]]
-[[機能要件設計書だけで20種類>http://itpro.nikkeibp.co.jp/article/COLUMN/20090108/322434/]] 2009.1.8
--基本設計は大きく分けて三つのプロセスを踏む。いずれの設計も入力情報となるのは要件定義で作成した成果物である。
---「機能要件設計」どのような機能をアプリケーションに求めるかを設計する。その際「画面」「業務プロセス」「データ」という三つの切り口に分ける。
---「システム方式設計」システム方式設計では、性能や信頼性などの非機能要件を整理する。それを踏まえて、ハードウエアやソフトウエアなどの構造や実装方式を練る。
---「アプリケーション方式設計」アプリケーション方式設計では、非機能要件を考慮しつつ、機能要件設計で明確にした機能（画面、業務プロセス、データ）を適切なサイズのモジュールに割り当てる。
--[[基本設計で作成する設計書の一覧(日立システム開発方法論「HIPACE」を基に作成)>http://itpro.nikkeibp.co.jp/article/COLUMN/20090108/322434/?SS=imgview&FD=54139247]]
-[[異種統合型情報サービスシステムにおける自律分散アシュアランス技術の研究>http://tdl.libra.titech.ac.jp/cgi-bin/z3950/gakui_detail_disp.cgi?REG_NO=117193144]]
-[[システムのリプレース案件が最も危険な理由>http://forza.cocolog-nifty.com/blog/2008/02/post_6234.html]] 2008.2.24
--運用していくうちに、バグフィックスや機能追加で、恐竜のように馬鹿でかくなった中身は、最新のオブジェクト指向言語で、同じようにたくさんのバグフィックスを重ねて積み上げたものに変わる。
同じソースコードの断片は一つもないはず。
--プログラムの保守性や移植性、再利用性が、どの時代になっても、言語がいくら発展しても難しいこと。
--特に再利用性は、そのライブラリの粒度に大きく依存する。
--再利用できる程度は、フレームワーク程度ぐらいで、昔から夢想するビジネスオブジェクトレベルまでなかなか辿り着けない。
-[[ドキュメントに「夜間バッチ」と書いてはいけない>http://enterprisezine.jp/article/detail/15?p=1]] 2007.7.30
--「○○ジョブ」には、「これらを整形し直し、本社DBに格納する」という意味が推測できるような名前をつけなければならない。「夜間バッチ」では単に「夜間にまとめて行う処理」というだけの意味しか表していないため、その推測ができない。これではいけないわけだ。
-[[オブジェクト指向の基本設計を理解する>http://itpro.nikkeibp.co.jp/article/lecture/20070702/276411/?ST=lecture&P=1]]
--UP:ユニファイド・プロセス
-[[DOA法による基本設計の解説>http://itpro.nikkeibp.co.jp/article/lecture/20070702/276410/?ST=lecture&P=1]]
**画面設計 [#p5d3b47d]
-[[Figmaのコンポーネントに動きをつける - Qiita>https://qiita.com/tomo_oe/items/89b617a5988f19adc33f]] 2022.10
* 要件定義と基本設計の違い [#od43245f]
-要件定義とは、乱暴に言うとそのシステムで実現したい（および実現しない）ことをまとめたもの
-要件定義の一般的項目→要件定義書の一般的な項目
・業務要件：現状、新業務フロー等
・システム要件：インフラ系を中心にネットワークやシステム構成等
・セキュリティー要件：セキュリティに関しての要求事項等
・機能要件：大まかな機能や、「これを実現して欲しい」等の要求
・非機能要件：性能要件や障害発生時にどうなるかなど
・運用要件：運用まわり、バックアップ、容量見積等
・その他：ケースバイケースで他に何かあれば
・昔はレスポンス要件等もあったがＷＥＢでは保証できない
-基本設計の一般的項目 乱暴に言うと、要件定義をインプットとしてシステムの外部仕様を決めるのが基本設計
・システム設計：インフラ、ネットワーク、機器構成、プロダクト構成等
・画面設計：デザイン、項目定義等
・ＤＢ設計：論理／物理設計、ＥＲ図等
・インターフェイス設計：他システムとの外部インターフェイス、ファイル、帳票設計等
・処理設計：ＤＦＤ、ＩＰＯ、ＣＲＵＤ、コード設計等
・業務・運用設計：サービススケジュール、バックアップ、リカバリー方法
新業務フローの詳細等
・テスト設計：テスト方法、ツール等の設計
・その他：補足資料他
*要求開発 [#bbfe4bee]
-[[「要件定義」のまえに、「要求定義」｜Shoty / UXデザイナー｜note>https://note.com/shoty/n/n821006286f0e]] 2020.5
-[[超上流を極めるための「要求開発」入門>http://itpro.nikkeibp.co.jp/article/COLUMN/20100723/350602/?ST=babok]] 2010.7.23
-[[観察力と推理力のプロ>http://itpro.nikkeibp.co.jp/article/COLUMN/20080328/297382/]] 2008.4.9
--「企業の本社や管理部門は報告書やら何やらであまり役に立っていないものがどっさりありますが，物流センターのような現場には無駄な物なんてないんですよ。どんなに旧式のプリンタであっても業務に必要だからそこに置いてあるわけで，そういう意味では紙切れ1枚にも大概役割があるんですね」
-[[システム開発には広い視点で取り組め>http://itpro.nikkeibp.co.jp/article/COLUMN/20080228/294986/?P=1&ST=management]] 2008.4.7
--利用部門が主体ということと，利用部門の言うことをなんでも聞くことは全く異なる。利用部門は新システムに対しても従来通りの機能を要求したり，自分が困っていることを解決してほしいという観点だけで要件を出すことが多い。
-[[RoRで要求仕様を開発(RfS)>http://itpro.nikkeibp.co.jp/article/Watcher/20080122/291715/?P=1]]
--要件定義フェーズでRfSを行うときには，もらった設計書を単にプログラム化するだけの能力しかないプログラマでは荷が重い。
--変化に強いスタイルで構築しなければならないため，オブジェクト指向をちゃんと理解したうえで，アジャイルの設計スキルと，きれいにコードを作成できる技術を身に付けた開発者である必要がある。そうでないと，要件定義の間に「仕様」のアプリケーションが変化に対応できなくなってしまう。また，開発しながら仕様を決めるので，要件定義のスキルも必要だ。
--つまり，このフェーズでプログラミングを行う開発者は高度なスキルを要求される。RfSとは，上流フェーズをプログラミングを使って行うということなのだ。
-[[要求を洗い出す４つの工夫>http://itpro.nikkeibp.co.jp/article/COLUMN/20071012/284428/?ST=print]]
--模型を作って動かす
--壊しては作る
--サンプル集で動きを確認
--UI仕様書と画面見本
-[[要求分析ツリー>http://itpro.nikkeibp.co.jp/article/Watcher/20071009/283860/]]
-[[開発プロセスの本質・要求開発のフロントローディング開発>http://itpro.nikkeibp.co.jp/article/Watcher/20070115/258715/]]
--【現状の課題】
---要求自体がどんどん複雑化し，とらえづらくなっています
---既存の人の業務をコンピュータ化するという観点だけではなく，業務をIT化することで付加価値を創出しなければならないという課題を負うことが多くなります。
---このような要求については，要求提案当初は非常にあいまいな場合が多いのです。
---様々なテクノロジを組み合わせて開発した結果，はたしてビジネス要求を実現できるかのかどうか，ちょっとやってみないとわからない
--【対策】
---これらのリスクをできるだけ早期にヘッジするために，反復開発やアジャイル開発
---(1)要求を早期に検証する
---(2)技術的リスクを早期にヘッジする
--【上記対策の問題点】
---システム開発よりも前段階で，つまり企業の将来ビジネスを構想する要求開発の段階にて，両リスクをヘッジするための対策を講じる必要が出てくる
---ビジネスとITが密接に関係するような問題領域では，ビジネス要求をITでどう表現するかによってIT化の価値が左右するため，試行錯誤しながらビジネス価値を創出するIT表現を洗練させることが重要となる。
-[[要求開発アライアンス(ReDA):http://www.openthology.org/index.html]]
--「要求開発」というフェーズが必要という主張
-[[要求開発について:http://dain.cocolog-nifty.com/myblog/2006/07/4_a6f2.html]]
-[[要求定義の基本を知る>http://itpro.nikkeibp.co.jp/article/lecture/20070124/259544/]]
--あらゆる要求定義に共通する「4つの必須スキル」がある。それは，
---（1）ヒアリング技法
---（2）業種・業務知識
---（3）要求定義の方法論
---（4）要求をモデル化するための図法――の4つだ。
--要求定義を成功させるためには，まずこの4つの必須スキルを身に付けて地道に実践するしかない。
-[[要求管理入門@IT:http://www.atmarkit.co.jp/farc/rensai/re_mgt01/re_mgt01.html]]
*業務知識 [#q5431ff4]
-[[「優しい銀行の読み方 銀行の財務諸表とディスクロージャー」 全銀協で配賦している冊子>https://www.zenginkyo.or.jp/fileadmin/res/abstract/efforts/smooth/accounting/disclosure.pdf]] 2019.5
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
