狠狠撸

受託だからといって
受け身である必要はない
泥臭い受託開発を語り合う
(DevLOVE関西×DevLOVE仙台コラボ企画)
Sat 17th, May, 2014
Toshiyuki Ohtomo

本日お話する内容
お客さんを満足させつつ
楽しく開発するために
やっていること

自己紹介
@toshiotm
Toshiyuki Ohtomo

自己紹介
@toshiotm
Toshiyuki Ohtomo
受託の経歴：
組み込み
パッケージ開発
業務系Webシステム開発

自己紹介受託の経歴：
組み込み
主な活動：
京都アジャイル勉強会とか
@toshiotm
Toshiyuki Ohtomo

自己紹介受託の経歴：
組み込み
主な活動：
京都アジャイル勉強会とか
目標：
炊事、洗濯、育児をこなす
フルスタックエンジニア
@toshiotm
Toshiyuki Ohtomo

コンテキストの説明
下請け具合

ここ→
下請け具合

会社規模

地理的な環境

地理的な環境
ユーザー

地理的な環境
発注元 ×2
ユーザー

地理的な環境
ここ
発注元 ×2
ユーザー

契約形態

契約形態
要求分析?基本設計詳細設計?システムテスト

委任契約
契約形態
請負契約
要求分析?基本設計詳細設計?システムテスト

チーム紹介

チーム紹介
社員

社員
チーム紹介
社員

チーム紹介
社員
派遣
社員

チーム紹介
社員
派遣
派遣
社員

開発環境

開発環境
Javaフレームワーク

開発環境
Javaフレームワーク (発注元独自拡張)

開発環境
発注元に社内標準あり
(発注元独自拡張)

開発環境
発注元に社内標準あり(Excel方眼紙)

開発環境
既存の追加機能
(Excel方眼紙)

開発環境
既存の追加機能
(2003年) (2013年)
(Excel方眼紙)

下請けからみて誰が
お客さん？

お客さん？
発注

お客さん？
発注
発注

お客さん？
発注
発注
発注

お客さん？
発注
発注
発注
全員お客さん

お客さん？
発注
発注
発注
全員お客さん
その中でも

お客さん？
発注
発注
発注
ここではない

お客さん？
発注
発注
発注
ここでもない

お客さん？
発注
発注
発注
ここの人が満足する
必要がある！

そんな雲の上にどう
やって辿り着くのか？

いつもやっているのは

いつもやっているのは
誰が何のために
をとことん尋ねる

何を作るかは他の人にも答えられる

でも

誰が何のために必要なのか
は、本当に要求を持っている人
（ドメインを理解している人）に
しか答えられない
でも

誰が何のために必要なのか
は、本当に要求を持っている人
（ドメインを理解している人）に
しか答えられない
でも
ここを理解しないと
満足させることは出来ない

ここを確認しないままプロジェクトが
進むと途中でちゃぶ台返される

ここを確認しないままプロジェクトが
進むと途中でちゃぶ台返される
ウォーターフォールとか
アジャイルは関係ない
どこでひっくり返されるかが
異なるだけ

本当の要求をもって
いるユーザーまで自
ら辿り着く
受け身じゃないポイント①

辿り着いたとして、どうやってお客さん
の要求を聞き出すのか？

質問を間違えれば、当然答えも変わって
くるし…。

質問を間違えれば、当然答えも変わって
くるし…。
予算も限られているから時間も掛けられ
ないし…。

お客さんが
何を考えていて
どうしようとしているのか
知る方法はないものか？
手っ取り早く…

そもそも…
n次受けまで話が来ている時には、
予算も納期も抱えている問題の解決策
すらもある程度決まっていることが多い

普段は、これが弊害となるんですが…
そもそも…

そもそも…
普段は、これが弊害となるんですが…
書いてあるのだから使
わない手はない

念のため教えてください。
御社で予算獲得時の資料などあります
でしょうか？

念のため見ておきたいので、
見せられるところだけで良いので、
見せて頂くことは出来ますか？

念のためっていい言叶…

ユーザーが予算獲得な
どで作成したコンセプ
ト資料を必ず手に入れ
る
受け身じゃないポイント②

そこには、ユーザーの
当初の熱い思いが書か
れている
受け身じゃないポイント②

コンセプト資料を手に入れたら、資料を元
に要求分析を行い要求仕様書を作成する

どんな要求仕様書を
作成しているのか？

?として、?したい
なぜなら?、?だからだ

?として、?したい
なぜなら?、?だからだ
ここをしっかり書く！

なぜなら?、?だか
らだ
これが書けない時は、ユーザーの要求
を理解しきっていない可能性がある

たとえ不要と言われて
も、要求には「なぜな
ら?」を書く
受け身じゃないポイント③

開発中のチーム内での
認識を揃えるためにも
「なぜなら?」は必須
受け身じゃないポイント③

ユーザーに満足してもらうための
「受け身じゃないポイント」３箇条
?本当の要求を持っているユーザーまで自ら辿
り着く
?ユーザーが予算獲得などで作成したコンセプ
ト資料を必ず手に入れる
?たとえ不要と言われても、要求には「なぜな
ら?」を書く

下請けからみてどこ
までがチーム？

発注
発注
発注

発注
発注
発注
全員チーム内

D
社内のチームが楽し
く開発するためには？

D
どんな時が楽しそうか？

D
?飲んでいる時

D
?飲んでいる時
?Officeグリコの前で話して
いる時

D
?飲んでいる時
いる時
?うまくコードで表現できた
時に話しかけてくる

D
?飲んでいる時
いる時
?ユーザーの価値をどう実現
するかについて話している
時

D
?飲んでいる時
いる時
?ユーザーの価値をどう実現
するかについて話している
時
とりあえず
話す機会が多くあれば
良さそう！

D
いっぱい話せる仕組み
を取り入れる

D
を取り入れる
?毎朝決まった時間にプチミー
ティング

D
を取り入れる
ティング
?毎夕決まった時間にプチミー
ティング

D
を取り入れる
ティング
ティング
?隔週で１日ミーティング

D
を取り入れる
ティング
ティング
?隔週で一緒にランチ

D
を取り入れる
ティング
ティング
?月１で飲み会

D
を取り入れる
ティング
ティング
?月１で飲み会
疲れてくるので
お菓子重要

チームが形成される
仕組みを積極的に組
み込む
受け身じゃないポイント④

普段からどうでもい
いことを話していな
いのに、大事な時だ
け話せるわけがない
受け身じゃないポイント④

社外のチームはどう
でもよいのか？

社外のチームはどう
でもよいのか？
そんなことはない

社外のチームと楽し
く開発するためには？

くない時はいつか？

?見積もり（お金）が合わな
い時

い時
?納品後の瑕疵について話す
時

い時
?納品後の瑕疵について話す
時
まずは、契約やお金の話以外（会社の利害
抜き）ではチームだと認識してもらおう

そのためには？
?毎朝数分のWeb会議を設定させてもらいチーム
で参加する（毎日顔を合わせる）

?週に１回は会って話す

?「我々はチームなので何でも共有します」と宣
言する
?週に１回は会って話す

良いプロダクトを作
る箇所では社外もチー
ムととらえ積極的に
会話する
受け身じゃないポイント⑤

泥臭い場所とそうで
ない場所を明確に分
けて対応する
受け身じゃないポイント⑤

チームで楽しく開発するための
「受け身じゃないポイント」２箇条
?チームが形成される仕組みを積極的に組み込
む
!
?良いプロダクトを作る箇所では社外もチーム
ととらえ積極的に会話する

重要なお知らせ
「言葉を選ぶことは、時としてコミュニケー
ションの量より重要」

コミュニケーションを増やすからこそ、気
をつけておかないとギスギスしてくる

コミュニケーションを増やすからこそ、気
をつけておかないとギスギスしてくる
会話の量は仕組みで増やせるが
会話の質は個人に依存するので要注意

泥臭い受託開発Dev love関西

狠狠撸

泥臭い受託開発Dev love関西

More Related Content

泥臭い受託開発Dev love関西