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

スクラムフェス札幌2022で発表したときのスライドです。

https://confengine.com/conferences/scrum-fest-sapporo-2022/proposal/17510

1. 受託開発受注のための ちょっとしたコツ 〜「何でもかんでもやります」じゃなく、まずはデモ〜 SATO Tatsuya Scrum Fest Sapporo 2022 Photo by Jason Goodman on Unsplash
2. 今日伝えたいこと
3. TAKAKING22 @TAKAKING22·Follow やっていないのに言うのはダサくてイヤなので、しばら く受託開発をマジメに取り組んでみた。そしてダメな受 託開発が生まれやすい構造と、自分が純粋に受託開発を 好きになれない理由がわかってきた。 たぶん言いたいことは #scrumsapporo で @sato_ryu が言 ってくれるハズ！？confengine.com/conferences/sc… 8:29 PM · Oct 27, 2022 8 Reply Copy link Read more on Twitter
4. 受託開発で アジャイル開発を している皆さん
5. 初手、デモ Photo by Carlos Esteves on Unsplash
6. お前、誰よ？ 自己紹介
7. さとうたつや プログラマー。 GitHub: @satoryu Twitter: @sato_ryu 趣味 BABYMETAL 武藤彩未 @onefive アリの飼育 駄洒落
8. 個人事業主 Webアプリケーションの開 発 プログラミング学習の支援 お仕事、お待ちしてます！ https://www.satoryu.com/ 仕事の依頼について 仕事の依頼について お問い合わせ お問い合わせ Tatsuya Sato Passionate Programmer / Father for two kids / MOSH’SH MATE  On this page 注意事項 屋号 事業内容 提供サービス Follow Satoryu's Website  自己紹介
9. Silver Bullet Club所属 Silver Bullet Clubというエンジニアチームに所属しています。
11. アリの飼育 女王アリを捕まえて、育てて います。 クロヤマアリ トビイロシワアリ キイロシリアゲアリ クロオオアリを捕まえたい。
12. 現地参加の皆さん、 羨ましいなー
13. 海岸線10km隣りどうしは家族同然: エゾアカヤ マアリ、スーパーコロニーの経営には血縁ではな く体臭による「敵・味方」識別の寛容さが関係し ていた 2012年10月25日 神戸大学大学院理学研究科、尾崎まみこ教授の研究室の小林 碧研究員は、同、佐倉緑講師、北海道大学大学院環境科学研究 科、東正剛教授の研究グループ、京都工芸繊維大学ベンチャー ラボラトリーの辻井直研究員、イスラエル共和国テルアビブ大 学のA. Hefetz教授らと共同で、近隣の巣を融合してコロニーを 巨大化するアリ種について、スーパーコロニー形成・維持の要 因を明らかにしました。 社会性をもつ生物はコロニーと呼ばれる集団をつくり協力し て生活をしています。普通、コロニーは巣ごとに独立に営まれ もちろん エゾアカヤマアリの スーパー コロニー ですよね！
14. ヒアリではありません！ 安心してください。 大きさが違います 北海道に住めません 北海道新聞 @doshinweb·Follow 道内で、南米原産で強い毒を持つ「ヒアリ」 に似たアリがいるとの情報が道や環境省など に計７０件以上寄せられています。道の調べ では、在来種の「エゾアカヤマアリ」と誤認 するケースなどが多く、ヒアリではありませ んでした。特徴を比べると…。 hokkaido-np.co.jp/article/128110 5:39 PM · Aug 26, 2017 54 Reply Copy link Read more on Twitter
15. 本題に戻ります
16. この数年で経験した開発 他社の社内サービスの開発 関係会社から発案のPoCの開発 自社の社内サービスの開発、リプレイス
17. 受託開発だ！
18. ここでの受託開発 作りたい人、作る人が離れている開発 会社が違う、部署が違うなど様々
19. 受託開発の始まり方 作りたい人がお願い（要求） 作る人が提案（要件） 要件の合意
20. 受託開発に現れる力学
21. 受託開発に現れる力学 作りたいモノがはっきりしていない どうやっていいのかもわからない 人月請求 契約 PoC
22. 作りたいモノがはっきりしていない 要求ができていない。PBIもない。 開始時点では情報が足りていない。 開発を積極的に進めることができない
23. 失敗理由の筆頭はシステムの「要件定義が不十分」 成功率が上がったものの、「半数が失敗」している現状がある。2018年の調査で日経コンピュータは失敗したプロジェクトの失敗理由を調べてい る。それによると、満足を得られなかった理由の筆頭は「要件定義が不十分」、コストを順守できなかった理由の筆頭は「追加の開発作業が発 生」、スケジュールを順守できなかった理由の筆頭は「システムの仕様変更が相次いだ」だった。スケジュールを守れなかったプロジェクトで最 も苦労した工程を尋ねると「要件定義」が筆頭に来た。 – プロジェクト失敗の理由、15年前から変わらず (2ページ目)：日経ビジネス電子版
24. どうやっていいのかもわからない 発注側は役割とその仕事を知らない 足りない情報を想像で埋めてしまう
25. 人月請求 この見積もりだと、発注側が理解しやすい 儲けるためには2通り 時間数を増やす 時間単価を上げる 内容は問われないので、 無駄なことをしても稼げる
26. 契約 契約時点で何を作るかが決まっていないので、準委任になりがち 完成を要求されない 人月請求と合わさると、 期間内での完成を目指さない方が儲けられてしまう
27. PoC, Proof Of Concept 人によって意味が異なる 新技術を試すことが目的だったり プロダクト開発の初期のことを指したり
28. 「PoCだから」 プロジェクト期間だけでしか利用しない場合 PoCは手を抜く理由にされがち パフォーマンスは気にしない ログは残さない テストコードは書かない
29. 悪い方向への力が多い 要求・要件定義や目的が定まらない 速く作らなくても稼げてしまう 良いものを作らなくても稼げてしまう
30. 「なんでもかんでもやります！」 聞こえは良いので、発注側は嬉しい しかし、良いものは生まれにくいのでは
31. 抗うにはどうしたらいいのか？ 最終的に開発チームに力が流れてくる 開発チームで抗うしかない
32. 開発チームの規律
33. 規律とは き‐りつ【規律／紀律】 1. 人の行為の基準として定められたもの。おきて。「― を守る」 2. 一定の秩序。「― 正しい生活」
34. では、規律として 何をまずやるべきなのか？
35. デモを作る Photo by Jo Szczepanska on Unsplash
36. デモ 今わかっている情報を集めて、欲しい物を想像して作る 誰がどういうときに使って、何を解決するのかを想像
37. デモアプリのいいこと 3選 要求・要件へのフィードバックループが作れる 実現可能かを試せる 技術プラクティスが使えるようになる
38. フィードバックループが作れる 要求・要件定義だけでは正しいのか検証できない 動くものがあれば検証ができる フィードバックを繰り返して、要件をよりよくできる
39. Agile and Requirement : アジャイルな要件定義について考える - Speaker Deck
40. 実現可能かを試せる 技術的制約がある場合、実現可能なのかを早く確認したい そもそもできなければ、プロジェクトはやらない方が良い 制約の不安を消して、見積もりしやすくなる
41. 技術プラクティスが使えるようになる テスト駆動開発やCIを始められる 途中から入れるのは難しい
42. 最近の事例
43. お客さんからの要求 外部サービスとBIツールとを自 動連携するPoC 技術的制約 外部サービスは固定 ざっくり「クラウドでやり たい」 ユーザーはまだ定まってない 現状
44. デモのシナリオを考える 想定ユーザーを一旦固定 その人が気にしそうなことを調べる ドメイン知識がある人が近くにいるのでヒアリング 正確であることより、何かが決めることが大事
45. 見えるところから作る 想定ユーザーが触る部分から作る データは仮のものでも評価できる BIツールのデータ投入、ダッシュボード作りから
46. 技術的に不安なところを触っ ておく 未経験の部分から着手 経験がある部分（クラウド環 境）は後回し 最低限触れるものが完成
47. デモをする 作ったものは実際の想定とは違った けれど、議論のスタートができた 「ここに◦◦は表示できないか？」 「これは一度、◦◦さんたちに見てもらいましょう」
48. まとめ
49. まとめ 受託開発に発生する悪い力 開発者の規律 規律としてのデモ デモを使って要件へのフィードバックループを作る
50. 受託開発は アジャイル開発が難しい？
51. どう始める？
52. アジャイルソフトウェア開発宣言 アジャイルソフトウェア開発宣言
53. 包括的なドキュメントよりも 動くソフトウェアを
54. 動くソフトウェアとして、ま ずデモを
55. 初手、デモ Photo by Carlos Esteves on Unsplash
56. 参考文献 羽生章洋, はじめよう! 要件定義 ~ビギナーからベテランまで, 技術評論社, 2015 岡島幸男, 受託開発の極意 変化はあなたから始まる 現場から学ぶ実践手法, 技術評論社, 2008 倉貫義人, 「納品」をなくせばうまくいく 」, 日本実業出版社, 2014 浅川直輝, 北川賢一, IT業界に根付く構造問題（日経BP Next ICT選書） 日経コンピュータReport3, 日経BP, 2015 川口恭伸, Agile and Requirement : アジャイルな要件定義について考える, https://speakerdeck.com/kawaguti/agile-and- requirement, 2022