泥臭い受託開発dev love関西

受託だからといって受け身である必要はない

泥臭い受託開発を語り合う (DevLOVE関西×DevLOVE仙台コラボ企画)

Sat 17th, May, 2014

Toshiyuki Ohtomo

本日お話する内容

お客さんを満足させつつ

楽しく開発するために

やっていること

自己紹介

@toshiotm Toshiyuki Ohtomo

自己紹介


受託の経歴：組み込みパッケージ開発業務系Webシステム開発

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

主な活動：

京都アジャイル勉強会とか


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

主な活動：

京都アジャイル勉強会とか

目標：

炊事、洗濯、育児をこなす

フルスタックエンジニア


コンテキストの説明

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


ここ→

下請け具合

コンテキストの説明会社規模

コンテキストの説明地理的な環境


ユーザー


発注元 ×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会議を設定させてもらいチームで参加する（毎日顔を合わせる）

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

•週に１回は会って話す

そのためには？

•「我々はチームなので何でも共有します」と宣言する

•毎朝数分のWeb会議を設定させてもらいチームで参加する（毎日顔を合わせる）

•週に１回は会って話す

良いプロダクトを作る箇所では社外もチームととらえ積極的に会話する

受け身じゃないポイント⑤

泥臭い場所とそうでない場所を明確に分けて対応する

受け身じゃないポイント⑤

チームで楽しく開発するための

「受け身じゃないポイント」２箇条

•チームが形成される仕組みを積極的に組み込

む

!

•良いプロダクトを作る箇所では社外もチーム

ととらえ積極的に会話する

重要なお知らせ

重要なお知らせ「言葉を選ぶことは、時としてコミュニケー

ションの量より重要」



コミュニケーションを増やすからこそ、気

をつけておかないとギスギスしてくる



コミュニケーションを増やすからこそ、気

をつけておかないとギスギスしてくる

会話の量は仕組みで増やせるが

会話の質は個人に依存するので要注意

おしまい

泥臭い受託開発dev love関西

Documents