Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,435 views

Published on

私見です。

Published in: Software
  • Be the first to comment

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

  1. 1. 市⾕聡啓 ソフトウェア開発の掟
  2. 2. 五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境
  3. 3. 五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境
  4. 4. 「⾃分のお⾦」を使ってでも やったほうが良いと思うか?
  5. 5. Whyが無い、共感を感じにくい場合、 まずやらない。 ・必ず途中で⾃分をだませ無くなるから。  - 「われわれはなぜここにいるのか」は最初の⼀回ではない。   毎⽇、問われる。(正直、ツライ)  - つくり⼿の中に「基準」がつくられないと、事前に想定   している以上のモノはできない。(他⼈の基準どおり) ・この時代、最も貴重なりソースとは?=「時間」  - 「⾦払ったらなんでもやってもらえる」の終焉 (⼈間不⾜)
  6. 6. 当事者より、当事者らしく。 ・⾃分の中に基準がある = 「当事者」  - 仮説検証を関係者とともに実施することで、つくり⼿に   「このプロダクトはこうあるべき」という基準が宿る。   結果、開発が圧倒的に速くなる。(4ヶ⽉→2ヶ⽉) - 単なる思い込み、思いつきではなく、仮説検証を踏まえて   いるため、「ソフトウェアを必要とする⼈基準」   (確からしい基準 ≠ 発注者基準)  - プロダクトオーナーが⽂字通り代⾏できる。   (受け⼊れ条件が分かっている)
  7. 7. 五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境
  8. 8. ソフトウェア開発とは、 開発チームと顧客で創作する物語
  9. 9. 意図的に、仕組む。 ・台本を⽤意する。  - ⼈を集めれば、勝⼿にチームになるわけではない、   勝⼿に期待がすりあうわけでもない。  - チーム(クライアントを含めた)の関係性を深める、   お互いの考え⽅・やり⽅、”完成の定義の感じ” を   意識的に整える (=⼼理的安全の確保 〜 信頼の醸成)  - WorkShop(デッキ、ドラッカー、星取表)で⾮⽇常的に演出、   ⽇々のスプリント開発(レビュー、ペア、モブ)で⽇常的に演出  - プラクティスを説明したり、こなすことを⽬的にしたり   しない。
  10. 10. そして、ソフトウェア開発に筋書きはない。 ・即興劇が演じられるか。  - お互いの間合い(考え⽅、やり⽅)が分かっているから、   その上で即興的な⾏動が重ねられる。  - 誰も予期していないことが起こせる可能性があるから、   チームでやる (創発)。  - 安易な「平均点」に妥協したら、つまらなくなる。   “チームワーク > チームプレー”  - 「良い感じの状況をつくる」のに、誰かの許可はいらない。   “許可を求めるな、謝罪せよ。”  - 変化を起こせる「ゆとり」(バッファマネジメント)
  11. 11. 五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境
  12. 12. Small is Justice.
  13. 13. ⼩さく。 ・最初から⼩さく。  - 何に価値があるか、たいてい最初はわからない。  - 「コンセプト負債」(未検証での想定での作り込み)を   ⼤きくしない。最⼩限の範囲ではじめる (MVP)  - ⼩さく始めるから、⽅向が転換しやすい (サンクコスト低減)  - コンセプトは「仮説検証」=「わかること」を増やす。   技術は「曳光弾開発」= リスク対象は先回りして実験する。   スコープは「スケルトン(背⾻)駆動」= 必要機能絶対範囲を   まずつくる(1本背⾻を通す)、その上で⾁(機能)付していく。
  14. 14. 徹底的に⼩さく。 ・つくりながら、⼩さくする。  - 何をつくるべきかを「⼀気呵成に」「事前」に知ることは   できない。  - 実際につくりはじめて (つくり⼿の⾝体知)、   形になるプロダクトを⾒て、触って(ユーザーとしての⾝体知)、   どうあるべきか分かってくる。  - 重要度が低いとわかった機能は、躊躇なく後回しにする(捨てる)  - 「基準」が関係者の共通認識になっているから、   何が⼤事か(=何が価値か)分かる。   何が⼤事か分かっているから「捨てられる」  - あとで、もう⼀度考える (余裕がある)
  15. 15. 五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境
  16. 16. プロダクトも、チームも、 だんだん出来上がる。
  17. 17. ともにつくる。 ・チーム = gainも、painも、分かち合う関係。  - 「ともにつくる」から、ムダ・ムリ・ムラが減り、速く的を   射抜くソフトウェアをつくれる。  - 「ともにつくる」から、楽しい。  - 「ともにつくる」とは、    チームでつくる、ということ。    顧客とともにつくる、ということ。    ユーザーとともにつくる、ということ。
  18. 18. ともに旅する。 ・⼀緒にやるから、だんだんと分かる  - 「お互いの理解」を「⼀気呵成に」「事前」に知ることは   できない (プロダクトと同じ。だんだんと分かってくる)  - 開発の現場は「リアル・カイゼン・ジャーニー」   『カイゼン・ジャーニー』 http://amzn.asia/4jMuMuS  - 成功循環モデルを意識する (関係の質が影響していないか)。   関係の質→思考の質→⾏動の質→結果の質。  - 「取引の関係」と「共創の関係」、どちらの関係なのか?   (ライスワーク的 or ライフワーク的)  - ともにつくる(共創)だから、速く的を(以下略
  19. 19. 五箇条の掟 ⼀、Whyがなければ開発しない ⼀、ソフトウェア開発を演じる ⼀、⼩さく始める、⼩ささを貫く ⼀、ともにつくる、ともに旅する ⼀、越境
  20. 20. どうやって世界を変える?
  21. 21. 越境。 ・「これまでの」認知バイアスを破壊する  - 越境するから、当事者よりも当事者らしくなる    (Whyがなければ開発しない)  - 越境するから、躊躇なく演じられる    (ソフトウェア開発を演じる)  - 越境するから、本質的な価値を⾒失わず捨てることができる    (⼩さく始める、⼩ささを貫く)  - 越境するから、同じ⽅向にむきなおることができる    (ともにつくる、ともに旅する)
  22. 22. 越境は、⾃分から始める。 ・「これまでの」認知バイアスを破壊して、  「⾃分から」前に出る。  - 「他の誰か」ではなくて「⾃分」  - 「他の誰か」を待っているほど、⾃分の⼈⽣は⻑くない   (時間が最も貴重なリソース)  - ⾃分ハンドルを握る。ハンドルを握ったらアクセルを踏む  - “良い感じの状況をつくる”のに、誰かの許可なんて要らない
  23. 23. Toshihiro Ichitani All Rights Reserved.

×