エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門
残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門：プロジェクト成功確率向上の近道とは？（3）（2/3 ページ） Design Docを書く いよいよ、Design Docを書いていきます。初めにやることは、システムに名前を付け、ドキュメントの冒頭の部分に署名し、そしてこのソフトウェアの目的やゴールを書くことです。 名前を付ける 不思議なことに、良い名前を付けると設計がはかどります。そのシステムにふさわしい名前を付けて、表紙に記載しましょう。 目的やゴールを書く 目的・ゴールの書き方の基本形は『このソフトウェアの目的は★★であり、◯◯を実現することがゴールである。』という定義文のスタイルです。何か誤解を生じる恐れがある場合は『なお、このソフトウェアには、××機能は含まない。』といった形で、除外されるものを明確にすることもあります。 目的・ゴールは、できるだけ明確に書い
Googleなどで利用されているDesign Doc入門 - MyEnigma
How Google Works (日本経済新聞出版) 目次 目次 はじめに Design Docの要点メモ 参考資料 MyEnigma Supporters はじめに GoogleなどのIT企業がソフトウェアを開発する際には Design Docというドキュメントを利用しているそうです。 Design Docは「設計書」と訳されることが多いですが、 日本語の設計書とは少し意味合いが違うようです。 今回は、このDesing Docの要点を、 末尾の参考資料を元に勉強してみたので、 自分用のメモとしてまとめておきたいと思います。 Design Docの要点メモ Design Docは、 これから新しく開発しようとするソフトウェアの全体の設計や、 既存のコードのpatchやプルリクエスト(PR)のコード変更の 基本的な要点をまとめる文書です。 PRを作成する前に、Design Docを作成して
AWS クラウドデザインシート テンプレートを公開してみた | DevelopersIO
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 パブリッククラウドの利用は今後も拡がっていくと予想しています。 比較的慎重であった社内基幹システムのクラウド移行も進んでいくことと思います。 今までとどう違うのか、AWS ならではの使い方はどうすればいいのか、という悩みをお持ちの方は大勢いらっしゃると感じています。 そんな方々のお役に少しでも立てばという想いでドキュメントテンプレートを公開しました。 クラウド上にシステム構築を行う前の設計フェーズで使用するドキュメントを想定して作成しました。 一般的に言う「インフラ基本設計」にあたるドキュメントです。 ドキュメントはこちらで公開しています。ご自由にお使いください。 対象利用者 以下のような利用者を想定しています。 AWS 上で自社サービスを構築するインフラ
バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する
組織における、エンジニアの情報共有について。あるいは、レビューや設計について。 - # TODO: タイトル決定
これは、「ドリコム Advent Calendar 2015 その2」の、8日目の記事になる。 7日目は、middlemanとGitHub Pagesでブログを5分で開設！ほか盛りだくさん！ | いくら寝ても眠たい だった。 私は、ドリコムでエンジニアをしている matsusaki (@misoobu) という者だ。 ここでは、最近考えることの多い、組織におけるエンジニアの情報共有と、そのあるべき姿について書く。 また、それに関連して、コードレビューや設計についても触れる。 内容は、エンジニア視点のものになる。 情報共有は、組織にとって極めて重要だが、簡単なことではない。 本記事が、再考するきっかけとなれば、幸いである。 情報共有とは 情報共有を失敗するとどうなるのか 様々な情報共有 プロジェクトの状況や方針 作業内容とその状況 プログラムの設計やコード レビューの目的 レビューをするとき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Qpstudy201404 インフラ設計の勘所