JIRA Portfolio でカンバンプロジェクトの管理をはじめる

この記事は、Atlassian User Group Tokyo Advent Calendar 2016 21日目の記事です。

qiita.com

--

恒久的な機能改善・メンテナンスが必要となるサービスにおいての究極は、ユーザーに対してより高い価値をデイリーでデリバリ することです。 私はこれに最も近づけるプロジェクト管理方式としてカンバンが有効であると考えています。

カンバンについての詳しい解説は書籍等を参照していただければと思いますが、カンバンにも当然弱点があり、それは計画性が薄いことだと認識しています。（長所でもあります） 計画性が薄いことで出る悪い影響として、課題ごとにいつデリバリされるのか予測しにくいことが挙げられます。 これはカンバン運用上の大きな問題となりえますし、まだカンバンを導入したい際にも大きな障壁となりえます。

JIRA Software のオプションである JIRA Portfolio は、ちょっといじってみたところカンバンの計画性の弱さをうまいこと緩和してくれそうです。 で、Atlassian の製品全体的に言えることですが、最初の使いかたのキャッチアップにま〜〜時間がかかりがち。ということで、本当に JIRA Portfolio でカンバンプロジェクトを管理できるようにしてみたところまでを共有します。 これでなんとなく導入部分のイメージをつけていただいた方々によって、さらに進歩的な使いかたを共有されることを願って…。

手順

1. カンバンプロジェクトおよびカンバンボードを作成しておく。
2. 計画（プラン）を作成する。
3. どのカンバンプロジェクトからプランをつくるか選択する。
4. プランに含めるバージョンを選択する。
5. プロジェクト管理にカンバンを用いることを選択する。
6. プランのスコープに入れる課題を選択する。
7. ステージ（開発工程）を作成する。
8. ステージごとに必要なスキルを設定する。
9. プランにメンバーをアサインし、週のアサイン可能時間を設定する。
10. アサインしたメンバーごとに担当させる工程・スキルを設定する。
11. 課題ごとの見積もりを設定する。

長いですががんばります。よくわからない単語の使い回し等になれればサクサクははずです。

1. 計画（プラン）を作成する。 プランに名前をつけるだけです。ここでは傲慢な地球人を粛清するための計画を起案します。 終わったら Next をクリックします。

2. どのカンバンプロジェクトからプランをつくるか選択する。 すでに作成されているカンバンボードをプランのソースとして選択します。 終わったら Next をクリックします。

3. プランに含めるバージョンを選択する。 このプランに含めるバージョンを選択します。あとで作成することもできます。ここでは開戦準備からジャブローにコロニーをこんにちはさせるまでを計画に入れます。 終わったら Next をクリックします。

4. プロジェクト管理にカンバンを用いることを選択する。 スクラムを選択してスプリントの管理もできます。が、ここではカンバンを選択します。 終わったら Next をクリックします。

5. プランのスコープに入れる課題を選択する。 ソース内にある課題のうちどこまでをプランのスコープにいれるか個別に選択します。 終わったら Done をクリックします。 これでプランの作成は終わりです。

6. ステージ（開発工程）を作成する。

7. ステージごとに必要なスキルを設定する。 ステージを作成します。ステージは "開発工程" と考えてよさそうです。 またステージごとに必要なスキルを設定しておきます。スキルは "技術分野" "作業カテゴリ" といった訳が近そうです。 サンプルとして分析・開発・テストをつくっておきます。

8. プランにメンバーをアサインし、週のアサイン可能時間を設定する。

9. アサインしたメンバーごとに担当させる工程・スキルを設定する。 右上の Teams をクリックしたら表示される画面でこのプランに参画するメンバーを選択します。 またメンバーごとにこのプランに参画できる週ごとの時間と、メンバーごとに担当させるステージ・スキルを設定します。 ここでは地球に対する恨みが強いメンバーを選出しました。

10. 課題ごとの見積もりを設定する。 Scope をクリックして元の画面に戻り、課題ごとに見積もりを登録していきます。 見積もりは各ステージ・スキルごとに登録できます。

結果

右上あたりにある Show timeline を見てみます。 先ほど入力した課題ごとの見積もり、アサインされたメンバーのスキルを見て各 Epic の開始可能日と完了予定日が視覚的に表示され、かつ勝手に最短プランを計画してくれてます。 Epic をクリックすると 各 Epic の開始可能日と完了予定日が表示されます。これは便利。 ビューを切り替えるとこのように課題ごとの工程単位での予定を見ることもできます。

つまり JIRA Portfolio によると、この作戦は 2016年1月4日に開始できた場合同年2月24日までにジャブローへのコロニー落としが成就するようです。

Capacity ビューをつかうと、各週での稼働時間の見込みを見ることができます。 ここで稼働見込みが余ってそうであれば、課題の優先順位を入れ替えたり、ボトルネックとなる工程に強いメンバーに参画してもらうなどの対応が考えられそうです。 逆に見込みが100%をオーバーしている場合はメンバーを追加で参画させたり課題を減らしたりすることが考えられそうです。

またこのほかにバージョンごと、課題事に開始日、完了日を固定で設定しておくことも可能です。 複数プロジェクトをここで一元的に管理・運用することもでき、スクラムプロジェクトも併存させることもできます。

まとめ

JIRA Portfolio を使うことでビジネスサイドの方でも誰でもどの課題がいつから対応が開始されて、いつごろデリバリされそうなのかを確認することができそうです。 ちょっと細かいところで、本当に実運用に耐えうるのか心配になることは多いのでしばらく様子見かなとは思っていますが、1.0 から 2.0 になるにあたって相当に進化していることがわかりますので、継続してウォッチしていきたいと思っています。 ぜひ検証されてみて、もろもろ情報交換させていただければこれ幸いでございます。 立てよ国民！！

今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント

カンバン仕事術

発表資料公開しました。-- カンバン基本の基 - 社内ランチ勉強会発表資料

弊社では毎週だいたい水曜日のランチタイム、任意参加でランチ勉強会をやっているのですが、10月12日は私の会でした。 ということで最近すっかりご執心のカンバンについて発表したので Speaker Deck で公開しておきました。

(公開用)カンバン基本の基 - 社内ランチ勉強会発表資料 // Speaker Deck https://goo.gl/zyftKi

なかなか反応良かったので来週もまた近いテーマでやろうかと。。。

プロジェクトに正しくセーフティ（保険）を乗せるための考え方

プロジェクトの開始時に余裕をもったスケジュールをたてたのにも関わらず、 気づけばいつも崖っぷち、もしくはもう崖から落ちてしまっているといった経験はプロジェクトに関わる人ならよく見かける光景だと思います。せっかく顧客やプロダクトオーナーなどのステークホルダーに対して、プロジェクト開始時にあれやこれやと根拠付けをして少し罪悪感を感じるほど甘く見積もっているならば、プロジェクト後半や終了後に大いに顰蹙を買うでしょう。

この記事ではその余裕（"セーフティ"と呼称します。）がどうしてことごとく神かくしにあってしまうのか、計画時に潜む原因のひとつである「タスク単位でセーフティを乗せてしまう問題」の紹介と、その解決策のひとつである セーフティプール を用いる方法について述べています。

リスクを担保する手段としてのセーフティ

ソフトウェア開発に関わらず、プロジェクトをはじめるにあたって（アジャイルであろうとウォーターフォールであろうと）それがビジネスである限り計画づくりは必要なプロセスです。 計画づくりにあたっては、対応アイテムをタスクに分解し "工数見積もり" をすることになります。

さて、この "工数見積もり" ですが、どんなに優秀な人物であっても将来掛かるであろう工数を完璧に読み切ることはできません。 みなさんが毎朝会社に出勤するとき、会社までの道のりは毎朝同じなのにも関わらず、到着する時間が一定でないように、どんなに自分が気をつけていても、他の通行人がみなさんの通行を邪魔しないとは保証されていませんし、信号が奇跡的に毎日青信号であることはまずありませんし、みなさん自身の体調が常に整っているとも限らないからです。 それらは殊更ソフトウェア開発プロジェクトに関わっている方であれば言うまでもないことであり、どのような形であれ身を持って（しばしば痛い思いをしながら）経験されています。

さて、このような経験をされてきた開発者は、冒頭の "工数見積もり" をプロジェクトマネージャー（以下PM）から指示されたときにどのような検討をするでしょうか。 ここでよく見られるのは、分解されたタスク単位で数%のセーフティ、つまり本来必要と思われる工数に対して 何かあったときのための保険 を乗せることです。

図1：セーフティとは

セーフティは、リスクを担保するためのひとつの方法として有効です。 もし想定されていたリスクが発生しなかった場合は、その分ほかのことをやればいいだけですので、ここに問題はありません。 「保険」のためですから、リスクが発生しない場合でほかにやることがない場合は「あわよくば」前倒しで進めることができます。これはプロジェクトにとって大変嬉しいことです。

神かくしにあうセーフティ

しかし、このセーフティの乗せ方を間違えると、その「あわよくば」はほとんどの場合訪れることはありません。 現実、プロジェクトをはじめてみると、残念ながらタスクが前倒しで終わったという『報告』が来ることはほとんどありません。 それどころか気づいたときには、あったはずのセーフティがことごとく消えてしまっています。 そもそもセーフティは「保険」なのですから、それがことごとく無くなっているようであればそれは見積もりがまずかったということです。 しかしなぜセーフティが神かくしにあったかのように、ことごとくいつのまにか消えてしまうのでしょうか。

ここで「セーフティが足りなかったのではないか」という仮説をたてることができます。 もちろんリスクの見積もりが甘かったということであればそのようなケースはありえますので、検討の余地は常にあると言えます。 ただあまりこの仮説だけに偏って考えすぎると、セーフティにセーフティを重ね続けて しまうことになり、「見積もりの雪だるま式的な肥大化」を招いてしまいます。 このことはプロジェクトにかかるコスト増大、もしくは製品品質の低下を簡単に招いてしまうため注意が必要です。

しかし実は、タスクの前倒しは必ずプロジェクトのどこかで起こっています。 「何かあったときのための保険」なのですから、ほとんどの場合保険を使わないで良いはずですし、異なるタスクを実施しているといっても同じソフトウェアの開発をしているのですから関連性があります。 そのため、プロジェクトが進むにつれて生産性は上がり、前倒しが起きて当然なのです。 （往々にして見積もり時にはプロジェクト進行による生産性向上は想定されていません。）

問題は、タスクが前倒しで終わった、または終わりそうなとき、そのことが『報告』されないことです。 とはいえ、ここでは報連相の重要性をお伝えしたいわけではありません。 当初見積もっていた工数に対して、前倒しで終わったことを報告した場合に起こることを想像すると、その理由は明快です。

頑張ってはやめにタスクが完了した場合、せっかく頑張って浮かせた時間ですので、自学の時間に充てたり、ネットサーフィンをしたり、また優秀なメンバーであるほど複数プロジェクトを掛け持ちしていますので、別プロジェクトのタスクの対応をはじめて自分をさらに楽にさせようとします。 しかし予定より早く終わったことを報告してしまうと、ほとんどの場合そのあとに対応する予定だったタスクを前倒しで対応開始するよう指示されるか、遅れが出ている他メンバーのタスク肩代わりを指示される可能性があります。 つまり、早く終わったことをを報告しても、プロジェクトにとって利益はあれど、個人にとっては対応する必要のなかった仕事が増える可能性が高くなるため、多くの場合報告されることはありません。 これがセーフティが保険であるにも関わらず、ことごとく神かくしにあってしまう理由です。

図2：セーフティがなくなる理由

セーフティはプロジェクト単位やイテレーション単位で乗せる

それではセーフティを乗せることが悪なのでしょうか。

冒頭にもあるとおり、見積もり担当者がいくら優秀であっても完璧な見積もりを常に出し続けることはできません。 その要因として最も大きいのは、ソフトウェア開発のプロジェクトと、モノの生産ラインで最も異なる部分である、ソフトウェア開発ではまったく同じ成果物を繰り返し生産することが基本的にありえないことです。 そのため、ソフトウェア開発プロジェクトでは常に新しいことにチャレンジすることになりますので、当然そこには不測の事態、リスクが多めにつきまといます。

そのリスクを担保するためにセーフティを乗せることは悪ではありません。 むしろどんなタスクであってもセーフティを乗せようとしない人は、単純に見ればストイックでプロフェッショナルな人に見えるかもしれませんが、相当腕ききで経験豊富でない限りは限りなく適切に近いセーフティを乗せたほうがみんなにとって賢明に思えます。

問題なのは、セーフティをタスク単位でタスクに対してそれぞれ乗せてスケジュールを計画してしまうことです。 タスク単位で見積もってしまうからこそ、図2で示したように、合法的にセーフティを使いきってしまうのです。 1つや2つであれば大した問題ではありませんが、プロジェクトの規模が大きくなればなるほど複数箇所でセーフティの浪費が起き、 結果的にコストの増大やスケジュールの遅延、品質の低下につながってしまいます。

ではどう乗せればよいのかと言うと、一つの解決策として、 「セーフティをプロジェクト単位、または イテレーション の単位で乗せる」ことを推奨しています。 私はこのとき乗せたセーフティの集合を セーフティプール と個人的に呼称しています。

図3：セーフティプール

このようにすると、各タスクの担当者はそのタスクにかける工数をセーフティなしの工数を見て動きます。 つまりセーフティプールにてリスクは担保しつつもそのタスクに対してそれぞれセーフティが割り当てられていないため、セーフティを見てペース配分したり報告をあえて行わないなどの問題は起きにくく、完了の報告がより適切に届きやすくなります。 また、セーフティプールは原則プロジェクトチームの共有物になりますので、あまり消化してしまうとチーム全体に影響が及びます。そのため、コミットしたターゲットを守るということに対して、良い塩梅の緊張感を生むことにも繋がります。

セーフティはリスクに対して見積もる

次に課題となるのはセーフティの見積もりです。 私はセーフティは事前に洗いだしたリスク要因に対して見積もられるべきだと考えています。 私は現在チームに対して、プロジェクト開始時に「プロジェクトキックオフミーティング」を開催し、必ずメンバー全員が出席のもとアイテム/タスクに対してリスクの洗い出しをするように指示しています。 これはスクラム開発でいうインセプションデッキというフレームワークにて用いられる「夜も眠れなくなるような問題は？」いうセッションです。 ( 参考：インセプションデッキ | ネスケラボ )

リスクの例

• このタスクでは初めて使用するライブラリを用いる可能性があるため心配。
• このタスクではまだ技術的調査が必要なため、現時点では厳密な見積もりができない。
• ビルド完了しても、App Store の審査が通るかどうか懸念がある。

上記のような洗い出されたリスクに対して、どの程度のセーフティを見積もるべきなのかをチームで協議し、合意のもとセーフティプールに追加します。 しかし、リスクは解決方法が判明していないからリスクであるため、ある程度見積もりのファニーさは許容する必要があります。 （その精度を上げていくためには見積もりスキルの向上が必要ですが、この記事では言及はしません。）

最後は文化的アプローチ

この記事では、セーフティを適切にとることによって、プロジェクトを健康に遂行するための方法を提案させて頂きました。 この方法はあくまでもセーフティに対してのアプローチであるため、タスクがセーフティを除いた見積もり工数より前倒しで終わった場合、それが適切に報告されることを促進されるわけではありません。

私は正直、メンバーが努力なり工夫するなりして早く終わったのなら、浮いた時間は自由に使ってくれればいいと思っています。 ただ一方でもし後ろにより大きなリスクを抱えているようであればできるだけ前倒しすべきです。

そこで結局効果があるのはアジャイル開発でレフトウィングと言われる、朝会や日報などの「文化的アプローチ」です。 いわゆる鬼詰めする必要はありませんし常に疑ってかかる必要はありませんが、毎日定期的に報告の場を設け、可能な限り具体的な報告をして貰うようチームに促し、前倒ししたい場合は前倒ししたい理由をしっかりと共有しさえしていれば、メンバーはどういう形であれプロジェクトの成功を願っているわけですから、前向きに協力してくれるはずです。

逆に言えば結局どれだけ計画づくりを論理的にしても、ここを逃げてしまうとチームのていをなすことはないでしょう。

参考書籍

この記事を書くにあたって、エリヤフ ゴールドラット著の クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか? を参考にしています。 キーワードである「セーフティ」はこの本で用いられている用語です。

いわゆる「制約条件の理論(TOC理論)」と「クリティカルチェーンマネジメント」について物語調で学ぶことができますので、 プロジェクトマネジメントに興味のある方はぜひ一読をおすすめします。

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

■

あらゆるスタートアップ/ベンチャー企業には決して他人ごとではない話。

kazuna.li

「御社の経営体力にも不安はあります」

これは僕がPM/営業時代に何度か商談中に言われた言葉で、今でもフロントメンバーはたまに商談で聞いていると思う。 弊社って実際ひいき目なしにすばらしいユーザー基盤を持っているのだけど、（特に大きな）ユーザーは選定の段階でかならず弊社の経営体力に不安を感じていて、それでもいろいろな要因、将来的な期待も含めて判断してサービスを買ってくれている。 サービス提供者としては、このことを強くを認識して、それに答える意識、努力をしていく義務がある。 決してネガティブな話ではなく、それほどそのサービスが自社に与えるポジティブな影響を期待していてくれているということであって、競合によっぽど背後に巨大な資本力を持つサービスはあるにも関わらず選んでくれているのは素晴らしいことだし、その期待に対して責任を持って応えていきたい。

退職者が出た場合の JIRA アカウントの無効化

残念ながら退職者が出てしまった場合、退職者が利用していた JIRA のアカウントを無効化する必要がある。 JIRAでは、その場合アカウントを削除するのではなく、アカウントの JIRA へのアクセス権を剥奪することで対応する。

アカウント毎の JIRA へのアクセス権剥奪方法（管理者のみ）

1. USER MANAGEMENT > Application access にアクセス。
2. アクセス権を剥奪したいユーザーを検索して選択。
3. JIRA に付いているチェックを外す。

以上

なぜアクセス権の剥奪なのか

JIRAでは、アカウントが何らかの課題の報告者であったり、担当者であったり、またコメントを投稿していたりすると削除できない仕様。 また削除できてしまうと、今での履歴に穴ができてしまうので、よろしくない。 （誰が書いたコメントなのかわからない、誰が報告した課題だったのかわからない、など。）

そこで、ユーザーアカウントは残しつつ、アプリケーションにアクセスできないようにしてあげれば、 諸々の履歴は残りつつ、かつその人がどんな人で、どの部署に所属していた人かもわかる。

勿論、JIRAへのアクセス権を剥奪した段階でライセンスは無効になるため課金対象から除外される。

エンタープライズソフトウェア企業は文化で組織する。（『隠れた人材価値』より）

　先日東京でお会いした方の紹介で、『隠れた人材価値―高業績を続ける組織の秘密 (Harvard Business School Press)』を読んだ。

隠れた人材価値―高業績を続ける組織の秘密 (Harvard Business School Press)

　本書内では、下記の7つの会社のサクセスストーリーを人材戦略というカットで述べられている。

サウスウエスト航空 / シスコシステムズ / メンズウエアハウス / SASインスティチュート / PSSワールドメディカル / AESコーポレーション / NUMMI

　本書の切り口はこうだ。
「ビジネスモデルが特段イノベーティブであったわけでもない、これらの企業が一体どうしてこれほどまでの成功を収めたのか？しかもそれを他の大会社が真似しても、決して成功し得なかった。これはまさにミステリーだ！」

　成功の要因についていくつか述べられているが、 一貫して強調されているのは、以下の2点にまとめられる。

• 真に従業員満足を重視した。
• 『文化によるインテグレーション』を重視した。

シスコやSASインスティチュートの章で述べられているように、人材側が超売り手市場であった（現在もだが）当時のシリコンバレーのコンピューター関連企業と比べるとべらぼうに高い報酬を与えているわけでもない。
それなのに離職率は非常に低く、一桁パーセントであり、社員の満足度も高い。
それに伴って顧客満足度も高水準となる理想的なスパイラルができあがっている。
例示された企業は、従業員の満足を真に重視し、素晴らしい労働環境を用意されることで、生き馬の目を抜く業界でもそれぞれ圧倒的な顧客満足を実現し、競争を勝ち抜いてきたというわけだ。

　話が少し逸れてしまうが、エンタープライズ分野の（大規模でない）ソフトウェアカンパニーが目指す1つの形だろうと思う。
エンタープライズでは、瞬間で潤沢なキャッシュフローを得る機会が極めて少ないため、 いきなりスーパースター人材を次々と獲得し、個人のパワーで競争を勝ち抜くという芸当が難しく、 現有戦力を中心としたチーム力での勝利が自然と要求される。 ただ、決してそれはマイナスではなく、チームでより大きな成果を出すという経験ができるし、それは相当に尊い。 エンタープライズという特徴を活かして、腰を据えてチーム力や技術力の向上にも力を注げる。 例えば私が所属する会社であれば、波はあるものの、他の地方ソフトウェア企業とは比べ物にならないくらい、帰宅時間は早いし、その分新しい知識の習得に時間を使えている。
サービス提供形態が年額または月額による課金形式であるために、当然継続的な Add value が要求される。そのために新たなチャレンジをする継続的な動機付けもある。

　ただ、転職市場において、やはりエンジニアやセールスは圧倒的な売り手市場だ。 潤沢なキャッシュフローを持つ企業からの引き合いは常にあり、技術力をつけるのはどの会社でもその人次第で可能であるため、 より条件の良い企業に流れるのは経済合理性から見ても正しい。

　そこを文化、更に掘り下げると、価値観を以て自社に従業員をインテグレーションし、かつ真に従業員を重視し続けた結果、 圧倒的な従業員満足と顧客満足度を獲得したのが本書で述べられた 7 社なのだろう。

　ちなみに、本書の初版は 2002 年であるが、少なくとも2014年時点でシスコは世界最大のコンピュータネットワーク企業の地位を盤石に保っているし、SASインスティチュートも、FORTUNE 紙 の「100 BEST COMPANIES TO WORK FOR（最も働きがいのある会社ベスト100）」にて 2010-2011年連続で1位を獲得し、2013-2014年もGoogleに次いで2位を獲得しており、安定した市場基盤を保っている。

隠れた人材価値―高業績を続ける組織の秘密 (Harvard Business School Press)

　また、文化で組織をリードした会社といえば、DEC社が有名であり、古典的名著『Engineering Culture（邦題：洗脳するマネジメント）』にて詳細が民族誌の形式で述べられている。ただし残念ながらDEC社は（原因は様々語られているので割愛するが）コンパックに買収されてしまったため、企業としては既に存在していない。

洗脳するマネジメント~企業文化を操作せよ

アトラシアン社のセミナーに参加しました

9月26日に、東京は八重洲にてアトラシアン社のセミナーが開催され、社命にて参加した。 参加したのは以下の2つのセミナー。

詳細な内容については、上記のリンク先を参照頂いたほうが早いので割愛。

全体的にはアトラシアン社の製品郡を使えば、開発者にとって素晴らしい世界が待っているよ！というのが全面に押し出されていた。私も JIRA や Confluence、Bitbucket などについては導入を前提として評価中だが、思い描いていた運用イメージが想像よりも一回り素敵な感じで実現できそうなことがデモを通して感じることができた。

恐らく、このセミナーに来ている人たちは、ある程度はもう運用イメージがついていて、Git をはじめとした DevOps 支援ツールは導入したほうがいいに決まっている！と思っている人が多かったのではないだろうか。そういった潜在顧客層に対して、+αをもった確信を持たせることのできるセミナー内容だったように思う。

同時通訳の切り替えのスムーズさなど、運営も素晴らしかった。勉強になります。

このご時世、東京にいなくても情報自体は入ってくるが、Face to Face での Q&A やネットワーキング、ユーザー会といったコミュニケーションは、福岡では気軽に行うことができない。ただ相応に価値はあるように思えるので、定期的に東京に出ていければと思う。