【データ基盤チーム ブログリレー 3日目】 こんにちは、エンジニアリンググループの石塚です。 趣味は筋トレです。好きなトレーニングはレッグカールです。今年2023年の1月に第一子が爆誕し、毎日子供の笑顔に癒されております。一方であまり言い訳にはしたくはないですが、事実自分自身の自由に使える時間は少なくなったなと感じております。そんな中でもトレーニングの時間は作りたいので、24時間ジムに契約して妻と娘が寝ている早朝の時間にウホウホトレーニングをしている今日この頃であります。時間のありがたみをとても感じるようになりました。 これは仕事でも同様かと思います。有限な時間の中でタスクを取捨選択して価値ある成果を上げていく事が仕事では求められます。ドキュメンテーションはその価値ある成果につながる時間を増やす一助になるかもしれません。 この記事では、ドキュメンテーションの必要性について言語化します。改め

仕様書？PRD？要件定義書？Design Doc？ プロダクト開発のドキュメントを作る前に、みんなで揃えたい考え方 💡このnoteはなに？ プロダクトに関するドキュメントの種類呼称別の整理と、どうしたら現在のチームにドキュメントに関する目線合わせのアイデアを書いたものです 💡誰のためのnote？ プロダクト開発に必要なドキュメントについて日々心を悩ませている人 ドキュメントの話に着地をつけたい 誰かが言い出すアレ今までの経験上、どこに配属されても、プロダクトに関するドキュメントとして誰が何を書き、そして運用するのか、という議論が起きないことは1度もない。 プロダクトに関するドキュメントは、PRD・要件定義書・仕様書・Design Docなど、さまざまな呼称があり、会社や部門によってさまざまな使われ方をしている。 そしてそれぞれの言葉には単一の定義があるわけではない。 そもそもドキュメン

最近ずっと仕様書を書いているのだが、なかなかうまく書けない。できるだけ次はうまく書けるようにメモをしておこう。 設計書の種類と目的 開発工程の共通知識 各設計書の説明に移る前に、ここではウォーターフォール型の開発における開発工程についての概要を記載する。 ウォーターフォール型開発の概要 開発工程についての基本的な説明はwikipediaを参照 ソフトウェア開発工程 - Wikipedia 最もよく知られた従来型の開発工程モデルはウォーターフォール・モデルである。このモデルでは、開発者は上述の工程（局面、フェーズ）を順番に行う。要求仕様を作成し、それを分析し、解決法を設計し、そのためのソフトウェアフレームワークのアーキテクチャを作り、コードを書き、評価し（単体テスト→システムテストの順）、配備し、保守する。各工程が完了すると、次の工程に進むことができる。ちょうど、家の骨組みを組み上げてから土

基本設計を終えて、次は詳細設計。 だけど詳細設計書ってうまく書けないんだよな。。 プログラムもあまり経験してこなかったし。 いったい何を書けばいいのか。。

背景 今まで携わったプロジェクト、人によって、「仕様書」、「設計書」と意味合いが違った呼び方されている。自分の見解を示す 辞書（weblio）を引いて比べてみましょう 仕様書とは ① やり方や、その順序を記した文書。 「作業の－」 ② 建築・機械などで、注文品の内容や図などを書いた書類。 設計書とは 建築物やシステムに関する構造、形、機能などを定義したもの。図面で表したものを設計図という。 自分の見解 辞書を引いて読むと違いは明確になりますね 仕様書は、こう有るべきという仕様（決め事）を記載する書類です。 設計書は、その仕様を実現する為に、「どのようなシステム構成にするか？」、「どうやって作るか？」という実現方法を記載した書類です。 例（ユーザーがWEB掲示板の製造をシステム開発会社に発注した場合） 以下の様な決め事を記載した書類が仕様書です。 WEB掲示板にアクセスするときには、ログイン

今回は機能仕様書について述べていこうと思う。 テンプレート 会社の機能仕様書は見せられないが、機能仕様書のテンプレートはネット上に沢山あるのでそちらを参照していただきたい。例えば以下のリンクが参考になりそうだ。 https://biz.trans-suite.jp/9158 ポイント 機能仕様書は「ユーザから見た仕様」について書く。プログラムなど詳細については次工程「詳細設計書」で書く。 記入事項 大きく分けて以下の8つの項目がある。 1. 表紙 2. 改訂履歴 3. 目次 4. 用語説明 5. システム 6. 機能策定方針 7. 機能概要 8. 機能仕様 9. 非機能仕様 10.データ仕様 それぞれの項目ごとに説明していく。 表紙 表紙には「○○システム機能仕様書 ver1.0」と「所属部署や名前等の出どころ」を書く。 改訂履歴 改訂履歴には「日付」「版（ver）」「改訂者の名前」「内容

いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・　良い仕様書がもたらす 5 つの効果 ・　仕様書の重要性が増していく 2 つの理由 ・　仕様書に含めたい 14 の項目・実戦編 ・　仕様書作成時に心に留めたい 3 つのこと ・　具体的な仕様書サンプル（

プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する（なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい）。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物（ドキュメント）を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 （1）題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”