サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック (1/3)：プロジェクト成功確率向上の近道とは？（2） - ＠IT
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック：プロジェクト成功確率向上の近道とは？（2）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、Joelの機能仕様書を日本人向けにカスタマイズされたものを例に、機能仕様書の基本的な書き方、読みやすくする7つのテクニック、仕様書作成ツールは何を使うべきか、誰が書くべきかなども解説します。 連載目次 連載の第1回の前回「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」では、ITシステム開発がビジネスに貢献していくためには、まずは開発の成功が出発点になること、そしてITシステム開発におけるコミュニケーションの重要性、そしてコミュニケーションにおけるドキュメントの重要性について説
綺麗なだけじゃ意味がない！ディレクターが見落としがちな仕様書作成の４ポイント : LINE Corporation ディレクターブログ
こんにちは。ウェブサービス本部の河野です。 ディレクターの業務の重要なものの一つに、仕様をまとめたりドキュメントを作る業務があります。限られた時間の中でシステムを開発しなければならない際に、どのようなドキュメントをどこまで作成するか悩むことも多いかと思います。 そこで今回はディレクターがドキュメントを作成する際の心がけやポイントについて考えてみたいと思います。 １．ドキュメントを作ることが目的とならないようにする 当たり前のことですが、一番重要なのは進めているシステム開発が納期通りに不具合なくリリースできることです。仕様をメンバーに理解してもらうことが第一で、その手段としてドキュメントがあるという優先度を間違えないようにしましょう。 きちんとしたドキュメントの作成には時間が掛かり、変更時の更新にも同じく時間がかかります。また、更新をせず情報が古いままの場合、開発メンバーがそれを最新バージョ
OPS 2.0 v1.0 日本語訳 [Open Publication Structure (OPS) 2.0 v1.0]
See related links to what you are looking for.
The ultimate website launch checklist | Insight | Box UK
We launched the original website launch checklist back in 2009 and, as is rapidly becoming tradition, have revisited it to check it’s still relevant, valuable and useful. So, take a look and make sure you’re ready to launch in style. 1. Be clear about the purpose of your new website Let’s start by asking the most important question of all – why are you about to launch something new? It’s only poss
要求仕様書の標準化プロセス
「DUNGEON」はソフトウェア開発の各工程において必要とするドキュメント標準を決めて、その具体的なテンプレートを用意したものです。概念的なアプローチとはまったく逆に、アウトプット側から開発プロセスを標準化するという実践的な考え方を重視しています。 これまで7回にわたって、基本設計から詳細設計、プログラミング、単体テスト、結合テスト、総合テストという流れに沿って、各プロセスで必要とするドキュメントの標準化を説明してきました。最終回の今回は、その前段のプロセスである要求分析フェーズのアウトプットについて説明します。 みなさんはSLCPという言葉を知っていますか。SLCPとはSoftware Life Cycle Processの略で、ソフトウェアの開発ライフサイクル、つまりこれまで解説してきた基本設計から総合テストまでの開発工程を指す言葉です。SLCPの代表的なものは30年前に提唱されたウォ
[設計編]ユースケースに詳細を書いてはいけない
機能要求を「ユースケース」（利用者＝アクターから見たシステムの利用場面）としてまとめ，それを基に分析設計することが一般化してきた。ところが「ビジネス・ルールを入れ込んだり，if～thenレベルのロジックまで書き込んだりと，誤った書き方をしている人が結構多い」と，日本を代表するITアーキテクトの1人，榊原彰氏（日本IBM 東京基礎研究所 IBMディスティングイッシュト・エンジニア）は指摘する。どんどん詳細化し，必要ない情報まで盛り込んでしまうのだ。 「詳細化しないと気が済まないのだろう。『分析麻痺（Analysis Paralysis）』と言える」と同氏。オブジェクト指向分析設計とプロジェクトの「見える化」を実践・推進するチェンジビジョンの平鍋健児氏（代表取締役）も同意見。「画面レイアウトなど情報量が多過ぎることが結構ある。ユースケースはシステムの目的なのに，ユースケース＝機能と考えるからそ
![[設計編]ユースケースに詳細を書いてはいけない](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
「良いダメ出し」で部下は10倍知恵を絞る
必要な条件を網羅したチェックポイント 部下に企画を出すよう命じるときには、「何を求められているか」という企画の方向性を明示しないと、後の企画会議が空中分解するようになってしまい、部下たちの間で、「どうせ企画を出せといってもハズレなんでしょ」という空気がまん延してしまう。これを避けるために企画マネジメントが必要で、具体的には（1）背景・経緯、（2）現状の課題、（3）課題改善の可能性、（4）目標、（5）目標達成のためのアクションプラン、（6）経済性、（7）他に与える影響という7つの項目を順番にチェックしていくことが大切だ。参照記事 こうした7つのチェックポイントを提案する、眼鏡レンズメーカーのニコン・エシロールの元CEOの長谷川和廣氏は、現在経営コンサルタントとして活動している。 「どうしてボツなのか」を説明できかどうか 長谷川氏によれば、人材が豊富な大企業でもこのようなチェックポイントで精査
第20回 画面遷移図作成の実践：ITpro
前回は画面遷移図の作成方法やと構成といった基本について説明した。今回は，実際に画面遷移図を作成するうえでのポイントと注意点を解説する。 ハイレベル・サイトマップとフローチャートをミックスする 今回説明する画面遷移図とは，リンク関係図のことではない。Excelを使って，1機能を1ワークシートに描く，リンク関係と画面設計とデータベース設計が混然一体となった図のことだ。Webデザイナー出身のプランナーには，ハイレベル・サイトマップ（双方向の詳細なリンク関係図）とフローチャートのごった煮のように見えるかもしれない。 前回述べたように，リンク関係図では「1個の箱」問題が生じる。さらに詳しいハイレベル・サイトマップでも，イベントと処理の関係を示すことは難しい。一方，フローチャートでは画面レイアウトを表現できない。また，技術者の間でのみ通用する表現手法では，顧客側との意思疎通をはかるには不都合だ。顧客と
第19回 画面遷移図作成の基本
企画書と同時に提出する画面遷移図は，Webの骨格だ。この図一つで，制作・開発効率や工期が決まるといっても過言ではない。今回と次回で，画面遷移図作成の基本と実践について見ていこう。 開発の効率化と長期運用のために 画面遷移図の果たす役割は大きい。顧客に完成予想図をイメージしてもらい，受注を獲得するための一助になる。概算見積書を作成するための資料にもなる。そして，実装機能やデータベース設計を固めるためのタタキ台にもなる。企画書と共に提出すれば終わりというわけではなく，モックアップやプロトタイプ開発にも利用できる。顧客との間で意識や記憶にズレが生じた場合の確認資料としても重宝する。 受注が確定的になると，顧客の要求を入れながら，何度も修正を重ねていく。画面遷移図の段階で調整に時間をかけて完全な合意を得ておけば，開発はスムーズに進む。段取り八分が何より肝心だ。データベース設計のような根幹の部分に変
第39回 Web開発者との付き合い方 〜Web屋の一分（いちぶん）：ITpro
前回は，コミュニケーション・コストについて触れましたが，今回はもう少しWebサイト・デザインに絞って話をしてみたいと思います。 意見集約という「小リーダー」の役目 前回の復習になりますが，何か大きな事柄を決めようようとするとき，あまりに民主的に行うと，意見を集約するのに膨大な時間がかかります。私は，Web開発にとって「時間」が一番大切だと思っているので，結論を出すまでのプロセスを効率化することは至上命令です。 様々な方法があるかもしれませんが，基本的には，機動性の良いグループ単位で意見を集約し，代表者会議の場で即決できることが鍵になるように思えます。小グループの小リーダーたちの機動力と，権限を持っているという体制，これに勝るものはないでしょう。 そして，意見集約の効率化という側面だけでなく，クライアントの担当者が時間までに難しい結論を決めてきてくれたり，決をとる場で「責任は俺が取るから」と
第36回 画面設計書を書くための手法とツール：ITpro
画面設計書について，前回に引き続き，それを書くツールや手法について考えてみましょう。 画面設計書の基本 まずは，画面設計書の中にあるべき情報から見てみましょう。これらすべてがそろっていなければならない，というわけではありませんが，望ましいのではないかと私自身は考えています。 header ページIDやタイトルなど，一目でそのページがどの画面仕様を記述しているかがわかるような「ヘッダー」部分。細かく書くならば，文字コードや対象ブラウザまで記述する場合もある。また，プロジェクトの名前（プロジェクト・コード）や版番号なども記し，似たようなドキュメントの中からも引き出せるようにしておく。 footer 制作サイドのコピーライトやページ番号などを記す。最終的には，クライアントのコピーライトに置き直して，最終納品とする場合もある。 Page Layout 画面内に配置する「ユーザー・インタフェース（U
意図が伝わる設計書作成の心得【第6回】
仕様書は，複数のメンバーが共同で作成することが多い。したがって,コミュニケーションを怠れば,「仕様書間の不整合」や「保留事項の連絡不徹底による手戻り」などの問題を起こしやすい。こうしたリスクを避け, 効率的に仕様書を作成するには,どうすればよいだろうか。頻繁に起こる2タイプの実例を通して,その原因と対応策を考えていこう。 実質的な作業メンバーが1人というプロジェクトもあるだろうが，大半は複数のメンバーによる共同作業になるだろう。こうした現場では，仕様書の作成を複数人で分担して行う必要が生じ，プログラム間の仕様の調整に手間がかかる。 これは設計工程全般に言えることではあるが，特に仕様書の作成フェーズでは，基本設計とは異なるレベルでユーザーと仕様の調整を行う。このため，より一層，コミュニケーションに注意を払う必要が生じる。 それを怠ると，誰も気づかないうちに仕様書間の不整合が起きてしまい，後に
意図が伝わる設計書作成の心得【第5回】
仕様書の品質を均一化するためにテンプレートを利用する現場は多いと思うが，正しく運用できているだろうか。ちょっとした心がけの違いで，過剰品質の原因となったり，型にはまりすぎた平板な仕様書を生みだしたりする。「テンプレートの利用に伴う弊害」をテーマに取り上げ，よく起こる2タイプの事例を通して，予防するための心得とは何かを考えてみたい。 仕様書を作成する際，記述する情報の質と量が重要であることは言うまでもないが，その記述レベルは人によってばらつきやすい。特にシステムの規模が大きければ，仕様書の作成にかかわる人の数が増え，生み出される仕様書の質と量のばらつきも大きくなってくる。 このような問題を避けるため，書式や記述レベルを均一化する目的で仕様書の「テンプレート（ひな型）集」や「ガイドライン」を用意したり，プロジェクトの実情に合わせた「記述サンプル」を作って配布したりする開発現場は多いだろう。仕様
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
