「やらなければならないかもしれないこと」までは見積もれない

MASA Nakamura @masayang

契約締結のために無駄な資料作らされてプロジェクト遠回りさせられているのなら、契約内容を見直せばいいじゃん。

MASA Nakamura @masayang

@masanork @yamasan007 @slm_sum @goshikun だとすれば開発期間をもっと短く切れる部分で契約締結するべきでしょうね。それならブレはなくなる。

山口フジアキ @yamasan007

@masayang @slm_sum @goshikun @masanork 合意形成は非常に重要な事で無視出来ません。その上で基本的ゴール設定は必要。それが、基本設計であり、その前の要件定義になります。

MASA Nakamura @masayang

@yamasan007 @slm_sum @goshikun @masanork なんで？　中の作りまで客は口出しする必要あるの？　開発要件で合意すれば、中がどうなっていようが開発側の勝手じゃん。

山口フジアキ @yamasan007

@masayang @slm_sum @goshikun @masanork 契約締結されないとエンドレスになりますよね。また、合意形成を促す為にも重要な過程となります。まぁ、イキナリ基本設計となる事はそうないですが。

MASA Nakamura @masayang

@yamasan007 @slm_sum @goshikun @masanork この要件が実装されれば完了、という合意でいいんでないの？　なんで基本設計がないと契約できないの？　

山口フジアキ @yamasan007

@masayang @slm_sum @goshikun @masanork 基本設計の目的は、要件定義(=システム範囲確定作業)から業務に適合するインターフェースなど決めていく物になります。人とシステムの具体的接点になりますね。

くろじゅん @kurokunaijun

超現場の本音 RT @masayang:@masanork 今朝から何度も書いていますが、「やらなければならないかもいけないこと」は見積もれないのですよ。そしてソフト開発の生産性を引っ張る最大の要因は「いくつ出てくるかわからない不具合の検知と対策」です。

MASA Nakamura @masayang

@yamasan007 @slm_sum @goshikun @masanork でもさー基本設計を「きちんと」やったプロジェクトでもデスマーチってのはたくさんあるよね。

山口フジアキ @yamasan007

R設計はレビュー込みではない？T @masanork そうでしょうねー。契約って意味じゃ検収要件が肝心かなあ、という気も @masayang @slm_sum @goshikun

MASA Nakamura @masayang

@yamasan007 @slm_sum @goshikun @masanork あなたがその設計書とやらでシステムを最後まで作れるというのならあたしゃ別に文句はいいませんよ。

山口フジアキ @yamasan007

@masayang @slm_sum @goshikun @masanork 要件定義は、主に実業務でシステム範囲確定作業だからです。で、その範囲でシステムと業務の接点を具体的に決めて行くのが、基本設計になると思いますが。

山口フジアキ @yamasan007

@masayang @slm_sum @goshikun @masanork 問題点は、様々でしょうが多くは要件定義過程か見積もりミスですね。

MASA Nakamura @masayang

@yamasan007 @slm_sum @goshikun @masanork 要件定義や見積がが正しく完了した、ってことをどうやって確認するか教えてくださいよ。（私はどちらも「作ってみないとわからない」という立場です）

MASA Nakamura @masayang

情報処理試験制度の弊害 RT @yamasan007: @masayang @slm_sum @goshikun @masanork 要件定義は、主に実業務でシステム範囲確定作業だからです。で、その範囲でシステムと業務の接点を具体的に決めて行くのが、基本設計になると思いますが。

山口フジアキ @yamasan007

@masayang @slm_sum @goshikun @masanork 合意です。

グタアリ @Lenny_gtr

@masayang @masanork @nonkun_minority 建築遺体に同じパーツの組み合わせ的仕事なら不具合の出現率含めてササッと積算できるけど、ソフト開発は未知の要素要求される事多いからね。

MASA Nakamura @masayang

製造業や建設業をモデルにしてしまったところに日本のシステム産業の悲劇の種は蒔かれてしまったと思うんよ。でもきっと巻き返せる。まだ読んでない人は「アジャイルな見積と計画づくり」を買うのだ。

MASA Nakamura @masayang

バインダーで10冊分の要件定義書渡されて「これでいいですよね」と言われたらどうしますか？＞要件定義を承認する側の人

MASA Nakamura @masayang

Adobe Acrobatが固まるくらい巨大なPDFに、画面見本がずらりと並んで「この設計でいいですよね？」と言われたらどうしますか？＞基本設計とやらを承認する立場の人

MASA Nakamura @masayang

一度に対峙する相手が多すぎれば、抜けや漏れ、誤りを排除することはできないんよ。いくらプロセスを整備しても、ね。そしてそれらが顕在化するのはコードが実装されてから。そういう世界で「設計書」を丁寧に整備する意味はどれほどあるのか。

MASA Nakamura @masayang

アツくなってしまった。反省。

山口フジアキ @yamasan007

@masayang @slm_sum @goshikun @masanork 普通の開発過程かと思いますよ。多少の違いはあるでしょうけど。

渡邉博之(魯) @litulon

質は判断できないから量で判断、でしょう。 QT @masayang: Adobe Acrobatが固まるくらい巨大なPDFに、画面見本がずらりと並んで「この設計でいいですよね？」と言われたらどうしますか？＞基本設計とやらを承認する立場の人

板前プロレス @lesimpudents

@masayang ひまそうな派遣にベンダーとの議事録と一言一句照合させる