熱かったです。ただの１セッションではなく、デブサミ全体を代表する基調講演と言ってもいいくらいだと思いました。
長野からだけど朝イチで行ってこのセッションを聴講できてとても良かったです。
以下適当なメモです。
第1部
- 環境の変化により途中でプロジェクト終了
- 残ったのは大量の紙
- 環境の変化は止められない
- ソフトウェア開発で何を実現したいのか
- 必要とされるソフトウェアの提供が困難
- 1. 変化に対応できない
- 2. 価格に対する納得感がない
- 3. 必要なタイミングで手に入らない
変化
- 外的変化 経済環境や政治環境
- 内的変化 状況が進み理解が深まり分かるようになる
受託開発一括請負における変化
- 変化=仕様変更
- 変更管理は開発を安全に遂行するためのもの
- 受注側は別料金
- 発注側は固定料金
- ゼロサムゲーム
- 仕様変更管理なんて言ってるレベルでは変化を受け入れることはできない
人月
- コスト算出の基準
- リスクが排除できる
- 価値には到達できない
顧客はドリルが欲しいのではなくネジの穴が欲しいのだ
- 顧客はシステムが欲しいのではなくシステムがもたらす便益が欲しい
- 開発コストは価値に直接は結びつかない
- 価値に結びつかないもので価格を決める→納得できない
ソフトウェア自体には価値はない
- ソフトウェアと利用者の間に価値が生まれる
- 利用しなければ価値はない
- 価値があるのか分からないまま確かめるのが1年先になる
- 1年後も用をなすのか？
プロセスの問題
- Agile
- プロセスだけ買えても問題は解決しない
- 「後で仕様を変える時費用はどうしましょうか」
- 変化=仕様変更
プロセスの前に契約の問題
- 契約の前に価格設定の問題
- 人月以外で測る
- 成果に応じて対価をうけとる
パフォーマンスベース契約
- 発注者と受注者が協働する世界。お互いが価値発見価値向上のために知恵を出し合う
- 課題 成果を測るまで時間がかかる
- 短いサイクルで。利用も評価もフィードバックを早く。
- ITだけの貢献(価値)を測るのは難しい。どこまでリスクを取れるかが肝
- ソフトウェア開発の新しいビジネスモデル確立をトライアル中
ビジネスモデルとプロセスを分けない
プロセスと契約を変えたら価値に到達できるのか
第2部
- 現状を変え始めることは一人でもできる。組織の仕事を一人で変えるのは難しい
- 現状に踏みとどまろうとする人の意識の問題
- これまでの前提や至高を疑ってみるきっかけが必要
- そう易々とは変われません。自分自身も
事件
- デブサミ2007
- 自分の信じるもののために生きる
- デブサミやコミュニティは気づくためのきっかけになる。
- きっかけ=勉強会
- 内と外の温度差
- 日常受動的→日常能動的はむり
- 日常受動的→非日常受動的→非日常能動的→日常能動的
- 普段はないコミュニケーションを育む SKIP
- 自分たちが向かいたい方向の確認
- 変化を起こすためには、これまでの前提や思考に問いかける事件が必要
- 「社内版デブサミ」
- 日常＝仕事 日常で繋がる 日常を変える
- 「社内勉強会 チームふりかえり」
- 日常と非日常を循環
コミュニティ
- 社外との接点(コミュニティ)を意図的に作る
- 開発の現場 →参加→ コミュニティ →仮説→ 現場 →事例→ コミュニティ
- この業界そのものが循環するシステム
- 我々のソフトウェア開発を支えるのはこの業界そのもの
- 期待通りいかなくて挫折する。期待とは一方向のただの想い。
- 信じること
- 自分が変われば他人も変わる
- 世界を買えるのは他の誰かではなく自分自身
第3部
- ソフトウェア開発で何を実現したいのか。
- 仕事のやり方をかえ、知恵を絞り、行動を起こす
- 我々にとっての月は何か
- 月に向かうためには乗り物が必要
- 重力をたちきる
- 私の乗り物とあなたの乗り物は同じものかもしれないし違うかもしれない
- 私の月はあなたのみてる月とはちがうかもしれない
- 重力を突破しようとする者たち
- 極限の状態で書いたソースコード
- その1行には俺たちがついてる
- 互いの月をめざしましょう
最後に
”次は君の番”
