仕様書がない開発が増えた理由 | ScrapEngineer
最近の開発で仕様書等のドキュメント類を書くことが少なくなりました。 私は主に業務系のWebサービスを作成してましたが、最近はオープン系のサービスも受け持つことも多いのですが、仕様書やテストのエビデンスがオープン系のお客様の場合は求められることが少ない・・・ というかほぼない。 何故、お客様は仕様書を求めないのか？ 予算を削りたい お客様にとって仕様書なんて見てもわからないもの貰ってもしょうがない。 貰ってもしょうがないものなら作ってもらわないで、削ってしまおうって考えがあります。 テストのエビデンスも同様です。 これは仕様書の作成やエビデンスの作成に工数が掛かるため、工数の削減を計って予算を削りたいという考えがあります。 例えば、おおまかに計算しますが以下のようなシステムがあります。 開発工数：1人月 検証工数：0.5人月 設計工数：0.5人月 ドキュメント作成工数：0.5人月 管理工数：
第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp
「締め切りを守ること」の大切さ 今までたくさんの日米のエンジニアと仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし、ものすごい生産性でプログラムを作ってくれる「馬力（ばりき）のあるエンジニア」もいた。しかし、そんな中でも、私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは、「常に締め切りを守れるように仕事をすること」である。 チームで仕事をする場合、どうしてもお互いが担当するタスク（＝作業）の間に依存関係が生じる。そんなときに、どれか一つのタスクの完了の遅れが、ほかのタスクの完了に波及し、それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が、自分に割り当てられたタス
満足せる豚。眠たげなポチ。:「業務システム開発学科」開講
前エントリの続きで、「業務システム開発学科」の単元を挙げてみる。 これがないと作れないという要素をボトムアップ（上流・下流からいくとボトムではないけど）で挙げていったつもり。（「エンタープライズ・コンピューティング学科」は要らぬ誤解を招きそうなので、止めておく。） やりたいこと・やるべきことを決める (Why/Whom/What) 現状のヒアリング 理想形のヒアリング 目的の確認 誰が使うのか どのようなものを作るのか 計画を立てる (When/Where/Who/How much/How) スコープを決める 実現方法の検討 見積り スケジュールを決める 担当を決める 道具を知る (How) コンピュータサイエンスの基礎 (設計しテストするのもプログラミングの一部としてここに入る) ネットワークの基礎 コンピュータアーキテクチャの基礎 OS の基礎 RDB の基礎 アプリケーションのための
2006-03-20
http://satoshi.blogs.com/life/2006/03/post_8.html うーん，ほとんど全くその通りなんで突っ込みどころがまるでない． 私はこの業界で多くのエンジニアも使ってきたが、優秀なエンジニアとそうでないエンジニアの生産性は（誇張抜きで）２０対１ぐらいである。そんな簡単な作業しか出来ないエンジニアとも呼べないようなエンジニアが沢山いてもマネージメントが大変なだけである。 これらは常識なのだが，なぜか公式の場やマスコミには存在しないことにされてしまう． そしてもっとも許せないのが、そういった上流→下流という階層構造でプログラムを作る工程そのものだ。(中略) 日本のエンタープライズ系のソフトウェア業界は、そんな根本的に間違ったソフトウェアの作り方を長年してきたために、まるで建築業界のような下請け・孫請け構造が出来てしまい、下流のエンジニア達が十分な経験も得るこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラミング言語は「黙って写経」──カーネルハッカー・小崎資広（4） | サイボウズ式
