ソフトウェア開発の(俺の)掟

240 Views

May 30, 18

スライド概要

私見です。

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

ソフトウェア開発の掟 市⾕聡啓

2.

五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境

3.

五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境

4.

「⾃分のお⾦」を使ってでも やったほうが良いと思うか?

5.

Whyが無い、共感を感じにくい場合、 まずやらない。 ・必ず途中で⾃分をだませ無くなるから。 - 「われわれはなぜここにいるのか」は最初の⼀回ではない。 毎⽇、問われる。(正直、ツライ) - つくり⼿の中に「基準」がつくられないと、事前に想定 している以上のモノはできない。(他⼈の基準どおり) ・この時代、最も貴重なりソースとは?=「時間」 - 「⾦払ったらなんでもやってもらえる」の終焉 (⼈間不⾜)

6.

当事者より、当事者らしく。 ・⾃分の中に基準がある = 「当事者」 - 仮説検証を関係者とともに実施することで、つくり⼿に 「このプロダクトはこうあるべき」という基準が宿る。 結果、開発が圧倒的に速くなる。(4ヶ⽉→2ヶ⽉) - 単なる思い込み、思いつきではなく、仮説検証を踏まえて いるため、「ソフトウェアを必要とする⼈基準」 (確からしい基準 ≠ 発注者基準) - プロダクトオーナーが⽂字通り代⾏できる。 (受け⼊れ条件が分かっている)

7.

五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境

8.

ソフトウェア開発とは、 開発チームと顧客で創作する物語

9.

意図的に、仕組む。 ・台本を⽤意する。 - ⼈を集めれば、勝⼿にチームになるわけではない、 勝⼿に期待がすりあうわけでもない。 - チーム(クライアントを含めた)の関係性を深める、 お互いの考え⽅・やり⽅、”完成の定義の感じ” を 意識的に整える (=⼼理的安全の確保 〜 信頼の醸成) - WorkShop(デッキ、ドラッカー、星取表)で⾮⽇常的に演出、 ⽇々のスプリント開発(レビュー、ペア、モブ)で⽇常的に演出 - プラクティスを説明したり、こなすことを⽬的にしたり しない。

10.

そして、ソフトウェア開発に筋書きはない。 ・即興劇が演じられるか。 - お互いの間合い(考え⽅、やり⽅)が分かっているから、 その上で即興的な⾏動が重ねられる。 - 誰も予期していないことが起こせる可能性があるから、 チームでやる (創発)。 - 安易な「平均点」に妥協したら、つまらなくなる。 “チームワーク > チームプレー” - 「良い感じの状況をつくる」のに、誰かの許可はいらない。 “許可を求めるな、謝罪せよ。” - 変化を起こせる「ゆとり」(バッファマネジメント)

11.

五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境

12.

Small is Justice.

13.

⼩さく。 ・最初から⼩さく。 - 何に価値があるか、たいてい最初はわからない。 - 「コンセプト負債」(未検証での想定での作り込み)を ⼤きくしない。最⼩限の範囲ではじめる (MVP) - ⼩さく始めるから、⽅向が転換しやすい (サンクコスト低減) - コンセプトは「仮説検証」=「わかること」を増やす。 技術は「曳光弾開発」= リスク対象は先回りして実験する。 スコープは「スケルトン(背⾻)駆動」= 必要機能絶対範囲を まずつくる(1本背⾻を通す)、その上で⾁(機能)付していく。

14.

徹底的に⼩さく。 ・つくりながら、⼩さくする。 - 何をつくるべきかを「⼀気呵成に」「事前」に知ることは できない。 - 実際につくりはじめて (つくり⼿の⾝体知)、 形になるプロダクトを⾒て、触って(ユーザーとしての⾝体知)、 どうあるべきか分かってくる。 - 重要度が低いとわかった機能は、躊躇なく後回しにする(捨てる) - 「基準」が関係者の共通認識になっているから、 何が⼤事か(=何が価値か)分かる。 何が⼤事か分かっているから「捨てられる」 - あとで、もう⼀度考える (余裕がある)

15.

五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境

16.

プロダクトも、チームも、 だんだん出来上がる。

17.

ともにつくる。 ・チーム = gainも、painも、分かち合う関係。 - 「ともにつくる」から、ムダ・ムリ・ムラが減り、速く的を 射抜くソフトウェアをつくれる。 - 「ともにつくる」から、楽しい。 - 「ともにつくる」とは、 チームでつくる、ということ。 顧客とともにつくる、ということ。 ユーザーとともにつくる、ということ。

18.

ともに旅する。 ・⼀緒にやるから、だんだんと分かる - 「お互いの理解」を「⼀気呵成に」「事前」に知ることは できない (プロダクトと同じ。だんだんと分かってくる) - 開発の現場は「リアル・カイゼン・ジャーニー」 『カイゼン・ジャーニー』 http://amzn.asia/4jMuMuS - 成功循環モデルを意識する (関係の質が影響していないか)。 関係の質→思考の質→⾏動の質→結果の質。 - 「取引の関係」と「共創の関係」、どちらの関係なのか? (ライスワーク的 or ライフワーク的) - ともにつくる(共創)だから、速く的を(以下略

19.

五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境

20.

どうやって世界を変える?

21.

越境。 ・「これまでの」認知バイアスを破壊する - 越境するから、当事者よりも当事者らしくなる (Whyがなければ開発しない) - 越境するから、躊躇なく演じられる (ソフトウェア開発を演じる) - 越境するから、本質的な価値を⾒失わず捨てることができる (⼩さく始める、⼩ささを貫く) - 越境するから、同じ⽅向にむきなおることができる (ともにつくる、ともに旅する)

22.

越境は、⾃分から始める。 ・「これまでの」認知バイアスを破壊して、 「⾃分から」前に出る。 - 「他の誰か」ではなくて「⾃分」 - 「他の誰か」を待っているほど、⾃分の⼈⽣は⻑くない (時間が最も貴重なリソース) - ⾃分ハンドルを握る。ハンドルを握ったらアクセルを踏む - “良い感じの状況をつくる”のに、誰かの許可なんて要らない

23.

Toshihiro Ichitani All Rights Reserved.