○○したら受託開発が180°変わった(10分版)

以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。

[yoiIT]

なぜ作るのか言葉にできないクライアントは多い

[dentaro]

これは受託に限ったことじゃない

[shields-pikes]

普通の話だった。今まで顧客からの与件を全くヒアリングしてなかった的な。ヒアリングが苦手ならヒアリングシートを作ることでモレを無くして精度を高められるけど、180度変わるのは元の精度が低すぎな気がする。

[raitu]

何を作るか聞く前に、なぜ作りたいのかを聞いた方が要件定義には良いって話

[iTaro]

要求開発は重要。要求開発は本当に重要。大事なことなので２回書きました。

[karikari1255]

ユーザーの情シスとかが間に入っている場合、その担当者が関連部署からWhyをきちんと汲み取ってなくて詰むパターンが結構多い。詳しく聞こうとすると、自分の仕事が増えるからかあからさまに面倒くさそうになる

[datemakio]

今までどうやって仕事してたんだよ・・・

[yetch]

そのwhy。顧客側担当者の想像でしょ？後で変わるんでしょ？

[sudo1101]

開発に限らず、何か仕事をふられた時に「なんでそれやるの？」って聞くともっと違う解決法があること多い。

[like_futsal]

受託開発

[phoope]

なんとなくしかわからない。

[rryu]

既存業務のシステム化とかだと結局howは出てこないまま実装することになるという。

[takets]

why how whatをまとめるシートがおもろい

[yuuAn]

受託開発でもユーザーストーリーから MVP 決めてアジャイルな開発をすることができる。

[takaboujp1122]

Good

[nffsjj]

How?のまえにWhy?がある。

[tsutomu-switch]

普通だね。

[moronbee]

顧客の能力を開発したら

[istb16]

受託は5W1H全部必要なのか http://t.co/bryDt49Kau

[tanorityy]

ど新規開発にはいいかもしれんが、改造開発には向かないな。

[stealthinu]

10Pくらいまでがあるあるすぎて泣けた…　非常にあいまいな要件定義が上がってきて後から現行システムではこうだからパターンで修正となって死ぬ。要件定義するときにはWhyを聞くべしとのこと。

[hatajoe]

素晴らしい。

[akulog]

あるある過ぎる

[terurou]

意識して鍛えてないと、中堅になった頃に爆死するポイント

[tak4hir0]

○○したら受託開発が180°変わった(10分版)

[vanbraam]

"ある一つの機能・画面に対して • なぜ？ • どんなときに？ • 誰が？ 使うかを、理解するまで作らない というルールを設けた"<これ良いルールだと思うけど,"誰"が理解するまで"誰"が作らないの?

[linklist]

Why?What?How?／Whyを理解しなければ作らないルールを設けた。

[acealpha]

何故作るかは企業秘密です

[jyuuden]

凄いですね‼

[ura_ra]

Whyを求める

[aquos12345]

この記事を読んだのは時間の無駄だった。

[mak_in]

受託開発ではこれを明確にするため、要件定義をやるはずなんだけど

[kamatamadai]

「なんで(弊社で受託開発が)うまくいっていないの?」に対する倉貫さんの返しが上手い。アジャイル・サムライ読み直さないと

[r_jimano]

WHY??