タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている
「設計書」というのは、作るものの構造を抽象的に表現したものと言うことができます。 ただ、ソフトウェアの抽象化の仕組みはプログラミングコード自体に備わっているので、ソフトウェア生成可能な抽象的表現というのはコード表現ができるはずですね。コードで表現しておくと、整合性のチェックとかも行いやすいです。 でも、コードではない「詳細設計書」というものが一部業界には必要とされているので、その「詳細設計書」というのは実際はなんなのか考えてみます。 ※ 最初はタイトルは「設計書」としてましたが、話を限定するため「詳細設計書」に変更しました。 追記：納品物に関する記述を追加しました。 追記(2024/11/27)：「概略図」「物理設備の設計」を追記 表現を変えたコーディング ソフトウェア生成可能な抽象的表現というのはコード表現ができるわけですが、文字で表記する必要もなく、ダイアグラムで表現することもできます
「ソフトウェアの「詳細設計書」とはなんなのか」というブログ記事を読んで考えたこと。設計に関するプロセスとドキュメンテーションの関係性についての考えの整理。SI屋的な視点で。 2024/8/18追記：文中にあった雑な文系disが不愉快というご指摘を受けました。ご指摘の通りだと思いましたので訂正しています。大変失礼しました。 「詳細設計書」とはなんなのか nowokay.hatenablog.com こちらの記事では詳細設計書とは以下のようなものであると整理されている。 表現を変えたコーディング（の一種） 机上プロトタイプ（の一種） 分析資料 保守（のための）資料 （水平作業の場合の）作業指示書 （委託している場合の）契約資料 上記以外で考えられるのは次のようなものがあるだろう 利害関係者が要求している たとえば受託開発において発注者が要求している場合 ほかには連携している相手先システム側から
ウォーターフォールモデルに則った大規模開発で設計書があるなら、全部Copilotに実装させよう！をコンセプトに、どうすれば設計書をインプットに、Github Copilotが大規模開発の品質に沿ったコードを生成してくれるか、を日々模索しています。 まだまだ課題はあるものの、少しでも開発の役に立てばと思い途中経過を公開します。 このドキュメントでは、現時点での設計書からCopilotを用いて実装を生成する手順の紹介、使用するツールの紹介、工夫したポイント、現時点での課題について記載します。 こんな人に読んでほしい Github Copilotしか使えない環境にある方 Github Copilotをコードの説明や、単純なメソッド生成をさせる程度にしか使用していない方 期待したコードが生成されず、使わなくなってしまった方 前提 今回生成対象とするのは業務レイヤの実装です。Webアプリケーションで
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
しのゆー𝕏今や酒ザコエンジニア @shinoyu 法人やってるソフトウェアエンジニア20年生+見習いバーテンダー 兼蒲田のガルバのオネェさん/ IT、V系 、ロリィタの人 / 鍵アカからのフォローは教義によりブロック mixi.social/invitations/@s… しのゆー𝕏酒クズエンジニア @shinoyu わし詳細設計書書くのやだよ(￣･ω･￣) 細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ 改修コストを下げるための設計になってることは前提だけどね。 だけど、詳細設計書が必要となる現場はこの設計することはできない。だってそれできてたら詳細設計書いらないわけで… 2024-05-31 0
今年４月からソフトウェアエンジニアとして働き始めたものです。 くまぎさんの会社ではソフトウェア開発でコード以外にはどういったものをアウトプットしていますか？ 配属された部署では設計/テスト関連では基本設計書、詳細設計書、単体試験項目書、結合試験項目書などなどをエクセル等でガチガチに作成しており非常に驚きました。 学生時代はそこまでしっかりとしたドキュメントを作成して開発したことはなく、どういったものが普通なのか、効率的なのか気になった次第です。 就職おめでとうございます。共に業界を盛り上げていきましょう。 コード以外で書くものと言ったらDD（デザインドキュメント）がもっぱら多いです。要するに基本設計書です。しかし、重要なのは業界に渡って「設計書」の指す内容には明確な合意や基準がないという事です。つまり僕のいう基本設計書があなたの会社での標準的な基本設計書ではないでしょうし、どちらが優れてい
はじめにフューチャー技術ブログのリレー形式の連載である、春の入門祭り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
はじめに お客様に提案をしているときの会話です。 お客様：「詳細設計書は作りますか」 私：「昔ながらの詳細設計（ロジックを日本語で書くもの）は作りません。クラス図とか、シーケンス図は複雑であれば作りますが、今回のシステムはそこまで必要なものはないものなので、割愛しようと思っています。」 お客様：「保守をお願いするかどうか未定なので、場合によっては引継ぎのために作ってもらうかもしれません」 私：「・・・・」 といった感じで、私がこの業界に入った30年前は、確かにプログラムを作る前に、詳細設計書と呼ばれるプログラムを日本語で書いていました。 最近、詳細設計と呼ばれるものを作った記憶がなく、無駄なものは作りたくないなぁという思いから、コードから自動生成できないかなと思って、いろいろ試してみました。 Doxygenって いろいろ調べてみると、Doxygen にたどり着きました。 色々な言語に対応し
ウォーターフォールモデルに則った大規模開発で設計書があるなら、全部Copilotに実装させよう！をコンセプトに、どうすれば設計書をインプットに、Github Copilotが大規模開発の品質に沿ったコードを生成してくれるか、の完成版です。前回の記事では途中経過でしたが、自分なりに方法が確立したので結果を共有します。 このドキュメントでは、現時点での設計書からCopilotを用いて実装を生成する手順の紹介、使用するツールの紹介、工夫したポイントについて記載します。 結論 で、本当に全部Copilotに実装させられるの？実装スピードはあがるの？と気になる方もいると思うので結論を先に書きます。 Q:本当に全部Copilotに実装させられるの？ A:完璧なものは無理でした。Copilotに実装させて間違った部分を人間が直す必要があります。今回紹介する方法だと、体感で8割程の正解コードを生成してきま
この記事は 食べログアドベントカレンダー2023 の23日目の記事です🎅🎄 こんにちは。食べログシステム本部 技術部 仕入チームの@shohei-yです。 今回は、新規事業の「食べログ仕入」プロダクト開発において所謂「設計書」を書かない設計に挑戦して開発効率を向上させた話を書きます。 （結局「書くの？書かないの？どっちなんだい！」と感じた人は、ぜひ読み進めてください。） 所属している仕入チームについてはこちらの記事をご覧ください。 目次 なぜ設計書を書かない設計に挑戦したのか 設計書を書かないチーム 設計書を書かないことによる問題 1. チーム協力の課題 2. ソースコードの複雑化 3. チーム変動に関わる問題 設計工程導入のきっかけ 設計書を書かない挑戦の背景 設計書を書かない設計 フロントエンド・バックエンドのインターフェースの明確化 ソースコードのスリム化対策 設計のレビュー方法
てとらα SI @TETRA_IT 設計書などドキュメント類は一切作りません！テスト結果もありません！でもその代わりシステムの出来上がりは超速で価格も激安です。っていう恐ろしい地方ベンダーの存在を知った。とにかく安く早くを求める地方企業や支社などの要望とマッチして管理不能なシステムが量産されてる 2024-05-28 09:25:50
はじめまして。 株式会社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つの契約を結ぶ。そこには実現すべき機能や費用などの詳細は記述されず、ただ全体としてのシステム開発を行うこと、そして機能や費用、具体的なスケジュールなどは別途契約して決めていくという程度のことが書かれている。これはよく「基本契約」と呼ばれる。 この基本契約の約束に従って作業工程を分割し、その小さな単位ごとに結ばれる契約を「個別契約」という。設計、製造、テスト――といった具合に小さな単位で契約し、検収もその単位で行うというわけだ。 大きなシステム開発の場合は、契約時点では先のことが分からず、作るべきものも費用も曖昧なことが多いので、工程ごとにそれらを決めて検収する方法はあ
テスト業務の専門事業者から退職した従業員が、テスト設計書のひな型を持ち出して転職先で使用したという件について、誓約書違反、不法行為、著作権侵害、不正競争（営業秘密）など、さまざまな根拠を挙げて損害賠償請求を行ったという事案。 事案の概要 Ｙ１は、2017年5月にソフトウェアテスト専門業者のＸ社に入社し、ソフトウェアテスト事業に従事し、グループ長を務めた後に2018年7月に退職した。その後、ＡＩの研究開発、テスト業務を行うＹ２社に転職した。 Ｙ１は、入社時に守秘義務を負う旨の誓約書をＸ社に提出しており、退職時にも守秘義務と競業避止義務を負う旨の誓約書をＸ社に提出していた。 Ｘ社では、テスト業務に用いるテスト設計書のひな型として、本件ファイル１，本件ファイル２を作成していた。 Ｙ１は、Ｘ社を退職する直前に本件ファイル１をチャットツールの自身のアカウントにアップロードし、Ｙ２社に転職した後にダウ
「Jitera」の利用イメージ 「Jitera」は、AIを活用してシステム開発のプロセス全体を効率化するプラットフォームで、システム設計書の生成からソースコードの生成まで、開発の全工程をAIがサポートする。ベンダーロックインの要素がなく、フルスクラッチと同様に高速な開発が可能となっている。 一般的な開発AIツールは、Webの情報とソースコードを参照するが、「Jitera」ではWebの情報およびソースコードに加えて、GitHub上にある既存プロジェクトのデータを読み込んだ上で設計書を自動生成する。自動生成した設計書や参照情報に基づいて、機能の追加・修正のサポートを行い高精度なコードを生成するため、開発現場で使われるAIアシスタントツールとして優れているという。 「Jitera」のおもなユースケースとしては、「既存のプロジェクトを理解し改善する能力」という強みを活かした、大規模なリファクタリン
生成AI（人工知能）を開発プロセスに適用する動きが活発になっている。先行するのはコーディング支援。それに続いてプロジェクト管理やコミュニケーションに利用するツールも生成AIを取り入れて進化している。大手ベンダーは詳細設計や品質管理に活用する社内ツールを開発し始めた。本特集では生成AIで進化するツール群の最新動向に迫る。 第1回から第3回までは国内大手ベンダーが社内で試験的に始めている取り組みを紹介する。まずは富士通が開発した「設計書レビュー支援」ツールを見ていこう。 設計書レビューを生成AIで支援 富士通が開発した設計書レビュー支援ツールは、生成AIが設計書の曖昧なポイントを抽出し、その判定の根拠や訂正案を表示できる。これまでシステムエンジニアが目検で確認していた、基本設計書と詳細設計書など設計書間の整合性も確かめられるという。 ツールを開発した主な狙いは、設計書レビューにかかる作業負荷軽
はじめに 皆さんこんにちは。株式会社サイカでソフトウェアエンジニアをやっている鹿島(kashitaka)です。 皆さんの開発組織では設計書（Design Doc）をどのように運用していますか？ Design Docをめぐる運用は開発組織全体の広い取り組みとしてプロセスに落とすことが難しく、チームごとに独自で運用しているなど取り組みが限定的だったりします。（社内の別チームは開発ドキュメントなどないチームもあったり） サイカでは Design Doc を開発組織全体として設計し運用しています。このDesign Docの運用体系は2021年ごろに定義し、 約2年運用して組織的に定着しています。 今回の記事ではサイカがどのように Design Doc を管理・運用しているのかをご紹介します。 この記事がチームや組織のDesign Docの運用に悩んでいる方、これから Design Doc の運用を
生成AI（人工知能）を有効に活用する勘所の2つ目は「工夫次第で精度は向上できる、RAG（検索拡張生成）を攻略し自社データをフル活用せよ」だ。生成AIで自社のデータを参照する手段として一躍有名になったRAG。しかし、思い通りの回答精度を引き出せず四苦八苦する「RAGの沼」にはまってしまう企業が多い。三菱電機やポーラ・オルビスホールディングス（HD）、三井住友ファイナンス＆リース（FL）の取り組みから、RAGを使いこなすためのノウハウを見ていく。 三菱電機は、家電の制御ソフトの開発工程で生成AIを使う。ソフトの改修内容を入力すると、該当する設計書や改修の影響が及ぶ部分を生成AIで抽出するシステムを開発した。RAGを構築する上で鍵になったのが、図や表を多用した開発文書の取り扱いだ。 近年の家電はクラウドとの接続やIoT（インターネット・オブ・シングズ）化が進んでおり、ソフト開発規模が大きくなって
この記事は hacomono advent calendar 2024 の16日目の記事です こんにちは、hacomonoのプロダクト開発本部のたつ（X）です。僕からはhacomonoの「プロダクトエンジニア」について今回も書かせてもらいます。前回は「プロダクトエンジニア」という役割を定義しましたというお話」という記事の中で、hacomonoのプロダクトエンジニアの定義やそのスキル・マインドについて紹介させていただきました。 さて本日のお話は、そのプロダクトエンジニアの定義や考え方をどのように浸透させていくか、育成していくかという視点からhacomono社内での取り組みの一つである開発設計書のテンプレートを紹介させていただこうと思います。 hacomonoでは機能の開発のフロー中で、実装に入る前に「開発設計書の作成」と「設計レビュー」という段階を用意しています。設計レビューとは端的に言って
※ 設計書に関する本文およびテンプレートは制限無く公開しておりますので、当該記事をご購入頂かなくても設計書テンプレートの利用は可能です。応援いただける方のみご購入頂けますと幸甚です。こんにちは。 フリーランスエンジニアの山口です。 私は元々SIer企業の会社員エンジニアでしたが、2019年3月よりフリーランスエンジニアとして活動を始めました。 フリーになってから参画先のプロジェクトで経験したのは、意外と設計書のテンプレートは整備されていないということです。 そもそも設計書が存在していないとか、メンテ不能なPDF版で存在するとか、設計書のフォーマットがばらばらでメモ書きのような雑なものだったりなど。 そのような現場に入った際に利用可能なテンプレートがあると便利だと思いませんか？ 書籍でも設計書の書き方や設計書として揃えるべきドキュメントの種類を学ぶことは可能です。むしろ、書籍のほうがまとまっ
Noteからの転載 —- 設計書は、現在、または過去、未来をつなぐコミュニケーションツールなので、そのコミュニケーション設計をどうするか？って話を抜きに、どう書くべきか？そもそも書くべきか？みたいな議論を始めてしまうと、会話が成立しないことが多いですよね 必要な抽象度だって全然違ってくるし— magnoliak🍧 (@magnolia_k_) 2021年2月6日 これが設計書です！と言われて見せられたものが、あからさまに個人的なメモを超えるものでない場合、「この文書は誰とのコミュニケーションを目的としましたか？」と聞くと良いのではないかっていう みんなオレオレ正しい設計書理論があるので— magnoliak🍧 (@magnolia_k_) 2021年2月6日 設計書になにが書かれているべきか、コードの世界と違ってあまりコンセンサスが得られた回答を見たことが無い気がする。 かなり大きめの
Excel で設計書作るのそんなに悪いことか？ 僕は長らく Excel で仕様書や設計書、テストケースなどを作ってきた。現在も、何か情報を整理しようと思うと、とりあえず Excel に書き始めている。とある現場では「Excel マスター」なる称号をもらったりしたし、Excel の細かな仕様は技術ブログ Corredor でも度々紹介してきたとおり、そこら辺のニホンノエスイーよりは熟知した上で使っていると自負している。 しかし、ネットの界隈では「まだ Excel で仕様書書いてんの？」という風潮が強く、「Excel で仕様書のフォーマット作ってみました！」みたいな記事にネガティブコメントがわんさか付き、「Docker を使って PlantUML 環境を構築！」みたいな記事が高評価を得ていたりする。自分も技術オタクなので、イマドキのツールが簡単便利に色んなことができるのを見ると、いいね！と思う
一般的にはどうなのか？が気になる人は後半にある「一般的には（参考）」に先に目を通してもらったほうがいいかもしれません。 サンプルダウンロード サンプルのダウンロードはこちらから。 作成してみる では作成していきましょう。 作成方針・ポイント 概要でも書きましたが、詳細設計書までの書類で開発に必要となる情報の全てを記述しておく必要があるので、要件定義書、基本設計書の記述として足りない内容を記述していきます。 構成（目次）を考える 今回は下記のような項目を記述してみました。 一般的には基本設計で行う外部設計、内部設計といった内容に加え、実装に必要な情報を記述します。 サーバ/アカウント情報 外部設計 PC用画面 スマホ用画面 画面のマークアップ バリデーションルール（フロント）と表示項目 送信ボタン押下時の処理 スプレッドシートのデータ構造とレイアウト 内部設計 APIの処理フロー APIの仕
いぬきち @chuki_zaru RPAを社内で広めようとしてるのは良いんだけど、仕様書や設計書の類いを一切作らずに思いつきのまま作り続けてるの恐怖すぎる 動作アカウントも専用のものを設けず、一般のユーザーアカウントを流用 そして、社内共有フォルダを直接触る まともにエラートラップもしてないのに、よくやるよ、、 2025-06-11 07:01:24 いぬきち @chuki_zaru なお、これらに対して情シスの立場から注意喚起したところ、「情シスが邪魔をして社内導入が遅れている」とエライサン達に言われてる模様 知らんがなでんがな、誰がケツ拭くねん 2025-06-11 08:01:58 梟🦉 @JpOwl123 @chuki_zaru 情シス部門のお偉いさんがそういう思想の人だと後で大変な目に遭うでしょうね。ある年にセキュリティ確保状況の社内監査なんかで「コントロールの欠如が甚だしい」
社畜バンドマンの備忘録 大手メーカー勤務のエンジニアの備忘録。 サラリーマンをやりながらロックバンドもゆるーく活動しており、社会人として、バンドマンとしての成長をここに刻む。 ビジネス関連、音楽関連はもちろん、テクノロジー、VR、ペット（鳥）など幅広く手を出しすぎて収集がつかなくなっている。 が頑張る。 今日は仕事の話。 弊チームはソフトウエアの開発も仕事の一部なのだが、開発の中で「詳細設計書」が問題に上がっている。 そこで世の中の「詳細設計書」について調べるため、ちょっとググってみたら気になるワードがヒットした。 「詳細設計書という名のゴミ」 元ネタのページは消えてしまっていたが、それを参考にしたページはいくつもあり、まさに今我々が直面している内容について書かれていた。 今回はそんな「詳細設計書」について書こうと思う。 私の所属している会社は製造業だ。 しかし、モノだけ作っているかという
よくジュニア層から「監査証跡のログってなんで3年間や5年間保存するんですか？」と聞かれることがある。 設計書には背景が記載されていないこともままあるけど、IPAの資料にいい感じにまとまっているので、気になる方は一度目を通しておく… https://t.co/kfCPAgjhfA
生成AI（人工知能）を開発プロセスに適用する動きが活発になっている。先行するのはコーディング支援。それに続いてプロジェクト管理やコミュニケーションに利用するツールも生成AIを取り入れて進化している。大手ベンダーは詳細設計や品質管理に活用する社内ツールを開発し始めた。第3回は日立製作所の取り組みを見ていこう。 詳細設計書を基に自動化を目指す 「開発工程に含まれるすべてのタスクに生成AIをフル活用していく」――。このように説明するのは、日立製作所の立川茂デジタルエンジニアリングビジネスユニットアプリケーションサービス事業部Lumada共通技術開発本部担当本部長だ。一般にシステム開発には、要件定義や設計、開発（コーディング）、テストなどの工程があり、それぞれの工程には様々な作業が含まれる。例えば要件定義の工程には、システム概要や機能要求の作成、要件間の整合性確認などの作業が必要だ。 日立はシステ
日立製作所は2024年5月21日、生成AI（人工知能）を活用した開発フレームワーク「Hitachi Generative AI System Development Framework」の一般提供を開始した。基幹系システム開発に欠かせない保守性の高いコードを生成し、開発効率を向上させるという。システム開発に生成AIを用いる取り組みは今後加速していきそうだ。 詳細設計書に沿って質の高いコードを生成 Hitachi Generative AI System Development FrameworkはWebブラウザーやVisual Studio Code（VS Code）で利用できるフレームワークで、システム開発に有用な様々な機能を提供する。例えば「システム開発アシスト」の項目には、開発者のコーディング作業を補助する「コードアシスト」などの機能が含まれる。 コーディングアシストの特徴の1つが、
カテゴリで探す 業界トレンド／展望 技術トレンド／展望 事例 サービスで探す コンサルティング 戦略コンサルティング 社会課題コンサルティング 業務コンサルティング デザインコンサルティング 変革支援コンサルティング アプリケーション・サービス テクノロジーコンサルティング CRM（Salesforce） ERP（SAP/Biz∫） 顧客接点・決済 カーボンニュートラル SCM ロジスティクス 電子申請 データ＆インテリジェンス 生成AI アプリケーション開発・管理 データスペース ブロックチェーン 量子コンピュータ・イジングマシン デジタルツイン IoT ロボティクス・RPA クラウド ネットワーク データセンター サイバーセキュリティ ビジネスプロセスサービス 業種で探す 金融 官公庁・自治体 医療・ヘルスケア 防災・レジリエンス 食品 流通・小売 モビリティ 製薬・ライフサイエンス
弊社では最近、新たなドキュメント管理ツールとしてNotionを導入しました。Notionは非常に使いやすく、システムの仕様書管理とも相性が良かったので、今回はその魅力をご紹介したいと思います。 Notionに移行した経緯以前は、Confluenceを使ってドキュメントの管理を行い、Jiraでタスク管理を行っていました。しかしNotionを試してみると、これらの機能を兼ね備えているだけでなく、カスタマイズ性が高く、操作性も良いのでドキュメント作成に適していると感じました。ツールを一元管理することで総合的なコストも下がるので、Notionへの移行に踏み切りました。 それでは、各仕様書の具体的な記載内容についてご紹介します。 今回は下記仕様書に絞って記載しています（他にも業務フロー図や状態遷移図、エラーメッセージ一覧などシステム仕様で必要なドキュメントは全てNotionで作成しています） 画面仕
# AWS非機能要件定義書 ## 文書情報 | 項目 | 内容 | |------|------| | 文書名 | AWS非機能要件定義書 | | 作成日 | YYYY/MM/DD | | 最終更新日 | YYYY/MM/DD | | バージョン | 0.1 | | 作成者 | | | 承認者 | | ## 1. はじめに ### 1.1 目的 本書は、[システム名]の非機能要件を定義するものである。AWS Well-Architected FrameworkとIPAの非機能要求グレードを組み合わせた観点から、システムが満たすべき非機能要件を明確にする。 ### 1.2 対象範囲 本書が対象とするシステムの範囲は以下の通りである。 - [対象システム/サブシステムの記載] - [対象外となるシステム/サブシステムの記載] ### 1.3 前提条件 - [前提条件1] - [前提条件2] #
形式手法特論：位相空間としての並行プログラミング #kernelvm / Kernel VM Study Tokyo 18th
人生の設計書を作る方法Bonnie Wan氏も2010年に、この難問に答えが見出せず、行き詰まりを感じていました。のちに『The Life Brief: A Playbook for No-Regrets Living（人生の設計書：後悔のない生き方のために）』という本を著したWan氏は、はた目には非の打ち所がない人生を送っているように見えました。 素晴らしい夫に、3人の子ども、素敵な家を持ち、夢のようなキャリアを築いていたからです。 しかし心の内はというと、疲労感にさいなまれ、さまざまな疑問を抱えていました。 Wan氏は自分の仕事において、クライアントが自身の本音にたどり着く手助けをするために、質問を投げかけたり、「クリエイティブ・ブリーフ」と呼ばれる、広告戦略を簡潔にまとめた設計書を作成したりしています。 そこでWan氏はこの手法を自分自身にも適用して、「ライフ・ブリーフ（人生の設計書
ブログ記事を書くにあたり、道路・街路事業の情報をどうやって入手しているか、また、工事の情報をどうやって得ているかについて、少し書いてみようと思います。 ページ下部では情報公開請求の方法についても触れてみます。意外と紹介してるサイトがないので需要あるかなと思って。 ここで書くのは官公庁が行う事業や発注する工事であり、市街地再開発組合などの民間の事業は対象としません。 また、ここで書くのはいろいろな方法があるうちの一例です。手続きは変更されることがありますので、参考程度にしてください。2025年9月初旬時点です。 道路・街路事業の情報の入手方法 まずは、事業そのものの情報の入手方法について。 私が普段行う方法は以下の通りです。 ◎自治体等のウェブサイト ◎官報・公報など ◎議会録を検索する ○自治体等に問い合わせる ○説明会に参加する △情報公開請求 △情報サイトや議員のブログから得る （◎→
この記事はリクルート ICT統括室 Advent Calendar 2023 2日目の記事です。 はじめにこんにちは。ICT統括室 インフラソリューションユニットの内海です。社内向けWebシステムの開発・運用を担当しています。私が所属しているチームでは設計書をマークダウンに変更しました。これにより、生成AI（Graffer AI Studio）と連携できるようになり、開発業務の効率化が行えるようになったので、その内容を紹介させていただきます。（※） ※業務においては「リクルートAI活用指針」に基づいて生成AIを利用しています なぜ設計書をマークダウンに変更したのか？マークダウンに変更する前の設計書はWordやExcelで作成していました。WordやExcelを利用すると誰でも扱えるメリットがある一方、GitHub等で差分比較が行えないことや書式設定などが面倒というデメリットがありました。こ
こんにちは、田口佳央莉です。 Webマーケターとして日々感じるのが、SEOの難しさです。特に、その重要性を周囲に伝えるのは一苦労ですよね。 「丁寧に調査しても、結果の説明がうまく伝わらない」 「レポートを作るのが手間で後回しになってしまう」 「社内の誰かが書いた記事を見ても、そもそも何を意図して作られたのかわからない」。そんな経験、ありませんか？ 今回は、こうしたWebマーケターの皆さんの悩みにお応えするべく、メディア記事やコラムだけでなく、自社の製品ページ制作にも活用でき、多くの人に見てもらえるコンテンツをつくるための設計ツール――「コンテンツ設計書（前半）～SEO検討シート～」を公開します。 記事は「書く前の準備」が8割SEOで成果が出る記事は、実は書く前の準備段階でほぼ勝負が決まっています。 以前は「どんなキーワードを入れるか」が重視されていましたが、今はそれだけでは不十分です。 「
![SEOを踏まえたコンテンツ設計書テンプレ、大公開！社内教育にも使える！｜DNP 田口佳央莉 | [マーケターコラム] Half Empty? Half Full? | Web担当者Forum](https://cdn-ak-scissors.b.st-hatena.com/image/square/3ce8634723ff2c09de41d53d2ec569f8852696fd/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fwebtan.impress.co.jp%2Fsites%2Fdefault%2Ffiles%2Fstyles%2F1200x630%2Fpublic%2Fimages%2Farticle2017%2Fhehf%2F2025%2Fhehf147_taguchi_ogp.jpg%3Fitok%3DZEbiaTT5)
はじめに これまで設計書からプログラム、構成図からIaCなど、GPT4-Vで画像を使ったケースを取り扱ってきました。今回は画面設計書みたいなものから画面のコードを生成させてみたいと思います。 なお、生成するコードはSvelteコンポーネントです。 画面設計書 本当は日本語が良かったのですが、日本語OCRの精度に不安があったので英語で記載しました。なお、英語もChatGPTで日本語をもとに翻訳したものをそのままいれています。 DallePanel.svleteというSvelteコンポーネントについて、画面の構成と、動作に関する説明などを右側にいれています。右側の説明は画像にいれなくてもプロンプトに入れてもいいかなと思いましたが、とりあえず画像です。 ともすればfigmaとかでもいいじゃないかっていう話もありますが、動作含めて画像にすることを今回試します。 説明の内容は日本語（翻訳前）だと以下
はじめに みなさんは設計書を書く際に気を付けていることはありますか？ 今回は私が最近設計書レビューをしてて感じる事について記載していこうと思います。 その設計書ただのメモ書きになってませんか？ 何故この記事を書こうと思ったのかですが、 「その設計書はあなたがコーディングをするためだけのものじゃない」 ということをお伝えしたいためになります。 では、具体的に何を意識するのか。 コーダーが何をどのように実装したいのか理解しやすい内容とする。 設計を担当したものを自分が作るとは限りません。 保守・運用を行う際にどのような造りになっているのか分かりやすい内容とする。 開発を行ったシステムを同じ人がそのまま保守・運用を行っていくとは限りません。 要するに、他人が見るドキュメントだということを意識してほしいということになります。
Kiro って何 つい最近 Amazon が発表した Vibe/Agentic Coding 向け IDE。 プロンプトのベスプラが定まらない中、一つの解答を与えると期待されている。 Claude Code 用 slash command Kiro ではユーザがやりたいことを以下のファイルに落とし込む。 要件定義 requirements.md 設計書 design.md 実装手順 tasks.md 実際に作成されるプロンプトがいい感じに Claude Code で流用できそうだったので、slash command 化してみた。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
