検索対象

並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 46件

新着順 人気順

設計書の検索結果1 - 40 件 / 46件

タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。

設計書に関するエントリは46件あります。 設計、 開発、 development などが関連タグです。 人気エントリには 『Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita』などがあります。

設計書の関連エントリー

  • Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita

    初めましてこんにちは。 最近コードレビューの記事書いたら、Excelベースだったことを理由に Qiitaコメントとはてブで徹底的に燃やされたおじさんです。 いやね、僕だって使いたくて使ってるわけではなくてね、 できることなら使いたくないんですよ。 というわけで名誉挽回のために脱Excelできた話、 それも日本の三大悪三大風習に数えられるExcel設計書を抹殺した話を書きます。 (2/25修正：悪は言いすぎました。訂正します。） Growi 最高。 またの名をExcel方眼紙。 エクセルのセルの縦横を同じくらいの大きさに調整し方眼紙のようにして、 そこに設計書として文字と図と表を記載する方式。 メリット 一つのファイルに文字と図と表がまとめて記載できる テキストでは文字は書けても図と表が書けない Wordでは、文字と図表エリアとを2列表示するのが難しい できなくはないが面倒くさい UMLモデ

      Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita

    • 設計書・仕様書のレビュー方法を定めたJIS規格登場　チェック体制を標準化しやすく

      経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている

        設計書・仕様書のレビュー方法を定めたJIS規格登場　チェック体制を標準化しやすく

      • 設計書には何を書くべきなのか - terurouメモ

        設計とは、 要求（やりたいこと）をヒアリングする 要求を要件（何を満たさないといけないのか）に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する（一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する） 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案（いわゆる比較表で書いていくのが楽） 検証結果 選定・合意結果（合意した代替策や妥協ラインについても記載する） 詳細設計（どういう実装にするとか、パラメーターにするとか、細

          設計書には何を書くべきなのか - terurouメモ

        • ソフトウェアの「詳細設計書」とはなんなのか - きしだのHatena

          「設計書」というのは、作るものの構造を抽象的に表現したものと言うことができます。 ただ、ソフトウェアの抽象化の仕組みはプログラミングコード自体に備わっているので、ソフトウェア生成可能な抽象的表現というのはコード表現ができるはずですね。コードで表現しておくと、整合性のチェックとかも行いやすいです。 でも、コードではない「詳細設計書」というものが一部業界には必要とされているので、その「詳細設計書」というのは実際はなんなのか考えてみます。 ※ 最初はタイトルは「設計書」としてましたが、話を限定するため「詳細設計書」に変更しました。 追記：納品物に関する記述を追加しました。 追記(2024/11/27)：「概略図」「物理設備の設計」を追記 表現を変えたコーディング ソフトウェア生成可能な抽象的表現というのはコード表現ができるわけですが、文字で表記する必要もなく、ダイアグラムで表現することもできます

            ソフトウェアの「詳細設計書」とはなんなのか - きしだのHatena

            • 設計書の関連エントリー

          • ドキュメントとしての詳細設計書と、プロセスとしての詳細設計 - 勘と経験と読経

            「ソフトウェアの「詳細設計書」とはなんなのか」というブログ記事を読んで考えたこと。設計に関するプロセスとドキュメンテーションの関係性についての考えの整理。SI屋的な視点で。 2024/8/18追記：文中にあった雑な文系disが不愉快というご指摘を受けました。ご指摘の通りだと思いましたので訂正しています。大変失礼しました。 「詳細設計書」とはなんなのか nowokay.hatenablog.com こちらの記事では詳細設計書とは以下のようなものであると整理されている。 表現を変えたコーディング（の一種） 机上プロトタイプ（の一種） 分析資料 保守（のための）資料 （水平作業の場合の）作業指示書 （委託している場合の）契約資料 上記以外で考えられるのは次のようなものがあるだろう 利害関係者が要求している たとえば受託開発において発注者が要求している場合 ほかには連携している相手先システム側から

              ドキュメントとしての詳細設計書と、プロセスとしての詳細設計 - 勘と経験と読経

            • DB設計書の管理が楽になるDBML入門 – DBMLの書き方,dbdiagram.io, dbdocs の紹介 – | SIOS Tech. Lab

              Table users { id integer [pk] first_name varchar last_name varchar email varchar [not null] password varchar [note: 'Hashed password'] created_at datetime [not null, default: `now()`] updated_at datetime Indexes { email [unique, name: "ui_users_email"] } Note: 'table: users' } 上記のテーブル定義を dbdiagram.io の左側のコード記載部分に張り付けると右側にプレビューが表示されます。 以下は dbdiagram.io でのプレビューをした時の表示です。(Noteの箇所は説明のため加工しています) (1) Ta

                DB設計書の管理が楽になるDBML入門 – DBMLの書き方,dbdiagram.io, dbdocs の紹介 – | SIOS Tech. Lab

              • 「わし詳細設計書書くのやだよ」システム開発で細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない話に賛否両論

                しのゆー𝕏酒くずエンジニア @shinoyu 元HN風嬢の男性 / 新宿で社長やってるソフトウェアエンジニア18年生 / 💻技術🎧 V系 🎀ロリィタの人 / 170スペ110 スプリング、骨ウェーブ、顔ソフエレ / 絡みない鍵とスパムはブロック(プライベートリスト使え) / 原則IT関連業のみフォロー https://t.co/zGFlbhGSDi しのゆ𝕏酒くずエンジニア @shinoyu わし詳細設計書書くのやだよ(￣･ω･￣) 細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ 改修コストを下げるための設計になってることは前提だけどね。 だけど、詳細設計書が必要となる現場はこの設計することは

                  「わし詳細設計書書くのやだよ」システム開発で細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない話に賛否両論

                • markdownlintで設計書の品質を高める | フューチャー技術ブログ

                  はじめにフューチャー技術ブログのリレー形式の連載である、春の入門祭り2023の1日目です。TIG真野です。 ここ数年、Markdownで設計書をチームで書き、GitHub（GitLab）上でレビューするフローを採用しています。なるべくテキストベースで設計開発フローを統一するため、私の所属するチームでは以下のようなツールを採用しています。 シーケンス図、業務フロー図 Markdown中にPlantUMLで記載 参照はGitHub上からも見れるように、pegmatite を利用 システム構成図など画像系 Diagrams.net（draw.io）で作成し、.drawio.png の拡張子でMarkdownから参照 これだけは目視で差分チェックとなる Web API定義 OpenAPI SpecのYAMLファイル 参照はGitHub上からも見れるように、swagger-viewer を利用 ER

                    markdownlintで設計書の品質を高める | フューチャー技術ブログ

                  • 詳細設計書なんて、書きたくない・・・・Doxygenを使って自動生成してみる - Qiita

                    はじめに お客様に提案をしているときの会話です。 お客様：「詳細設計書は作りますか」 私：「昔ながらの詳細設計（ロジックを日本語で書くもの）は作りません。クラス図とか、シーケンス図は複雑であれば作りますが、今回のシステムはそこまで必要なものはないものなので、割愛しようと思っています。」 お客様：「保守をお願いするかどうか未定なので、場合によっては引継ぎのために作ってもらうかもしれません」 私：「・・・・」 といった感じで、私がこの業界に入った30年前は、確かにプログラムを作る前に、詳細設計書と呼ばれるプログラムを日本語で書いていました。 最近、詳細設計と呼ばれるものを作った記憶がなく、無駄なものは作りたくないなぁという思いから、コードから自動生成できないかなと思って、いろいろ試してみました。 Doxygenって いろいろ調べてみると、Doxygen にたどり着きました。 色々な言語に対応し

                      詳細設計書なんて、書きたくない・・・・Doxygenを使って自動生成してみる - Qiita

                    • 設計書を書かない設計で開発効率を向上させた話 - Tabelog Tech Blog

                      この記事は 食べログアドベントカレンダー2023 の23日目の記事です🎅🎄 こんにちは。食べログシステム本部 技術部 仕入チームの@shohei-yです。 今回は、新規事業の「食べログ仕入」プロダクト開発において所謂「設計書」を書かない設計に挑戦して開発効率を向上させた話を書きます。 （結局「書くの？書かないの？どっちなんだい！」と感じた人は、ぜひ読み進めてください。） 所属している仕入チームについてはこちらの記事をご覧ください。 目次 なぜ設計書を書かない設計に挑戦したのか 設計書を書かないチーム 設計書を書かないことによる問題 1. チーム協力の課題 2. ソースコードの複雑化 3. チーム変動に関わる問題 設計工程導入のきっかけ 設計書を書かない挑戦の背景 設計書を書かない設計 フロントエンド・バックエンドのインターフェースの明確化 ソースコードのスリム化対策 設計のレビュー方法

                        設計書を書かない設計で開発効率を向上させた話 - Tabelog Tech Blog

                      • 設計書・仕様書の書き方が分かる！

                        弊社では開発工程の上流である「要件定義、基本設計、詳細設計」において必要となるドキュメント標準が定義されております。本稿では「ドキュメント標準」の一部をご紹介しますので、是非ご参考にしてください。 各工程で必要なドキュメントを定義しましょう 下記のように工程ごとにドキュメント成果物、内容を定めております。 どの企業でも必要なドキュメント成果物になりますが、必要に応じて追加・削除頂ければと思います。 ※業務系のシステム開発に照準を当てております。 要求分析（要件定義） システム開発は要求分析（要件定義）というプロセスから始まります。要求分析（要件定義）は、顧客の要求を把握してシステム要件を確定することです。主に以下のような事項をまとめます。 要求概要 システムの目的 現状の課題と改善案 基本要件と優先順位 到達目標 システムの実現手段 システム化の範囲 概略費用 効果（定性／定量） 体制図

                          設計書・仕様書の書き方が分かる！

                        • 伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.pdf

                          Analytics-Backed App Widget Development - Served with Jetpack Glance

                            伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.pdf

                          • 設計書などドキュメント類は一切作りません！でもその代わりシステムの出来上がりは超速で価格も激安です。っていうベンダーの存在を知った

                            てとらα SI @TETRA_IT 設計書などドキュメント類は一切作りません！テスト結果もありません！でもその代わりシステムの出来上がりは超速で価格も激安です。っていう恐ろしい地方ベンダーの存在を知った。とにかく安く早くを求める地方企業や支社などの要望とマッチして管理不能なシステムが量産されてる

                              設計書などドキュメント類は一切作りません！でもその代わりシステムの出来上がりは超速で価格も激安です。っていうベンダーの存在を知った

                            • 【徹底解説】アジャイル開発に設計書は不要か？｜開発管理者が語る設計書の役割と運用・管理方法

                              はじめまして。 株式会社Enlytのベトナム側開発拠点、SupremeTech Co.,Ltdの上木です。 SupremeTechの副社長として、Project Management Office（PMO）やResource Management Office（RMO）など、管理面から開発プロジェクトを支援しています。 このEnlytブログでは名無しのインタビュアーとしてこれまでに２件の記事を書きましたが、ご覧いただけましたでしょうか。 【社長インタビュー】スタートアップとポストコロナ〜VUCA時代における不安との付き合い方〜【社長インタビュー】スタートアップがAIのR&Dにかける思い 先日「Why programmers don’t write documentation」という興味深い記事を読みまして、思うところがあり筆を執りました。以前、ディレクターの竹内がEnlytブログでドキュメ

                                【徹底解説】アジャイル開発に設計書は不要か？｜開発管理者が語る設計書の役割と運用・管理方法

                              • 基本設計書は納品前ですが、システム作っちゃいました

                                連載目次 基本契約と個別契約 今回は「契約論」に関わる紛争の例を紹介したい。 ある程度の規模のシステム開発、特にウオーターフォール型の開発では、その全体を1つの契約で行わない場合が多い。まず、プロジェクトの全体を通して大きな1つの契約を結ぶ。そこには実現すべき機能や費用などの詳細は記述されず、ただ全体としてのシステム開発を行うこと、そして機能や費用、具体的なスケジュールなどは別途契約して決めていくという程度のことが書かれている。これはよく「基本契約」と呼ばれる。 この基本契約の約束に従って作業工程を分割し、その小さな単位ごとに結ばれる契約を「個別契約」という。設計、製造、テスト――といった具合に小さな単位で契約し、検収もその単位で行うというわけだ。 大きなシステム開発の場合は、契約時点では先のことが分からず、作るべきものも費用も曖昧なことが多いので、工程ごとにそれらを決めて検収する方法はあ

                                  基本設計書は納品前ですが、システム作っちゃいました

                                • テスト設計書ひな型の著作物性・営業秘密該当性等　東京地判令4.5.31（令元ワ12715） - IT・システム判例メモ

                                  テスト業務の専門事業者から退職した従業員が、テスト設計書のひな型を持ち出して転職先で使用したという件について、誓約書違反、不法行為、著作権侵害、不正競争（営業秘密）など、さまざまな根拠を挙げて損害賠償請求を行ったという事案。 事案の概要 Ｙ１は、2017年5月にソフトウェアテスト専門業者のＸ社に入社し、ソフトウェアテスト事業に従事し、グループ長を務めた後に2018年7月に退職した。その後、ＡＩの研究開発、テスト業務を行うＹ２社に転職した。 Ｙ１は、入社時に守秘義務を負う旨の誓約書をＸ社に提出しており、退職時にも守秘義務と競業避止義務を負う旨の誓約書をＸ社に提出していた。 Ｘ社では、テスト業務に用いるテスト設計書のひな型として、本件ファイル１，本件ファイル２を作成していた。 Ｙ１は、Ｘ社を退職する直前に本件ファイル１をチャットツールの自身のアカウントにアップロードし、Ｙ２社に転職した後にダウ

                                    テスト設計書ひな型の著作物性・営業秘密該当性等　東京地判令4.5.31（令元ワ12715） - IT・システム判例メモ

                                  • システム設計書やソースコードを自動生成し、リファクタリングなどを支援するAIプラットフォーム「Jitera」が提供開始

                                    「Jitera」の利用イメージ 「Jitera」は、AIを活用してシステム開発のプロセス全体を効率化するプラットフォームで、システム設計書の生成からソースコードの生成まで、開発の全工程をAIがサポートする。ベンダーロックインの要素がなく、フルスクラッチと同様に高速な開発が可能となっている。 一般的な開発AIツールは、Webの情報とソースコードを参照するが、「Jitera」ではWebの情報およびソースコードに加えて、GitHub上にある既存プロジェクトのデータを読み込んだ上で設計書を自動生成する。自動生成した設計書や参照情報に基づいて、機能の追加・修正のサポートを行い高精度なコードを生成するため、開発現場で使われるAIアシスタントツールとして優れているという。 「Jitera」のおもなユースケースとしては、「既存のプロジェクトを理解し改善する能力」という強みを活かした、大規模なリファクタリン

                                      システム設計書やソースコードを自動生成し、リファクタリングなどを支援するAIプラットフォーム「Jitera」が提供開始

                                    • 設計工程に生成AI適用を目指す富士通、ツールが設計書の抜け漏れと改善案を提示

                                      生成AI（人工知能）を開発プロセスに適用する動きが活発になっている。先行するのはコーディング支援。それに続いてプロジェクト管理やコミュニケーションに利用するツールも生成AIを取り入れて進化している。大手ベンダーは詳細設計や品質管理に活用する社内ツールを開発し始めた。本特集では生成AIで進化するツール群の最新動向に迫る。 第1回から第3回までは国内大手ベンダーが社内で試験的に始めている取り組みを紹介する。まずは富士通が開発した「設計書レビュー支援」ツールを見ていこう。 設計書レビューを生成AIで支援 富士通が開発した設計書レビュー支援ツールは、生成AIが設計書の曖昧なポイントを抽出し、その判定の根拠や訂正案を表示できる。これまでシステムエンジニアが目検で確認していた、基本設計書と詳細設計書など設計書間の整合性も確かめられるという。 ツールを開発した主な狙いは、設計書レビューにかかる作業負荷軽

                                        設計工程に生成AI適用を目指す富士通、ツールが設計書の抜け漏れと改善案を提示

                                      • サイカの即戦力を生む2つの設計書 - XEP と Architecture Guide - XICA Tech blog

                                        はじめに 皆さんこんにちは。株式会社サイカでソフトウェアエンジニアをやっている鹿島(kashitaka)です。 皆さんの開発組織では設計書（Design Doc）をどのように運用していますか？ Design Docをめぐる運用は開発組織全体の広い取り組みとしてプロセスに落とすことが難しく、チームごとに独自で運用しているなど取り組みが限定的だったりします。（社内の別チームは開発ドキュメントなどないチームもあったり） サイカでは Design Doc を開発組織全体として設計し運用しています。このDesign Docの運用体系は2021年ごろに定義し、 約2年運用して組織的に定着しています。 今回の記事ではサイカがどのように Design Doc を管理・運用しているのかをご紹介します。 この記事がチームや組織のDesign Docの運用に悩んでいる方、これから Design Doc の運用を

                                          サイカの即戦力を生む2つの設計書 - XEP と Architecture Guide - XICA Tech blog

                                        • 設計書には何が書かれてるべきか - Magnolia Tech

                                          Noteからの転載 —- 設計書は、現在、または過去、未来をつなぐコミュニケーションツールなので、そのコミュニケーション設計をどうするか？って話を抜きに、どう書くべきか？そもそも書くべきか？みたいな議論を始めてしまうと、会話が成立しないことが多いですよね 必要な抽象度だって全然違ってくるし— magnoliak🍧 (@magnolia_k_) 2021年2月6日 これが設計書です！と言われて見せられたものが、あからさまに個人的なメモを超えるものでない場合、「この文書は誰とのコミュニケーションを目的としましたか？」と聞くと良いのではないかっていう みんなオレオレ正しい設計書理論があるので— magnoliak🍧 (@magnolia_k_) 2021年2月6日 設計書になにが書かれているべきか、コードの世界と違ってあまりコンセンサスが得られた回答を見たことが無い気がする。 かなり大きめの

                                            設計書には何が書かれてるべきか - Magnolia Tech

                                          • 基本設計書のテンプレート｜Shinji Yamaguchi

                                            ※ 設計書に関する本文およびテンプレートは制限無く公開しておりますので、当該記事をご購入頂かなくても設計書テンプレートの利用は可能です。応援いただける方のみご購入頂けますと幸甚です。こんにちは。 フリーランスエンジニアの山口です。 私は元々SIer企業の会社員エンジニアでしたが、2019年3月よりフリーランスエンジニアとして活動を始めました。 フリーになってから参画先のプロジェクトで経験したのは、意外と設計書のテンプレートは整備されていないということです。 そもそも設計書が存在していないとか、メンテ不能なPDF版で存在するとか、設計書のフォーマットがばらばらでメモ書きのような雑なものだったりなど。 そのような現場に入った際に利用可能なテンプレートがあると便利だと思いませんか？ 書籍でも設計書の書き方や設計書として揃えるべきドキュメントの種類を学ぶことは可能です。むしろ、書籍のほうがまとまっ

                                              基本設計書のテンプレート｜Shinji Yamaguchi

                                            • Excel で設計書作るのそんなに悪いことか？ - Neo's World

                                              Excel で設計書作るのそんなに悪いことか？ 僕は長らく Excel で仕様書や設計書、テストケースなどを作ってきた。現在も、何か情報を整理しようと思うと、とりあえず Excel に書き始めている。とある現場では「Excel マスター」なる称号をもらったりしたし、Excel の細かな仕様は技術ブログ Corredor でも度々紹介してきたとおり、そこら辺のニホンノエスイーよりは熟知した上で使っていると自負している。 しかし、ネットの界隈では「まだ Excel で仕様書書いてんの？」という風潮が強く、「Excel で仕様書のフォーマット作ってみました！」みたいな記事にネガティブコメントがわんさか付き、「Docker を使って PlantUML 環境を構築！」みたいな記事が高評価を得ていたりする。自分も技術オタクなので、イマドキのツールが簡単便利に色んなことができるのを見ると、いいね！と思う

                                              • 令和時代の設計書の基本方針

                                                はじめに さて、今回から機能設計書の標準化について取り上げていきます。今回は、平成時代の基本設計書を押えたうえで、令和時代の機能設計書の書き方や標準化に向けた基本的なドキュメント方針を解説します。 機能設計書とは 第4回の図3「システム開発のドキュメントフロー」で、システム開発に必要な主なドキュメントを紹介しました。ここで画面遷移図や業務フローなどはシステム全体に対して作成しますが、機能設計書は機能ごとに作成します。例えば基幹業務システムなら「受注入力画面」「受注伝票検索画面」「受注伝票(帳票)」などが”機能”で、全部で200機能あるとすれば200冊の設計書が作成されます(図1)。 Excelベースの機能設計書(基本設計書サンプル) 2005年の連載「即活用! 業務システムの開発ドキュメント標準化」では、図2のような機能設計書(基本設計書)のひな型をダウンロードできるようにしていました。こ

                                                  令和時代の設計書の基本方針

                                                • 令和時代のシステム開発では、どのような設計書を書くべきか

                                                  Copyright © 2004-2024 Impress Corporation. An Impress Group Company. All rights reserved.

                                                  • 「詳細設計書」を作ってみる - Qiita

                                                    一般的にはどうなのか？が気になる人は後半にある「一般的には（参考）」に先に目を通してもらったほうがいいかもしれません。 サンプルダウンロード サンプルのダウンロードはこちらから。 作成してみる では作成していきましょう。 作成方針・ポイント 概要でも書きましたが、詳細設計書までの書類で開発に必要となる情報の全てを記述しておく必要があるので、要件定義書、基本設計書の記述として足りない内容を記述していきます。 構成（目次）を考える 今回は下記のような項目を記述してみました。 一般的には基本設計で行う外部設計、内部設計といった内容に加え、実装に必要な情報を記述します。 サーバ/アカウント情報 外部設計 PC用画面 スマホ用画面 画面のマークアップ バリデーションルール（フロント）と表示項目 送信ボタン押下時の処理 スプレッドシートのデータ構造とレイアウト 内部設計 APIの処理フロー APIの仕

                                                      「詳細設計書」を作ってみる - Qiita

                                                    • 詳細設計書って何をどう書くの？ - Qiita

                                                      WEBアプリ開発のプロジェクトで詳細設計書を一から作成することになったので、 これを機に「詳細設計書に必要な最低限の記載内容」の再確認とメモ書きφ(..) また別プロジェクトで一から書くことになった時の判断基準にするためにも。 本題に入る前に、前提知識をザックリと。 詳細設計書は、上流工程の 「要件定義」 クライアントの要望とその要望をどのように叶えるのかを明確にする。 ↓ 「外部設計」 要件定義で決まった内容をもとに、画面や帳票、操作性などのユーザーインターフェースを設計する。 外部システムと連携する部分の仕様を設計し、内部設計の土台を作る。 ↓ 「内部設計」 外部設計で決まった内容をもとに、システムとして何を使ってどう実現していくかを具体的に定めていく。←★ここの工程で必要になる設計書 一先ず、 ・外部設計で作成する「基本設計書」はどちらかというとクライアント向けの設計書。 ・内部設計

                                                        詳細設計書って何をどう書くの？ - Qiita

                                                      • 「詳細設計書という名のゴミ」が問題になっている : 社畜バンドマンの備忘録

                                                        社畜バンドマンの備忘録 大手メーカー勤務のエンジニアの備忘録。 サラリーマンをやりながらロックバンドもゆるーく活動しており、社会人として、バンドマンとしての成長をここに刻む。 ビジネス関連、音楽関連はもちろん、テクノロジー、VR、ペット（鳥）など幅広く手を出しすぎて収集がつかなくなっている。 が頑張る。 今日は仕事の話。 弊チームはソフトウエアの開発も仕事の一部なのだが、開発の中で「詳細設計書」が問題に上がっている。 そこで世の中の「詳細設計書」について調べるため、ちょっとググってみたら気になるワードがヒットした。 「詳細設計書という名のゴミ」 元ネタのページは消えてしまっていたが、それを参考にしたページはいくつもあり、まさに今我々が直面している内容について書かれていた。 今回はそんな「詳細設計書」について書こうと思う。 私の所属している会社は製造業だ。 しかし、モノだけ作っているかという

                                                          「詳細設計書という名のゴミ」が問題になっている : 社畜バンドマンの備忘録

                                                        • iselegant | Masaya ARAI on Twitter: "よくジュニア層から「監査証跡のログってなんで3å¹´é–“ã‚„5年間保存するんですか？」と聞かれることがある。 設計書には背景が記載されていないこともままあるけど、IPAの資料にいい感じにまとまっているので、気になる方は一度目を通しておく… https://t.co/kfCPAgjhfA"

                                                          よくジュニア層から「監査証跡のログってなんで3年間や5年間保存するんですか？」と聞かれることがある。 設計書には背景が記載されていないこともままあるけど、IPAの資料にいい感じにまとまっているので、気になる方は一度目を通しておく… https://t.co/kfCPAgjhfA

                                                            iselegant | Masaya ARAI on Twitter: "よくジュニア層から「監査証跡のログってなんで3年間や5年間保存するんですか？」と聞かれることがある。 設計書には背景が記載されていないこともままあるけど、IPAの資料にいい感じにまとまっているので、気になる方は一度目を通しておく… https://t.co/kfCPAgjhfA"

                                                          • 無料ダウンロード！基本設計書・詳細設計書のテンプレート（サンプル付き）

                                                            システム開発において、会社指定のドキュメントフォーマットがない場合、エンジニアは独自にレイアウトや構成を作成する必要があります。これには仕様書や設計書の作成に多くの時間と労力がかかってしまいます。 システムエンジニアを目指す方々も、求めるシステム開発用のテンプレートを簡単には見つけられないことが多いでしょう。 この記事では、エクセル形式の仕様書や設計書のテンプレートやサンプルを無料でダウンロードできます。これらのテンプレートは、システム開発の効率を向上させるための参考資料としてご利用いただけます。実際のプロジェクトに役立つだけでなく、学習の一環としてもご活用ください。 仕様書・設計書のテンプレート システム開発のドキュメントのうち、要件定義書、基本設計書、詳細設計書、テスト仕様書・報告書のテンプレートがダウンロード可能です。 それぞれのテンプレートは、すべて日本語ファイル名のエクセルファイ

                                                              無料ダウンロード！基本設計書・詳細設計書のテンプレート（サンプル付き）

                                                            • システム開発の生産性30％向上を目指す日立、詳細設計書を基に開発工程自動化へ

                                                              生成AI（人工知能）を開発プロセスに適用する動きが活発になっている。先行するのはコーディング支援。それに続いてプロジェクト管理やコミュニケーションに利用するツールも生成AIを取り入れて進化している。大手ベンダーは詳細設計や品質管理に活用する社内ツールを開発し始めた。第3回は日立製作所の取り組みを見ていこう。 詳細設計書を基に自動化を目指す 「開発工程に含まれるすべてのタスクに生成AIをフル活用していく」――。このように説明するのは、日立製作所の立川茂デジタルエンジニアリングビジネスユニットアプリケーションサービス事業部Lumada共通技術開発本部担当本部長だ。一般にシステム開発には、要件定義や設計、開発（コーディング）、テストなどの工程があり、それぞれの工程には様々な作業が含まれる。例えば要件定義の工程には、システム概要や機能要求の作成、要件間の整合性確認などの作業が必要だ。 日立はシステ

                                                                システム開発の生産性30％向上を目指す日立、詳細設計書を基に開発工程自動化へ

                                                              • 【Notion】システム開発における設計書の管理方法 | ELW株式会社

                                                                弊社では最近、新たなドキュメント管理ツールとしてNotionを導入しました。Notionは非常に使いやすく、システムの仕様書管理とも相性が良かったので、今回はその魅力をご紹介したいと思います。 Notionに移行した経緯以前は、Confluenceを使ってドキュメントの管理を行い、Jiraでタスク管理を行っていました。しかしNotionを試してみると、これらの機能を兼ね備えているだけでなく、カスタマイズ性が高く、操作性も良いのでドキュメント作成に適していると感じました。ツールを一元管理することで総合的なコストも下がるので、Notionへの移行に踏み切りました。 それでは、各仕様書の具体的な記載内容についてご紹介します。 今回は下記仕様書に絞って記載しています（他にも業務フロー図や状態遷移図、エラーメッセージ一覧などシステム仕様で必要なドキュメントは全てNotionで作成しています） 画面仕

                                                                  【Notion】システム開発における設計書の管理方法 | ELW株式会社

                                                                • IaCジェネレーターとBedrockで詳細設計書を生成してみた

                                                                  論文紹介：Direct Preference Optimization: Your Language Model is Secretly a Reward Model

                                                                    IaCジェネレーターとBedrockで詳細設計書を生成してみた

                                                                  • 我々は、なぜ設計書を作成するのか

                                                                    はじめに 先日、「設計書の書き方」セミナーで、設計の効率化＆品質向上のために下記3つのうちどれが一番大切だと思うかを聞いてみました。みなさんなら、どれを選びますか。 (A)設計スキルを教育する(B)設計の標準化を進める(C)設計ツールを導入する システム設計ツール(CAD)を自らの効率化のために作った身からすると、今こそ(C)は重要だと思っています。しかし、そんな私でもこの3つはどれも大切で、どれが一番とは甲乙つけがたいものと感じています。 内心、票が割れるかなと思っていたのですが、結果は(B)の標準化に手を上げる人が圧倒的に多くいました。 それほど多くの人々が重要視している設計書の標準化ですが、その割にはチームごと、部署ごとにフォーマットがバラバラで、「組織単位で設計書を標準化できている」と胸を張れる会社は多くありません。そこで、令和時代の設計書の標準とはどうあるべきかをテーマにしている

                                                                      我々は、なぜ設計書を作成するのか

                                                                    • 日立が生成AIを用いた開発フレームワーク、設計書に基づきコーディング速度5割増

                                                                      日立製作所は2024年5月21日、生成AI（人工知能）を活用した開発フレームワーク「Hitachi Generative AI System Development Framework」の一般提供を開始した。基幹系システム開発に欠かせない保守性の高いコードを生成し、開発効率を向上させるという。システム開発に生成AIを用いる取り組みは今後加速していきそうだ。 詳細設計書に沿って質の高いコードを生成 Hitachi Generative AI System Development FrameworkはWebブラウザーやVisual Studio Code（VS Code）で利用できるフレームワークで、システム開発に有用な様々な機能を提供する。例えば「システム開発アシスト」の項目には、開発者のコーディング作業を補助する「コードアシスト」などの機能が含まれる。 コーディングアシストの特徴の1つが、

                                                                        日立が生成AIを用いた開発フレームワーク、設計書に基づきコーディング速度5割増

                                                                      • 幸福度が自然と上がる「人生設計書」の書き方 | ライフハッカー・ジャパン

                                                                        あなたは何を望んでいますか？ 「本当に」それを望んでいますか？ 今の質問に、「人生で」という言葉が加わると、これは答えるのが最も難しいタイプの問いかけになります。 「答えはわかっている」と思える人もいるでしょうが、「今ひとつ確信が持てない」とか「もっといろいろな可能性がある気がする」という人は、この問いかけにはっきりと答えられないのではないでしょうか。 人生の設計書を作る方法Bonnie Wan氏も2010年に、この難問に答えが見出せず、行き詰まりを感じていました。のちに『The Life Brief: A Playbook for No-Regrets Living（人生の設計書：後悔のない生き方のために）』という本を著したWan氏は、はた目には非の打ち所がない人生を送っているように見えました。 素晴らしい夫に、3人の子ども、素敵な家を持ち、夢のようなキャリアを築いていたからです。 しか

                                                                          幸福度が自然と上がる「人生設計書」の書き方 | ライフハッカー・ジャパン

                                                                        • 技術レポート「内部設計書に書くべきこと～組込みソフト開発の場合～」｜ソフテックだより｜株式会社ソフテック

                                                                          私はソフテックに入社して15年超の社員で、主に組込みソフトの開発に携わっています。最近、関わった仕事で、内部設計フェーズにおいてどういった資料を作成すべきかを見直す機会がありました。 今回のソフテックだよりでは、組込みソフト開発において内部設計書に書くべき内容について、まとめてみたいと思います。ソフテックで実際に作成している資料など、できるだけ具体的な例をあげて、ご説明していきます。 内部設計書とは、一般的に、ユーザーの目に見えないシステム内部の設計を記述したドキュメントを指します。詳細設計書と呼ばれる場合もあり、ソフトウェアのプログラミングを行うために必要な資料になります。 ソフトウェアの開発プロセスは一般的に下図のようなV字モデルで示されますが、その中で、内部設計書を作成する段階は、要件定義と基本設計（外部設計）が完了した後、プログラミング（コーディング）を行う前の作業になります。 図

                                                                          • プレインテキスト形式の設計書で、生産性を向上 | NTTデータ

                                                                            キーワードで探す カテゴリで探す 業界トレンド／展望 技術トレンド／展望 事例 サービスで探す コンサルティング CRM（Salesforce） ERP（SAP/Biz∫） 顧客接点・決済 カーボンニュートラル SCM・ロジスティクス 電子申請 データ＆インテリジェンス 生成AI アプリケーション開発・管理 データスペース ブロックチェーン 量子コンピュータ・イジングマシン デジタルツイン IoT ロボティクス・RPA クラウド ネットワーク データセンター サイバーセキュリティ アウトソーシング 業種で探す 金融 官公庁・自治体 医療・ヘルスケア 防災・レジリエンス 食品 流通・小売 モビリティ 製薬・ライフサイエンス 食農・農業 製造 通信・放送 電力・ガス・水道 建設・不動産 個人のお客様向け 教育 トピックで探す Foresight Day サステナビリティ キーワードで探す カテ

                                                                              プレインテキスト形式の設計書で、生産性を向上 | NTTデータ

                                                                            • 設計書をマークダウンに変更したら生成AIと連携できるようになった件｜kazami

                                                                              この記事はリクルート ICT統括室 Advent Calendar 2023 2日目の記事です。 はじめにこんにちは。ICT統括室 インフラソリューションユニットの内海です。社内向けWebシステムの開発・運用を担当しています。私が所属しているチームでは設計書をマークダウンに変更しました。これにより、生成AI（Graffer AI Studio）と連携できるようになり、開発業務の効率化が行えるようになったので、その内容を紹介させていただきます。（※） ※業務においては「リクルートAI活用指針」に基づいて生成AIを利用しています なぜ設計書をマークダウンに変更したのか？マークダウンに変更する前の設計書はWordやExcelで作成していました。WordやExcelを利用すると誰でも扱えるメリットがある一方、GitHub等で差分比較が行えないことや書式設定などが面倒というデメリットがありました。こ

                                                                                設計書をマークダウンに変更したら生成AIと連携できるようになった件｜kazami

                                                                              • GPT4-Vで画面設計書から画面を生成させる - Qiita

                                                                                はじめに これまで設計書からプログラム、構成図からIaCなど、GPT4-Vで画像を使ったケースを取り扱ってきました。今回は画面設計書みたいなものから画面のコードを生成させてみたいと思います。 なお、生成するコードはSvelteコンポーネントです。 画面設計書 本当は日本語が良かったのですが、日本語OCRの精度に不安があったので英語で記載しました。なお、英語もChatGPTで日本語をもとに翻訳したものをそのままいれています。 DallePanel.svleteというSvelteコンポーネントについて、画面の構成と、動作に関する説明などを右側にいれています。右側の説明は画像にいれなくてもプロンプトに入れてもいいかなと思いましたが、とりあえず画像です。 ともすればfigmaとかでもいいじゃないかっていう話もありますが、動作含めて画像にすることを今回試します。 説明の内容は日本語（翻訳前）だと以下

                                                                                  GPT4-Vで画面設計書から画面を生成させる - Qiita

                                                                                • システム開発・設計企業必見！実際の設計書を公開！

                                                                                  div.hs-menu-wrapper > ul > li" data-pacnav-mobile-width="820"> OB Designer とは 機能 動作環境 導入事例 価格 FAQ 保守サポート バージョンアップ履歴 ブログ 昨今、基幹システムの入れ替え（マイグレーション案件）や債券法の改正など、IT業界に影響が多いことばかりです。請負契約に関しては「長年にわたって無償改修のリスク」を伴うことが予想される為、ますます納品物・成果物に対しての品質が問われてくるのではないでしょうか。 以前まではシステムを引き渡してから1年間だけでしたが、改正後は10年後に変更されることが予定されております。つまり、契約不適合が認められた場合は10年前のシステムであろうとも改修を行う必要がでてきます。当然、改修費用や保守費用も上乗せが必要と言えるでしょう。 しかしながら、債券法の改正が無かったとし

                                                                                    システム開発・設計企業必見！実際の設計書を公開！
                                                                                  1 2 次のページ

                                                                                  新着記事

                                                                                  はてなブックマーク

                                                                                  公式Twitter

                                                                                  はてなのサービス

                                                                                  • App Storeからダウンロード
                                                                                  • Google Playで手に入れよう
                                                                                  Copyright © 2005-2024 Hatena. All Rights Reserved.