いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
新機能をつくる前に整理しておきたい10のこと - Qiita
この記事は CrowdWorks Advent Calendar 2017 13日目の記事です。 はじめに クラウドワークスにて、プロダクトオーナーとエンジニア組織のマネージャーをやっている @teriyakisan です。 （最近は開発業務の比率がだいぶ下がってしまっているのですが）Webエンジニアの経験をベースに、クラウドワークス上の仕事発注者に向けた機能開発のプロジェクトを進行中です。 今回はプロダクトオーナーをやる中で考えることが増えている新機能などの中規模施策を企画するときに、どんなことを整理しておくとスムーズにプロジェクトを始められるかの話をしたいと思います。 クラウドワークスで馴染みのmini spec クラウドーワークスでの小規模な機能追加や機能改修、キャンペーン企画の要件整理を進めるときにはmini specというフォーマットがよく使われています。 これは、2016年に「
押下(おうか)にまつわる話 - Qiita
はじめに 私が仕様書を書くようになったのは30歳を過ぎてからと遅く、仕様書の書き方が分からなくて悩んだことがありました。通常は先輩たちが作成した仕様書等を見て書き方を覚えていくのでしょうが、仕様書も無く直接プログラムを組むような体制の仕事をしていたため、SI系に転職してから苦労したのであった。 仕様書を書く際に、ボタンを「Enterキーを押す」か「クリックする」かで考えて「押下」にすれば両方満たすだろうと、それ以来ずっと使用しています。 押下については、コンピューター雑誌やマニュアル等を読んで憶えていた用語で特に気にも止めていなかったのですが、別ブログの仲間が過去に「ボタン押下？」について書いていたことを思い出し、調べてみることにしました。 調べていくと自分は誤用して使っている気がしますw 押下について 読み方 押下は「おうか」と読みます。ちなみに苗字の押下さん(読方：おしした)は全国でお
非機能要件 - Wikipedia
非機能要件(Non-functional requirement)とは、システム設計や情報システム開発上の要求分析において、要件、システム要件といった機能面以外の全般を指す。 機能要件を実装するための設計がシステム設計であり、非機能要件を実装するための設計がシステムアーキテクチャとなる。 広義には、機能要件とはシステムが動作する内容について定義し、非機能要件とはシステムが動作する方法を定義すると言える。 機能要件は「要件に対するシステムのふるまい」の形で記述され、通常はシステム一部の個々の動作が明示されたり、数学関数として表されたり、あるいはブラックボックスとしての説明だったり、機能モデルとして説明される。 一方、非機能要件は、特定の状態のシステムとしてではなく、機能の全体的な特性を「システムが要件を満たさなければならない」の形で記述される。非機能要件は、システムの全体的な特性として、開発
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック (1/3)：プロジェクト成功確率向上の近道とは？（2） - ＠IT
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック：プロジェクト成功確率向上の近道とは？（2）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、Joelの機能仕様書を日本人向けにカスタマイズされたものを例に、機能仕様書の基本的な書き方、読みやすくする7つのテクニック、仕様書作成ツールは何を使うべきか、誰が書くべきかなども解説します。 連載目次 連載の第1回の前回「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」では、ITシステム開発がビジネスに貢献していくためには、まずは開発の成功が出発点になること、そしてITシステム開発におけるコミュニケーションの重要性、そしてコミュニケーションにおけるドキュメントの重要性について説
システム開発の王道を極める
| トップ扉 | 思考支援 . ネット革 . ＵＩ考房 . 設計技術 . シス開発 . 道具活用 | 自己紹介 | | 最近更新 | 思考方法 . 議論手法 . 説明技術 . 知能教育 . □□□□ . □□□□ | 著作更新 | | 総合目次 | 社会進歩 . 市民運動 . ジャナ革 . 未来社会 . 一流仕事 . 組織構築 | 独り言？ | | 補助索引 | 心の階段 . □□□□ . 芸術奥覗 . 残り物達 . リンク集 . 脳ぐちゃ | 推奨用語 | ソフトウェアを中心としたシステム開発では、規模が大きくて複雑なほど、いろいろな技術が必要となる。高度な設計技術はもちろん、分析技術や管理技術などもだ。これらの技術を活用できれば、難易度の高い開発でも成功の可能性が高まる。本格的なシステム開発に役立つ技術を、活用ノウハウも含めて紹介する。 ・システム開発には様々な技術が必要 ・力ずくから
Latex + GitLab + Jenkinsで全自動仕様書作成システムを作った. - 「不自由な自由」を持て余して
経緯 私の務めている会社ではMicrosoftさんの製品が主に使われています. 私はMicrosoft Wordを使うとあまりの使いづらさに集中力が切れて仕事の能率が著しく低下するのですが,そんな私に上司はある日「要件定義書書いて.」という言葉を投げかけてきました.要件定義書？また作業が滞る日々が続くと思ったので先手を打って起きました. 曰く,「PDF形式でも宜しいですか？」と. 上司は怪訝な顔をしながらも承諾してくださいました.これで,私の無駄なことに全力になってしまう本能が遺憾なく発揮されるのでした. 成果物 Latexで仕様書を書いた.GitLabで成果物管理をした. GitLabとJenkinsを連動させて,Push後に自動的にBuildするシステムを作り上げた. 無駄にLatexのMakefileに詳しくなった. 手順 Ubuntu 12.04でLaTeX環境を構築する GitL
綺麗なだけじゃ意味がない！ディレクターが見落としがちな仕様書作成の４ポイント : LINE Corporation ディレクターブログ
こんにちは。ウェブサービス本部の河野です。 ディレクターの業務の重要なものの一つに、仕様をまとめたりドキュメントを作る業務があります。限られた時間の中でシステムを開発しなければならない際に、どのようなドキュメントをどこまで作成するか悩むことも多いかと思います。 そこで今回はディレクターがドキュメントを作成する際の心がけやポイントについて考えてみたいと思います。 １．ドキュメントを作ることが目的とならないようにする 当たり前のことですが、一番重要なのは進めているシステム開発が納期通りに不具合なくリリースできることです。仕様をメンバーに理解してもらうことが第一で、その手段としてドキュメントがあるという優先度を間違えないようにしましょう。 きちんとしたドキュメントの作成には時間が掛かり、変更時の更新にも同じく時間がかかります。また、更新をせず情報が古いままの場合、開発メンバーがそれを最新バージョ
設計書仕様書テンプレート PocketDOC | 株式会社イーイノベーション
弊社サービスをご利用頂き、誠に有り難うございます。 ドキュメントのダウンロード件数が2007年5月の開設以来300000件を突破しました！ 今度ともご愛顧の程よろしくお願いいたします。 PocketDOC(ポケットドック)とはシステム開発に必要な設計書や仕様書などのドキュメントやテンプレートはもちろんのこと、 議事録、納品・検収書、近年話題になっている個人情報に関しての取扱管理表などの ドキュメントやテンプレートも提供しています。 実際に弊社のプロジェクトで使用されているため精度も高く、カスタマイズなしでも利用可能なほどです。 上流工程から下流工程まで広い範囲をサポートしているので、 必要なテンプレートだけをダウンロードして利用することも可能です。 ドキュメントやテンプレートのファイル形式はWord(doc形式)やExcel(xls形式)です。 ダウンロード後、すぐにお使いいただけるように
最低限知っておきたい仕様書を書くときの３つのポイント 【ボクバイＺ the blog】
こんにちは。ライブドアでブログを更新しているキツネハンターです。 今回はソフトウェア開発に必要となる「仕様書」を書く際のポイントについて紹介したいと思います。あと、このテイストはlivedoor ディレクター Blogのパクリです。 さて、仕様書と言っても、大別して２種類あることをご存知でしょうか？１つはユーザー側から見た外部仕様（機能仕様）、もう１つは開発者側から見た内部仕様（技術仕様）です。 例えば、「0〜100までの素数を全て求めたい、素数を数えて落ち着くんだ」というのが外部仕様。これに対して、「ある数Ｘ（Ｘは0以上、100以下）を２からＸまで順に割ってアレする」というのが内部仕様。 外部仕様を書くのはカンタンです。たぶん、誰でも書けます。でも、内部仕様を書くのはプログラミングのスキルがないと書けません。内部仕様を書けるのは、プログラマーかスーパープランナーだけです。 ボク
プログラマに負担をかけない仕様書の書き方や対応についての質問です。…
プログラマに負担をかけない仕様書の書き方や対応についての質問です。 今後、プログラマに事細かに指示を出す必要がある仕事に自分がつきそうです。いろいろなサイトを見ましたが、意思の疎通がうまくいかず、プログラマに負担がいってしまう事例が多くあり、気を引き締めて取りかかりたいと思います。 自分も若干の言語ならばわかりますが、ほとんど無知の状態に近いです。 自信の勉強ももちろんのこと、ミーティングなども綿密に行う事が必要ですが、その他に気をつけなければならない事や注意点、プログラマから見たやりやすさなどがありましたら教えて下さい。 また、どういう状況での作業がやりやすか、などの環境についてもよければご意見を聞きたいと思います。
職業PGにわかるFizzBuzz - 日々常々
なんかFizzBuzzが書けないPGがどーとか定期的に話題になってるけど、私に言わせれば説明の仕方が悪い。 こうすれば誰でも書ける。 これだから最近の若いもんは……。 GoogleDocsのスプレッドシート、方眼紙作るのに向いてませんね……。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A guide to writing specs toward engineers(Japanese)
コミっくむｰび-
Joel on Software - やさしい機能仕様
プログラマが欲しい仕様書とは