部品構造
- 大部品: アジャイルソフトウェア開発 RD:17 評価値:7
- 部品: アジャイルソフトウェア開発とは
- 部品: ジャストインタイム分析
- 大部品: カンバン RD:4 評価値:3
- 大部品: チームボード RD:1 評価値:1
- 部品: カンバンとは
- 部品: WIP制限
- 部品: ナンバーマルチタスクゲーム
- 大部品: テスト駆動開発 RD:2 評価値:2
- 部品: テスト駆動開発とは
- 部品: リファクタリング
- 大部品: モブプログラミング・ペアプログラミング RD:5 評価値:4
- 部品: モビング・ペアリング
- 部品: レビューコスト削減
- 部品: デグレード回避
- 部品: バス係数の改善
- 部品: フロー重視
- 大部品: アジャイルミーティング RD:3 評価値:3
- 部品: レトロスペクティブ
- 大部品: デイリースタンドアップミーティング RD:2 評価値:2
- 部品: デイリースタンドアップミーティングとは
- 部品: スクラムオブスクラム
- 大部品: プランニング・ポーカー RD:1 評価値:1
部品定義
部品: アジャイルソフトウェア開発とは
アジャイルソフトウェア開発とは、要件に適応するよう、短期間でソフトウェアを開発する技法の総称。
アジャイルとは、Agile、つまり「迅速な」「俊敏な」「機敏な」を意味する。
アジャイルソフトウェア開発と呼ばれる方式は、スクラムやエクストリーム・プログラミング、フィーチャー駆動開発、クリスタル・ファミリーなど、様々な手法が存在する。
アジャイルソフトウェア開発の多くはイテレーションと呼ばれる短い期間を単位に分けている。
一回のイテレーションはだいたい一週間から二週間、長くても四週間である。
一回のイテレーションの中で、ひとつあるいは少数の小さな機能だけについて、要件定義・設計・開発・テスト・リリースといったソフトウェアプロジェクトにあるのすべての工程をおこなう。
このイテレーションを何度も繰り返すことで開発を進めていく。
イテレーションが終わるたびに、残った機能の優先順位を見直し、まだ開発が必要か否かを検討する。
開発終了の目安はたとえば、当初予定した機能をすべて開発したとき、予定した期日が来たとき、予算を使い切ったときなどである。
アジャイルソフトウェア開発は、開発中に要件が頻繁に変わる場合でも、変更に応じて速やかに適応できるという利点がある。
部品: ジャストインタイム分析
アジャイルソフトウェア開発においては文書資料の作成よりも、実際に動く機能をすばやく作り、その機能の動きを実際に見たうえで、関係者同士で顔を合わせて話し合うことを重視する。
この関係者の中には当然、顧客も含まれる。
大量に文書があると、仕様変更時があった際、修正する文書が多くなり、文書資料間で整合性をとることも難しくなる。
また、どんなにがんばって事前に情報を集めても、その情報の多くは使われずに終わるかもしれない。
そのため、文書の作成・修正よりもプログラム開発に労力や時間を使うよう、このような方針となっている。
なお、アジャイルソフトウェア開発は文書資料をまったく作らないわけではなく、不要な労力を減らすため、文書資料の作成を必要最小限に抑えるという戦略である。
そのため、文書資料を作ることが作らないよりも適切な場合は文書資料を作成する。
言い換えると、必要なときに必要な分だけを分析し、資料を作成する。
そして、本当に必要になるまでは計画・分析・資料作成は先送りにする。
ここまですればいいという絶対的な基準はないため、プロジェクトやチームに応じた適切な規模で計画・分析・資料作成をおこなう。
余計な負担は開発の速度を下げることになるため、最初は小さく始め、必要に応じて分析や資料を増やすことが望ましい。
部品: チームボードとは
チームボードとは、やるべきことを忘れないようにするため、および作業の進捗状況を常に見えるようにするための工夫である。
チームボードを簡単に説明すると、インデックスカードや強粘着の付箋などにユーザーストーリーや作業内容を簡潔に書き、付箋の粘着力や画鋲・磁石などで壁やホワイトボード・コルクボード・スチレンボードなどに貼り付けるというものである。
電子的なシステムに計画や進捗状況がデータとして保存されていると、ナチュラルネットに接続できない知類は、パソコンやスマートフォンなどの電子機器を介さない限り、保存されたデータを確認することができない。
そのため、冷蔵庫が開いているときしか中のものを取り出せないことにたとえ、このような電子的に保存された情報を情報冷蔵庫と呼ぶこともある。
チームボードはチーム全員の席から見える位置にあるため、チームのおおまかな作業状況を常に把握することができる。
また、貼り付けたカードや付箋を手に取って話すことができる。
チームのメンバーが遠隔地で作業している場合は、チームボードの写真を適切な頻度で定期的に送ることで、同じ場所にいない場合でも進捗状況を把握できる。
定期的に写真をとることで、プロジェクトの作業内容を振り返す際、当時の作業進捗状況を確認することができる。
AI知類やサイボーグなど、ナチュラルネットに直接アクセスできる作業者が多い場合は、チームボードを電子的なシステムで構築してもよいが、ネットに直接アクセスできない者のため、大型モニターやプロジェクターなどで常時表示することが望ましい。
チームボードは、リリースボードとストーリーボードの二つに分けて運用される場合もある。
／＊／
リリースボードとは、プロジェクトの中でリリースが完了したユーザーストーリーと、未完了のユーザーストーリーを掲示したものである。
たとえば、ホワイトボートの左端に最初のイテレーションでリリースしたユーザーストーリーを縦に並べて貼り、その隣の列がその次のイテレーションにリリースしたユーザーストーリーを貼り、という具合に左から順に貼り付ける。
右側にまだリリースしていないユーザーストーリーを貼り、完了と未完了の間に、ホワイトボードマーカーやカラーテープなどで分かりやすいように線を引く。
どこまで仕事が終わり、どれだけの仕事が残っているかを見えるようにすることでプロジェクト全体の状況を把握することができる。
／＊／
ストーリーボードとは、今回のイテレーションで対応するユーザーストーリーを、未着手(ToDo)・作業中(Doing)・リリース完了(Done)の三つに分けて貼り付けたものである。
たとえば、ホワイトボートの左側に未着手のユーザーストーリーを貼り、右側に顧客の承認を得てリリースしたユーザーストーリーを貼る。
中央には作業中のユーザーストーリーを貼り、未着手と作業中の間、および作業中とリリース完了の間に、ホワイトボードマーカーやカラーテープなどで分かりやすいように線を引く。
ユーザーストーリーの作業規模に応じて付箋の大きさを変えたり、納期で付箋の端に記入するなどの工夫をおこなう場合もある。
また、新規機能追加や既存機能改修は黄、欠陥・不備・不具合の修正・対応は赤、リファクタリングは緑といったように、作業内容に応じて付箋の色を変える工夫をおこなうこともある。
この場合、機能追加と不具合改修の両方を対応するユーザーストーリーは、黄と赤のふたつの付箋やカードにユーザーストーリーを分けて管理すると分かりやすくなる。
／＊／
チームボードに付箋を用いる場合、付箋の外し方に注意が必要である。
付箋の接着面を上にしてホワイトボードに貼り付けている場合、下から上に勢いよくはがすと、付箋がカールして貼り付けにくくなる。
付箋のカールを防ぐためには、左から右に、あるいは右から左に、そっとはがす。
なお、付箋やカードが貼り付けにくくなったり、汚れて読みにくくなったりした場合は、新しい付箋やカードにユーザーストーリーを書き写して使うようにするとよい。
カードや付箋に作業内容を書く際、文字の大きさはチームボードから少し離れても楽に読めるくらいが望ましい。
部品: カンバンとは
カンバン(kanban)とは、見える化やWIP制限をおこなったストーリーボードのことである。
／＊／
カンバンにおいて、見える化とは、作業の状況を標示することで理解しやすくすることである。
複数名が一緒に働く際、多くの仮定や方針が暗黙的に存在する。
それらの仮定は、お互いに矛盾や行き違いがあることもある。
作業を形式化することで、作業担当者や利害関係者が意見交換をする助けとなる。
たとえば、作業担当者の顔写真を貼った磁石を付箋に貼ることで、誰が作業を担当しているかを分かりやすくすることができる。
また、ストーリーボードの作業中の列を分析・開発・テストなどに分けることで、現在そのユーザーストーリーがどこまで進んでいるかわかるようになる。
さらに、開発を開発待ち・開発中に細分化すれば次に開発するユーザーストーリーはなにかが分かりやすくなる。
あるいは、開発を開発中・開発完了に分ければ、次の工程(テスト)の担当者がどのユーザーストーリーをテストすればよいか分かりやすくなる。
このように作業の進捗を掲示すれば、開発中のユーザーストーリーを開発完了の列に移すための条件を話し合うきっかけになる。
作業担当者と利害関係者が話し合い、情報を共有、透明性を高めることでプロジェクトを円滑に進められるようになる。
不要な情報や情報過多は理解を難しくするため、避けるべきである。
／＊／
スクラムとカンバンの組み合わせた手法はスクラムバン(scrum-ban)と呼ばれる。
部品: WIP制限
WIP制限とは
WIPとは、work in progress(進行中の作業)、またはwork in process(加工中の作業)の略で、仕掛り作業や仕掛りとも呼ばれる。
カンバンにおいて、WIP制限とは、複数の作業を掛け持ちして作業効率が下がらないようにするため、同時におこなう作業の数を制限することである。
WIP制限には、チーム単位の制限・作業種別ごとの制限・作業担当者ごとの制限などに分けられる。
一回のイテレーションの中でチーム全体がいくつの作業をこなすのか、分析・開発・テストなど作業種別(カンバンの列)ごとにいくつの作業をこなすのか、個々の作業担当者がいくつの作業をこなすのかをそれぞれ制限することで、作業の効率を上げることができる。
ただし、WIPが多すぎると誰も担当していない作業が出てきてしまう。
WIPはなるべく少ないほうが望ましいが、WIPが少なすぎると作業をしていない者が出てしまう。
そのため、WIP制限は適切な数を設定する必要がある。
適切な数を見つける手段として、「チームの構成員数の1.5倍」「通常時の作業数の倍」などをいったん上限に定めてイテレーションを回し、問題がなければ適切な数になるまで2割ずつ上限を減らすといった方法が考えられる。
通常、チーム単位のWIP制限は1より大きくなる。
ただし、モブプログラミングで開発している場合、チーム単位のWIP制限は1になることもある。
WIP制限は厳密なルールではなく、設定したWIPの上限を超えてもよい。
ただし、いつもWIPの上限を超えているようなら、話し合う必要がある。
たとえば、作業担当者ごとのWIP制限をXさんが頻繁に超えている場合、Xさんは他の者でもできる作業を抱え込んでいるかもしれないため、どの作業なら他の者に任せられそうか話し合ったほうがよい。
チーム単位や作業種別に対するWIPの上限は、カンバンにホワイトボードマーカーなどでその数を数字で書くと分かりやすい。
あるいは、作業種別(列)ごとにWIPの数だけ四角の枠を書き、そこに付箋を貼り付けることで、あといくつまで作業を追加してもよいか示すこともできる。
また、ユーザーストーリーにカードを用いている場合は、作業種別(列)ごとのカードホルダーの数で示すこともできる。
作業担当者ごとの上限は、顔写真付き磁石の数で、誰がいくつまで作業を担当できるかが分かりやすくなる。
／＊／
仕事が作業の繰り返しにならないよう、お祝いのタイミングを作るためにもWIP制限は利用できる。
たとえば、完了(Done)の列にWIP制限を設定するというものがある。
完了(Done)の列の作業がWIPの上限に達した場合、顧客や利用者などの利害関係者が開発チームへお礼を述べ、ケーキを渡すまで作業をしないというルールである。
開発チームが楽しめて就業時間内に食べたり飲んだりできるものであれば、ケーキ以外のものでもよい。
部品: ナンバーマルチタスクゲーム
ナンバーマルチタスクゲームとは、WIPを減らすとどのような価値をもたらすかを理解するためのゲームである。
ナンバーマルチタスクゲームは、ひとりでも多人数でもできるゲームである。
まずプレイヤーごとに、ストップウォッチ、三色のペンと二枚の紙を用意する。
三色のペンは、たとえば黒ペン・赤ペン・青ペンである。
プレイヤーには、以下の三つの作業を依頼する。
ひとつ目の作業は、漢数字の一から十までを上から下に向かって黒ペンで書く。
ふたつ目の作業は、漢数字の隣に、アルファベットのAからJまでを上から下に向かって赤ペンで書く。
みっつ目の作業は、アルファベットの隣に、アラビア数字の1から10までを上から下に向かって青ペンで書く。
プレイヤーには、三つの作業はどれも等しく重要で、最優先で対応しなければならないため、三つの作業は一枚目の紙に横方向に一行ずつ進めるよう指示する。
たとえば、一行書いた時点では「一A1」、二行書いた時点では二行目は「二B2」となる。
ゲームの管理者は、プレイヤーがそれぞれの作業を終えるまでの時間と、すべての作業を終えるまでの時間をストップウォッチで計測する。
すべての作業を終わったら、各作業の所要時間を紙やホワイトボードに書き込む。
次に、プレイヤーへもっとも重要な作業は漢数字を書く作業で、次がアルファベット、最後がアラビア数字であると伝える。
つまり、漢数字をすべて書き終えてから、アルファベットにとりかかり、アルファベットをすべて書き終えてから、アラビア数字を書くという手順である。
この手順で、二枚目の紙に書いてもらい、一枚目の紙のときと同様に時間を計測し、各作業の所要時間を紙やホワイトボードに書き込む。
一枚目の紙に書いたときと比べ、二枚目の紙に書いたときのほうが各作業の所要時間が大幅に短縮されているはずである。
ゲームの管理者はプレイヤーへゲームに協力してくれたことについて感謝を伝え、なぜ作業の所要時間が減ったのか、このことが実際の仕事にどのように当てはめられるのかなどについて話し合う。
部品: テスト駆動開発とは
テスト駆動開発(test-driven development)とは、多くのアジャイルソフトウェア開発において推奨されているプログラム開発の手法のひとつである。
テスト駆動開発は、TDDとも呼ばれる。
テスト駆動開発は、プログラミングにともなう様々な複雑さと向き合うための設計手法である。
たとえば、クラスベースのオブジェクト指向プログラミングでメソッドを宣言する場合、たった1行のコードでも、どのクラスのメソッドにするべきか、メソッドや仮引数の適切な名前、そのメソッドがpublicなのかprotectedなのかprivateなのかといったメソッドの可視性、引数や戻り値の適切な型など、それぞれどのように設計すべきか判断しなければならない。
1行でこれだけたくさんのことを考えなければならないため、プログラム全体でどこか見落としがあってもおかしくはない。
テスト駆動開発は、このような複雑さに立ち向かうため、一度に相手するテストをひとつだけに絞って、同時に考えるべきことを減らす手法である。
／＊／
テスト駆動開発は、テストファーストでおこなわれる。
テストファーストとは、プログラムをコーディングする前に、そのプログラムをテストを作るすることである。
プログラムより先にテストを作ることは、すでに実装されたコードがあると考えながら、テストを作ることである。
そのため、仕様の理解があいまいなまま、行き当たりばったりにコーディングすることを防ぐことができる。
また、不具合を修正する際、テストを先に作ることで、不具合の本質をどのように理解していたか示すことができる。
テストを作ったら、作ったテストが現行のプログラムで失敗することを確認する。
まだプログラムに存在しないクラスや関数に対するテストの場合、テストできるようクラスや関数を宣言するなど、必要な最小限のコードを追加する。
もし、作ったテストが現行のプログラムで成功するようなら、テスト自体の不備が考えられるため、失敗するまでテストを修正する。
テストが失敗することを確認したら、テストに合格するプログラムをなるべく早く作る。
この際、テストに合格するためなら、洗練されたコードになっていなくてもよい。
テストに合格することを確認したら、リファクタリングをおこなう。
リファクタリングが難しい場合、別のテストケースを追加し、それらのテストケースを合格するプログラムの共通点を見つけ出すことで、リファクタリングすべき箇所の指標とする。
テスト駆動開発ではテストを頻繁におこなうため、手動操作ではなく、自動でテストおこなうテスト用のプログラムを用意することが前提である。
なお、テスト駆動開発で作られるテストは、あくまでプログラム開発の過程で生まれる副産物である。
開発したソフトウェアの品質を検証するには充分でない場合があるため、テストの工程では確認の足りない箇所を検証するテストを追加したほうがよい。
部品: リファクタリング
リファクタリング(refactoring)とは、外から見たプログラムの動作を変えずに、ソースコードの内部構造を読みやすく、修正しやすいよう整理することである。
ソースコードは読みやすいと、そのコードがなにをしているのか理解するために必要な時間が短くなる。
ソースコードが整理されていない場合、修正に時間がかかり、修正による意図せぬ不具合も起きやすい。
ソースコードの整理とは、たとえば、似たような処理を関数やメソッドでひとつにまとめることである。
似たような処理が複数の箇所に分散して書かれていた場合、その処理の修正も複数の箇所でおこなうため、修正し忘れる恐れがある。
処理が一箇所にまとまっていれば、そこだけを修正すれば済むため、修正の不備は起きにくくなる。
逆にひとつの関数の中で処理の場合分けが複雑な場合は、複数の関数に分けることで関数内での場合分けを減らし、コードをわかりやすくすることができる。
マジックナンバー(magic number)やマジックストリング(magic string)など、ソースコード上に直接記述された数値や文字列を定数や列挙型に置き換えることもリファクタリングである。
また、関数や変数・定数などの名称を、内容にあったわかりやすい名前へ変更することもリファクタリングである。
なお、リファクタリングは意図通りに動くコードに手を加えるため、適切なテストで修正の前と後で意図せず動きが変わっていないか検証する必要がある。
部品: モビング・ペアリング
モブプログラミング(mob programming)とは、モビング(mobbing)とも呼ばれる、ソフトウェア開発の手法のひとつ。
通常のソフトウェア開発では、作業者ごとに映像表示端末・入力機器・パーソナルコンピュータ(またはワークステーション)を一台ずつ(あるいはそれ以上)使う。
モブプログラミングでは、チーム全員で一台の端末を共有する。
なお、映像表示端末とは液晶ディスプレイ・液晶プロジェクタ・有機ELディスプレイなど、入力機器とはキーボードやマウスなどのことである。
モブプログラミングでチームの作業者は、ドライバーとナビゲーターに役割が分かれる。
ドライバーはソースコードを入力するタイピストで、ナビゲーターの指示や提案に従って作業する。
ドライバーは指示の内容が理解できない場合、理解できるまでナビゲーターに質問する。
入力機器は一名分しかないため、必然的にチーム内のドライバーは一名となる。
ドライバーは自分で勝手に考えてソースコードを作ってはならず、自分の考えをコードに盛り込みたい場合は他の作業者にドライバーをやってもらい、ナビゲーターとしてどう実装するかを伝える形になる。
またドライバーの集中力が続くよう、一定時間経過でドライバーの役割を交代する規則を採用する場合もある。
必ず他者を通してソースコードが入力されるため、説明を通じてチーム全員が設計やコードを理解することができる。
なお、ドライバーとナビゲーターという名前は、参加者の役割を車の運転にたとえたものである。
ナビゲーターが複数名いることに違和感をおぼえる場合、ドライバーをタイピスト、ナビゲーターを「その他のモブ」と呼ぶ場合もある。
モブプログラミングの欠点として必ず話し合いがおこなわれるため、議論が盛り上がって作業が進まない場合がある。
そのため、モブプログラミングをおこなう場合、ファシリテーターを用意したり、議論のルールを決めたりするなど、円滑に議論をおこなうための手立てを用意したほうがよい。
チーム内でお互いに安心して、直接はっきりと意見を言い合える文化を育てることも重要である。
第三者がモブプログラミングを見た場合、チームで作業をしているのは一名だけで、他の者は作業していないように見える場合がある。
そのため、チームの上司や顧客など、開発関係者にモブプログラミングの概念や利点を説明する必要がある。
参加者全員がよく知らない技術をあつかう場合や、なにをすれば分からない場合は、目の前の課題について理解を深めるため、個々の参加者にそれぞれの考えを掘り下げる時間を与えたほうがよい。
なお、モブプログラミングの参加者が育児・介護・健康上の理由などから出勤できない場合、テレビ電話やチャットなどで遠隔地からモブプログラミングに参加するリモートモビングという手法がある。
／＊／
モブプログラミングでチームが二名の場合、つまり二名一組でひとつのキーボードを使い、ひとつの作業を遂行することをペアプログラミング(pair programming)と呼ぶ。
ペアプラミングはペアリング(pairing)とも呼ばれる。
ペアプログラミングはテスト駆動開発で利用されている。
ペアプログラミングには、ピンポンペアプログラミングやマイクロペアリングなどの手法がある。
／＊／
ピンポンペアプログラミング(ping-pong pair programming)とは、二名一組がひとつのキーボードで作業するテスト駆動開発である。
たとえば、XとYの二名の開発者がピンポンペアプログラミングをおこなう場合、Xが失敗するテストを作り、Yがテスト成功に必要最小限のコードを実装する。
このやりとりを課題が終わるまで繰り返すものがピンポンペアプログラミングである。
なお、上記の場合、リファクタリングはYがおこなう。
ピンポンペアプログラミングはペアプログラミングピンポン(pair programming ping-pong)とも呼ばれている。
／＊／
マイクロペアリング(micro pairing)とは、ピンポンペアプログラミングと同様に、二名一組がひとつのキーボードで作業するテスト駆動開発である。
ピンポンペアプログラミングでは、テストを作る者と、目的のプログラムをコーディングする者の役割が固定されている。
それに対し、マイクロペアリングでは役割が固定されていない。
たとえば、XとYの二名の開発者がマイクロペアリングをおこなう場合、Xは失敗するテストか成功するテストを作る。
Xが失敗するテストを作った場合、Yはテスト成功に必要最小限のコードを実装する。
Xが成功するテストを作った場合、Yはコードをリファクタリングするか、失敗するテストを作る。
Yが失敗するテストを作った場合、今度はXがテスト成功に必要最小限のコードを実装する。
このやりとりを課題が終わるまで繰り返すテスト駆動開発がマイクロペアリングである。
成功するテストを作る理由は、すでに実装されている動作や機能を分かりやすい記録として、テストの形で残すためである。
また、失敗するテストを作ったつもりが意図せず成功してしまった場合もある。
意図せず成功した場合は、テストが誤っているのか、実装が誤っているのかを検証する必要がある。
／＊／
ピンポンペアプログラミングやマイクロペアリングなどのペアプログラミングは、電話やメール、チャットなどの注意を逸らす活動を減らし、やるべき仕事に集中できる利点がある。
反面、ペアプログラミングはその集中ゆえに疲れる活動であり、特に二名の間で頻繁にキーボードが行き来するピンポンペアプログラミングやマイクロペアリングは消耗が激しい。
そのため、ペアプログラミングをおこなう時間は一日あたり6時間以下にすることが望ましい。
モブプログラミングやペアプログラミングで疲労を防ぐために適切な休憩の頻度は、25分から30分に1回とされている。
また、疲労を感じた作業者は、なるべく早くチームに伝えたほうがよい。
／＊／
モブプログラミングやペアプログラミングでは、チーム全員が快適に作業できるよう、作業環境を整えることが重要である。
チーム全員が画面を見られるよう、大型の映像表示端末を用意するか、同じ画面を表示する映像表示端末を複数台用意することが望ましい。
チーム全員が入れるだけの充分に広い部屋、考えを整理するためのホワイトボード、快適に作業をできるだけの性能を持つ端末、作業のしやすい高さと形状の机なども用意したほうがよい。
モブプログラミングのために新しい備品や機材を買う場合、不適切な備品を購入しないよう、購入予定の備品を数週間レンタルし、使い勝手を確認したほうがよい。
参加者が協調性や情緒が安定していることも重要なため、適切な者を選ぶことや、モブプログラミングに適した考え方を教育すること、参加者同士が互いを理解しあうためのグループセッションなども大切である。
参加者のモブプログラミングの経験が乏しい場合、チーム結成時の混乱を減らすため、チームを小規模にしたほうがよい。
モブプログラミングを始める以前から同じチームだった者同士だと、より混乱が少なくなる。
モブプログラミングの参加者を組織の外部から新規に雇用する場合、1日か2日給料を払い、フルタイムで参加してもらい、モブプログラミングの適性を確認したほうがよい。
／＊／
モブプログラミングは話し合いながら仕事を進めるため、ペアプログラミングや単独で仕事する場合に比べ、うるさくなる。
そのため、同じ部屋を他のチームと共同で使用する場合は、防音対策も重要である。
モブプログラミング専用に用意された部屋や場所をモビングエリアやモビングステーションなどと呼ばれる。
いつもモブプログラミングしているわけではない場合、モビングエリアは普段仕事をしている場所から近いほうがよい。
部品: レビューコスト削減
モブプログラミングの利点のひとつに、レビューコストの削減があげられる。
レビューには様々な種類があるが、ここではおおざっぱに「作った成果物が適切であるか、あいまいな点や問題点を検証する会議をおこなうこと」とする。
成果物とは、要件定義書や外部設計書・内部設計書といった各種仕様書やソースコードのことである。
レビューをおこなう場合、関係者を会議に集めるため、作業者の時間が拘束される。
また、レビューで使用する資料の作成といった、会議の準備にも時間が必要となる。
モブプログラミングでは、チーム全員でひとつの作業に取り組むため、実質的にチーム内で常にレビューをしている形となる。
モブプログラミングによって成果物の品質が向上するため、チーム内ではレビューを別途おこなう必要がなくなる。
部品: デグレード回避
モブプログラミングの利点のひとつに、デグレードを防ぎやすいことがあげられる。
作業者ごとに異なる作業をしている場合、同じソースファイルにそれぞれ異なる修正をすることが起きうる。
この場合、一方の修正で追加した機能や訂正した不具合が、もう一方の修正で消される恐れがある。
このように、新しいバージョンのほうが品質が劣化していることを、デグレード(degrade)やリグレッション(regression)、先祖返りなどと呼ぶ。
デグレードを防ぐためには、ふたつの修正の差異を比較し、どちらの修正も意図した動作が残るよう、対応する必要がある。
この作業をマージと呼ぶ。
また、先祖返りが起きていないか確認するためのテストも必要になる。
このテストは、回帰テストや退行テストと呼ばれる。
モブプログラミングでは、チーム全員でひとつの作業に取り組むため、マージが不要となり、また全員で設計やソースコードを確認しながら作業するため、デグレードも起きにくくなる。
部品: バス係数の改善
モブプログラミングの利点のひとつに、バス係数の改善があげられる。
バス係数(bus factor)とは、「プロジェクトの作業担当者が何名バスで轢かれたら(あるいは病欠・急用・離職などの理由で仕事に参加できなくなったら)、そのプロジェクトが破綻するか」という数値である。
たとえば、特定の技能に特化した専門家や業務知識に精通した作業者が一名しかいない場合、その一名がいなくなるとプロジェクトが破綻するため、バス係数は一になる。
ひとりで仕事をしていると、往々にして自分がしている仕事に熟練するため、時間とともに組織は熟練者への依存度が高くなる。
なぜなら未熟な者に仕事を頼むより、熟練者に頼むほうが短時間で仕事が終わり、失敗も少ないからである。
しかし、熟練者ひとりでは抱えきれないほどの作業が発生した場合、他の者は未熟であるため、プロジェクトが破綻してしまう。
モブプログラミングでは、チーム全員でひとつの作業に取り組むため、プロジェクトの情報がチーム内で共有される。
チームが担当している作業についてはチーム内の全員が有能になるため、一部の作業者が仕事を離れてもプロジェクトを継続することができる。
モブプログラミングを毎日おこなっていて、プロジェクトの情報が常に共有されている場合、実質的に常時チーム内のデイリースタンドアップミーティングをしていることになる。
そのため、そのような場合はチーム内のデイリースタンドアップミーティングも省くことができる。
部品: フロー重視
モブプログラミングの利点のひとつに、フロー効率の改善があげられる。
フロー効率とは、作業の流れのよさのことである。
作業者ごとに異なる作業をしている場合、他の作業者の作業待ちになることがある。
たとえば、プログラム開発で仕様を確認したいが、仕様を決めた者は別の仕事で不在だったり、テスト担当者がソフトウェアの不具合を見つけたが、開発者は他の作業をしていてすぐに修正できず、再テストができなかったりといった場合などがあげられる。
またソフトウェア開発は頭脳労働のため、作業者が複数の作業を兼任している場合、作業の切り替えに時間的コストが発生する。
たとえば、データベースにアクセスする言語とビジネスロジックを記述する言語が異なり、両方を同じ作業者が担当している場合、作業者はふたつのプログラミング言語の異なる構文を頭の中で切り替えたり、ソースコードを書くための開発環境を言語に合わせて切り替えたりする必要がある。
モブプログラミングでは、チーム全員でひとつの作業に専念するため、チーム内で完結する作業については、流れが滞ることなく、終わらせることができる。
開発途中の機能がいくらあっても、ソフトウェアの利用者はその機能を利用できない。
そのため、機能の追加・改善や不具合の修正を、ひとつひとつ確実にリリースするほうが、利用者にとって価値がある。
またリリースの期間が短くなると、利用者から改善や修正のフィードバックをすみやかに得られるため、利用者の意見を次の設計に反映することができる。
／＊／
モブプログラミングはチームの外から突然、割り込み作業が入った場合、フロー効率が大きく損なわれる問題がある。
そのため、当番兵を設けることがある。
モブプログラミングにおいて当番兵(batman)とは、突然の割り込みからチームを守るため、緩衝材となる要員である。
モブプログラミングのチームに対して質問や注文がある場合、当番兵が窓口となることで、チームの作業中断を防ぐことができる。
持ち回りで当番兵を担当する場合、誰が当番兵か判別しやすいよう、帽子や腕章などの目印があるとよい。
部品: レトロスペクティブ
アジャイルソフトウェア開発において、レトロスペクティブ(retrospective)とは、イテレーションやプロジェクトの終わりなど、仕事が一段落したタイミングで仕事のやり方を振り返る会議のことである。
レトロスペクティブは、振り返りやアジャイルレトロスペクティブ、チームレトロスペクティブ、反省会などとも呼ばれる。
レトロスペクティブの目的は、失敗の分析や反省ではなく、チーム関係や品質・生産性の改善である。
レトロスペクティブは誰かを糾弾する場ではないということを示すため、時間を割いてくれた参加者を歓迎し、会議の開始と終了に感謝を述べるとよい。
一回のレトロスペクティブにかける時間は、イテレーションやプロジェクトの長さによる。
振り返る時間が長いほど、一回のレトロスペクティブの時間は長くなる。
たとえば、一か月のイテレーションを振り返るなら、最低でも半日は必要である。
数か月のプロジェクトを振り返る場合は一日以上である。
また、失敗したプロジェクトは数日かける場合もある。
参加者の仕事の都合で長時間参加できない場合は、レトロスペクティブを円滑に行うため、整理した客観的データとともに、議題や目的など予定している内容をまとめ、事前に提示しておくと会議の時間を短縮できる。
レトロスペクティブで使われる枠組みにKPTがある。
KPTとは、続けること(keep)・問題点(problem)・試したいこと(try)の三つに分けて現状分析をおこなうというものである。
ホワイトボードを「今後も続けたいこと」「今後はやめること」「新しくやってみたいこと」の三つの領域に分け、各自がそれぞれに応じた内容を付箋に書き込んで貼り付けていく。
付箋がない場合はホワイトボードに直接記入してもよい。
出てきた案を複数同時に採用すると、うまくいかない場合があるため、対話や投票で、特に優先してやりたいものをひとつかふたつに絞るとうまくいきやすい。
／＊／
うまくいかないレトロスペクティブは、いくつかの類型がある。
そのひとつが、アイデア自慢大会である。
ここでいうアイデア自慢大会とは、前回のイテレーションやプロジェクトで起きたことを話し合わずに、提案だけ出すレトロスペクティブである。
課題と向き合っていないため、出てきた提案は課題を解決に役立つものではない恐れがある。
歴史の授業もうまくいかないレトロスペクティブの類型のひとつである。
ここでいう歴史の授業とは、前回のイテレーションやプロジェクトで何が問題だったか、どこを改善すべきかを調べるだけのレトロスペクティブである。
具体的な改善方法については話し合わないため、変化は個々の作業者任せとなってしまう。
不平不満を言い、責任をなすりつけあう、魔女狩りのようなレトロスペクティブも改善の役には立たない。
そのため、これらの問題が出た場合は、レトロスペクティブの実施方法を見直し、改善する必要がある。
部品: デイリースタンドアップミーティングとは
デイリースタンドアップミーティング(daily stand-up meeting)とは、重要な情報をチーム内ですばやく共有するための集まりである。
デイリースタンドアップミーティングは、デイリースタンドアップやスタンドアップ、デイリースクラムなどとも呼ばれている。
また、開催する時刻が朝の場合は朝会、昼の場合は昼会、夕方の場合は夕会と呼ばれることもある。
デイリースタンドアップミーティングは、チームによるチームのための会議で、正式な会議として開催しないため、議事録は作られない。
適切に実施されたデイリースタンドアップミーティングは、日々の成果をチーム全員が正しく認識し、目標に向かって一体となって進むために役立つものである。
／＊／
デイリースタンドアップミーティングは、決まった時刻に毎日開催される。
決まった時刻とは、たとえば出社時刻の15分後や30分後など、チームがミーティングをおこなうのに都合のよい時刻である。
福利厚生で自由に出社時間を選べる企業の場合、朝方の社員と夜型の社員がそれぞれ情報の同期をとれるよう、午前と午後に一回ずつデイリースタンドアップミーティングをおこなう場合もある。
また、デイリースタンドアップミーティングを二部構成でおこなう場合もある。
たとえば、顧客には理解が難しい技術的な専門用語で話し合う開発チーム内のミーティングが第一部、誰がどのユーザーストーリーを担当するのか開発チームから顧客チームに対するミーティングが第二部という形式である。
チームのメンバーが遠隔地で作業している場合は、テレビ会議でデイリースタンドアップミーティングをおこなうこともある。
／＊／
一回のデイリースタンドアップミーティングにかける時間は5分ほどで、長くても15分である。
ミーティングの時間を短くする工夫として、ミーティングで報告された問題やチーム全員に関わらない内容については、そのミーティングの中で深掘りせず、ミーティング後に話すこととしてホワイトボードや付箋などに書き留めておくことが挙げられる。
また、参加者全員が立ったままミーティングすることも、ミーティングの時間短縮の工夫のひとつである。
立つことで机の下で携帯電話を操作したり、落書きしたりといったことができなくなる。
さらに、長時間立ち続けると座りたくなるため、ミーティングが長引いたときに気づきやすい。
腰痛や妊娠など健康上の理由、および種族の身体的構造で立つことが困難な場合、無理に立たせる必要はないが、他の参加者がチームの一員であると感じられるよう、視線の高さを合わせるなどの工夫をしたほうがよい。
他の者が話している最中に割り込んだりしないよう、トーキングスティックを使うことも時間の短縮に役立つ。
／＊／
デイリースタンドアップミーティングで何について話すか、参加者が忘れないようにするため、あらかじめいくつかの質問項目をホワイトボードや付箋などに書いて掲示しておくとよい。
たとえば、「昨日は何をしたか。それは世界をどう変えたか」「今日は何をするか。それは世界をどう変えるか」「チームの開発速度を下げているものはあるか。何が邪魔しているか」など、そのチームにとって必要な質問である。
質問はチームの振る舞いを変えたり、新しいひらめきをもたらすような表現に変えてもよい。
／＊／
デイリースタンドアップミーティングに遅刻することは、作業の進捗状況や問題など、重要な情報をチーム内で共有することのさまたげとなる。
そのため、デイリースタンドアップミーティングで遅刻した者には、今後の遅刻を防ぐ目的で、罰金などの罰を与える。
罰は当事者自身が選ぶと時間を守る原動力となる。
たとえば、運動の苦手な者なら遅刻一回につき腕立て伏せ30回、コーヒーが好きな者なら遅刻した日はコーヒーを飲まないなどとすれば、時間を守りやすくなる。
遅刻することで、チームがどのように迷惑しているかを話すことも有効である。
頻繁に遅刻する者は遅刻のたび、ホワイトボードに記名し、遅刻の頻度を当事者自身が自覚できるようにするのも遅刻防止に効果的である。
／＊／
デイリースタンドアップミーティングが適切におこなわれているかどうかは、レトロスペクティブなどで、ミーティングの有効性をレビューし、必要に応じてミーティングの形式に変えるよい。
部品: スクラムオブスクラム
スクラムオブスクラム(scrum of scrum)とは、大規模なチームでデイリースタンドアップミーティングを短時間で終わらせるための工夫である。
たとえば、六十名のチームが一名当たり1分で順番に話した場合、それだけで一時間が必要になる。
そこでチームを少数名のサブチームに分け、それぞれのサブチームごとにデイリースタンドアップミーティングをおこなう。
その後、各サブチームの代表者が集まり、ミーティングをおこなうことでサブチーム同士を連携する。
この代表者が集まるミーティングをスクラムオブスクラムと呼ぶ。
たとえば、各六名のサブチームが一名当たり1分で話した場合、6分で終わる。
その後、サブチームの代表者十名が一名当たり1分で話せば10分となるため、六十名のチームでも計16分でミーティングを終えることができる。
スクラムオブスクラムは、ビッグデイリー(big daily)やデイリーシンク(daily sync)とも呼ばれる。
また、スクラムオブスクラムの内容のほとんどがデプロイとリリースに関するものの場合、リリースシンク(release sync)とも呼ばれる。
／＊／
スクラムオブスクラムは、スペシャリティ同期ミーティングとプロジェクト同期ミーティングの二回に分けておこなうこともある。
／＊／
スペシャリティ同期ミーティングとは、要求分析・開発・テストなどそれぞれの担当ごとに集まり、チームの垣根を越えてお互いの状況を話し合うミーティングである。
たとえば、要求分析の担当者だけが集まって開催するアナリスト同期ミーティング(requirements sync)や、テストの担当者だけが集まって開催するテスター同期ミーティング(test sync)などがある。
この場合、要求分析の担当者は、開発者からの質問に答え、要求を明確にするために、各開発チームにそれぞれ所属しているが、システムの全体像の分析に専念するため、開発チームに所属しない担当者もいる。
また、状況に応じて開発チームで要求分析したり、システムの全体像の分析をしたりと、そのときどきに応じて必要な役割を担う担当者もいる。
テストの担当者も同様に、各開発チームに所属し、機能レベルのソフトウェアテストやデバッグをおこなう者や、システム全体の概要レベルの結合テストやシステムテストに焦点を当てる者、両者の役割を必要に応じて柔軟に対応する者に分かれる。
これらの担当者ごとに最新の情報を持ち寄って話し合うことで、最新の状況を共有することができる。
プロジェクトマネージャはそれぞれのミーティングを見て回りながら、プロジェクトとして解決すべき問題がないか探す。
個別のミーティングに参加せず聞いているだけのこともあれば、プロジェクトマネージャが議論に混ざることもある。
／＊／
プロジェクト同期ミーティングは、スペシャリティ同期ミーティングの結果をふまえ、要求分析から本番リリースまでの、チーム間の仕事の流れに着目し、プロジェクト全体の視点から代表者が話し合うミーティングである。
プロジェクト同期ミーティングは、チーム間の協同に関する課題を解決する場としても機能する。
部品: プランニング・ポーカーとは
プランニング・ポーカーとは、作業工数を適切に見積もるための工夫である。
プランニング・ポーカーは、主にソフトウェア開発で使われる。
たとえば、一名の作業者が見積もると、その者が仕様をどの程度理解しているかによって、適切な工数よりも低く見積もられたり、高く見積もられたりする。
また、複数名で見積もりの会議をおこなうと、最初に発言した者や声の大きい者の意見に誘導されたり、専門外や作業担当ではないことを理由に見積もりの参加に消極的だったりすることがある。
プランニング・ポーカーは、こういった問題を防ぐための工夫である。
／＊／
プランニング・ポーカーの手順は以下のとおりである。
まず見積もりの参加者全員を実装するユーザーストーリーについて手短に説明し、要求仕様を理解するまでユーザーストーリーに関する質疑応答をおこなう。
充分に理解できたところで工数が書かれたカードを選び、参加者全員で一斉に公開する。
カードに書かれた工数の種類は、たとえば「S(小さい)」「M(中くらい)」「L(大きい)」「XL(とても大きい)」「∞(終わらない)」「？(わからない)」などが考えられる。
事前にカードを用意できない場合は、カードの代わりに、相手から見えないように紙や砂地などに工数を書いたり、指の立てた本数で工数を表したりしてもよい。
全員の出した工数がだいたい一致していれば、その工数が妥当と考えられるため、次のユーザーストーリーの工数を同様の手順で見積もる。
もし、出した工数が大きく異なるようなら、数分ほど時間をとり、他の者がなぜその工数を出したのか、それぞれに黙考してもらう。
その後、なぜその工数が適切と判断したか、参加者全員からそれぞれ理由や根拠を手短に述べてもらう。
たとえば、「以前のプロジェクトで作ったプログラムを流用できそう」や「テストが大変」などである。
そのうえで再度、参加者全員がカードを選び、公開する。
ここでも工数が大きく異なる場合は、このユーザーストーリーの工数見積もりを後回しにして、次のユーザーストーリーの工数を同様の手順で見積もる。
後回しにしたユーザーストーリーは、他の見積もりが終わったあとで、時間をかけて議論する。
休憩しやすくするため、「休(会議を中断して休憩しよう)」というカードを使う場合もある。
／＊／
プランニング・ポーカーの利点はいくつかある。
ひとつは、見積もりという孤独になりがちな作業をゲーム感覚で楽しくできることである。
また、参加者全員が自分の考えた工数を提示し、その理由を説明しなければならないから、工数を見積もるために充分な情報を得られるよう、参加者が積極的に質問するようになる。
こういった質疑応答や議論によって、有益な情報が集まりやすくなる。
たとえば「このユーザーストーリーは抽象的で分かりにくい」「テストがしにくい」「もっと単純なユーザーストーリーに分割しよう」といった意見である。
参加者全員に発言の機会が与えられるため、参加者同士で知識を共有し、お互いの観点や価値観を理解する助けにもなる。
提出書式
大部品: アジャイルソフトウェア開発 RD:17 評価値:7
-部品: アジャイルソフトウェア開発とは
-部品: ジャストインタイム分析
-大部品: カンバン RD:4 評価値:3
--大部品: チームボード RD:1 評価値:1
---部品: チームボードとは
--部品: カンバンとは
--部品: WIP制限
--部品: ナンバーマルチタスクゲーム
-大部品: テスト駆動開発 RD:2 評価値:2
--部品: テスト駆動開発とは
--部品: リファクタリング
-大部品: モブプログラミング・ペアプログラミング RD:5 評価値:4
--部品: モビング・ペアリング
--部品: レビューコスト削減
--部品: デグレード回避
--部品: バス係数の改善
--部品: フロー重視
-大部品: アジャイルミーティング RD:3 評価値:3
--部品: レトロスペクティブ
--大部品: デイリースタンドアップミーティング RD:2 評価値:2
---部品: デイリースタンドアップミーティングとは
---部品: スクラムオブスクラム
-大部品: プランニング・ポーカー RD:1 評価値:1
--部品: プランニング・ポーカーとは
部品: アジャイルソフトウェア開発とは
アジャイルソフトウェア開発とは、要件に適応するよう、短期間でソフトウェアを開発する技法の総称。
アジャイルとは、Agile、つまり「迅速な」「俊敏な」「機敏な」を意味する。
アジャイルソフトウェア開発と呼ばれる方式は、スクラムやエクストリーム・プログラミング、フィーチャー駆動開発、クリスタル・ファミリーなど、様々な手法が存在する。
アジャイルソフトウェア開発の多くはイテレーションと呼ばれる短い期間を単位に分けている。
一回のイテレーションはだいたい一週間から二週間、長くても四週間である。
一回のイテレーションの中で、ひとつあるいは少数の小さな機能だけについて、要件定義・設計・開発・テスト・リリースといったソフトウェアプロジェクトにあるのすべての工程をおこなう。
このイテレーションを何度も繰り返すことで開発を進めていく。
イテレーションが終わるたびに、残った機能の優先順位を見直し、まだ開発が必要か否かを検討する。
開発終了の目安はたとえば、当初予定した機能をすべて開発したとき、予定した期日が来たとき、予算を使い切ったときなどである。
アジャイルソフトウェア開発は、開発中に要件が頻繁に変わる場合でも、変更に応じて速やかに適応できるという利点がある。
部品: ジャストインタイム分析
アジャイルソフトウェア開発においては文書資料の作成よりも、実際に動く機能をすばやく作り、その機能の動きを実際に見たうえで、関係者同士で顔を合わせて話し合うことを重視する。
この関係者の中には当然、顧客も含まれる。
大量に文書があると、仕様変更時があった際、修正する文書が多くなり、文書資料間で整合性をとることも難しくなる。
また、どんなにがんばって事前に情報を集めても、その情報の多くは使われずに終わるかもしれない。
そのため、文書の作成・修正よりもプログラム開発に労力や時間を使うよう、このような方針となっている。
なお、アジャイルソフトウェア開発は文書資料をまったく作らないわけではなく、不要な労力を減らすため、文書資料の作成を必要最小限に抑えるという戦略である。
そのため、文書資料を作ることが作らないよりも適切な場合は文書資料を作成する。
言い換えると、必要なときに必要な分だけを分析し、資料を作成する。
そして、本当に必要になるまでは計画・分析・資料作成は先送りにする。
ここまですればいいという絶対的な基準はないため、プロジェクトやチームに応じた適切な規模で計画・分析・資料作成をおこなう。
余計な負担は開発の速度を下げることになるため、最初は小さく始め、必要に応じて分析や資料を増やすことが望ましい。
部品: チームボードとは
チームボードとは、やるべきことを忘れないようにするため、および作業の進捗状況を常に見えるようにするための工夫である。
チームボードを簡単に説明すると、インデックスカードや強粘着の付箋などにユーザーストーリーや作業内容を簡潔に書き、付箋の粘着力や画鋲・磁石などで壁やホワイトボード・コルクボード・スチレンボードなどに貼り付けるというものである。
電子的なシステムに計画や進捗状況がデータとして保存されていると、ナチュラルネットに接続できない知類は、パソコンやスマートフォンなどの電子機器を介さない限り、保存されたデータを確認することができない。
そのため、冷蔵庫が開いているときしか中のものを取り出せないことにたとえ、このような電子的に保存された情報を情報冷蔵庫と呼ぶこともある。
チームボードはチーム全員の席から見える位置にあるため、チームのおおまかな作業状況を常に把握することができる。
また、貼り付けたカードや付箋を手に取って話すことができる。
チームのメンバーが遠隔地で作業している場合は、チームボードの写真を適切な頻度で定期的に送ることで、同じ場所にいない場合でも進捗状況を把握できる。
定期的に写真をとることで、プロジェクトの作業内容を振り返す際、当時の作業進捗状況を確認することができる。
AI知類やサイボーグなど、ナチュラルネットに直接アクセスできる作業者が多い場合は、チームボードを電子的なシステムで構築してもよいが、ネットに直接アクセスできない者のため、大型モニターやプロジェクターなどで常時表示することが望ましい。
チームボードは、リリースボードとストーリーボードの二つに分けて運用される場合もある。
／＊／
リリースボードとは、プロジェクトの中でリリースが完了したユーザーストーリーと、未完了のユーザーストーリーを掲示したものである。
たとえば、ホワイトボートの左端に最初のイテレーションでリリースしたユーザーストーリーを縦に並べて貼り、その隣の列がその次のイテレーションにリリースしたユーザーストーリーを貼り、という具合に左から順に貼り付ける。
右側にまだリリースしていないユーザーストーリーを貼り、完了と未完了の間に、ホワイトボードマーカーやカラーテープなどで分かりやすいように線を引く。
どこまで仕事が終わり、どれだけの仕事が残っているかを見えるようにすることでプロジェクト全体の状況を把握することができる。
／＊／
ストーリーボードとは、今回のイテレーションで対応するユーザーストーリーを、未着手(ToDo)・作業中(Doing)・リリース完了(Done)の三つに分けて貼り付けたものである。
たとえば、ホワイトボートの左側に未着手のユーザーストーリーを貼り、右側に顧客の承認を得てリリースしたユーザーストーリーを貼る。
中央には作業中のユーザーストーリーを貼り、未着手と作業中の間、および作業中とリリース完了の間に、ホワイトボードマーカーやカラーテープなどで分かりやすいように線を引く。
ユーザーストーリーの作業規模に応じて付箋の大きさを変えたり、納期で付箋の端に記入するなどの工夫をおこなう場合もある。
また、新規機能追加や既存機能改修は黄、欠陥・不備・不具合の修正・対応は赤、リファクタリングは緑といったように、作業内容に応じて付箋の色を変える工夫をおこなうこともある。
この場合、機能追加と不具合改修の両方を対応するユーザーストーリーは、黄と赤のふたつの付箋やカードにユーザーストーリーを分けて管理すると分かりやすくなる。
／＊／
チームボードに付箋を用いる場合、付箋の外し方に注意が必要である。
付箋の接着面を上にしてホワイトボードに貼り付けている場合、下から上に勢いよくはがすと、付箋がカールして貼り付けにくくなる。
付箋のカールを防ぐためには、左から右に、あるいは右から左に、そっとはがす。
なお、付箋やカードが貼り付けにくくなったり、汚れて読みにくくなったりした場合は、新しい付箋やカードにユーザーストーリーを書き写して使うようにするとよい。
カードや付箋に作業内容を書く際、文字の大きさはチームボードから少し離れても楽に読めるくらいが望ましい。
部品: カンバンとは
カンバン(kanban)とは、見える化やWIP制限をおこなったストーリーボードのことである。
／＊／
カンバンにおいて、見える化とは、作業の状況を標示することで理解しやすくすることである。
複数名が一緒に働く際、多くの仮定や方針が暗黙的に存在する。
それらの仮定は、お互いに矛盾や行き違いがあることもある。
作業を形式化することで、作業担当者や利害関係者が意見交換をする助けとなる。
たとえば、作業担当者の顔写真を貼った磁石を付箋に貼ることで、誰が作業を担当しているかを分かりやすくすることができる。
また、ストーリーボードの作業中の列を分析・開発・テストなどに分けることで、現在そのユーザーストーリーがどこまで進んでいるかわかるようになる。
さらに、開発を開発待ち・開発中に細分化すれば次に開発するユーザーストーリーはなにかが分かりやすくなる。
あるいは、開発を開発中・開発完了に分ければ、次の工程(テスト)の担当者がどのユーザーストーリーをテストすればよいか分かりやすくなる。
このように作業の進捗を掲示すれば、開発中のユーザーストーリーを開発完了の列に移すための条件を話し合うきっかけになる。
作業担当者と利害関係者が話し合い、情報を共有、透明性を高めることでプロジェクトを円滑に進められるようになる。
不要な情報や情報過多は理解を難しくするため、避けるべきである。
／＊／
スクラムとカンバンの組み合わせた手法はスクラムバン(scrum-ban)と呼ばれる。
部品: WIP制限
WIP制限とは
WIPとは、work in progress(進行中の作業)、またはwork in process(加工中の作業)の略で、仕掛り作業や仕掛りとも呼ばれる。
カンバンにおいて、WIP制限とは、複数の作業を掛け持ちして作業効率が下がらないようにするため、同時におこなう作業の数を制限することである。
WIP制限には、チーム単位の制限・作業種別ごとの制限・作業担当者ごとの制限などに分けられる。
一回のイテレーションの中でチーム全体がいくつの作業をこなすのか、分析・開発・テストなど作業種別(カンバンの列)ごとにいくつの作業をこなすのか、個々の作業担当者がいくつの作業をこなすのかをそれぞれ制限することで、作業の効率を上げることができる。
ただし、WIPが多すぎると誰も担当していない作業が出てきてしまう。
WIPはなるべく少ないほうが望ましいが、WIPが少なすぎると作業をしていない者が出てしまう。
そのため、WIP制限は適切な数を設定する必要がある。
適切な数を見つける手段として、「チームの構成員数の1.5倍」「通常時の作業数の倍」などをいったん上限に定めてイテレーションを回し、問題がなければ適切な数になるまで2割ずつ上限を減らすといった方法が考えられる。
通常、チーム単位のWIP制限は1より大きくなる。
ただし、モブプログラミングで開発している場合、チーム単位のWIP制限は1になることもある。
WIP制限は厳密なルールではなく、設定したWIPの上限を超えてもよい。
ただし、いつもWIPの上限を超えているようなら、話し合う必要がある。
たとえば、作業担当者ごとのWIP制限をXさんが頻繁に超えている場合、Xさんは他の者でもできる作業を抱え込んでいるかもしれないため、どの作業なら他の者に任せられそうか話し合ったほうがよい。
チーム単位や作業種別に対するWIPの上限は、カンバンにホワイトボードマーカーなどでその数を数字で書くと分かりやすい。
あるいは、作業種別(列)ごとにWIPの数だけ四角の枠を書き、そこに付箋を貼り付けることで、あといくつまで作業を追加してもよいか示すこともできる。
また、ユーザーストーリーにカードを用いている場合は、作業種別(列)ごとのカードホルダーの数で示すこともできる。
作業担当者ごとの上限は、顔写真付き磁石の数で、誰がいくつまで作業を担当できるかが分かりやすくなる。
／＊／
仕事が作業の繰り返しにならないよう、お祝いのタイミングを作るためにもWIP制限は利用できる。
たとえば、完了(Done)の列にWIP制限を設定するというものがある。
完了(Done)の列の作業がWIPの上限に達した場合、顧客や利用者などの利害関係者が開発チームへお礼を述べ、ケーキを渡すまで作業をしないというルールである。
開発チームが楽しめて就業時間内に食べたり飲んだりできるものであれば、ケーキ以外のものでもよい。
部品: ナンバーマルチタスクゲーム
ナンバーマルチタスクゲームとは、WIPを減らすとどのような価値をもたらすかを理解するためのゲームである。
ナンバーマルチタスクゲームは、ひとりでも多人数でもできるゲームである。
まずプレイヤーごとに、ストップウォッチ、三色のペンと二枚の紙を用意する。
三色のペンは、たとえば黒ペン・赤ペン・青ペンである。
プレイヤーには、以下の三つの作業を依頼する。
ひとつ目の作業は、漢数字の一から十までを上から下に向かって黒ペンで書く。
ふたつ目の作業は、漢数字の隣に、アルファベットのAからJまでを上から下に向かって赤ペンで書く。
みっつ目の作業は、アルファベットの隣に、アラビア数字の1から10までを上から下に向かって青ペンで書く。
プレイヤーには、三つの作業はどれも等しく重要で、最優先で対応しなければならないため、三つの作業は一枚目の紙に横方向に一行ずつ進めるよう指示する。
たとえば、一行書いた時点では「一A1」、二行書いた時点では二行目は「二B2」となる。
ゲームの管理者は、プレイヤーがそれぞれの作業を終えるまでの時間と、すべての作業を終えるまでの時間をストップウォッチで計測する。
すべての作業を終わったら、各作業の所要時間を紙やホワイトボードに書き込む。
次に、プレイヤーへもっとも重要な作業は漢数字を書く作業で、次がアルファベット、最後がアラビア数字であると伝える。
つまり、漢数字をすべて書き終えてから、アルファベットにとりかかり、アルファベットをすべて書き終えてから、アラビア数字を書くという手順である。
この手順で、二枚目の紙に書いてもらい、一枚目の紙のときと同様に時間を計測し、各作業の所要時間を紙やホワイトボードに書き込む。
一枚目の紙に書いたときと比べ、二枚目の紙に書いたときのほうが各作業の所要時間が大幅に短縮されているはずである。
ゲームの管理者はプレイヤーへゲームに協力してくれたことについて感謝を伝え、なぜ作業の所要時間が減ったのか、このことが実際の仕事にどのように当てはめられるのかなどについて話し合う。
部品: テスト駆動開発とは
テスト駆動開発(test-driven development)とは、多くのアジャイルソフトウェア開発において推奨されているプログラム開発の手法のひとつである。
テスト駆動開発は、TDDとも呼ばれる。
テスト駆動開発は、プログラミングにともなう様々な複雑さと向き合うための設計手法である。
たとえば、クラスベースのオブジェクト指向プログラミングでメソッドを宣言する場合、たった1行のコードでも、どのクラスのメソッドにするべきか、メソッドや仮引数の適切な名前、そのメソッドがpublicなのかprotectedなのかprivateなのかといったメソッドの可視性、引数や戻り値の適切な型など、それぞれどのように設計すべきか判断しなければならない。
1行でこれだけたくさんのことを考えなければならないため、プログラム全体でどこか見落としがあってもおかしくはない。
テスト駆動開発は、このような複雑さに立ち向かうため、一度に相手するテストをひとつだけに絞って、同時に考えるべきことを減らす手法である。
／＊／
テスト駆動開発は、テストファーストでおこなわれる。
テストファーストとは、プログラムをコーディングする前に、そのプログラムをテストを作るすることである。
プログラムより先にテストを作ることは、すでに実装されたコードがあると考えながら、テストを作ることである。
そのため、仕様の理解があいまいなまま、行き当たりばったりにコーディングすることを防ぐことができる。
また、不具合を修正する際、テストを先に作ることで、不具合の本質をどのように理解していたか示すことができる。
テストを作ったら、作ったテストが現行のプログラムで失敗することを確認する。
まだプログラムに存在しないクラスや関数に対するテストの場合、テストできるようクラスや関数を宣言するなど、必要な最小限のコードを追加する。
もし、作ったテストが現行のプログラムで成功するようなら、テスト自体の不備が考えられるため、失敗するまでテストを修正する。
テストが失敗することを確認したら、テストに合格するプログラムをなるべく早く作る。
この際、テストに合格するためなら、洗練されたコードになっていなくてもよい。
テストに合格することを確認したら、リファクタリングをおこなう。
リファクタリングが難しい場合、別のテストケースを追加し、それらのテストケースを合格するプログラムの共通点を見つけ出すことで、リファクタリングすべき箇所の指標とする。
テスト駆動開発ではテストを頻繁におこなうため、手動操作ではなく、自動でテストおこなうテスト用のプログラムを用意することが前提である。
なお、テスト駆動開発で作られるテストは、あくまでプログラム開発の過程で生まれる副産物である。
開発したソフトウェアの品質を検証するには充分でない場合があるため、テストの工程では確認の足りない箇所を検証するテストを追加したほうがよい。
部品: リファクタリング
リファクタリング(refactoring)とは、外から見たプログラムの動作を変えずに、ソースコードの内部構造を読みやすく、修正しやすいよう整理することである。
ソースコードは読みやすいと、そのコードがなにをしているのか理解するために必要な時間が短くなる。
ソースコードが整理されていない場合、修正に時間がかかり、修正による意図せぬ不具合も起きやすい。
ソースコードの整理とは、たとえば、似たような処理を関数やメソッドでひとつにまとめることである。
似たような処理が複数の箇所に分散して書かれていた場合、その処理の修正も複数の箇所でおこなうため、修正し忘れる恐れがある。
処理が一箇所にまとまっていれば、そこだけを修正すれば済むため、修正の不備は起きにくくなる。
逆にひとつの関数の中で処理の場合分けが複雑な場合は、複数の関数に分けることで関数内での場合分けを減らし、コードをわかりやすくすることができる。
マジックナンバー(magic number)やマジックストリング(magic string)など、ソースコード上に直接記述された数値や文字列を定数や列挙型に置き換えることもリファクタリングである。
また、関数や変数・定数などの名称を、内容にあったわかりやすい名前へ変更することもリファクタリングである。
なお、リファクタリングは意図通りに動くコードに手を加えるため、適切なテストで修正の前と後で意図せず動きが変わっていないか検証する必要がある。
部品: モビング・ペアリング
モブプログラミング(mob programming)とは、モビング(mobbing)とも呼ばれる、ソフトウェア開発の手法のひとつ。
通常のソフトウェア開発では、作業者ごとに映像表示端末・入力機器・パーソナルコンピュータ(またはワークステーション)を一台ずつ(あるいはそれ以上)使う。
モブプログラミングでは、チーム全員で一台の端末を共有する。
なお、映像表示端末とは液晶ディスプレイ・液晶プロジェクタ・有機ELディスプレイなど、入力機器とはキーボードやマウスなどのことである。
モブプログラミングでチームの作業者は、ドライバーとナビゲーターに役割が分かれる。
ドライバーはソースコードを入力するタイピストで、ナビゲーターの指示や提案に従って作業する。
ドライバーは指示の内容が理解できない場合、理解できるまでナビゲーターに質問する。
入力機器は一名分しかないため、必然的にチーム内のドライバーは一名となる。
ドライバーは自分で勝手に考えてソースコードを作ってはならず、自分の考えをコードに盛り込みたい場合は他の作業者にドライバーをやってもらい、ナビゲーターとしてどう実装するかを伝える形になる。
またドライバーの集中力が続くよう、一定時間経過でドライバーの役割を交代する規則を採用する場合もある。
必ず他者を通してソースコードが入力されるため、説明を通じてチーム全員が設計やコードを理解することができる。
なお、ドライバーとナビゲーターという名前は、参加者の役割を車の運転にたとえたものである。
ナビゲーターが複数名いることに違和感をおぼえる場合、ドライバーをタイピスト、ナビゲーターを「その他のモブ」と呼ぶ場合もある。
モブプログラミングの欠点として必ず話し合いがおこなわれるため、議論が盛り上がって作業が進まない場合がある。
そのため、モブプログラミングをおこなう場合、ファシリテーターを用意したり、議論のルールを決めたりするなど、円滑に議論をおこなうための手立てを用意したほうがよい。
チーム内でお互いに安心して、直接はっきりと意見を言い合える文化を育てることも重要である。
第三者がモブプログラミングを見た場合、チームで作業をしているのは一名だけで、他の者は作業していないように見える場合がある。
そのため、チームの上司や顧客など、開発関係者にモブプログラミングの概念や利点を説明する必要がある。
参加者全員がよく知らない技術をあつかう場合や、なにをすれば分からない場合は、目の前の課題について理解を深めるため、個々の参加者にそれぞれの考えを掘り下げる時間を与えたほうがよい。
なお、モブプログラミングの参加者が育児・介護・健康上の理由などから出勤できない場合、テレビ電話やチャットなどで遠隔地からモブプログラミングに参加するリモートモビングという手法がある。
／＊／
モブプログラミングでチームが二名の場合、つまり二名一組でひとつのキーボードを使い、ひとつの作業を遂行することをペアプログラミング(pair programming)と呼ぶ。
ペアプラミングはペアリング(pairing)とも呼ばれる。
ペアプログラミングはテスト駆動開発で利用されている。
ペアプログラミングには、ピンポンペアプログラミングやマイクロペアリングなどの手法がある。
／＊／
ピンポンペアプログラミング(ping-pong pair programming)とは、二名一組がひとつのキーボードで作業するテスト駆動開発である。
たとえば、XとYの二名の開発者がピンポンペアプログラミングをおこなう場合、Xが失敗するテストを作り、Yがテスト成功に必要最小限のコードを実装する。
このやりとりを課題が終わるまで繰り返すものがピンポンペアプログラミングである。
なお、上記の場合、リファクタリングはYがおこなう。
ピンポンペアプログラミングはペアプログラミングピンポン(pair programming ping-pong)とも呼ばれている。
／＊／
マイクロペアリング(micro pairing)とは、ピンポンペアプログラミングと同様に、二名一組がひとつのキーボードで作業するテスト駆動開発である。
ピンポンペアプログラミングでは、テストを作る者と、目的のプログラムをコーディングする者の役割が固定されている。
それに対し、マイクロペアリングでは役割が固定されていない。
たとえば、XとYの二名の開発者がマイクロペアリングをおこなう場合、Xは失敗するテストか成功するテストを作る。
Xが失敗するテストを作った場合、Yはテスト成功に必要最小限のコードを実装する。
Xが成功するテストを作った場合、Yはコードをリファクタリングするか、失敗するテストを作る。
Yが失敗するテストを作った場合、今度はXがテスト成功に必要最小限のコードを実装する。
このやりとりを課題が終わるまで繰り返すテスト駆動開発がマイクロペアリングである。
成功するテストを作る理由は、すでに実装されている動作や機能を分かりやすい記録として、テストの形で残すためである。
また、失敗するテストを作ったつもりが意図せず成功してしまった場合もある。
意図せず成功した場合は、テストが誤っているのか、実装が誤っているのかを検証する必要がある。
／＊／
ピンポンペアプログラミングやマイクロペアリングなどのペアプログラミングは、電話やメール、チャットなどの注意を逸らす活動を減らし、やるべき仕事に集中できる利点がある。
反面、ペアプログラミングはその集中ゆえに疲れる活動であり、特に二名の間で頻繁にキーボードが行き来するピンポンペアプログラミングやマイクロペアリングは消耗が激しい。
そのため、ペアプログラミングをおこなう時間は一日あたり6時間以下にすることが望ましい。
モブプログラミングやペアプログラミングで疲労を防ぐために適切な休憩の頻度は、25分から30分に1回とされている。
また、疲労を感じた作業者は、なるべく早くチームに伝えたほうがよい。
／＊／
モブプログラミングやペアプログラミングでは、チーム全員が快適に作業できるよう、作業環境を整えることが重要である。
チーム全員が画面を見られるよう、大型の映像表示端末を用意するか、同じ画面を表示する映像表示端末を複数台用意することが望ましい。
チーム全員が入れるだけの充分に広い部屋、考えを整理するためのホワイトボード、快適に作業をできるだけの性能を持つ端末、作業のしやすい高さと形状の机なども用意したほうがよい。
モブプログラミングのために新しい備品や機材を買う場合、不適切な備品を購入しないよう、購入予定の備品を数週間レンタルし、使い勝手を確認したほうがよい。
参加者が協調性や情緒が安定していることも重要なため、適切な者を選ぶことや、モブプログラミングに適した考え方を教育すること、参加者同士が互いを理解しあうためのグループセッションなども大切である。
参加者のモブプログラミングの経験が乏しい場合、チーム結成時の混乱を減らすため、チームを小規模にしたほうがよい。
モブプログラミングを始める以前から同じチームだった者同士だと、より混乱が少なくなる。
モブプログラミングの参加者を組織の外部から新規に雇用する場合、1日か2日給料を払い、フルタイムで参加してもらい、モブプログラミングの適性を確認したほうがよい。
／＊／
モブプログラミングは話し合いながら仕事を進めるため、ペアプログラミングや単独で仕事する場合に比べ、うるさくなる。
そのため、同じ部屋を他のチームと共同で使用する場合は、防音対策も重要である。
モブプログラミング専用に用意された部屋や場所をモビングエリアやモビングステーションなどと呼ばれる。
いつもモブプログラミングしているわけではない場合、モビングエリアは普段仕事をしている場所から近いほうがよい。
部品: レビューコスト削減
モブプログラミングの利点のひとつに、レビューコストの削減があげられる。
レビューには様々な種類があるが、ここではおおざっぱに「作った成果物が適切であるか、あいまいな点や問題点を検証する会議をおこなうこと」とする。
成果物とは、要件定義書や外部設計書・内部設計書といった各種仕様書やソースコードのことである。
レビューをおこなう場合、関係者を会議に集めるため、作業者の時間が拘束される。
また、レビューで使用する資料の作成といった、会議の準備にも時間が必要となる。
モブプログラミングでは、チーム全員でひとつの作業に取り組むため、実質的にチーム内で常にレビューをしている形となる。
モブプログラミングによって成果物の品質が向上するため、チーム内ではレビューを別途おこなう必要がなくなる。
部品: デグレード回避
モブプログラミングの利点のひとつに、デグレードを防ぎやすいことがあげられる。
作業者ごとに異なる作業をしている場合、同じソースファイルにそれぞれ異なる修正をすることが起きうる。
この場合、一方の修正で追加した機能や訂正した不具合が、もう一方の修正で消される恐れがある。
このように、新しいバージョンのほうが品質が劣化していることを、デグレード(degrade)やリグレッション(regression)、先祖返りなどと呼ぶ。
デグレードを防ぐためには、ふたつの修正の差異を比較し、どちらの修正も意図した動作が残るよう、対応する必要がある。
この作業をマージと呼ぶ。
また、先祖返りが起きていないか確認するためのテストも必要になる。
このテストは、回帰テストや退行テストと呼ばれる。
モブプログラミングでは、チーム全員でひとつの作業に取り組むため、マージが不要となり、また全員で設計やソースコードを確認しながら作業するため、デグレードも起きにくくなる。
部品: バス係数の改善
モブプログラミングの利点のひとつに、バス係数の改善があげられる。
バス係数(bus factor)とは、「プロジェクトの作業担当者が何名バスで轢かれたら(あるいは病欠・急用・離職などの理由で仕事に参加できなくなったら)、そのプロジェクトが破綻するか」という数値である。
たとえば、特定の技能に特化した専門家や業務知識に精通した作業者が一名しかいない場合、その一名がいなくなるとプロジェクトが破綻するため、バス係数は一になる。
ひとりで仕事をしていると、往々にして自分がしている仕事に熟練するため、時間とともに組織は熟練者への依存度が高くなる。
なぜなら未熟な者に仕事を頼むより、熟練者に頼むほうが短時間で仕事が終わり、失敗も少ないからである。
しかし、熟練者ひとりでは抱えきれないほどの作業が発生した場合、他の者は未熟であるため、プロジェクトが破綻してしまう。
モブプログラミングでは、チーム全員でひとつの作業に取り組むため、プロジェクトの情報がチーム内で共有される。
チームが担当している作業についてはチーム内の全員が有能になるため、一部の作業者が仕事を離れてもプロジェクトを継続することができる。
モブプログラミングを毎日おこなっていて、プロジェクトの情報が常に共有されている場合、実質的に常時チーム内のデイリースタンドアップミーティングをしていることになる。
そのため、そのような場合はチーム内のデイリースタンドアップミーティングも省くことができる。
部品: フロー重視
モブプログラミングの利点のひとつに、フロー効率の改善があげられる。
フロー効率とは、作業の流れのよさのことである。
作業者ごとに異なる作業をしている場合、他の作業者の作業待ちになることがある。
たとえば、プログラム開発で仕様を確認したいが、仕様を決めた者は別の仕事で不在だったり、テスト担当者がソフトウェアの不具合を見つけたが、開発者は他の作業をしていてすぐに修正できず、再テストができなかったりといった場合などがあげられる。
またソフトウェア開発は頭脳労働のため、作業者が複数の作業を兼任している場合、作業の切り替えに時間的コストが発生する。
たとえば、データベースにアクセスする言語とビジネスロジックを記述する言語が異なり、両方を同じ作業者が担当している場合、作業者はふたつのプログラミング言語の異なる構文を頭の中で切り替えたり、ソースコードを書くための開発環境を言語に合わせて切り替えたりする必要がある。
モブプログラミングでは、チーム全員でひとつの作業に専念するため、チーム内で完結する作業については、流れが滞ることなく、終わらせることができる。
開発途中の機能がいくらあっても、ソフトウェアの利用者はその機能を利用できない。
そのため、機能の追加・改善や不具合の修正を、ひとつひとつ確実にリリースするほうが、利用者にとって価値がある。
またリリースの期間が短くなると、利用者から改善や修正のフィードバックをすみやかに得られるため、利用者の意見を次の設計に反映することができる。
／＊／
モブプログラミングはチームの外から突然、割り込み作業が入った場合、フロー効率が大きく損なわれる問題がある。
そのため、当番兵を設けることがある。
モブプログラミングにおいて当番兵(batman)とは、突然の割り込みからチームを守るため、緩衝材となる要員である。
モブプログラミングのチームに対して質問や注文がある場合、当番兵が窓口となることで、チームの作業中断を防ぐことができる。
持ち回りで当番兵を担当する場合、誰が当番兵か判別しやすいよう、帽子や腕章などの目印があるとよい。
部品: レトロスペクティブ
アジャイルソフトウェア開発において、レトロスペクティブ(retrospective)とは、イテレーションやプロジェクトの終わりなど、仕事が一段落したタイミングで仕事のやり方を振り返る会議のことである。
レトロスペクティブは、振り返りやアジャイルレトロスペクティブ、チームレトロスペクティブ、反省会などとも呼ばれる。
レトロスペクティブの目的は、失敗の分析や反省ではなく、チーム関係や品質・生産性の改善である。
レトロスペクティブは誰かを糾弾する場ではないということを示すため、時間を割いてくれた参加者を歓迎し、会議の開始と終了に感謝を述べるとよい。
一回のレトロスペクティブにかける時間は、イテレーションやプロジェクトの長さによる。
振り返る時間が長いほど、一回のレトロスペクティブの時間は長くなる。
たとえば、一か月のイテレーションを振り返るなら、最低でも半日は必要である。
数か月のプロジェクトを振り返る場合は一日以上である。
また、失敗したプロジェクトは数日かける場合もある。
参加者の仕事の都合で長時間参加できない場合は、レトロスペクティブを円滑に行うため、整理した客観的データとともに、議題や目的など予定している内容をまとめ、事前に提示しておくと会議の時間を短縮できる。
レトロスペクティブで使われる枠組みにKPTがある。
KPTとは、続けること(keep)・問題点(problem)・試したいこと(try)の三つに分けて現状分析をおこなうというものである。
ホワイトボードを「今後も続けたいこと」「今後はやめること」「新しくやってみたいこと」の三つの領域に分け、各自がそれぞれに応じた内容を付箋に書き込んで貼り付けていく。
付箋がない場合はホワイトボードに直接記入してもよい。
出てきた案を複数同時に採用すると、うまくいかない場合があるため、対話や投票で、特に優先してやりたいものをひとつかふたつに絞るとうまくいきやすい。
／＊／
うまくいかないレトロスペクティブは、いくつかの類型がある。
そのひとつが、アイデア自慢大会である。
ここでいうアイデア自慢大会とは、前回のイテレーションやプロジェクトで起きたことを話し合わずに、提案だけ出すレトロスペクティブである。
課題と向き合っていないため、出てきた提案は課題を解決に役立つものではない恐れがある。
歴史の授業もうまくいかないレトロスペクティブの類型のひとつである。
ここでいう歴史の授業とは、前回のイテレーションやプロジェクトで何が問題だったか、どこを改善すべきかを調べるだけのレトロスペクティブである。
具体的な改善方法については話し合わないため、変化は個々の作業者任せとなってしまう。
不平不満を言い、責任をなすりつけあう、魔女狩りのようなレトロスペクティブも改善の役には立たない。
そのため、これらの問題が出た場合は、レトロスペクティブの実施方法を見直し、改善する必要がある。
部品: デイリースタンドアップミーティングとは
デイリースタンドアップミーティング(daily stand-up meeting)とは、重要な情報をチーム内ですばやく共有するための集まりである。
デイリースタンドアップミーティングは、デイリースタンドアップやスタンドアップ、デイリースクラムなどとも呼ばれている。
また、開催する時刻が朝の場合は朝会、昼の場合は昼会、夕方の場合は夕会と呼ばれることもある。
デイリースタンドアップミーティングは、チームによるチームのための会議で、正式な会議として開催しないため、議事録は作られない。
適切に実施されたデイリースタンドアップミーティングは、日々の成果をチーム全員が正しく認識し、目標に向かって一体となって進むために役立つものである。
／＊／
デイリースタンドアップミーティングは、決まった時刻に毎日開催される。
決まった時刻とは、たとえば出社時刻の15分後や30分後など、チームがミーティングをおこなうのに都合のよい時刻である。
福利厚生で自由に出社時間を選べる企業の場合、朝方の社員と夜型の社員がそれぞれ情報の同期をとれるよう、午前と午後に一回ずつデイリースタンドアップミーティングをおこなう場合もある。
また、デイリースタンドアップミーティングを二部構成でおこなう場合もある。
たとえば、顧客には理解が難しい技術的な専門用語で話し合う開発チーム内のミーティングが第一部、誰がどのユーザーストーリーを担当するのか開発チームから顧客チームに対するミーティングが第二部という形式である。
チームのメンバーが遠隔地で作業している場合は、テレビ会議でデイリースタンドアップミーティングをおこなうこともある。
／＊／
一回のデイリースタンドアップミーティングにかける時間は5分ほどで、長くても15分である。
ミーティングの時間を短くする工夫として、ミーティングで報告された問題やチーム全員に関わらない内容については、そのミーティングの中で深掘りせず、ミーティング後に話すこととしてホワイトボードや付箋などに書き留めておくことが挙げられる。
また、参加者全員が立ったままミーティングすることも、ミーティングの時間短縮の工夫のひとつである。
立つことで机の下で携帯電話を操作したり、落書きしたりといったことができなくなる。
さらに、長時間立ち続けると座りたくなるため、ミーティングが長引いたときに気づきやすい。
腰痛や妊娠など健康上の理由、および種族の身体的構造で立つことが困難な場合、無理に立たせる必要はないが、他の参加者がチームの一員であると感じられるよう、視線の高さを合わせるなどの工夫をしたほうがよい。
他の者が話している最中に割り込んだりしないよう、トーキングスティックを使うことも時間の短縮に役立つ。
／＊／
デイリースタンドアップミーティングで何について話すか、参加者が忘れないようにするため、あらかじめいくつかの質問項目をホワイトボードや付箋などに書いて掲示しておくとよい。
たとえば、「昨日は何をしたか。それは世界をどう変えたか」「今日は何をするか。それは世界をどう変えるか」「チームの開発速度を下げているものはあるか。何が邪魔しているか」など、そのチームにとって必要な質問である。
質問はチームの振る舞いを変えたり、新しいひらめきをもたらすような表現に変えてもよい。
／＊／
デイリースタンドアップミーティングに遅刻することは、作業の進捗状況や問題など、重要な情報をチーム内で共有することのさまたげとなる。
そのため、デイリースタンドアップミーティングで遅刻した者には、今後の遅刻を防ぐ目的で、罰金などの罰を与える。
罰は当事者自身が選ぶと時間を守る原動力となる。
たとえば、運動の苦手な者なら遅刻一回につき腕立て伏せ30回、コーヒーが好きな者なら遅刻した日はコーヒーを飲まないなどとすれば、時間を守りやすくなる。
遅刻することで、チームがどのように迷惑しているかを話すことも有効である。
頻繁に遅刻する者は遅刻のたび、ホワイトボードに記名し、遅刻の頻度を当事者自身が自覚できるようにするのも遅刻防止に効果的である。
／＊／
デイリースタンドアップミーティングが適切におこなわれているかどうかは、レトロスペクティブなどで、ミーティングの有効性をレビューし、必要に応じてミーティングの形式に変えるよい。
部品: スクラムオブスクラム
スクラムオブスクラム(scrum of scrum)とは、大規模なチームでデイリースタンドアップミーティングを短時間で終わらせるための工夫である。
たとえば、六十名のチームが一名当たり1分で順番に話した場合、それだけで一時間が必要になる。
そこでチームを少数名のサブチームに分け、それぞれのサブチームごとにデイリースタンドアップミーティングをおこなう。
その後、各サブチームの代表者が集まり、ミーティングをおこなうことでサブチーム同士を連携する。
この代表者が集まるミーティングをスクラムオブスクラムと呼ぶ。
たとえば、各六名のサブチームが一名当たり1分で話した場合、6分で終わる。
その後、サブチームの代表者十名が一名当たり1分で話せば10分となるため、六十名のチームでも計16分でミーティングを終えることができる。
スクラムオブスクラムは、ビッグデイリー(big daily)やデイリーシンク(daily sync)とも呼ばれる。
また、スクラムオブスクラムの内容のほとんどがデプロイとリリースに関するものの場合、リリースシンク(release sync)とも呼ばれる。
／＊／
スクラムオブスクラムは、スペシャリティ同期ミーティングとプロジェクト同期ミーティングの二回に分けておこなうこともある。
／＊／
スペシャリティ同期ミーティングとは、要求分析・開発・テストなどそれぞれの担当ごとに集まり、チームの垣根を越えてお互いの状況を話し合うミーティングである。
たとえば、要求分析の担当者だけが集まって開催するアナリスト同期ミーティング(requirements sync)や、テストの担当者だけが集まって開催するテスター同期ミーティング(test sync)などがある。
この場合、要求分析の担当者は、開発者からの質問に答え、要求を明確にするために、各開発チームにそれぞれ所属しているが、システムの全体像の分析に専念するため、開発チームに所属しない担当者もいる。
また、状況に応じて開発チームで要求分析したり、システムの全体像の分析をしたりと、そのときどきに応じて必要な役割を担う担当者もいる。
テストの担当者も同様に、各開発チームに所属し、機能レベルのソフトウェアテストやデバッグをおこなう者や、システム全体の概要レベルの結合テストやシステムテストに焦点を当てる者、両者の役割を必要に応じて柔軟に対応する者に分かれる。
これらの担当者ごとに最新の情報を持ち寄って話し合うことで、最新の状況を共有することができる。
プロジェクトマネージャはそれぞれのミーティングを見て回りながら、プロジェクトとして解決すべき問題がないか探す。
個別のミーティングに参加せず聞いているだけのこともあれば、プロジェクトマネージャが議論に混ざることもある。
／＊／
プロジェクト同期ミーティングは、スペシャリティ同期ミーティングの結果をふまえ、要求分析から本番リリースまでの、チーム間の仕事の流れに着目し、プロジェクト全体の視点から代表者が話し合うミーティングである。
プロジェクト同期ミーティングは、チーム間の協同に関する課題を解決する場としても機能する。
部品: プランニング・ポーカーとは
プランニング・ポーカーとは、作業工数を適切に見積もるための工夫である。
プランニング・ポーカーは、主にソフトウェア開発で使われる。
たとえば、一名の作業者が見積もると、その者が仕様をどの程度理解しているかによって、適切な工数よりも低く見積もられたり、高く見積もられたりする。
また、複数名で見積もりの会議をおこなうと、最初に発言した者や声の大きい者の意見に誘導されたり、専門外や作業担当ではないことを理由に見積もりの参加に消極的だったりすることがある。
プランニング・ポーカーは、こういった問題を防ぐための工夫である。
／＊／
プランニング・ポーカーの手順は以下のとおりである。
まず見積もりの参加者全員を実装するユーザーストーリーについて手短に説明し、要求仕様を理解するまでユーザーストーリーに関する質疑応答をおこなう。
充分に理解できたところで工数が書かれたカードを選び、参加者全員で一斉に公開する。
カードに書かれた工数の種類は、たとえば「S(小さい)」「M(中くらい)」「L(大きい)」「XL(とても大きい)」「∞(終わらない)」「？(わからない)」などが考えられる。
事前にカードを用意できない場合は、カードの代わりに、相手から見えないように紙や砂地などに工数を書いたり、指の立てた本数で工数を表したりしてもよい。
全員の出した工数がだいたい一致していれば、その工数が妥当と考えられるため、次のユーザーストーリーの工数を同様の手順で見積もる。
もし、出した工数が大きく異なるようなら、数分ほど時間をとり、他の者がなぜその工数を出したのか、それぞれに黙考してもらう。
その後、なぜその工数が適切と判断したか、参加者全員からそれぞれ理由や根拠を手短に述べてもらう。
たとえば、「以前のプロジェクトで作ったプログラムを流用できそう」や「テストが大変」などである。
そのうえで再度、参加者全員がカードを選び、公開する。
ここでも工数が大きく異なる場合は、このユーザーストーリーの工数見積もりを後回しにして、次のユーザーストーリーの工数を同様の手順で見積もる。
後回しにしたユーザーストーリーは、他の見積もりが終わったあとで、時間をかけて議論する。
休憩しやすくするため、「休(会議を中断して休憩しよう)」というカードを使う場合もある。
／＊／
プランニング・ポーカーの利点はいくつかある。
ひとつは、見積もりという孤独になりがちな作業をゲーム感覚で楽しくできることである。
また、参加者全員が自分の考えた工数を提示し、その理由を説明しなければならないから、工数を見積もるために充分な情報を得られるよう、参加者が積極的に質問するようになる。
こういった質疑応答や議論によって、有益な情報が集まりやすくなる。
たとえば「このユーザーストーリーは抽象的で分かりにくい」「テストがしにくい」「もっと単純なユーザーストーリーに分割しよう」といった意見である。
参加者全員に発言の機会が与えられるため、参加者同士で知識を共有し、お互いの観点や価値観を理解する助けにもなる。
インポート用定義データ
[
{
"title": "アジャイルソフトウェア開発",
"part_type": "group",
"children": [
{
"title": "アジャイルソフトウェア開発とは",
"description": "アジャイルソフトウェア開発とは、要件に適応するよう、短期間でソフトウェアを開発する技法の総称。\nアジャイルとは、Agile、つまり「迅速な」「俊敏な」「機敏な」を意味する。\nアジャイルソフトウェア開発と呼ばれる方式は、スクラムやエクストリーム・プログラミング、フィーチャー駆動開発、クリスタル・ファミリーなど、様々な手法が存在する。\nアジャイルソフトウェア開発の多くはイテレーションと呼ばれる短い期間を単位に分けている。\n一回のイテレーションはだいたい一週間から二週間、長くても四週間である。\n一回のイテレーションの中で、ひとつあるいは少数の小さな機能だけについて、要件定義・設計・開発・テスト・リリースといったソフトウェアプロジェクトにあるのすべての工程をおこなう。\nこのイテレーションを何度も繰り返すことで開発を進めていく。\nイテレーションが終わるたびに、残った機能の優先順位を見直し、まだ開発が必要か否かを検討する。\n開発終了の目安はたとえば、当初予定した機能をすべて開発したとき、予定した期日が来たとき、予算を使い切ったときなどである。\nアジャイルソフトウェア開発は、開発中に要件が頻繁に変わる場合でも、変更に応じて速やかに適応できるという利点がある。",
"part_type": "part",
"localID": 1
},
{
"title": "ジャストインタイム分析",
"description": "アジャイルソフトウェア開発においては文書資料の作成よりも、実際に動く機能をすばやく作り、その機能の動きを実際に見たうえで、関係者同士で顔を合わせて話し合うことを重視する。\nこの関係者の中には当然、顧客も含まれる。\n大量に文書があると、仕様変更時があった際、修正する文書が多くなり、文書資料間で整合性をとることも難しくなる。\nまた、どんなにがんばって事前に情報を集めても、その情報の多くは使われずに終わるかもしれない。\nそのため、文書の作成・修正よりもプログラム開発に労力や時間を使うよう、このような方針となっている。\nなお、アジャイルソフトウェア開発は文書資料をまったく作らないわけではなく、不要な労力を減らすため、文書資料の作成を必要最小限に抑えるという戦略である。\nそのため、文書資料を作ることが作らないよりも適切な場合は文書資料を作成する。\n言い換えると、必要なときに必要な分だけを分析し、資料を作成する。\nそして、本当に必要になるまでは計画・分析・資料作成は先送りにする。\nここまですればいいという絶対的な基準はないため、プロジェクトやチームに応じた適切な規模で計画・分析・資料作成をおこなう。\n余計な負担は開発の速度を下げることになるため、最初は小さく始め、必要に応じて分析や資料を増やすことが望ましい。",
"part_type": "part",
"localID": 2
},
{
"title": "カンバン",
"description": "流用可能",
"part_type": "group",
"children": [
{
"title": "チームボード",
"description": "流用可能",
"part_type": "group",
"children": [
{
"title": "チームボードとは",
"description": "チームボードとは、やるべきことを忘れないようにするため、および作業の進捗状況を常に見えるようにするための工夫である。\nチームボードを簡単に説明すると、インデックスカードや強粘着の付箋などにユーザーストーリーや作業内容を簡潔に書き、付箋の粘着力や画鋲・磁石などで壁やホワイトボード・コルクボード・スチレンボードなどに貼り付けるというものである。\n電子的なシステムに計画や進捗状況がデータとして保存されていると、ナチュラルネットに接続できない知類は、パソコンやスマートフォンなどの電子機器を介さない限り、保存されたデータを確認することができない。\nそのため、冷蔵庫が開いているときしか中のものを取り出せないことにたとえ、このような電子的に保存された情報を情報冷蔵庫と呼ぶこともある。\nチームボードはチーム全員の席から見える位置にあるため、チームのおおまかな作業状況を常に把握することができる。\nまた、貼り付けたカードや付箋を手に取って話すことができる。\nチームのメンバーが遠隔地で作業している場合は、チームボードの写真を適切な頻度で定期的に送ることで、同じ場所にいない場合でも進捗状況を把握できる。\n定期的に写真をとることで、プロジェクトの作業内容を振り返す際、当時の作業進捗状況を確認することができる。\nAI知類やサイボーグなど、ナチュラルネットに直接アクセスできる作業者が多い場合は、チームボードを電子的なシステムで構築してもよいが、ネットに直接アクセスできない者のため、大型モニターやプロジェクターなどで常時表示することが望ましい。\nチームボードは、リリースボードとストーリーボードの二つに分けて運用される場合もある。\n／＊／\nリリースボードとは、プロジェクトの中でリリースが完了したユーザーストーリーと、未完了のユーザーストーリーを掲示したものである。\nたとえば、ホワイトボートの左端に最初のイテレーションでリリースしたユーザーストーリーを縦に並べて貼り、その隣の列がその次のイテレーションにリリースしたユーザーストーリーを貼り、という具合に左から順に貼り付ける。\n右側にまだリリースしていないユーザーストーリーを貼り、完了と未完了の間に、ホワイトボードマーカーやカラーテープなどで分かりやすいように線を引く。\nどこまで仕事が終わり、どれだけの仕事が残っているかを見えるようにすることでプロジェクト全体の状況を把握することができる。\n／＊／\nストーリーボードとは、今回のイテレーションで対応するユーザーストーリーを、未着手(ToDo)・作業中(Doing)・リリース完了(Done)の三つに分けて貼り付けたものである。\nたとえば、ホワイトボートの左側に未着手のユーザーストーリーを貼り、右側に顧客の承認を得てリリースしたユーザーストーリーを貼る。\n中央には作業中のユーザーストーリーを貼り、未着手と作業中の間、および作業中とリリース完了の間に、ホワイトボードマーカーやカラーテープなどで分かりやすいように線を引く。\nユーザーストーリーの作業規模に応じて付箋の大きさを変えたり、納期で付箋の端に記入するなどの工夫をおこなう場合もある。\nまた、新規機能追加や既存機能改修は黄、欠陥・不備・不具合の修正・対応は赤、リファクタリングは緑といったように、作業内容に応じて付箋の色を変える工夫をおこなうこともある。\nこの場合、機能追加と不具合改修の両方を対応するユーザーストーリーは、黄と赤のふたつの付箋やカードにユーザーストーリーを分けて管理すると分かりやすくなる。\n／＊／\nチームボードに付箋を用いる場合、付箋の外し方に注意が必要である。\n付箋の接着面を上にしてホワイトボードに貼り付けている場合、下から上に勢いよくはがすと、付箋がカールして貼り付けにくくなる。\n付箋のカールを防ぐためには、左から右に、あるいは右から左に、そっとはがす。\nなお、付箋やカードが貼り付けにくくなったり、汚れて読みにくくなったりした場合は、新しい付箋やカードにユーザーストーリーを書き写して使うようにするとよい。\nカードや付箋に作業内容を書く際、文字の大きさはチームボードから少し離れても楽に読めるくらいが望ましい。",
"part_type": "part",
"localID": 5
}
],
"localID": 4,
"expanded": true
},
{
"title": "カンバンとは",
"description": "カンバン(kanban)とは、見える化やWIP制限をおこなったストーリーボードのことである。\n／＊／\nカンバンにおいて、見える化とは、作業の状況を標示することで理解しやすくすることである。\n複数名が一緒に働く際、多くの仮定や方針が暗黙的に存在する。\nそれらの仮定は、お互いに矛盾や行き違いがあることもある。\n作業を形式化することで、作業担当者や利害関係者が意見交換をする助けとなる。\nたとえば、作業担当者の顔写真を貼った磁石を付箋に貼ることで、誰が作業を担当しているかを分かりやすくすることができる。\nまた、ストーリーボードの作業中の列を分析・開発・テストなどに分けることで、現在そのユーザーストーリーがどこまで進んでいるかわかるようになる。\nさらに、開発を開発待ち・開発中に細分化すれば次に開発するユーザーストーリーはなにかが分かりやすくなる。\nあるいは、開発を開発中・開発完了に分ければ、次の工程(テスト)の担当者がどのユーザーストーリーをテストすればよいか分かりやすくなる。\nこのように作業の進捗を掲示すれば、開発中のユーザーストーリーを開発完了の列に移すための条件を話し合うきっかけになる。\n作業担当者と利害関係者が話し合い、情報を共有、透明性を高めることでプロジェクトを円滑に進められるようになる。\n不要な情報や情報過多は理解を難しくするため、避けるべきである。\n／＊／\nスクラムとカンバンの組み合わせた手法はスクラムバン(scrum-ban)と呼ばれる。",
"part_type": "part",
"localID": 6
},
{
"title": "WIP制限",
"description": "WIP制限とは\nWIPとは、work in progress(進行中の作業)、またはwork in process(加工中の作業)の略で、仕掛り作業や仕掛りとも呼ばれる。\nカンバンにおいて、WIP制限とは、複数の作業を掛け持ちして作業効率が下がらないようにするため、同時におこなう作業の数を制限することである。\nWIP制限には、チーム単位の制限・作業種別ごとの制限・作業担当者ごとの制限などに分けられる。\n一回のイテレーションの中でチーム全体がいくつの作業をこなすのか、分析・開発・テストなど作業種別(カンバンの列)ごとにいくつの作業をこなすのか、個々の作業担当者がいくつの作業をこなすのかをそれぞれ制限することで、作業の効率を上げることができる。\nただし、WIPが多すぎると誰も担当していない作業が出てきてしまう。\nWIPはなるべく少ないほうが望ましいが、WIPが少なすぎると作業をしていない者が出てしまう。\nそのため、WIP制限は適切な数を設定する必要がある。\n適切な数を見つける手段として、「チームの構成員数の1.5倍」「通常時の作業数の倍」などをいったん上限に定めてイテレーションを回し、問題がなければ適切な数になるまで2割ずつ上限を減らすといった方法が考えられる。\n通常、チーム単位のWIP制限は1より大きくなる。\nただし、モブプログラミングで開発している場合、チーム単位のWIP制限は1になることもある。\nWIP制限は厳密なルールではなく、設定したWIPの上限を超えてもよい。\nただし、いつもWIPの上限を超えているようなら、話し合う必要がある。\nたとえば、作業担当者ごとのWIP制限をXさんが頻繁に超えている場合、Xさんは他の者でもできる作業を抱え込んでいるかもしれないため、どの作業なら他の者に任せられそうか話し合ったほうがよい。\nチーム単位や作業種別に対するWIPの上限は、カンバンにホワイトボードマーカーなどでその数を数字で書くと分かりやすい。\nあるいは、作業種別(列)ごとにWIPの数だけ四角の枠を書き、そこに付箋を貼り付けることで、あといくつまで作業を追加してもよいか示すこともできる。\nまた、ユーザーストーリーにカードを用いている場合は、作業種別(列)ごとのカードホルダーの数で示すこともできる。\n作業担当者ごとの上限は、顔写真付き磁石の数で、誰がいくつまで作業を担当できるかが分かりやすくなる。\n／＊／\n仕事が作業の繰り返しにならないよう、お祝いのタイミングを作るためにもWIP制限は利用できる。\nたとえば、完了(Done)の列にWIP制限を設定するというものがある。\n完了(Done)の列の作業がWIPの上限に達した場合、顧客や利用者などの利害関係者が開発チームへお礼を述べ、ケーキを渡すまで作業をしないというルールである。\n開発チームが楽しめて就業時間内に食べたり飲んだりできるものであれば、ケーキ以外のものでもよい。",
"part_type": "part",
"localID": 7
},
{
"title": "ナンバーマルチタスクゲーム",
"description": "ナンバーマルチタスクゲームとは、WIPを減らすとどのような価値をもたらすかを理解するためのゲームである。\nナンバーマルチタスクゲームは、ひとりでも多人数でもできるゲームである。\nまずプレイヤーごとに、ストップウォッチ、三色のペンと二枚の紙を用意する。\n三色のペンは、たとえば黒ペン・赤ペン・青ペンである。\nプレイヤーには、以下の三つの作業を依頼する。\nひとつ目の作業は、漢数字の一から十までを上から下に向かって黒ペンで書く。\nふたつ目の作業は、漢数字の隣に、アルファベットのAからJまでを上から下に向かって赤ペンで書く。\nみっつ目の作業は、アルファベットの隣に、アラビア数字の1から10までを上から下に向かって青ペンで書く。\nプレイヤーには、三つの作業はどれも等しく重要で、最優先で対応しなければならないため、三つの作業は一枚目の紙に横方向に一行ずつ進めるよう指示する。\nたとえば、一行書いた時点では「一A1」、二行書いた時点では二行目は「二B2」となる。\nゲームの管理者は、プレイヤーがそれぞれの作業を終えるまでの時間と、すべての作業を終えるまでの時間をストップウォッチで計測する。\nすべての作業を終わったら、各作業の所要時間を紙やホワイトボードに書き込む。\n次に、プレイヤーへもっとも重要な作業は漢数字を書く作業で、次がアルファベット、最後がアラビア数字であると伝える。\nつまり、漢数字をすべて書き終えてから、アルファベットにとりかかり、アルファベットをすべて書き終えてから、アラビア数字を書くという手順である。\nこの手順で、二枚目の紙に書いてもらい、一枚目の紙のときと同様に時間を計測し、各作業の所要時間を紙やホワイトボードに書き込む。\n一枚目の紙に書いたときと比べ、二枚目の紙に書いたときのほうが各作業の所要時間が大幅に短縮されているはずである。\nゲームの管理者はプレイヤーへゲームに協力してくれたことについて感謝を伝え、なぜ作業の所要時間が減ったのか、このことが実際の仕事にどのように当てはめられるのかなどについて話し合う。",
"part_type": "part",
"localID": 8
}
],
"localID": 3,
"expanded": true
},
{
"title": "テスト駆動開発",
"description": "流用可能",
"part_type": "group",
"children": [
{
"title": "テスト駆動開発とは",
"description": "テスト駆動開発(test-driven development)とは、多くのアジャイルソフトウェア開発において推奨されているプログラム開発の手法のひとつである。\nテスト駆動開発は、TDDとも呼ばれる。\nテスト駆動開発は、プログラミングにともなう様々な複雑さと向き合うための設計手法である。\nたとえば、クラスベースのオブジェクト指向プログラミングでメソッドを宣言する場合、たった1行のコードでも、どのクラスのメソッドにするべきか、メソッドや仮引数の適切な名前、そのメソッドがpublicなのかprotectedなのかprivateなのかといったメソッドの可視性、引数や戻り値の適切な型など、それぞれどのように設計すべきか判断しなければならない。\n1行でこれだけたくさんのことを考えなければならないため、プログラム全体でどこか見落としがあってもおかしくはない。\nテスト駆動開発は、このような複雑さに立ち向かうため、一度に相手するテストをひとつだけに絞って、同時に考えるべきことを減らす手法である。\n／＊／\nテスト駆動開発は、テストファーストでおこなわれる。\nテストファーストとは、プログラムをコーディングする前に、そのプログラムをテストを作るすることである。\nプログラムより先にテストを作ることは、すでに実装されたコードがあると考えながら、テストを作ることである。\nそのため、仕様の理解があいまいなまま、行き当たりばったりにコーディングすることを防ぐことができる。\nまた、不具合を修正する際、テストを先に作ることで、不具合の本質をどのように理解していたか示すことができる。\nテストを作ったら、作ったテストが現行のプログラムで失敗することを確認する。\nまだプログラムに存在しないクラスや関数に対するテストの場合、テストできるようクラスや関数を宣言するなど、必要な最小限のコードを追加する。\nもし、作ったテストが現行のプログラムで成功するようなら、テスト自体の不備が考えられるため、失敗するまでテストを修正する。\nテストが失敗することを確認したら、テストに合格するプログラムをなるべく早く作る。\nこの際、テストに合格するためなら、洗練されたコードになっていなくてもよい。\nテストに合格することを確認したら、リファクタリングをおこなう。\nリファクタリングが難しい場合、別のテストケースを追加し、それらのテストケースを合格するプログラムの共通点を見つけ出すことで、リファクタリングすべき箇所の指標とする。\nテスト駆動開発ではテストを頻繁におこなうため、手動操作ではなく、自動でテストおこなうテスト用のプログラムを用意することが前提である。\nなお、テスト駆動開発で作られるテストは、あくまでプログラム開発の過程で生まれる副産物である。\n開発したソフトウェアの品質を検証するには充分でない場合があるため、テストの工程では確認の足りない箇所を検証するテストを追加したほうがよい。",
"part_type": "part",
"localID": 10
},
{
"title": "リファクタリング",
"description": "リファクタリング(refactoring)とは、外から見たプログラムの動作を変えずに、ソースコードの内部構造を読みやすく、修正しやすいよう整理することである。\nソースコードは読みやすいと、そのコードがなにをしているのか理解するために必要な時間が短くなる。\nソースコードが整理されていない場合、修正に時間がかかり、修正による意図せぬ不具合も起きやすい。\nソースコードの整理とは、たとえば、似たような処理を関数やメソッドでひとつにまとめることである。\n似たような処理が複数の箇所に分散して書かれていた場合、その処理の修正も複数の箇所でおこなうため、修正し忘れる恐れがある。\n処理が一箇所にまとまっていれば、そこだけを修正すれば済むため、修正の不備は起きにくくなる。\n逆にひとつの関数の中で処理の場合分けが複雑な場合は、複数の関数に分けることで関数内での場合分けを減らし、コードをわかりやすくすることができる。\nマジックナンバー(magic number)やマジックストリング(magic string)など、ソースコード上に直接記述された数値や文字列を定数や列挙型に置き換えることもリファクタリングである。\nまた、関数や変数・定数などの名称を、内容にあったわかりやすい名前へ変更することもリファクタリングである。\nなお、リファクタリングは意図通りに動くコードに手を加えるため、適切なテストで修正の前と後で意図せず動きが変わっていないか検証する必要がある。",
"part_type": "part",
"localID": 11,
"expanded": true
}
],
"localID": 9,
"expanded": true
},
{
"title": "モブプログラミング・ペアプログラミング",
"part_type": "group",
"children": [
{
"title": "モビング・ペアリング",
"description": "モブプログラミング(mob programming)とは、モビング(mobbing)とも呼ばれる、ソフトウェア開発の手法のひとつ。\n通常のソフトウェア開発では、作業者ごとに映像表示端末・入力機器・パーソナルコンピュータ(またはワークステーション)を一台ずつ(あるいはそれ以上)使う。\nモブプログラミングでは、チーム全員で一台の端末を共有する。\nなお、映像表示端末とは液晶ディスプレイ・液晶プロジェクタ・有機ELディスプレイなど、入力機器とはキーボードやマウスなどのことである。\nモブプログラミングでチームの作業者は、ドライバーとナビゲーターに役割が分かれる。\nドライバーはソースコードを入力するタイピストで、ナビゲーターの指示や提案に従って作業する。\nドライバーは指示の内容が理解できない場合、理解できるまでナビゲーターに質問する。\n入力機器は一名分しかないため、必然的にチーム内のドライバーは一名となる。\nドライバーは自分で勝手に考えてソースコードを作ってはならず、自分の考えをコードに盛り込みたい場合は他の作業者にドライバーをやってもらい、ナビゲーターとしてどう実装するかを伝える形になる。\nまたドライバーの集中力が続くよう、一定時間経過でドライバーの役割を交代する規則を採用する場合もある。\n必ず他者を通してソースコードが入力されるため、説明を通じてチーム全員が設計やコードを理解することができる。\nなお、ドライバーとナビゲーターという名前は、参加者の役割を車の運転にたとえたものである。\nナビゲーターが複数名いることに違和感をおぼえる場合、ドライバーをタイピスト、ナビゲーターを「その他のモブ」と呼ぶ場合もある。\nモブプログラミングの欠点として必ず話し合いがおこなわれるため、議論が盛り上がって作業が進まない場合がある。\nそのため、モブプログラミングをおこなう場合、ファシリテーターを用意したり、議論のルールを決めたりするなど、円滑に議論をおこなうための手立てを用意したほうがよい。\nチーム内でお互いに安心して、直接はっきりと意見を言い合える文化を育てることも重要である。\n第三者がモブプログラミングを見た場合、チームで作業をしているのは一名だけで、他の者は作業していないように見える場合がある。\nそのため、チームの上司や顧客など、開発関係者にモブプログラミングの概念や利点を説明する必要がある。\n参加者全員がよく知らない技術をあつかう場合や、なにをすれば分からない場合は、目の前の課題について理解を深めるため、個々の参加者にそれぞれの考えを掘り下げる時間を与えたほうがよい。\nなお、モブプログラミングの参加者が育児・介護・健康上の理由などから出勤できない場合、テレビ電話やチャットなどで遠隔地からモブプログラミングに参加するリモートモビングという手法がある。\n／＊／\nモブプログラミングでチームが二名の場合、つまり二名一組でひとつのキーボードを使い、ひとつの作業を遂行することをペアプログラミング(pair programming)と呼ぶ。\nペアプラミングはペアリング(pairing)とも呼ばれる。\nペアプログラミングはテスト駆動開発で利用されている。\nペアプログラミングには、ピンポンペアプログラミングやマイクロペアリングなどの手法がある。\n／＊／\nピンポンペアプログラミング(ping-pong pair programming)とは、二名一組がひとつのキーボードで作業するテスト駆動開発である。\nたとえば、XとYの二名の開発者がピンポンペアプログラミングをおこなう場合、Xが失敗するテストを作り、Yがテスト成功に必要最小限のコードを実装する。\nこのやりとりを課題が終わるまで繰り返すものがピンポンペアプログラミングである。\nなお、上記の場合、リファクタリングはYがおこなう。\nピンポンペアプログラミングはペアプログラミングピンポン(pair programming ping-pong)とも呼ばれている。\n／＊／\nマイクロペアリング(micro pairing)とは、ピンポンペアプログラミングと同様に、二名一組がひとつのキーボードで作業するテスト駆動開発である。\nピンポンペアプログラミングでは、テストを作る者と、目的のプログラムをコーディングする者の役割が固定されている。\nそれに対し、マイクロペアリングでは役割が固定されていない。\nたとえば、XとYの二名の開発者がマイクロペアリングをおこなう場合、Xは失敗するテストか成功するテストを作る。\nXが失敗するテストを作った場合、Yはテスト成功に必要最小限のコードを実装する。\nXが成功するテストを作った場合、Yはコードをリファクタリングするか、失敗するテストを作る。\nYが失敗するテストを作った場合、今度はXがテスト成功に必要最小限のコードを実装する。\nこのやりとりを課題が終わるまで繰り返すテスト駆動開発がマイクロペアリングである。\n成功するテストを作る理由は、すでに実装されている動作や機能を分かりやすい記録として、テストの形で残すためである。\nまた、失敗するテストを作ったつもりが意図せず成功してしまった場合もある。\n意図せず成功した場合は、テストが誤っているのか、実装が誤っているのかを検証する必要がある。\n／＊／\nピンポンペアプログラミングやマイクロペアリングなどのペアプログラミングは、電話やメール、チャットなどの注意を逸らす活動を減らし、やるべき仕事に集中できる利点がある。\n反面、ペアプログラミングはその集中ゆえに疲れる活動であり、特に二名の間で頻繁にキーボードが行き来するピンポンペアプログラミングやマイクロペアリングは消耗が激しい。\nそのため、ペアプログラミングをおこなう時間は一日あたり6時間以下にすることが望ましい。\nモブプログラミングやペアプログラミングで疲労を防ぐために適切な休憩の頻度は、25分から30分に1回とされている。\nまた、疲労を感じた作業者は、なるべく早くチームに伝えたほうがよい。\n／＊／\nモブプログラミングやペアプログラミングでは、チーム全員が快適に作業できるよう、作業環境を整えることが重要である。\nチーム全員が画面を見られるよう、大型の映像表示端末を用意するか、同じ画面を表示する映像表示端末を複数台用意することが望ましい。\nチーム全員が入れるだけの充分に広い部屋、考えを整理するためのホワイトボード、快適に作業をできるだけの性能を持つ端末、作業のしやすい高さと形状の机なども用意したほうがよい。\nモブプログラミングのために新しい備品や機材を買う場合、不適切な備品を購入しないよう、購入予定の備品を数週間レンタルし、使い勝手を確認したほうがよい。\n参加者が協調性や情緒が安定していることも重要なため、適切な者を選ぶことや、モブプログラミングに適した考え方を教育すること、参加者同士が互いを理解しあうためのグループセッションなども大切である。\n参加者のモブプログラミングの経験が乏しい場合、チーム結成時の混乱を減らすため、チームを小規模にしたほうがよい。\nモブプログラミングを始める以前から同じチームだった者同士だと、より混乱が少なくなる。\nモブプログラミングの参加者を組織の外部から新規に雇用する場合、1日か2日給料を払い、フルタイムで参加してもらい、モブプログラミングの適性を確認したほうがよい。\n／＊／\nモブプログラミングは話し合いながら仕事を進めるため、ペアプログラミングや単独で仕事する場合に比べ、うるさくなる。\nそのため、同じ部屋を他のチームと共同で使用する場合は、防音対策も重要である。\nモブプログラミング専用に用意された部屋や場所をモビングエリアやモビングステーションなどと呼ばれる。\nいつもモブプログラミングしているわけではない場合、モビングエリアは普段仕事をしている場所から近いほうがよい。",
"part_type": "part",
"localID": 13
},
{
"title": "レビューコスト削減",
"description": "モブプログラミングの利点のひとつに、レビューコストの削減があげられる。\nレビューには様々な種類があるが、ここではおおざっぱに「作った成果物が適切であるか、あいまいな点や問題点を検証する会議をおこなうこと」とする。\n成果物とは、要件定義書や外部設計書・内部設計書といった各種仕様書やソースコードのことである。\nレビューをおこなう場合、関係者を会議に集めるため、作業者の時間が拘束される。\nまた、レビューで使用する資料の作成といった、会議の準備にも時間が必要となる。\nモブプログラミングでは、チーム全員でひとつの作業に取り組むため、実質的にチーム内で常にレビューをしている形となる。\nモブプログラミングによって成果物の品質が向上するため、チーム内ではレビューを別途おこなう必要がなくなる。",
"part_type": "part",
"localID": 14
},
{
"title": "デグレード回避",
"description": "モブプログラミングの利点のひとつに、デグレードを防ぎやすいことがあげられる。\n作業者ごとに異なる作業をしている場合、同じソースファイルにそれぞれ異なる修正をすることが起きうる。\nこの場合、一方の修正で追加した機能や訂正した不具合が、もう一方の修正で消される恐れがある。\nこのように、新しいバージョンのほうが品質が劣化していることを、デグレード(degrade)やリグレッション(regression)、先祖返りなどと呼ぶ。\nデグレードを防ぐためには、ふたつの修正の差異を比較し、どちらの修正も意図した動作が残るよう、対応する必要がある。\nこの作業をマージと呼ぶ。\nまた、先祖返りが起きていないか確認するためのテストも必要になる。\nこのテストは、回帰テストや退行テストと呼ばれる。\nモブプログラミングでは、チーム全員でひとつの作業に取り組むため、マージが不要となり、また全員で設計やソースコードを確認しながら作業するため、デグレードも起きにくくなる。",
"part_type": "part",
"localID": 15
},
{
"title": "バス係数の改善",
"description": "モブプログラミングの利点のひとつに、バス係数の改善があげられる。\nバス係数(bus factor)とは、「プロジェクトの作業担当者が何名バスで轢かれたら(あるいは病欠・急用・離職などの理由で仕事に参加できなくなったら)、そのプロジェクトが破綻するか」という数値である。\nたとえば、特定の技能に特化した専門家や業務知識に精通した作業者が一名しかいない場合、その一名がいなくなるとプロジェクトが破綻するため、バス係数は一になる。\nひとりで仕事をしていると、往々にして自分がしている仕事に熟練するため、時間とともに組織は熟練者への依存度が高くなる。\nなぜなら未熟な者に仕事を頼むより、熟練者に頼むほうが短時間で仕事が終わり、失敗も少ないからである。\nしかし、熟練者ひとりでは抱えきれないほどの作業が発生した場合、他の者は未熟であるため、プロジェクトが破綻してしまう。\nモブプログラミングでは、チーム全員でひとつの作業に取り組むため、プロジェクトの情報がチーム内で共有される。\nチームが担当している作業についてはチーム内の全員が有能になるため、一部の作業者が仕事を離れてもプロジェクトを継続することができる。\nモブプログラミングを毎日おこなっていて、プロジェクトの情報が常に共有されている場合、実質的に常時チーム内のデイリースタンドアップミーティングをしていることになる。\nそのため、そのような場合はチーム内のデイリースタンドアップミーティングも省くことができる。",
"part_type": "part",
"localID": 16
},
{
"title": "フロー重視",
"description": "モブプログラミングの利点のひとつに、フロー効率の改善があげられる。\nフロー効率とは、作業の流れのよさのことである。\n作業者ごとに異なる作業をしている場合、他の作業者の作業待ちになることがある。\nたとえば、プログラム開発で仕様を確認したいが、仕様を決めた者は別の仕事で不在だったり、テスト担当者がソフトウェアの不具合を見つけたが、開発者は他の作業をしていてすぐに修正できず、再テストができなかったりといった場合などがあげられる。\nまたソフトウェア開発は頭脳労働のため、作業者が複数の作業を兼任している場合、作業の切り替えに時間的コストが発生する。\nたとえば、データベースにアクセスする言語とビジネスロジックを記述する言語が異なり、両方を同じ作業者が担当している場合、作業者はふたつのプログラミング言語の異なる構文を頭の中で切り替えたり、ソースコードを書くための開発環境を言語に合わせて切り替えたりする必要がある。\nモブプログラミングでは、チーム全員でひとつの作業に専念するため、チーム内で完結する作業については、流れが滞ることなく、終わらせることができる。\n開発途中の機能がいくらあっても、ソフトウェアの利用者はその機能を利用できない。\nそのため、機能の追加・改善や不具合の修正を、ひとつひとつ確実にリリースするほうが、利用者にとって価値がある。\nまたリリースの期間が短くなると、利用者から改善や修正のフィードバックをすみやかに得られるため、利用者の意見を次の設計に反映することができる。\n／＊／\nモブプログラミングはチームの外から突然、割り込み作業が入った場合、フロー効率が大きく損なわれる問題がある。\nそのため、当番兵を設けることがある。\nモブプログラミングにおいて当番兵(batman)とは、突然の割り込みからチームを守るため、緩衝材となる要員である。\nモブプログラミングのチームに対して質問や注文がある場合、当番兵が窓口となることで、チームの作業中断を防ぐことができる。\n持ち回りで当番兵を担当する場合、誰が当番兵か判別しやすいよう、帽子や腕章などの目印があるとよい。",
"part_type": "part",
"localID": 17
}
],
"expanded": true,
"localID": 12,
"description": "流用可能"
},
{
"title": "アジャイルミーティング",
"description": "流用可能",
"part_type": "group",
"children": [
{
"title": "レトロスペクティブ",
"description": "アジャイルソフトウェア開発において、レトロスペクティブ(retrospective)とは、イテレーションやプロジェクトの終わりなど、仕事が一段落したタイミングで仕事のやり方を振り返る会議のことである。\nレトロスペクティブは、振り返りやアジャイルレトロスペクティブ、チームレトロスペクティブ、反省会などとも呼ばれる。\nレトロスペクティブの目的は、失敗の分析や反省ではなく、チーム関係や品質・生産性の改善である。\nレトロスペクティブは誰かを糾弾する場ではないということを示すため、時間を割いてくれた参加者を歓迎し、会議の開始と終了に感謝を述べるとよい。\n一回のレトロスペクティブにかける時間は、イテレーションやプロジェクトの長さによる。\n振り返る時間が長いほど、一回のレトロスペクティブの時間は長くなる。\nたとえば、一か月のイテレーションを振り返るなら、最低でも半日は必要である。\n数か月のプロジェクトを振り返る場合は一日以上である。\nまた、失敗したプロジェクトは数日かける場合もある。\n参加者の仕事の都合で長時間参加できない場合は、レトロスペクティブを円滑に行うため、整理した客観的データとともに、議題や目的など予定している内容をまとめ、事前に提示しておくと会議の時間を短縮できる。\nレトロスペクティブで使われる枠組みにKPTがある。\nKPTとは、続けること(keep)・問題点(problem)・試したいこと(try)の三つに分けて現状分析をおこなうというものである。\nホワイトボードを「今後も続けたいこと」「今後はやめること」「新しくやってみたいこと」の三つの領域に分け、各自がそれぞれに応じた内容を付箋に書き込んで貼り付けていく。\n付箋がない場合はホワイトボードに直接記入してもよい。\n出てきた案を複数同時に採用すると、うまくいかない場合があるため、対話や投票で、特に優先してやりたいものをひとつかふたつに絞るとうまくいきやすい。\n／＊／\nうまくいかないレトロスペクティブは、いくつかの類型がある。\nそのひとつが、アイデア自慢大会である。\nここでいうアイデア自慢大会とは、前回のイテレーションやプロジェクトで起きたことを話し合わずに、提案だけ出すレトロスペクティブである。\n課題と向き合っていないため、出てきた提案は課題を解決に役立つものではない恐れがある。\n歴史の授業もうまくいかないレトロスペクティブの類型のひとつである。\nここでいう歴史の授業とは、前回のイテレーションやプロジェクトで何が問題だったか、どこを改善すべきかを調べるだけのレトロスペクティブである。\n具体的な改善方法については話し合わないため、変化は個々の作業者任せとなってしまう。\n不平不満を言い、責任をなすりつけあう、魔女狩りのようなレトロスペクティブも改善の役には立たない。\nそのため、これらの問題が出た場合は、レトロスペクティブの実施方法を見直し、改善する必要がある。",
"part_type": "part",
"localID": 19
},
{
"title": "デイリースタンドアップミーティング",
"description": "流用可能",
"part_type": "group",
"children": [
{
"title": "デイリースタンドアップミーティングとは",
"description": "デイリースタンドアップミーティング(daily stand-up meeting)とは、重要な情報をチーム内ですばやく共有するための集まりである。\nデイリースタンドアップミーティングは、デイリースタンドアップやスタンドアップ、デイリースクラムなどとも呼ばれている。\nまた、開催する時刻が朝の場合は朝会、昼の場合は昼会、夕方の場合は夕会と呼ばれることもある。\nデイリースタンドアップミーティングは、チームによるチームのための会議で、正式な会議として開催しないため、議事録は作られない。\n適切に実施されたデイリースタンドアップミーティングは、日々の成果をチーム全員が正しく認識し、目標に向かって一体となって進むために役立つものである。\n／＊／\nデイリースタンドアップミーティングは、決まった時刻に毎日開催される。\n決まった時刻とは、たとえば出社時刻の15分後や30分後など、チームがミーティングをおこなうのに都合のよい時刻である。\n福利厚生で自由に出社時間を選べる企業の場合、朝方の社員と夜型の社員がそれぞれ情報の同期をとれるよう、午前と午後に一回ずつデイリースタンドアップミーティングをおこなう場合もある。\nまた、デイリースタンドアップミーティングを二部構成でおこなう場合もある。\nたとえば、顧客には理解が難しい技術的な専門用語で話し合う開発チーム内のミーティングが第一部、誰がどのユーザーストーリーを担当するのか開発チームから顧客チームに対するミーティングが第二部という形式である。\nチームのメンバーが遠隔地で作業している場合は、テレビ会議でデイリースタンドアップミーティングをおこなうこともある。\n／＊／\n一回のデイリースタンドアップミーティングにかける時間は5分ほどで、長くても15分である。\nミーティングの時間を短くする工夫として、ミーティングで報告された問題やチーム全員に関わらない内容については、そのミーティングの中で深掘りせず、ミーティング後に話すこととしてホワイトボードや付箋などに書き留めておくことが挙げられる。\nまた、参加者全員が立ったままミーティングすることも、ミーティングの時間短縮の工夫のひとつである。\n立つことで机の下で携帯電話を操作したり、落書きしたりといったことができなくなる。\nさらに、長時間立ち続けると座りたくなるため、ミーティングが長引いたときに気づきやすい。\n腰痛や妊娠など健康上の理由、および種族の身体的構造で立つことが困難な場合、無理に立たせる必要はないが、他の参加者がチームの一員であると感じられるよう、視線の高さを合わせるなどの工夫をしたほうがよい。\n他の者が話している最中に割り込んだりしないよう、トーキングスティックを使うことも時間の短縮に役立つ。\n／＊／\nデイリースタンドアップミーティングで何について話すか、参加者が忘れないようにするため、あらかじめいくつかの質問項目をホワイトボードや付箋などに書いて掲示しておくとよい。\nたとえば、「昨日は何をしたか。それは世界をどう変えたか」「今日は何をするか。それは世界をどう変えるか」「チームの開発速度を下げているものはあるか。何が邪魔しているか」など、そのチームにとって必要な質問である。\n質問はチームの振る舞いを変えたり、新しいひらめきをもたらすような表現に変えてもよい。\n／＊／\nデイリースタンドアップミーティングに遅刻することは、作業の進捗状況や問題など、重要な情報をチーム内で共有することのさまたげとなる。\nそのため、デイリースタンドアップミーティングで遅刻した者には、今後の遅刻を防ぐ目的で、罰金などの罰を与える。\n罰は当事者自身が選ぶと時間を守る原動力となる。\nたとえば、運動の苦手な者なら遅刻一回につき腕立て伏せ30回、コーヒーが好きな者なら遅刻した日はコーヒーを飲まないなどとすれば、時間を守りやすくなる。\n遅刻することで、チームがどのように迷惑しているかを話すことも有効である。\n頻繁に遅刻する者は遅刻のたび、ホワイトボードに記名し、遅刻の頻度を当事者自身が自覚できるようにするのも遅刻防止に効果的である。\n／＊／\nデイリースタンドアップミーティングが適切におこなわれているかどうかは、レトロスペクティブなどで、ミーティングの有効性をレビューし、必要に応じてミーティングの形式に変えるよい。",
"part_type": "part",
"localID": 21
},
{
"title": "スクラムオブスクラム",
"description": "スクラムオブスクラム(scrum of scrum)とは、大規模なチームでデイリースタンドアップミーティングを短時間で終わらせるための工夫である。\nたとえば、六十名のチームが一名当たり1分で順番に話した場合、それだけで一時間が必要になる。\nそこでチームを少数名のサブチームに分け、それぞれのサブチームごとにデイリースタンドアップミーティングをおこなう。\nその後、各サブチームの代表者が集まり、ミーティングをおこなうことでサブチーム同士を連携する。\nこの代表者が集まるミーティングをスクラムオブスクラムと呼ぶ。\nたとえば、各六名のサブチームが一名当たり1分で話した場合、6分で終わる。\nその後、サブチームの代表者十名が一名当たり1分で話せば10分となるため、六十名のチームでも計16分でミーティングを終えることができる。\nスクラムオブスクラムは、ビッグデイリー(big daily)やデイリーシンク(daily sync)とも呼ばれる。\nまた、スクラムオブスクラムの内容のほとんどがデプロイとリリースに関するものの場合、リリースシンク(release sync)とも呼ばれる。\n／＊／\nスクラムオブスクラムは、スペシャリティ同期ミーティングとプロジェクト同期ミーティングの二回に分けておこなうこともある。\n／＊／\nスペシャリティ同期ミーティングとは、要求分析・開発・テストなどそれぞれの担当ごとに集まり、チームの垣根を越えてお互いの状況を話し合うミーティングである。\nたとえば、要求分析の担当者だけが集まって開催するアナリスト同期ミーティング(requirements sync)や、テストの担当者だけが集まって開催するテスター同期ミーティング(test sync)などがある。\nこの場合、要求分析の担当者は、開発者からの質問に答え、要求を明確にするために、各開発チームにそれぞれ所属しているが、システムの全体像の分析に専念するため、開発チームに所属しない担当者もいる。\nまた、状況に応じて開発チームで要求分析したり、システムの全体像の分析をしたりと、そのときどきに応じて必要な役割を担う担当者もいる。\nテストの担当者も同様に、各開発チームに所属し、機能レベルのソフトウェアテストやデバッグをおこなう者や、システム全体の概要レベルの結合テストやシステムテストに焦点を当てる者、両者の役割を必要に応じて柔軟に対応する者に分かれる。\nこれらの担当者ごとに最新の情報を持ち寄って話し合うことで、最新の状況を共有することができる。\nプロジェクトマネージャはそれぞれのミーティングを見て回りながら、プロジェクトとして解決すべき問題がないか探す。\n個別のミーティングに参加せず聞いているだけのこともあれば、プロジェクトマネージャが議論に混ざることもある。\n／＊／\nプロジェクト同期ミーティングは、スペシャリティ同期ミーティングの結果をふまえ、要求分析から本番リリースまでの、チーム間の仕事の流れに着目し、プロジェクト全体の視点から代表者が話し合うミーティングである。\nプロジェクト同期ミーティングは、チーム間の協同に関する課題を解決する場としても機能する。",
"part_type": "part",
"localID": 22
}
],
"localID": 20,
"expanded": true
}
],
"localID": 18,
"expanded": true
},
{
"title": "プランニング・ポーカー",
"part_type": "group",
"children": [
{
"title": "プランニング・ポーカーとは",
"description": "プランニング・ポーカーとは、作業工数を適切に見積もるための工夫である。\nプランニング・ポーカーは、主にソフトウェア開発で使われる。\nたとえば、一名の作業者が見積もると、その者が仕様をどの程度理解しているかによって、適切な工数よりも低く見積もられたり、高く見積もられたりする。\nまた、複数名で見積もりの会議をおこなうと、最初に発言した者や声の大きい者の意見に誘導されたり、専門外や作業担当ではないことを理由に見積もりの参加に消極的だったりすることがある。\nプランニング・ポーカーは、こういった問題を防ぐための工夫である。\n／＊／\nプランニング・ポーカーの手順は以下のとおりである。\nまず見積もりの参加者全員を実装するユーザーストーリーについて手短に説明し、要求仕様を理解するまでユーザーストーリーに関する質疑応答をおこなう。\n充分に理解できたところで工数が書かれたカードを選び、参加者全員で一斉に公開する。\nカードに書かれた工数の種類は、たとえば「S(小さい)」「M(中くらい)」「L(大きい)」「XL(とても大きい)」「∞(終わらない)」「？(わからない)」などが考えられる。\n事前にカードを用意できない場合は、カードの代わりに、相手から見えないように紙や砂地などに工数を書いたり、指の立てた本数で工数を表したりしてもよい。\n全員の出した工数がだいたい一致していれば、その工数が妥当と考えられるため、次のユーザーストーリーの工数を同様の手順で見積もる。\nもし、出した工数が大きく異なるようなら、数分ほど時間をとり、他の者がなぜその工数を出したのか、それぞれに黙考してもらう。\nその後、なぜその工数が適切と判断したか、参加者全員からそれぞれ理由や根拠を手短に述べてもらう。\nたとえば、「以前のプロジェクトで作ったプログラムを流用できそう」や「テストが大変」などである。\nそのうえで再度、参加者全員がカードを選び、公開する。\nここでも工数が大きく異なる場合は、このユーザーストーリーの工数見積もりを後回しにして、次のユーザーストーリーの工数を同様の手順で見積もる。\n後回しにしたユーザーストーリーは、他の見積もりが終わったあとで、時間をかけて議論する。\n休憩しやすくするため、「休(会議を中断して休憩しよう)」というカードを使う場合もある。\n／＊／\nプランニング・ポーカーの利点はいくつかある。\nひとつは、見積もりという孤独になりがちな作業をゲーム感覚で楽しくできることである。\nまた、参加者全員が自分の考えた工数を提示し、その理由を説明しなければならないから、工数を見積もるために充分な情報を得られるよう、参加者が積極的に質問するようになる。\nこういった質疑応答や議論によって、有益な情報が集まりやすくなる。\nたとえば「このユーザーストーリーは抽象的で分かりにくい」「テストがしにくい」「もっと単純なユーザーストーリーに分割しよう」といった意見である。\n参加者全員に発言の機会が与えられるため、参加者同士で知識を共有し、お互いの観点や価値観を理解する助けにもなる。",
"part_type": "part",
"localID": 24
}
],
"expanded": true,
"localID": 23,
"description": "流用可能"
}
],
"expanded": true,
"localID": 0,
"description": "流用可能"
}
]
最終更新：2021年04月04日 20:56
