Are you...

Are you ready?～これからアジャイル開発をスタートアップするためにプラクティスの実践と実感～

ツノダシュン / 池田暁

2016.7.30(土)

Agile Japan 2016 長崎サテライト with NaITE

http://nagasaki-it-engineers.connpass.com/event/32873/

Agile Japan 2016 Nagasaki satellite with NaITE

本資料についてのご注意

本資料は「Agile Japan 2016 長崎サテライト with

NaITE」で使用した発表資料を見直して公開用としたも

のです

•一部のスライドを落としています

•一部の構成を変更しています

•誤字脱字等を修正しています

•レポートも合わせてご参照いただくと当日の雰囲気も味わえますNaITE公式サイト「Agile Japan 2016 長崎サテライト with NaITE」開催レポート

http://naite.swquality.jp/?p=259

2016.7.30©NaITE

2



http://naite.swquality.jp/?p=259


自己紹介（ツノダシュン）

主な分野

•入社5年目、主に組込系ソフト開発

コミュニティなど

• NaITE（長崎ＩＴ技術者会）運営スタッフ

• WACATEの勉強会合宿などにも参加しています

•その他、分野を問わず様々な勉強会に参加し、スキルアップに励んでます

SNSなど

• Twitter @imtnd

アジャイルとの関わり

•過去にXP祭りに参加

•アジャイル開発の経験以降、アジャイル開発に興味を持つ

長崎との関わり

•人生初の来長崎です！

2016.7.30©NaITE

3



自己紹介（池田暁）

主な分野

•組込系開発とかテストとか管理とか

コミュニティなど

• NaITE（長崎ＩＴ技術者会）代表

• ASTER 理事、SQiP運営委員、AFFORDD 運営委員、日本品質管理学会会員、等

•テストに関する本とか記事とか書いています

SNSなど

• Twitter @ikedon0505

アジャイルとの関わり

•その昔XPJugに通ってました（最近ご無沙汰…）

• XP祭りのLTでジャグリングとかしてました

長崎との関わり

•長崎出身です！(^^

2016.7.30©NaITE

4



今日の話の目的

アジャイルプラク

ティスを導入/経

験して得た実感

や知見の共有

アジャイルプラク

ティスを1つでも

使ってもらうため

のきっかけ作り(

スタートアップ！)

2016.7.30©NaITE

5



本発表についてのご注意

書物に書かれたことや厳密な定義よりも、

やってみての実感を扱います

プロセスについての議論は扱いません

本発表内容は発表者の個人的見解によるものです

本資料に登場する会社名や製品名等は一般に

各社の商標です

2016.7.30©NaITE

6



アジャイル開発のおさらいさらりとおさらいしてみよう

2016.7.30©NaITE 7



アジャイル開発とは

• そのほか• 顧客や製品にとって本当に必要なもの（要素）を作る

• 期間とゴールを細かく設定し見通し、今見通せる期間で開発する

• コミュニケーションを重視する

・・・等様々に言われている

2016.7.30©NaITE

アジャイル開発

•アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。

8



ウォータフォール的な開発アジャイル的な開発

一度に走るか細かく走るか

2016.7.30©NaITE

9



ウォータフォール的な開発アジャイル的な開発

ビジネスは変化する

2016.7.30©NaITE

ビジネスが変化し目標が変わってしまった！

手戻り追従

10



アジャイル開発とは

ビジネスや開発の目標の変化に「柔軟に」「俊敏に」「臨機応変に」対応していくための開発のスタイル

ビジネスや目標の変化を前提として、使う技術や手法を選択し、またそれらすら変え続けてゆく

2016.7.30©NaITE

※注意本発表においてはこのように捉えることとします

11



アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

© 2001、上記の著者たち

この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。

2016.7.30©NaITE

Kent Beck James Grenning Robert C. Mart in

Mike Beedle Jim Highsmith Steve Mellor

Arie van Bennekum Andrew Hunt Ken Schwaber

Alistair Cockburn Ron Jeffries Jeff Sutherland

Ward Cunningham Jon Kern Dave Thomas

Mart in Fowler Brian Marick

これらに対応するために様々なプラクティスが

生み出されてきた

12



アジャイル開発におけるプラクティスプラクティスについて整理してみましょう

2016.7.30©NaITE 13



プラクティスとは

プラクティス

（大辞泉より）

練習。演習。実行。

プラクティス

（大辞林より）

① 何度も繰り返し

行う練習。訓練。

② 実際に行うこと。実行。

実践。「パターン-－」

2016.7.30©NaITE

14



プラクティスとは

ベストプラクティス（Wikipediaより）

•ベストプラクティス（英: best practice）は、ある結果を得るの

に最も効率のよい技法、手法、プロセス、活動などのこと。最善

慣行、最良慣行と訳されることもある。また、仕事を行うために最

も効率のよい技法、手法などがあるという考え方をいう。すなわち、

適切なプロセスを確立し、チェックと検証を行えば、問題の発生や

予期しない複雑さを低減させて、望ましい結果が得られると考え

る。ベストプラクティスは、多くの人々によって反復され、最も効率

的で最も効果的であることが時間をかけて証明されてきた。

2016.7.30©NaITE

15



アジャイルプラクティスとは

2016.7.30©NaITE

アジャイル開発の「柔軟に」「俊敏

に」「臨機応変に」に対応していくた

めの最も効率のよい「技法」、「手

法」、「プロセス」、「活動」などのことアジャイル開発に関わる開発者が実践を通じて蓄え、見いだし、発明し、まとめてきた、まさに生きたノウハウ

※ご注意アジャイルプラテクティスについては様々な解釈/定義があります。あくまで本発表での定義です。

16



プラクティス導入とっかかりにおけるよくあるつまずき

はじめてアジャイルプラクティスを試してみようと思ったときには何かとつまずきがあります

もっとも初期につまづく3点について紹介します

2016.7.30©NaITE 17



さて、アジャイルプラクティスにチャレンジしてみよう…

2016.7.30©NaITE

デイリーミーティング

Scrum

プロダクトオーナー

しかし、Webを調べても沢山のキーワードがありよくわからない…

18



アジャイル型開発におけるプラクティス活用事例調査

IPA/SECの部会で日本国内のアジャイル開発

実践者が中心となった国内におけるアジャイル開

発実践状況の調査が実施されている

アジャイル開発実践企業へのヒアリングなどによる

調査内容は、調査報告書や事例集、プラクティ

スのリファレンスガイドとしてまとめられている

2016.7.30©NaITE

アジャイル開発・プラクティスの解説資料としてもよくまとめられているため、手始めの読み物として大変有益（無償公開！）すぐに情報収集できるよう、こちらの報告書を参考に話を進めます

（ https://www.ipa.go.jp/sec/softwareengineering/reports/20130319.html ）

19


https://www.ipa.go.jp/sec/softwareengineering/reports/20130319.html



プラクティス導入検討時の悩み

どのようなものがあるかわからない

何を選んだら良いかわからない

実際に使った感想を聞きたい

2016.7.30©NaITE

20







2016.7.30©NaITE

21




2016.7.30©NaITE

まずはガイドを参照してみるのがおすすめ

出典「アジャイル型開発におけるプラクティス活用事例調査調査概要報告書」https://www.ipa.go.jp/sec/softwareengineering/reports/20130319.html

22





2016.7.30©NaITE


23





2016.7.30©NaITE


24





2016.7.30©NaITE


25








2016.7.30©NaITE

26



何を使ったら良いかわからない

• 例えば、XPやScrumなどの開発方法論で選ぶ

2016.7.30©NaITE

27





何を使ったら良いかわからない

2016.7.30©NaITE

28


• 例えば、すでに整理されたカテゴリから選ぶ








2016.7.30©NaITE

以前利用したプラクティスのいくつかについて実践した感想ベースで紹介します（比較的すぐに取り組めるもの）

29



プラクティスの実践と実感比較的すぐに取り組めるアジャイルプラクティスについて

簡単に概要や実感ベースでの良い点つまづきなどをご紹介します

2016.7.30©NaITE 30



今回ご紹介するプラクティス

2016.7.30©NaITE

31

プランニングポーカー

タスクかんばん

バーンダウンチャート

デイリースタンドアップ

テスト駆動開発

ペアプログラミング


プランニングポーカー

32

2016.7.30 ©NaITE


プランニングポーカーの概要

専用のカードを用いて見積もる

一人で作業の見積もりを行うのではなく、開発メンバ全

員で見積もりを行う

開発メンバの見積もりの値が開いていた場合は、話し

合いを行い見積もりの値を合わせていく

2016.7.30©NaITE

33



良かったこと

見積もり時の属人性の排除

見積もりを通して認識の共有が行える

開発メンバの平均スキルで見積もれる

開発メンバ全員が見積もり経験を積める

2016.7.30©NaITE

34



最初のつまづきと対応

プランニングポーカーを使用した見積もりの結果、見積も

りの値に差があった場合に他人の意見に流されがちにな

る

2016.7.30©NaITE

プランニングポーカーを行うことの目的として、開発メンバの認識のズレを修正することも含まれる。見積もり時にモヤモヤしている点は話し合いで潰しておこう。

35


タスクかんばん

36

2016.7.30 ©NaITE


タスクかんばんの概要

付箋紙にチームのやるべきタスクを書き出す

タスクをTODO、DOING、DONEに分けて可視化する

2016.7.30©NaITE

TODO 担当者 DOING DONE

タスク４

タスク５

タスク６

タスク７

タスク８

タスク９

タスク１０

タスク１

タスク２

タスク３

A

B

C

37



良かったこと

2016.7.30©NaITE

38

誰が何の作業をしているのか全員が一目で分かる

残タスク、終了タスクが分かりやすい

アラートを挙げなくても困っていそうなときは周りが分かる例：タスクがDOINGから長期間動かない

→ 問題が発生している可能性がある事が一目で分かる




プロジェクトが進むと小さなタスクが発生するが、簡単なタスクは

カンバンを作成するのも面倒くさくなり、どの程度のタスクからか

んばんにすべきか難しい

プロジェクトが終盤になると、忙しくなってくるため、かんばんが移

動されないことがある

2016.7.30©NaITE

カンバンを作成しないと、振り返りも行えず、そのタスクがあったことも開発メンバに周知されない。最初はどんなタスクもかんばんにしておくと良い。自分が何をしたのかのエビデンスにもなる。

39


バーンダウンチャート

40

2016.7.30 ©NaITE


バーンダウンチャートの概要

終了タスクをグラフ化する縦軸：タスク量

横軸：作業開始日から終了日までの日付

タスク数から終了日まで一直線に引いた

線が予定となる

進捗率、予定と実績の差分が可視化さ

れる2016.7.30©NaITE

41



良かったこと

一目で現在の進捗が把握できる

チームとしての作業遅延がメンバ全員に分かる

いつ、どのタスクが原因で作業が遅れ始めたの

かという事が分かりやすく可視化される

進捗状態に嘘がなくなる

2016.7.30©NaITE

42




2016.7.30©NaITE

特につまづくことはなかったため積極的に使っていくと良い（ただ、強いて言えば、壁の確保に苦労することもあるかもしれない）

43


デイリースタンドアップ

44

2016.7.30 ©NaITE


デイリースタンドアップの概要

決まった時間に全員参加でミーティングを開く

全員で立って行う

時間は１５分程度で「昨日やったこと」、「今日やること」、「共有しておく

べき情報」を話す

簡単に結論の出ない議題が出たら、別途話し合いの時間を設ける

2016.7.30©NaITE

45



良かったこと

進捗と、今日何やるかが毎日共有される

問題点が発生した場合は毎日共有される

全員が立ったままミーティングを行うことで話し合いが長くならない

話が長くなりそうな時は別途機会を設けることで、決めるべき結論をミー

ティング参加者で共有できた会議が開ける

2016.7.30©NaITE

46




朝イチに実施すると、フレックスで人が揃わないことがある

ずるずると長引いてしまうことがある

2016.7.30©NaITE

朝は人数がそろわないことがあるため、お昼休み15分前からの実施とすることとした。

お昼休み15分前からとすることで、チャイムがなったら強制的にミーティングは打ち切る。話し足りない場合は、午後一から気分転換して

話し合いをする。

47


テスト駆動開発

48

2016.7.30 ©NaITE


テスト駆動開発の概要

達成すべきテストコードを記述し、それを達成するソー

スコードを作成する

テストコードが達成されたら、成果物のソースコードを見

直す

修正を入れた後にも、最初に作成したテストコードが

NGとならないことを確認する

2016.7.30©NaITE

49



良かったこと

作成すべきものが明確になる

作成物コードを書いた後、すぐにどう動作するのかの

フィードバッグが得られる(安心感)

リファクタリングをプロセスに組み込む事で、綺麗なソース

コードが残る

2016.7.30©NaITE

50




テストを先に書くと決めても、実際にはなかなか難しい

テスト先に書くより、プログラミングを先に始めたくなる

2016.7.30©NaITE

テストが書けないということは、作成する対象物が明確になっていない可能性がある。仕様を明確にしてからプログラミングしよう。

51




経歴、年齢バラバラな開発メンバで、ペアプログラミングは抵抗

感がある

2016.7.30©NaITE

経歴、年齢がバラバラでも、気軽に意見を言い合える空気作りから始めよう。ペアプログラミングが向いているのかどうかは、プロジェクトメンバの関係性次第。

55




最初は１時間区切りで、ペアの役割を交代、または、ペアの組

み換えと決めていたが、タスクの進捗上難しかった

2016.7.30©NaITE

ペアを流動的にすることは必要だが、作業を無理やり中断するのは難しく、引き継ぎ作業が発生してしまう。そのため、役割交代、ペアの組み換えの基準は現場により話し合って決めよう。

56



プラクティスを実践しての実感

個人で仕事をするという認識を捨て、チームで仕事をしているという認識を

持つことが必要だと感じた

今までの仕事のスタイルを変え、人間的に積極性などが必要だと感じた

プラクティスはそのまま導入するのではなく、組織にあった方法を検討してい

くことが大切

2016.7.30©NaITE

はじめたときは何かと戸惑いもあったが、終わってみたら、やってみて良かったと実感している

58



コツ・注意点（その１）事前調査

アジャイル開発に関する専門のイベントに参加し、正確な情報の

入手と実践者の声を聞いておいた方がよい

•国内ではアジャイル開発はイメージ先行の取り上げられ方がまだまだ多く、誤った

知識で取り組んでしまうかもしれない

•Agile Japan やXP祭りなどは最低一度は参加しておくほうがよい

•Agile Japan：http://www.agilejapan.org/

•XP祭り(Xpjug)：http://xpjug.com/

•勿論本日の場も活用していただければと思います

•Agile Japan 2016 長崎サテライト with NaITE：


2016.7.30©NaITE

60


http://www.agilejapan.org/

http://xpjug.com/



コツ・注意点（その２）開発環境

開発ツールの導入を必須とするプラクティスは、事前に開発ツールの評価や味見を

しておいた方がよい

• 例えば、xUNITやCIツールの導入にハマってしまった場合、本来やりたかった

開発が止まる

• 新興ツールなど、安定度を見誤ると、ツールのデバッグ作業が発生し、本来の

開発が止まる

• ベンダのツールなど、実は上位ライセンスが必要だったが購入費を工面できず、

プラクティスを導入できない

• サーバスペックなどは必ず、将来予測をして見積もっておくこと（処理能力がボ

トルネックとなり開発を止めてはならない）

2016.7.30©NaITE

61



コツ・注意点（その３）社内の開発規格との整合性

社内の開発規格がアジャイル開発スタイルを考慮していない

場合、開発規格との整合性を前もって考えておいた方がよい

• 現在の規格で定められている開発成果物（特にドキュメント）の作成もタ

スク化しておくと良い

• メトリクスの読み替えも事前に決めておく必要がある

• TDDを導入したときの単体テストバグ密度の考え方等

• アジャイル開発スタイルを考慮した開発規格を整備するのもよい

• ただし、経験無く整備するのは困難なので、外部のコンサルタントを入れ

るのがよい

2016.7.30©NaITE

62



コツ・注意点（その４）導入準備、教育

はじめは、スタンドアップミーティングなど、軽量で特に準備を必要とし

ないものから試すとよい

•準備が必要なものはそれだけ期間も人がかかり、大がかりになってしまう

•できればアジャイルコーチやアジャイルに詳しい人にチームに入ってもらったり、支援して

もらった方がよい。状況によっては外部のコンサルティングサービスやエンジニアリング

サービスの利用を検討した方がよい

•プラクティスを何でもかんでも導入しようとすると、結果的に開発プロセスが重くなり、ア

ジリティが損なわれる

•新しいことをやるということであるため、メンバの心理的障壁も考慮しておくことが大切

•現実的には事前の教育は必要、チームメンバによる勉強会を実施するのも良い

2016.7.30©NaITE

63



コツ・注意点（その５）スタイル・プロセス自体の継続的改善

アジャイル手法やプラクティスを導入しても、それが現状に

合っているかどうかはわからない

• メンバー構成やプロダクトの性質、その他の制約によっては、効果が出なかっ

たりマイナスの効果を出してしまうことがおきる

• スプリントミーティングやウィークリーレトロスペクティブにて、プロダクトだけでなく、

自分達の開発そのものについても振り返り、改善することが大切

• 自分たちの開発スタイルの見える化のための手段、例えばPFD（Process

Flow Diagram）などプロセス表現できる技術を持っておくと良いhttp://kohablog.cocolog-nifty.com/blog/pfd.html

2016.7.30©NaITE

64


http://kohablog.cocolog-nifty.com/blog/pfd.html


コツ・注意点（その６）テストやQA活動の考慮

プロのソフト開発である以上、品質保証のためのテストや品質保証その

ものは取り組む必要がある

• TDDやBDDだけでは不十分な場合がある

• バグを叩き出すためのテストは別途実施する必要があるかもしれない

• アクセプタンステストや（出荷品としての）品質保証テストは必要

• テストチームやＱＡ部門が別に存在している場合は協調関係や様々について合意を

取っておくこと

• 理想的にはテストエンジニアやQAエンジニアをチームに加えて、開発とテスト、QAを統合

してしまうのが良い

• ただし、開発技術にも精通しているテストエンジニアやQAエンジニアの確保は（国内

では）まだまだ難しい状況でもある（所謂SET等）

2016.7.30©NaITE

65



コツ・注意点（その７）その他考慮しておいたほうが良い事

発注元との契約形態

• 契約によっては納品の有無や責任限界等、契約時に合意し、かつ法に触れないようにする必

要がある（もちろん、自分たちが不利にならないためという理由もある）

OSSに関する輸出管理関係

• OSSはなんとなく使ってしまいがちだが、特に暗号技術については注意しておく必要がある

メンバーの脱退や離脱

• 少人数開発のケースが多いため、1人の離脱が致命的になることも少なからずある

プラクティス至上主義にならないこと

• プラクティスを導入することが目的になったり、それ以外を排除することは、開発を堅くしてしまう

2016.7.30©NaITE

などなど・・・

66



おわりに

アジャイル開発では、いかにアジャイルプラクティスを有効実践す

るかが成功の鍵です

まずは世の中の整理された情報を入手し、小さいことから、軽

快に、プラクティスを導入していくことをおすすめします

決してプラクティス導入自体が計画重視にならないように

アジャイル宣言を意識し、プラクティスをもまたアジャイルに導入

していくことが大切です

2016.7.30©NaITE

68


Are you ready?この発表が皆様のアジャイル開発導入の“Ready”にお役立ちできれば幸いです

是非Agility高い開発を手に入れてください！

ツノダシュン / 池田暁

2016.7.30

Agile Japan 2016 長崎サテライト with NaITE



参考リンク

• Agile Japan• 公式

• http://www.agilejapan.org/

• XPjug（日本XPユーザーグループ）• 公式

• http://xpjug.com/

• NaITE（長崎ＩＴ技術者会）• 公式

• http://naite.swquality.jp/

• Facebookページ• https://www.facebook.com/NagasakiITEngineers/

• Facebookの参加者交流用グループ• https://www.facebook.com/groups/Nagasaki.IT.Engineers/

• connpassのNaITEのグループ• http://nagasaki-it-engineers.connpass.com/

2016.7.30©NaITE

70


http://www.agilejapan.org/

http://xpjug.com/

http://naite.swquality.jp/

https://www.facebook.com/NagasakiITEngineers/

https://www.facebook.com/groups/Nagasaki.IT.Engineers/

http://nagasaki-it-engineers.connpass.com/

Are you...

Technology

Transcript of Are you...