Embed Size (px)
Citation preview
自己紹介★西村 直人★ http://friendfeed.com/nawoto
★Rails案件専門の現場リーダー★ LLWG
★リーダー★偉くない方の西村
今日、話したい事ソフトウェア開発は年々、要求される事が難しくなってきています。効率とか生産性の向上を求められています。
今日、話したい事少しでも効率とか生産性を良くするために普段の仕事のムダを減らす事を考えてみます。
アジェンダ1.何がムダなんだろう?2.なぜムダなんだろう?3.どうやって解決しよう?1.例えば Scrum の場合4.質疑応答
何がムダ
ムダとは?製造業では価値を付加しないあらゆるもの★作り過ぎのムダ★手待ちのムダ★不良を作るムダ★動作のムダ★ムダを改善しない等
ソフトウェア開発?価値を付加しないあらゆるものはムダ
お客さん 開発側
要件
ソフトウェア
ソフトウェア開発?価値を付加しないあらゆるものはムダ
お客さん 開発側
要件
ソフトウェア
私の仕事★リーダー業★進捗管理、報告★タスクのアサイン★調整作業★要件、仕様の取りまとめ★基本設計
★開発★実装、テスト★各種ドキュメント作成
Q.どれがムダですか?★リーダー業★進捗管理、報告★タスクのアサイン★調整作業★要件、仕様の取りまとめ★基本設計
★開発★実装、テスト★各種ドキュメント作成
A.これがムダです★リーダー業★進捗管理、報告★タスクのアサイン★調整作業★要件、仕様の取りまとめ★基本設計
★開発★実装、テスト★各種ドキュメント作成
何故ムダ
どこにムダがあるのか★進捗管理、報告★タスクのアサイン★調整作業★要件、仕様の取りまとめ★基本設計
それぞれの視点★開発メンバー★開発リーダー★お客様
メンバーの場合★進捗管理、報告★タスクのアサイン★調整作業★要件、仕様の取りまとめ★基本設計
メンバーの悩み★要件のまとめに時間がかかる★要件がころころ変わる★仕様の確認が発生する
メンバーの悩み
★開発作業に着手できない★開発に手戻りが発生する
★要件のまとめに時間がかかる★要件がころころ変わる★仕様の確認が発生する
メンバーの悩み
★開発作業に着手できない時間★手戻りが消費した時間
★要件のまとめに時間がかかる★要件がころころ変わる★仕様の確認が発生する
ムダ
メンバーが感じるムダ★開発作業に遅れが発生する問題★過度な進捗管理で開発作業に支障がでる場合★タスクのアサインが適切でない場合★調整作業が難航している場合★基本設計がなかなか完了してない場合
リーダーの場合★進捗管理、報告★タスクのアサイン★調整作業★要件、仕様の取りまとめ★基本設計
リーダーの悩み★色々と素早く対応していくのは大変
★タスクは一杯ある★ 某岡島さんはチームビルディングも...
★お客様に納得してもらう事は特に難しい
リーダーの悩み★色々と素早く対応していくのは大変
★タスクは一杯ある★ 某岡島さんはチームビルディングも...
★お客様に納得してもらう事は特に難しい
★対応に予想より多く掛った時間ムダ
リーダーが感じるムダ★一人では上手く対応できない★タスクのアサインが上手くいかない場合★仕様の整理が上手く進まない場合★基本設計がなかなか完了しない場合
★上手く納得してもらえない★整理した要件を納得してもらえない場合★進捗の報告に時間が掛かる場合★調整作業が難航している場合
顧客の場合★進捗管理、報告★タスクのアサイン★調整作業★要件、仕様の取りまとめ★基本設計
顧客の悩み★ちゃんと予算に見合うシステムが出来るのか分からない
★進捗に遅れがあるんだけど★問題が発生した場合の解決に時間が掛かる
顧客の悩み★ちゃんと予算に見合うシステムが出来るのか分からない
★進捗に遅れがあるんだけど★問題が発生した場合の解決に時間が掛かる
★状況を納得するのに掛かる時間ムダ
顧客が感じるムダ★プロジェクトの状況を把握するのに時間が掛かる
★要件を整理したものに違和感がある場合★進捗に遅れがある場合の原因が不明な場合★問題の対応策が中途半端な場合
ムダの正体★開発作業の進捗に遅れが発生する問題★一人で上手く対応できない★上手く納得してもらえない★プロジェクトの状況を把握するのに時間が掛かる
お客さん 開発側
要件
ソフトウェア
ムダの正体★開発作業の進捗に遅れが発生する問題★一人で上手く対応できない★上手く納得してもらえない★プロジェクトの状況を把握するのに時間が掛かる
お客さん メンバー
要件
ソフトウェアリーダー
仕様タスク進捗
調整
ムダの正体★開発作業の進捗に遅れが発生する問題★一人で上手く対応できない★上手く納得してもらえない★プロジェクトの状況を把握するのに時間が掛かる
お客さん 開発側
要件
ソフトウェア
中まとめ★顧客に最も価値のあるものは、ソフトウェアです。
★間に色んな作業が必要なので、開発に100%注力できるわけではない
★開発以外の作業は価値を提供しない
注意点★開発以外の作業は不要だという事ではありません。
★お客さんは安心するために説明を求めています★タスクは適切に分割し誰かをアサインする必要がある★問題があった場合には何かしら調整する必要があります★要件は整理する必要があります★仕様は明確にする必要があります★設計せずにソフトウェアは作れません
どうしよう
スクラム
スクラム
重視している事★自己組織化★透明性★責任分担
重視している事★自己組織化★透明性★責任分担
私の仕事★進捗管理、報告★タスクのアサイン★調整作業★要件、仕様の取りまとめ★基本設計
上手くいってる実感メンバーに色んな作業を任せる事ができはじめると良い感じになってきたと感じます。例えば、設計の一部や仕様の調整をお願いできた時
任せる事ができると★他の作業に注力できます★要件の整理★タスクのアサイン★進捗管理★調整作業★仕様の調整★基本設計★開発に参加できます
全て任せてしまうと★他の作業にさらに注力できます★要件の整理★タスクのアサイン★進捗の管理、報告★調整作業★仕様の調整★基本設計★開発に貢献できます
私の仕事★進捗管理、報告★タスクのアサイン★調整作業★要件の取りまとめ
私の仕事★進捗管理、報告★タスクのアサイン★調整作業★要件の取りまとめ
バックログスクラムでは一定期間毎に開発する機能を合意しながら進めていきます。その期間内の全作業を洗い出して一覧にしたものをバックログといいます
バックログメンバーはバックログに挙げられているタスクをみんなで相談し、自分のやる作業を決定する仕様の調整、設計、開発も単なる作業です。
私の仕事★進捗管理、報告★タスクのアサイン★調整作業★要件の取りまとめ
Q.本当かよ?★そんなに色々と任せられるの?★メンバーが作業を決めれるの?★新人に設計とかムリだろ?★自分の作業を人にやってもらってるだけだから作業量は変わんないだろww
A.いきなりはムリ★例えば、1年間続けてみたら?★任せられる部分が増えないだろうか?★一度やったタスクは一年後も取れないだろうか?★設計は学習できないものだろうか?★僕が複数の機能を並行して担当するより、各メンバーが各機能を責任持って担当するのと一緒?
重視している事★自己組織化★透明性★責任分担
私の仕事★進捗管理、報告★調整作業★要件の取りまとめ
バックログスクラムでは二つのバックログを用意します。期間内の全作業一覧をスプリントバックログ。プロジェクト全体の要件を一覧にして管理するためのプロダクトバックログ
ミーティング各期間の最初に対応する要件を決定します。各期間の終了後に実装した機能をレビューする。遅れているか、次をどうするかの調整等はそれで行なわれる。
バックログどの作業が完了しているのか? どの要件まで実装が済んでいるのか一目瞭然です。進み具合の実績から今後のスケジュールもより正確になる
Q.本当かよ?★バックログは何で管理するの?★お客は作業一覧とか見ないだろ?★そんなに簡単に調整できるの?★何時間のミーティングやるつもりなのww
A.あとで説明する★あとで説明できるといいな★こういう話を2日間かけてやってきました。★ 1時間で話すのはムズカしいです...
重視している事★自己組織化★透明性★責任分担
私の仕事★進捗管理、報告★調整作業★要件の取りまとめ
悩んでいる事要件を整理する時には、開発側ではコントロールできない問題に直面する事が多いです。例えば、先方で要件の詳細をまとめる宿題が終らない...
悩んでいる事全部まとめてやろうとしているのが原因みたいです。重要な要件を提案して、優先してもらおうと提案すべきでしょうか?
Q.どれがが重要?★ウナギの養殖★ウサギの養殖★人工衛星の部品選定
決めれないのでは?お客さんの業務を理解するのは非常に重要ですが、最終的な判断は誰がやるべきしょうか?僕たちがやる事でムダな時間がかかっていませんか?
プロダクトオーナーバックログの優先度を最終的に決定する権利を持つ。また予算に見合う費用対効果を保証する責任を持つ。
POのお仕事★機能の特徴を定義する★リリースの内容と時期を決める★各期間の最初までに仕様や優先度を変更する
★各作業の成果に OK or NG を出す
バックログ要件が決定したものを優先度を高くする事により、作業に着手できない事故を防ぐ。逆に決定が遅れてるものを理解する助けになるかも
Q.本当かよ?★無理だろ??
A.あとで説明する★あとで説明できるといいな★こういう話を2日間かけてやってきました。★ 1時間で話すのはムズカしいです...
私の仕事★進捗管理、報告★調整作業★要件の取りまとめ
★開発にちゃんと貢献できます
重視している事★自己組織化★透明性★責任分担
★開発チームのパフォーマンスは向上していませんか?
中まとめ★やり方を工夫すると目的は変えずに間に発生する色んな作業は減らせます
★価値を最大化するためには開発チームのパフォーマンスを最大にする努力が必要です
注意点★効果が出るまでには時間がかかるかもしれません
★実は具体的なやり方は存在しません......
あとの部分★実は具体的なやり方は無いw★ Scrumは開発の進め方のフレームワーク★お客さん、自分の組織によって詳細な部分は違って当然★詳細な部分は自分たちで考えなさい
★ Scrumの導入に失敗するケースの多くは上辺だけやった場合★ 研修では一般的にはこうした方が良いとされるって話は一杯聞いてきた
どうするの?★無理だろ?★バックログは何で管理するの?★お客は作業一覧とか見ないだろ?★そんなに簡単に調整できるの?★何時間のミーティングやるつもりなのww
スクラムではこれらは問題です。作業を妨げる障害。放置しておけばどこかにムダが発生しています。
重視している事★自己組織化★透明性★責任分担★ムダを取り除き続ける
最初の一歩★プログラム以外のタスクをやってみる
★メンバーにタスクを任せてみる★お客さんと進捗の見せ方について話してみる
★仕様の決定が遅れている理由をちゃんと相談してみる等
ふりかえりチームの問題を考え、みんなで知恵を絞る大事な時間です。明日から何か一つは改善できているはずです。
スクラムマスター助けてくれる人がいます。進め方のアドバイスや問題の解決を支援します。外部の妨害からチームを守ります。リーダーと促進役です。
スクラムマスター★お客様と開発チームとの間の障害に対処します
★お客様にスクラムのメリットと目標の達成方法を教えます
★チームに仕事のやりがいを伝授★効率向上に貢献します★管理もしないし、権限もない
こんな体制
プロダクトオーナー
開発チーム
要件
ソフトウェア
スクラムマスター
支援 支援
最後にスクラムは一つのアプローチにしか過ぎません。ただし、メリットはあります。幸いな事に東京には4人もスクラムマスターがいます
Q.最後に★前期から改善できた点はどこでしょうか?
★競合他社がスクラムを採用してたら、永和のアピールポイントはどこなのでしょうか?
以上です。ご清聴ありがとうございました。もし質問等があれば、懇親会とかで気軽に声を掛けて下さい。
