Excel で設計書作るのそんなに悪いことか？ - Neo's World
Excel で設計書作るのそんなに悪いことか？ 僕は長らく Excel で仕様書や設計書、テストケースなどを作ってきた。現在も、何か情報を整理しようと思うと、とりあえず Excel に書き始めている。とある現場では「Excel マスター」なる称号をもらったりしたし、Excel の細かな仕様は技術ブログ Corredor でも度々紹介してきたとおり、そこら辺のニホンノエスイーよりは熟知した上で使っていると自負している。 しかし、ネットの界隈では「まだ Excel で仕様書書いてんの？」という風潮が強く、「Excel で仕様書のフォーマット作ってみました！」みたいな記事にネガティブコメントがわんさか付き、「Docker を使って PlantUML 環境を構築！」みたいな記事が高評価を得ていたりする。自分も技術オタクなので、イマドキのツールが簡単便利に色んなことができるのを見ると、いいね！と思う
blockdiag シリーズで色々な作図をしてみる
作図をするときに使うソフトというと PowerPoint とか Visio とか色々あるけど、大抵は GUI で素材をチマチマとドラッグアンドドロップしていく系が多いと思う。 ただ、保存形式がバイナリだとバージョン管理なんかと相性悪いし、なにかをひとつ追加するだけで周りを全部移動させたりーとか考えると結構めんどいこともある。 それに対して blockdiag シリーズはテキストベースの設定ファイルを図に変換することができるツールだ。 blockdiag シリーズは作成する図に応じて blockdiag、seqdiag、nwdiag、actdiag と分かれていて、それぞれブロック図、シーケンス図、ネットワーク図、アクティビティ図を作成することができる。 まずはブロック図を作成できる blockdiag から使ってみよう。 OS X だと、まずは Homebrew で依存パッケージを入れてお
あなたの仕様書は大丈夫？ 日本語文のあいまい度診断ツール『ClearDoc』でドキュメントをチェック
ウォーターフォール型の開発では、要件定義、設計、プログラミング、テスト、運用といった作業工程が時系列に進んでいく。開発当初に作成される要件定義や基本設計のドキュメントは、そのプロジェクトに関わる人たち全員が目にするため、そのドキュメントにあいまいな点や複雑な点などがあれば、後々の行程で問題が発生し、品質と生産性に影響する。この課題を解消するのが、株式会社シーイーシー PROVEQサービス事業部の開発した日本語文のあいまい度診断ツール『ClearDoc』だ。 ウォーターフォール型の開発では、要件定義、設計、プログラミング、テスト、運用といった作業工程が時系列に進んでいく。開発当初に作成される要件定義や基本設計のドキュメントは、そのプロジェクトに関わる人たち全員が目にするため、そのドキュメントにあいまいな点や複雑な点などがあれば、後々の工程で問題が発生し、品質と生産性に影響する。この課題を解消
仕様書の書き方はどうやっておぼえるのか - Some Days You Get the Bear
（仕様書というよりは）資料を書くときにごく普通に意識していること。 ■言葉を統一する 同じものを指すのなら、常に同じ言葉で書き表す。 ■初出のものには説明を 重要なもの・ことについては、章を割いて説明する。 読み手の前提知識がどの程度で、どこまで説明を必要としているかを考える。 ■説明の流れを意識する 「どう説明したらわかったもらえるだろうか？」を意識し、 絵や語句の登場順などの、各章の関連・構成を考える。 ■図解 必要に応じて、文章や言葉を説明するための絵を示す （文章を使って絵を説明する、とも言える）。 このとき、説明したい文章・言葉と絵が対応づけされていることが 読み手にわかるようにする。 おおざっぱにイメージで言えば 読み手を迷わせない、混乱させない、ムダに想像させない ということだ。 こういう視点で見れるようになったのは たぶんレビューでいろんな人の資料を見るようになったからなの
まずは「箇条書き」でしょ！ ～仕様書の書き方（２）～ - Some Days You Get the Bear
仕様書の書き方、第２弾です。 漏れ抜けのないようにと、あれもこれもと盛り込みたくて、 ついつい長文になってしまうこと、けっこう多いように感じています。 しかし、仕様書は、 まずは「箇条書き」です！ 要素をきちんと分解し、１つのことを１つの項目として書き表すこと、 これがすごく大事な観点だと思っています。 なぜならば！ 我々は仕様書を書いているのだから。 なんだそりゃ！？ とお思いでしょうが、仕様書ならではの以下の役割があるからです。 ■よい設計の観点から 機能ブロックや入力情報等がきちんと整理・分解されることは、そのままわかりやすい設計につながります どんな機能、どんな情報があるかをきちんと把握できることは、システムの登場人物を正しく把握でき、概要の理解を助けます ■トレーサビリティの観点から 次工程のインプットとして、仕様書どうし・仕様どうしの各項目の対応付けが明確になります 特に仕様が
悪文と良文から学ぶロジカル・ライティング 目次
ITエンジニアにとって文書作成技術は欠かせません。日常のメールのやりとりにはじまり、要件定義書、機能仕様書、企画の提案書など、上司やチーム、顧客などに対して、文章でコミュニケーションをとる機会がとても多いからです。 本連載では、論理的にわかりやすい文章を書く「ロジカル・ライティング」のノウハウを伝授します。ITエンジニアが日常的に用いるであろう文章を例に使い、どこが悪くてどう直せばいいのかといったポイントをわかりやすく解説します。実践すれば、誰でもすぐにわかりやすい文書が書けるようになるはずです。 連載目次 ●オリエンテーション ・ITエンジニアにとって「書く技術」とは？ ●文書の全体構成を組み立てられるようにする ・内容を大きく分けて項目を立てる ・適切な順番で項目を並べる ・話の階層をそろえる ●文章表現の基本ルールをマスターする ・主語と述語を対応させる ・修飾語と被修飾語をはっきり
理系のための文書作成術(1) ―― 開発文書を分かりやすく記述する
ソフトウェアやハードウェアなどの開発作業には，仕様書や設計書などの文書（ドキュメント）を読んだり書いたりすることが欠かせません．通常，開発文書は，読み手が理解しやすいように，正確で明快であることが求められます．さらに，開発文書としての内容が必要十分であることも求められます．それは，読み手が，開発文書の内容を理解するだけでなく，理解した情報を次に続く開発作業につなげなければならないからです．読み手にとって分かりにくい開発文書は，読み手の理解を妨げ，さらには開発作業の進み具合や作業そのものの成否にも影響を及ぼします． 本連載では，ソフトウェア開発を例にして，仕様書や設計書に散見される分かりにくい記述例を紹介しながら，次の論点を考察していきます． どんな文書が開発を妨げるのか 分かりやすい開発文書を書くにはどうしたらよいのか 文書作成をどのように開発業務に組み入れていけば，品質と生産性が上がるの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
