【公開版】アジャイル開発とプロジェクト管理ツールの相性

Backlog World アジャイル開発と プロジェクト管理ツールの相性 ギルドワークス 中村 洋(@yohhatu) https://visualhunt.com/photo/215760/

自己紹介 ・中村 洋(よう) ・ギルドワークス ・エナジャイル ・現場コーチ/アジャイルコーチ ・認定スクラムマスター ・DevLOVE関西 ・@yohhatu http://about.me/yohhatu

• http://about.me/yohhatu

ギルドワークス ✔ 仮説検証型のサービス企画や開発、現場 改善する現場コーチなどでクライアントの 事業を推進する ✔ ミッションは「正しいものを正しくつく る」、価値は「越境」 ✔ 全国各地のエンジニア、デザイナー組 み、適時適チームを実現している

現場コーチとは？ https://visualhunt.com/f/photo/6320530955/0096f62955/

ミッション 「正しいものを正しくつくる」 現場を増やす

関わった現場 21社 https://visualhunt.com/photo/8648/

関わったチーム 42チーム https://visualhunt.com/photo/35879/

注意点 https://visualhunt.com/photo/172801/

注意点 ✔ ある特定の現場のことではないです ✔ 自分の体験や知見からの意見です ✔ スライドは後で公開します(たぶん)

今日の前提 https://visualhunt.com/photo/193910/

プロジェクト管理ツール ✔ このセッションでの「プロジェクト 管理ツール」はデジタルなITS(Issue Tracking System)を指す

プロジェクトの特性 ✔ 不確実性の高い領域 ✔ グループではなくチームで挑む ✔ “アジャイル"に進めるのが良さそう

“Agile”とは？ Copyright (c) 2014 Guild Works Inc. https://visualhunt.com/photo/127756/

“アジャイル(Agile)”とは？ 「素早い、身軽な、機敏な、頭の回転が速い」 という意味の形容詞

“アジャイル(Agile)”とは？ 「素早い、身軽な、機敏な、頭の回転が速い」 という意味の形容詞 他にも「活発な、いきいきとした」

アジャイル宣言の背後にある原則 http://agilemanifesto.org/iso/ja/principles.html

アジャイル宣言の 背後にある原則 ・顧客価値の最優先 ・動くソフトウェアが重要 ・変化に対応 ・持続可能なペース ・短い間隔でのリリース ・技術的卓越性 ・全員同席 ・シンプルさが本質 ・モチベーション ・自己組織的なチーム ・顔を合わせての対話 ・ふりかえりと改善

アジャイル宣言の背後にある原則 ・顧客満足を最優先し、価値のあるソフトウェア を早く継続的に提供します。 ・要求の変更はたとえ開発の後期であっても歓迎 します。変化を味方につけることによって、お客 様の競争力を引き上げます。 ・動くソフトウェアを、2-3週間から2-3ヶ月と いうできるだけ短い時間間隔でリリースします。

アジャイル宣言の背後にある原則 ・ビジネス側の人と開発者は、プロジェクトを通 して日々一緒に働かなければなりません。 ・意欲に満ちた人々を集めてプロジェクトを構成 します。環境と支援を与え仕事が無事終わるまで 彼らを信頼します。 ・情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。

アジャイル宣言の背後にある原則 ・動くソフトウェアこそが進捗の最も重要な尺度 です。 ・アジャイル･プロセスは持続可能な開発を促進 します。一定のペースを継続的に維持できるよう にしなければなりません。 ・技術的卓越性と優れた設計に対する不断の注意 が機敏さを高めます。

アジャイル宣言の背後にある原則 ・シンプルさ（ムダなく作れる量を最大限にする こと）が本質です。 ・最良のアーキテクチャ・要求・設計は、自己組 織的なチームから生み出されます。 ・チームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのや り方を最適に調整します。

アジャイルな開発のやり方 https://visualhunt.com/photo/43958/

代表的なアジャイルな開発のやり方 エクストリームプログラミング(XP) →エンジニアリング スクラム(Scrum) →チームやマネジメント リーンソフトウェア開発(Lean Software Development) →ムダ

“アジャイル”とは？ 自己組織化し協働しながら MovingTargetのような不確実な領域で 少しずつ進み、フィードバックを得て 価値を継続的に届けていく

リファレンス https://www.slideshare.net/papanda/ss-79465986

「アジャイル宣言の背後にある原 則」とプロジェクト管理ツール http://agilemanifesto.org/iso/ja/principles.html

アジャイル宣言の 背後にある原則 ・顧客価値の最優先 ・動くソフトウェアが重要 ・変化に対応 ・持続可能なペース ・短い間隔でのリリース ・技術的卓越性 ・全員同席 ・シンプルさが本質 ・モチベーション ・自己組織的なチーム ・顔を合わせての対話 ・ふりかえりと改善

変化に対応 https://visualhunt.com/photo/56878/

変化に対応 要求の変更はたとえ開発の後期であっても歓迎し ます。変化を味方につけることによって、お客様 の競争力を引き上げます。

変化に対応 要求の変更はたとえ開発の後期であっても歓迎し ます。変化を味方につけることによって、お客様 の競争力を引き上げます。 ✔ やってみてわかることがある(やってみないと わからないことがある) ✔ “作る”という視座ではなく、”作ったものがど う役立つか”という視座 ✔「以前こう言っていました」では変化を味方に つけることはできない

目的に忠誠を誓う Copyright (c) 2014 Guild Works Inc. https://visualhunt.com/photo/46996/

インセプションデッキ

インセプションデッキ プロジェクトの全体像(目的、その背景、方向性や優 先順位など)を伝えるためのドキュメント。 狙いは、異なる役割の人達の間でプロジェクトに対す る共通認識を作るため。

特徴 ・10個のタフクエスチョン ・関係者全員で ・1デッキ60〜90分 ・1回で終わりではない(叩き台) ・作っておわりでもない ・ふりかえり、リリース後に見直す ・常に見えるように

全員同席 https://visualhunt.com/f2/photo/37201321510/86358167bf/

全員同席 ビジネス側の人と開発者は、プロジェクトを通し て日々一緒に働かなければなりません。

全員同席 ビジネス側の人と開発者は、プロジェクトを通し て日々一緒に働かなければなりません。 ✔ お互いの得意技を活かして目的の実現に向かう のであり、どっちが上とかではない ✔ お互いのことを知ることで関係性が構築さ れ、チームとなっていく ✔ 物理的な距離や掛け持ちによる濃度の低下

タックマンモデル 形成期 Forming 混乱期 Storming 統一期 Norming 機能期 Performing お互いのこと 考え方や役割 共通認識がで チームが一体 を知らない などで衝突が きチームが安 となり目標達 関係性を築く 起きる 定していく 成に向かう

ドラッカー風 エクササイズ https://www.flickr.com/photos/sanchom/2963072255

ドラッカー風エクササイズ チームメンバー同士の 期待をすりあわせるために行う チームビルディングのプラクティス。 4つのタフな質問をメンバーで 話し合う。

4つの質問 1：自分は何が得意なのか？ 2：どういう風に仕事するか？ 3：大切に思う価値はなにか？ 4：メンバは自分にどんな成果を 期待していると思うか？

顔を合わせての対話 https://visualhunt.com/f2/photo/4175199668/503ba73321/

顔を合わせての対話 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。

顔を合わせての対話 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 ✔ 会話することで他にも色々な情報が入ってくる ✔ 見える化することで同じ情報をインプットにし て話し合う ✔ 推測で話すことはムダ ✔ 「チケットに書いているから見ておいてね」も ムダ

動くソフトウェアが重要 https://visualhunt.com/f2/photo/3936781785/53a797d3d5/

動くソフトウェアが重要 動くソフトウェアこそが進捗の最も重要な尺度で す。

動くソフトウェアが重要 動くソフトウェアこそが進捗の最も重要な尺度で す。 ✔ 動くもので状況を判断する ✔ 受入条件とそれを実現するための計画づくり ✔ 「チケットはだいたい終わっています」「一部 が終わって進捗80％です」は意味がない

ふりかえりと改善

ふりかえりと改善 チームがもっと効率を高めることができるかを定 期的に振り返り、それに基づいて自分たちのや り方を最適に調整します。

ふりかえりと改善 チームがもっと効率を高めることができるかを定 期的に振り返り、それに基づいて自分たちのや り方を最適に調整します。 ✔ 前提を置かないで、もっとうまくできるやり方 を実験していく ✔ 説明責任と改善責任 ✔ デジタルツールの制限を制約に置いてしまい、 最適なやり方にするのを妨げる

まとめ https://visualhunt.com/photo/128272/

伝えたいこと ✔ プロジェクト管理ツールを使うだけで 良い仕事ができるわけではない ✔ プロジェクト管理ツールを使うなら、 使いながら自分達の仕事のやり方を実験 する ✔ 時にはプロジェクト管理ツールを捨て る選択も必要

よい ”プロジェクトマネジメント”を https://www.flickr.com/photos/rishibando/4282630035 https://www.flickr.com/photos/kacey/14903219403