属人化を避ける - Qiita
属人化の理由 個人の問題 手抜きやバグを隠す たとえば、仕様書外の動作を実装し、それをプロジェクトで利用する 解雇されないための保険的行動 チームの問題 マニュアルを作る文化の欠如 他人のタスクに対する無関心 他人の監査なしにプロジェクトを更新可能 どうやって属人化を避けるのか 間違った対策 ○○さん以外にもマニュアルなしで操作できる人間を育成 育成した人が全滅すればやっぱり同じ状況 全員がすべてのプロジェクトに精通するとかはムリ 正しい対策 モジュールごとに仕様書を用意 間違って使うことが難しい仕様とする 即ち、仕様書を読まなくてもある程度正確に使える お互いにコードレビューさせる 具体的にはどうすれば良い？ テスト・仕様書・利用例 テストは仕様書のベースとなる 仕様書を見れば、深い動作がわかるようになる 仕様書を読まなくても、利用例を見れば使える 全員がテストできる環境を作る 前提条件
押下(おうか)にまつわる話 - Qiita
はじめに 私が仕様書を書くようになったのは30歳を過ぎてからと遅く、仕様書の書き方が分からなくて悩んだことがありました。通常は先輩たちが作成した仕様書等を見て書き方を覚えていくのでしょうが、仕様書も無く直接プログラムを組むような体制の仕事をしていたため、SI系に転職してから苦労したのであった。 仕様書を書く際に、ボタンを「Enterキーを押す」か「クリックする」かで考えて「押下」にすれば両方満たすだろうと、それ以来ずっと使用しています。 押下については、コンピューター雑誌やマニュアル等を読んで憶えていた用語で特に気にも止めていなかったのですが、別ブログの仲間が過去に「ボタン押下？」について書いていたことを思い出し、調べてみることにしました。 調べていくと自分は誤用して使っている気がしますw 押下について 読み方 押下は「おうか」と読みます。ちなみに苗字の押下さん(読方：おしした)は全国でお
今までに経験した中で最悪の開発環境について書く
なんとなく吐きだしてみる。老害の昔語りなので興味ない人はスルー推奨。 時は2000年代初頭、俺は最初に就職した独立系SIerから4次請けの派遣として某銀行の営業店システム開発に参加していた。 新卒で入社して、二つ目のプロジェクトだった。当時は最先端であったJavaでのプロジェクトということで、ずいぶんと喜んだことは記憶している。 1フロアが丸ごとプロジェクトルームとなっており、プロジェクト統括の事業部長が常に怒号をあげながらフロアを徘徊するなかで、15インチCRTディスプレイ(当然液晶なんかじゃない)がようやく置ける狭い机とパイプ椅子で、右も左もわからないまま、Excelで書かれた仕様書と向き合い、秀丸エディタ(当時はEclipseがまだ生まれていなかった)でジャバを書いていた。 デスマであったかというと、今思うとそこまでデスってはいなかったように思う。頻繁にリスケが行われていたのでプロジ
開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経
時々組織の内外で盛り上がるネタの一つに「設計書は必要なのか」談義がある。今回も後輩の一人から設計書不要論がぶつけられてきたので、現時点での個人的見解をまとめておくもの。個人的には、ソフトウェアの設計書は必須でもないし、開発戦略を練る段階で作成するかどうかを決めればいいと思っている。 議論の前提：仕様書と設計書 議論を簡単にするために、まず「仕様書」と「設計書」という言葉を再定義しておきたい。今回の整理は以下としている。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 要は今回議論しようとしている「設計書」は、ユーザー(仕様決定者)とは無関係なものであるという前提である。また、ここ
ドキュメンテーションを加速するストレスフリーの作図ツール『blockdiag』 jus2011年6月勉強会
システム開発や保守、運用の現場においてドキュメントは必須のものです。 しかし、ドキュメントの作成・維持には多くのパワーがかかるため、ドキュ メントが存在しない、資料が古いままになっているなどといった現状を多く 耳にします。 本勉強会ではこれらのドキュメントでよく利用される「図」にフォーカスし、 みるみるうちに図を作成できる「blockdiag」をご紹介します。 「blockdiag」はシンプルなテキスト記述からブロック図、ネットワーク図などの 画像ファイルを出力可能なオープンソースの画像生成ツールです。書き やすさ、メンテナンスしやすさを中心にデザインされており、図を作るのに 配置や並べ替えに苦労する必要はありません。 blockdiagのサンプルはこちら このような特徴を持つ「blockdiag」と、シンプルな記述でドキュメントを作成 するツール「Sphinx」を組み合わせることによって
個人で作ったWebサービスの仕様書（Evernoteのメモ）を2つ公開してみる - アインシュタインの電話番号
個人でWebサービスを作る際の考察に関する以下の記事が、とても興味深く面白かった。ここに書いてあることはだいたい同意で、自分も実践したいと思うことばかり。 個人でWebサービスを超高速でつくる人たちの作り方を考察。 │ モノづくりブログ 株式会社8bitのスタッフブログです で、記事の最後に執筆者が聞いてみたいこととして「個人Webサービスの場合、仕様書はどうしてるの？」と呼びかけていたので、僭越ながら自分が過去に作ったWebサービスの仕様書（Evernoteに書いたメモ）を公開してみる。公開するのはNekostagramとはてなスターカウンターのもの。 仕様書（TODOリスト）の書き方 自分の場合、Webサービスを作るときに書くものは「仕様書」などと呼べるようなちゃんとしたシロモノではなく、Evernoteに思いついたことをどんどんリストアップしていくだけ。いわゆるTODOリストですね。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
