受託開発受注のためのちょっとしたコツ〜「何でもかんでもやります」じゃなく、まずはデモ〜 / demonstation first

by Tatsuya Sato

Slide 1

Slide 1 text

受託開発受注のためのちょっとしたコツ〜「何でもかんでもやります」じゃなく、まずはデモ〜 SATO Tatsuya Scrum Fest Sapporo 2022 Photo by Jason Goodman on Unsplash

Slide 2

Slide 2 text

今日伝えたいこと

Slide 3

Slide 3 text

TAKAKING22 @TAKAKING22·Follow やっていないのに言うのはダサくてイヤなので、しばらく受託開発をマジメに取り組んでみた。そしてダメな受託開発が生まれやすい構造と、自分が純粋に受託開発を好きになれない理由がわかってきた。たぶん言いたいことは #scrumsapporo で @sato_ryu が言ってくれるハズ！？confengine.com/conferences/sc… 8:29 PM · Oct 27, 2022 8 Reply Copy link Read more on Twitter

Slide 4

Slide 4 text

受託開発でアジャイル開発をしている皆さん

Slide 5

Slide 5 text

初手、デモ Photo by Carlos Esteves on Unsplash

Slide 6

Slide 6 text

お前、誰よ？自己紹介

Slide 7

Slide 7 text

さとうたつやプログラマー。 GitHub: @satoryu Twitter: @sato_ryu 趣味 BABYMETAL 武藤彩未 @onefive アリの飼育駄洒落

Slide 8

Slide 8 text

個人事業主 Webアプリケーションの開発プログラミング学習の支援お仕事、お待ちしてます！ https://www.satoryu.com/ 仕事の依頼について仕事の依頼についてお問い合わせお問い合わせ Tatsuya Sato Passionate Programmer / Father for two kids / MOSH’SH MATE  On this page 注意事項屋号事業内容提供サービス Follow Satoryu's Website  自己紹介

Slide 9

Slide 9 text

Silver Bullet Club所属 Silver Bullet Clubというエンジニアチームに所属しています。

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

アリの飼育女王アリを捕まえて、育てています。クロヤマアリトビイロシワアリキイロシリアゲアリクロオオアリを捕まえたい。

Slide 12

Slide 12 text

現地参加の皆さん、羨ましいなー

Slide 13

Slide 13 text

海岸線10km隣りどうしは家族同然: エゾアカヤマアリ、スーパーコロニーの経営には血縁ではなく体臭による「敵・味方」識別の寛容さが関係していた 2012年10月25日神戸大学大学院理学研究科、尾崎まみこ教授の研究室の小林碧研究員は、同、佐倉緑講師、北海道大学大学院環境科学研究科、東正剛教授の研究グループ、京都工芸繊維大学ベンチャーラボラトリーの辻井直研究員、イスラエル共和国テルアビブ大学のA. Hefetz教授らと共同で、近隣の巣を融合してコロニーを巨大化するアリ種について、スーパーコロニー形成・維持の要因を明らかにしました。社会性をもつ生物はコロニーと呼ばれる集団をつくり協力して生活をしています。普通、コロニーは巣ごとに独立に営まれもちろんエゾアカヤマアリのスーパーコロニーですよね！

Slide 14

Slide 14 text

ヒアリではありません！安心してください。大きさが違います北海道に住めません北海道新聞 @doshinweb·Follow 道内で、南米原産で強い毒を持つ「ヒアリ」に似たアリがいるとの情報が道や環境省などに計７０件以上寄せられています。道の調べでは、在来種の「エゾアカヤマアリ」と誤認するケースなどが多く、ヒアリではありませんでした。特徴を比べると…。 hokkaido-np.co.jp/article/128110 5:39 PM · Aug 26, 2017 54 Reply Copy link Read more on Twitter

Slide 15

Slide 15 text

本題に戻ります

Slide 16

Slide 16 text

この数年で経験した開発他社の社内サービスの開発関係会社から発案のPoCの開発自社の社内サービスの開発、リプレイス

Slide 17

Slide 17 text

受託開発だ！

Slide 18

Slide 18 text

ここでの受託開発作りたい人、作る人が離れている開発会社が違う、部署が違うなど様々

Slide 19

Slide 19 text

受託開発の始まり方作りたい人がお願い（要求）作る人が提案（要件）要件の合意

Slide 20

Slide 20 text

受託開発に現れる力学

Slide 21

Slide 21 text

受託開発に現れる力学作りたいモノがはっきりしていないどうやっていいのかもわからない人月請求契約 PoC

Slide 22

Slide 22 text

作りたいモノがはっきりしていない要求ができていない。PBIもない。開始時点では情報が足りていない。開発を積極的に進めることができない

Slide 23

Slide 23 text

失敗理由の筆頭はシステムの「要件定義が不十分」成功率が上がったものの、「半数が失敗」している現状がある。2018年の調査で日経コンピュータは失敗したプロジェクトの失敗理由を調べている。それによると、満足を得られなかった理由の筆頭は「要件定義が不十分」、コストを順守できなかった理由の筆頭は「追加の開発作業が発生」、スケジュールを順守できなかった理由の筆頭は「システムの仕様変更が相次いだ」だった。スケジュールを守れなかったプロジェクトで最も苦労した工程を尋ねると「要件定義」が筆頭に来た。 – プロジェクト失敗の理由、15年前から変わらず (2ページ目)：日経ビジネス電子版

Slide 24

Slide 24 text

どうやっていいのかもわからない発注側は役割とその仕事を知らない足りない情報を想像で埋めてしまう

Slide 25

Slide 25 text

人月請求この見積もりだと、発注側が理解しやすい儲けるためには2通り時間数を増やす時間単価を上げる内容は問われないので、無駄なことをしても稼げる

Slide 26

Slide 26 text

契約契約時点で何を作るかが決まっていないので、準委任になりがち完成を要求されない人月請求と合わさると、期間内での完成を目指さない方が儲けられてしまう

Slide 27

Slide 27 text

PoC, Proof Of Concept 人によって意味が異なる新技術を試すことが目的だったりプロダクト開発の初期のことを指したり

Slide 28

Slide 28 text

「PoCだから」プロジェクト期間だけでしか利用しない場合 PoCは手を抜く理由にされがちパフォーマンスは気にしないログは残さないテストコードは書かない

Slide 29

Slide 29 text

悪い方向への力が多い要求・要件定義や目的が定まらない速く作らなくても稼げてしまう良いものを作らなくても稼げてしまう

Slide 30

Slide 30 text

「なんでもかんでもやります！」聞こえは良いので、発注側は嬉しいしかし、良いものは生まれにくいのでは

Slide 31

Slide 31 text

抗うにはどうしたらいいのか？最終的に開発チームに力が流れてくる開発チームで抗うしかない

Slide 32

Slide 32 text

開発チームの規律

Slide 33

Slide 33 text

規律とはき‐りつ【規律／紀律】 1. 人の行為の基準として定められたもの。おきて。「― を守る」 2. 一定の秩序。「― 正しい生活」

Slide 34

Slide 34 text

では、規律として何をまずやるべきなのか？

Slide 35

Slide 35 text

デモを作る Photo by Jo Szczepanska on Unsplash

Slide 36

Slide 36 text

デモ今わかっている情報を集めて、欲しい物を想像して作る誰がどういうときに使って、何を解決するのかを想像

Slide 37

Slide 37 text

デモアプリのいいこと 3選要求・要件へのフィードバックループが作れる実現可能かを試せる技術プラクティスが使えるようになる

Slide 38

Slide 38 text

フィードバックループが作れる要求・要件定義だけでは正しいのか検証できない動くものがあれば検証ができるフィードバックを繰り返して、要件をよりよくできる

Slide 39

Slide 39 text

Agile and Requirement : アジャイルな要件定義について考える - Speaker Deck

Slide 40

Slide 40 text

実現可能かを試せる技術的制約がある場合、実現可能なのかを早く確認したいそもそもできなければ、プロジェクトはやらない方が良い制約の不安を消して、見積もりしやすくなる

Slide 41

Slide 41 text

技術プラクティスが使えるようになるテスト駆動開発やCIを始められる途中から入れるのは難しい

Slide 42

Slide 42 text

Slide 43

Slide 43 text

お客さんからの要求外部サービスとBIツールとを自動連携するPoC 技術的制約外部サービスは固定ざっくり「クラウドでやりたい」ユーザーはまだ定まってない現状

Slide 44

Slide 44 text

デモのシナリオを考える想定ユーザーを一旦固定その人が気にしそうなことを調べるドメイン知識がある人が近くにいるのでヒアリング正確であることより、何かが決めることが大事

Slide 45

Slide 45 text

見えるところから作る想定ユーザーが触る部分から作るデータは仮のものでも評価できる BIツールのデータ投入、ダッシュボード作りから

Slide 46

Slide 46 text

技術的に不安なところを触っておく未経験の部分から着手経験がある部分（クラウド環境）は後回し最低限触れるものが完成

Slide 47

Slide 47 text

デモをする作ったものは実際の想定とは違ったけれど、議論のスタートができた「ここに○○は表示できないか？」「これは一度、○○さんたちに見てもらいましょう」

Slide 48

Slide 48 text

まとめ

Slide 49

Slide 49 text

まとめ受託開発に発生する悪い力開発者の規律規律としてのデモデモを使って要件へのフィードバックループを作る

Slide 50

Slide 50 text

受託開発はアジャイル開発が難しい？

Slide 51

Slide 51 text

どう始める？

Slide 52

Slide 52 text

アジャイルソフトウェア開発宣言アジャイルソフトウェア開発宣言

Slide 53

Slide 53 text

包括的なドキュメントよりも動くソフトウェアを

Slide 54

Slide 54 text

動くソフトウェアとして、まずデモを

Slide 55

Slide 55 text

初手、デモ Photo by Carlos Esteves on Unsplash

Slide 56

Slide 56 text

参考文献羽生章洋, はじめよう! 要件定義 ~ビギナーからベテランまで, 技術評論社, 2015 岡島幸男, 受託開発の極意変化はあなたから始まる現場から学ぶ実践手法, 技術評論社, 2008 倉貫義人, 「納品」をなくせばうまくいく」, 日本実業出版社, 2014 浅川直輝, 北川賢一, IT業界に根付く構造問題（日経BP Next ICT選書）日経コンピュータReport3, 日経BP, 2015 川口恭伸, Agile and Requirement : アジャイルな要件定義について考える, https://speakerdeck.com/kawaguti/agile-and- requirement, 2022