高度な検索
検索結果
540件見つかりました
BookStack 骨格(章・WIPページ)自動生成ツール 要件定義書
1. 目的 BookStack において、本・章・ページの骨格(章および WIP ページ)を 手作業を排除して一括生成するための Python ツールを作成する。 本ツールは、一度きり使う YAML 定義を入力として、 既存構造を壊さず、安全側(新規作成のみ・既存はスキップ)で動作することを目的とする。 2. 対象スコープ 2.1 対象とする操作 ページの 新規作成 章の 新規作成(存在しない場合のみ) 2.2 対象外とする操作 既存ページ・章の更新 既存ページ・章の削除 YAML と BookStack ...
YAML 定義書(BookStack 骨格生成:Book直下ページ → 章 → 章配下ページ)
1. 目的 この YAML は、指定した Book(book_id) に対して以下を上から順に生成するための入力定義である。 Book 直下ページ(pages) 章(chapters)(存在しなければ作成) 章配下ページ(chapters[].pages) 既存の同名ページは SKIP(作らない)。既存の同名章は再利用する。 2. スキーマ(仕様) 2.1 トップレベル キー 型 必須 説明 book_id int 必須 BookStack の book id(名前ではなく ID) wip_...
0. 仕様設計手順
1. 入力仕様の確定(YAML → ドメイン) YAML スキーマの確定(キー、型、必須/任意) 処理順が意味を持つことの明文化 不正入力の扱い(エラーにする条件)の洗い出し ドメインデータクラス定義 Book 単位 Chapter 単位 ドメインレベルでのバリデーション仕様決定 必須チェック 重複チェック 型チェック 2. 同一性判定ルールの具体化 Book 直下ページの同一性判定方法 Chapter の同一性判定方法 Chapter 配下ページの同一性判定方法 SKIP 条件...
1. 入力仕様定義(YAML → ドメイン)
1. 入力全体の位置づけ 入力は 一度きり使う YAML 定義 YAML に書かれた 記載順=処理順 既存構造は破壊せず、新規作成のみ 既存要素が存在する場合は SKIP YAML は BookStack の状態と同期しない(使い捨て) 2. トップレベルスキーマ book_id: int wip_markdown: string pages: list[string] # optional chapters: list[chapter] # optional 2.1 トップレベル項目定...
2. ドメインデータクラス設計(YAML → ドメイン)
1. 設計方針 入力1ファイル=1 Book(book_id を必須) 記載順は意味を持つため、list の順序は保持する 既存更新・削除はしない(SKIP 判定は後段のユースケースで行う) データクラスは YAML スキーマの写像に徹し、BookStack API 概念(id 等)は持たない None を持ち込まず、後段ロジックの分岐を減らすため 空リストに正規化する 文字列は前後 trim(strip)してから保持する(本仕様で固定) 2. データクラス一覧 2.1 BookInput(入力全体) ...
ISO 21434(自動車サイバーセキュリティ)とは何か
🧭 はじめに ISO 21434 は、自動車(車載ECU・車載ネットワーク・ソフトウェア・クラウド連携など)を対象にした サイバーセキュリティの国際規格です。 一言でいうと、「車がネットワークにつながることによって発生する脅威(攻撃)に対して、開発から運用まで一貫して安全性を確保するための“やり方(プロセス)”」を定めます。 ISO 26262(機能安全)が「故障による危険」を扱うのに対し、ISO 21434 は「攻撃による危険」を扱うのが中心です。 ISO 21434 は「セキュリティ機能の実装カタログ」ではなく...
SOTIF(ISO 21448)とは何か:安全なのに危険になる問題を扱う規格
🧭 はじめに SOTIF(Safety Of The Intended Functionality)は、自動車の先進運転支援(ADAS)や自動運転(AD) のようなシステムにおいて、 「故障していないのに」 「設計通りに動いているのに」 「それでも危険になる」 というタイプの安全課題を扱う考え方・規格です。 規格としては ISO 21448 が SOTIF に対応します。 SOTIF は ISO 26262(機能安全)と対立するものではなく、26262ではカバーしづらい危険領域を補う位置づけです。 🧩 まず結...
ADAS(先進運転支援システム)とは何か
🧭 はじめに ADAS(Advanced Driver Assistance Systems)は、日本語では一般に 先進運転支援システムと呼ばれます。 一言でいうと、ADASは「運転という人間のタスクのうち、一部をクルマ側が支援する機能群」です。 重要なのは、ADASは自動運転(Autonomous / Automated Driving)そのものではなく、基本的に “運転者が主体である”ことを前提にした支援だという点です。 ADAS は「運転を代わりにやる」ではなく、運転の失敗を減らす/負担を減らす方向の技術とし...
3. 全体処理フロー(ユースケース手順)
0) 起動〜前処理 CLI 引数を解釈(-i <yaml> 必須) ロギング初期化(ログは stderr / stdout とは分離) 入力ファイル存在チェック(無ければ入力エラーで即時終了) 1) YAML 読み込み(入力→ドメイン) YAML を読み込み、ドメインモデル(Book/Chapter/Page)へ変換 ここでトリム等の正規化(前後 trim)は 変換時に実施(以後は正規化済みを前提にする) 2) ドメイン検証(API を叩く前に止める) 必須チェック・型チェック・重複チェックなど(要件にあ...
4. API 境界設計(インフラ層)
4.1 BookStack API の使用エンドポイント整理 本ツール(Book/Chapter/Page の骨格生成)で利用するエンドポイントは最小限に絞る。 一覧取得系(同一性判定・SKIP判定のための現状取得) GET /api/books/{book_id} Book直下の Page と Chapter の“並び”を content から取得する前提 原則これ1本で足りる設計とし、追加の list 取得は増やさない 作成系(骨格生成の本体) POST /api/chapters(Chapter...
5. エラーモデル設計
5. エラーモデル設計 本章では、本ツールにおけるエラーの分類、扱い方、および どこで捕捉し、どこで処理を終了するかの境界を定義する。 本ツールは「安全側・再実行可能」を最優先とし、 エラー発生時は即時終了する fail-fast 方針を採用する。 5.1 エラー種別の分類 5.1.1 入力エラー(YAML / バリデーション) YAML の内容に問題があり、再実行しても成功しないエラーを入力エラーとする。 対象 YAML ファイルが読めない YAML 構文エラー YAML定義書.md に定義された以...
6. CLI設計
6.1 実行ファイル名と基本形式 6.1.1 実行ファイル名 実行ファイル名は create_skeleton.py とする。 6.1.2 基本コマンド形式 python create_skeleton.py -i path/to/input.yaml 6.2 引数仕様 6.2.1 オプション一覧 オプション 必須 値 説明 -i / --input 必須 ファイルパス 入力 YAML ファイルパス 6.2.2 入力ファイルパスの取り扱い -i/--input は 必須。 相対パス/絶...
7. ロギング設計
ロギング設計 本章では、本ツールにおけるログの目的、出力先、ログレベル、および 標準出力との役割分担を定義する。 本ツールは CLI ツールであり、 人間が標準出力を見て結果を確認し、ログは問題発生時の調査に使う という役割分離を前提とする。 ロギングの基本方針 ログは デバッグ・原因追跡用途に限定する 標準出力は 処理結果(OK / SKIP / ERROR)のみを出す ログと標準出力は 混在させない ログと標準出力の責務を分離することで、 実行結果の可読性と障害調査のしやすさを両立できる。 ログ...
BookStackページ自動生成スクリプト 実装計画(WBS)
はじめに 本ページでは、添付された 要件定義書・YAML定義書・ソフトウェア仕様 を前提として、 BookStack の本・章・ページ骨格を自動生成する Python スクリプトを実装するための 作業分解構造(WBS) を示す。 ここでの WBS は、 実装順がそのまま理解できること 設計済み仕様(責務分割・fail-fast・安全側)と整合していること BookStack 上の記事として「後から見返しても実装の全体像が即座に把握できる」こと を目的としている。 全体フェーズ構成 フェーズ0:事前整理・方針...
プロジェクトマネジメント関係リンク集
要件定義 超上流から始めるIT化の原理原則 17か条:https://www.ipa.go.jp/archive/publish/qv6pgp0000000xa0-att/000005109.pdf ユーザーのための要件定義ガイド:https://www.ipa.go.jp/archive/publish/qv6pgp0000000wrt-att/000079352.pdf セキュリティ 安全なWebサイトの作り方:https://www.ipa.go.jp/security/vuln/websecurity...
新規ページ
要件定義書(テンプレート:小規模Excelツール) 1. 概要 1.1 背景・目的 背景: 目的(何を解決するか): ゴール(成功条件): 1.2 スコープ 対象業務: 対象外(やらないこと): 1.3 用語定義 用語 意味 2. 利用者・利用シーン 2.1 想定ユーザー 利用者(例:経理担当、営業事務など): PCスキル前提(例:Excel基本操作は可能、マクロは不可など): 2.2 利用シーン いつ使うか(頻度): どんな入力を受けて、何を出すか: 1回の作業時間目安: ...
派閥政治とは何だったのか
🧭 はじめに 本章では、自民党における「派閥政治」とは何であったのかを整理する。 派閥は単なる仲良しグループでも、単純な権力争いの装置でもない。それは日本型政党システムの内部に組み込まれた制度的な権力配分メカニズムであり、長期政権を支えた統治装置でもあった。 本章では、 派閥の定義と日本型政党の構造的特徴 派閥が担った具体的機能 派閥をどう評価すべきか 本書の分析視角 を明確にする。 📚 派閥の定義と日本型政党の特徴 🏛 派閥とは何か 自民党の派閥とは、党内の議員グループであり、以下の特徴を持つ。 領袖(派...
制度が生んだ派閥(中選挙区制〜小選挙区制の制度分析)
🧭 はじめに 本章では、派閥政治を「文化」ではなく制度の帰結として捉える。 なぜ自民党では派閥がこれほど強固に形成されたのか。それは政治家の性格や日本人の気質ではなく、選挙制度が作り出した合理的行動の結果である。 本章では、 中選挙区制が生んだ党内競争 「数は力」という派閥拡大の合理性 1994年政治改革の狙い 小選挙区制でも派閥が残った理由 比例復活制度と派閥インセンティブ を制度分析の視点から整理する。 🏛 中選挙区制と党内競争 📊 中選挙区制とは何だったか 1994年の政治改革以前、衆議院選挙は中選挙区...