冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

JIRAで社内テストから課題を収集する

チームビルディング その他

ちょっとした準備です。

社内テスト用のステージング環境を公開して触ってもらうことはよくやりますね。MallNaviでもプロダクトマネージャの受け入れテストだけでなく、ステージングを使ってもらって、より広いユーザの意見として社内から課題を集めて生かしていきたいわけです *1 。これらを効率的に、なるべく手間なく集めるための仕掛けをJIRAで設定してみました。

やりたいこと

  • ステージング環境使いながらシームレスに課題を作れて
  • ログインせずとも課題の検索や参照ができること

課題の参照や検索は、課題を上げるにしてもダブりとかないよね？と気にしてくれる人がいるので、その方の好意に答えるためのものです。ありがたや。

AsIs

redmineに課題作成用のユーザとサブプロジェクトを作って、ユーザ名とパスワードを社内に向けて公開しています。セキュリティ的にもあまりやるべきことじゃないですね。ちなみに、匿名ユーザのアクセス自体はredmineでもできるので、今回対応したのはJIRAじゃないとできないことばかり、というわけではありません。単純に、匿名ユーザの存在を忘れてスタート切ってしまっただけです。

匿名アクセスと課題コレクター

で、今回は上記の要件を匿名アクセスと課題コレクターを使って実現します。

JIRAでの匿名アクセス

まずは課題の参照について。匿名ユーザがプロジェクトの課題を参照できるようにします。

匿名アクセス自体は公式ドキュメントにも書いてある基本的なものです。

プロジェクトに匿名アクセスを許可する - アトラシアン製品ドキュメント

注意すべき点としては、プロジェクトスキームくらいですね。既定のスキームを使っている場合は、スキームをコピーして適用し直してから権限を変更したほうがいいでしょう。既定のスキームを変更してしまうと、プロジェクト作成時に必ず適用されてしまうため、社内でもごく限られた人が参照するプロジェクトだとかも同様に参照できるようになってしまいます。既定の権限スキームはプロジェクトロールを基本に割と狭く作って、プロジェクトごとにコピーして適用する、という形にしたほうが運用がうまくいくと思います。

課題コレクター

そして、ステージング環境使いながらシームレスに課題を作れるようにします。これはredmineの基本機能では該当するやつが見当たらなかったんですよね。JIRAの課題コレクターという機能を使います。

課題コレクターとは、プロジェクトの課題作成を外部のサイトで行うための埋め込みフォームを作るための機能です。埋め込みフォームはHTMLかjavascriptを選択することができます。プロジェクトごとに複数の課題コレクターを作ることができます。

これも公式ドキュメントに書いてある基本的な機能です。

課題コレクターの利用 - アトラシアン製品ドキュメント

課題コレクターにはコレクターの報告者を指定する必要があります。プロジェクト内のユーザを指定してもいいのですが、プロジェクトから外れたときなど面倒なので、専用のユーザを作り、課題作成と割り当て権限だけ与えて *2 コレクターに設定しています。

課題セキュリティスキームの検討

課題セキュリティスキームは、課題の種類とプロジェクトロールなどを元に課題に対するアクセス権限をコントロールするための機能です。より、経営に近い意思決定やプロジェクト内で見せたくないもの、課題コレクターを顧客向けに公開する場合は顧客に見せたくないものを設定するといいのでしょうが、今回はまだそこまで隠す情報はないので、設定を見送りました。

なんか組み込みの機能でできた

最初、ServiceDeskを導入しようか、という話をしていたんですよ。やりたいことだけ考えるとJIRAの組み込み機能だけでできたので良かったですね。

今後

Confluenceの導入検討を進めているので、課題状況のレポートなんかがそっちで出せるといいのかなあ、とか妄想中です。

広告

こんな感じで、情報集約がスムーズに進むように整備しながら開発を進めております。まだまだ成長途中のサービスではありますが、MallNaviをよろしくお願いいたします。

mall-navi.com

*1:必ずしもターゲットではないので、対応するかどうかはプロダクトマネージャ判断

*2:これも全プロジェクト共通というわけではないので権限スキームは分けておいたほうがいい

Atlasssian Tools利用のスナップショット

こういうことをやっていました。そのうち、開発のカンバンが欲しくなりWaffle.ioを導入したりしてツールの関係はさらに複雑になってくるのと比例して、情報の同期を取るのがしんどくなってきました。

mao-instantlife.hatenablog.com

それを解消するためにちょっと身銭を切って、Atlassian Toolsを導入して検証しています。2イテレーションほど回して、FeatureMapとWaffle.ioはプロジェクトから切り離して情報の同期も少なくなったので、開発チーム内のみで本格採用しています。

このエントリは、その間で試してみたことや、現時点での運用についてまとめます。

前提

元のツール構成になった理由を整理してみましょう。手作業での同期も辞さなかったのは、プロジェクトに関わる各レイヤー、フェーズによってみたい情報の質と見せ方が変わる、という仮説に基づいていて、それは変わっていません。

各役割

  • FeatureMap => ストーリーの構造化
  • Github + Waffle.io => ストーリーの進捗可視化
  • redmine => プロダクトマネジメントタスクの進捗可視化とビジネスサイドも必要な各種ドキュメントの管理、ロードマップの可視化

問題点

もうそれ以外ないんですが、それぞれのツールが連携していないので、動機を取るのに人間の手作業が必要だということです。特にロードマップの計画のズレなんかがステークホルダーと生じてしまうと目も当てられません。

置き換え

Atlassian User Group 中国地方勉強会中にJIRA向けのアドオンや他の製品を見ていたら、ちょっとの身銭でいけるんじゃないかな、と思うようになってきたので1か月の検証期間を設けてみることにしました。ちなみに、身銭でスターターライセンス買ったのは、会社で本格的に導入する時には新規にライセンス購入してもらって、スターターライセンスは自分のプライベートマシンに検証用に引き上げることを想定しているからです。

というわけで、以下のような構成で仮運用がスタート。

  • JIRA => チケット管理
  • Agile Story Map for JIRA => ストーリーの構造化
  • Portfolio for JIRA => ロードマップの可視化

ちなみに社内サーバに構築しています。評価期間が終わったのでHSQLからPostgreSQLに乗り換えようとしたら、エラーで立ち上がらんようになった話はちょっと別にまとめます。

利用の流れ

JIRAで統一できるようになっただけで、以前のツールから計画や管理の流れはあまり変わっていません。

  1. ユーザストーリマップでストーリーのロードマップを計画
  2. ストーリーマップを元にPortfolioでリリース計画を作成(見積もりのキャパシティ)
  3. リリースに入ったものをカンバンで進捗管理
    1. 簡易見積もりができたチケットから「開発予約」レーンに
    2. コードレビューが終わったら「受入テスト中」レーンに
  4. リリース後にふりかえりしてバージョンをリリース
    1. リリース作業そのものの確認と次回の改善タスク
    2. イテレーションの見積もりを再確認(精度の話)
    3. 次期イテレーションの計画と設計

これらを同じデータソースを使いながらビューの切り替えで把握することできるのがかなりストレスフリーです。

カンバンのワークフロー、トランジションはデフォルトから変更しておらず、レーンと必要なフィールドを運用に合わせて追加しただけです。

とりあえず開発では本格導入決定

2イテレーション試して、FeatureMapもWaffle.ioもなくて困らない、という結論になったので開発チームでの移行は完了しました。

次の段階でビジネスサイドを巻き込もうかと思っています。まずは、ビジネスサイドの実務者レベルで使い方を広げてみて、というところですかね。

ConfluenceとService Desk(これは課題コレクターでいいのではないかという考えもある)を試してドキュメントやビジネス系タスク管理などを一緒に行ってもらうことを考えています。

以下、管理上のメモ

ユーザ管理

  • 匿名ユーザは使えない(おそらくService Deskでは可能)
  • ユーザグループは一度作成したら名称変更はできない模様
  • パーミッションスキームはグローバルなのでユーザグループではなくプロジェクトロール当てた方が管理が楽
  • プロジェクトロールはグローバルな設定として追加(設定 > システム > プロジェクトロール)

まだ使っていませんが、課題レベルのセキュリティという機能があるので、セキュリティ上見せたくないチケットをパーミッションスキームでコントロールとかしなくていいようです。チケットごとにコントロールできるようになるため、基本誰にでも見せるようにして課題レベルで参照をコントロールするのが良さそうですね。

要注意事項

Portfolioの参照、管理権限には必ずjira-administratorを入れて、ユーザグループやらプロジェクトロールやらは本格運用開始する前にある程度固めておきましょう。Portfolioの参照権限を使っていて、

ユーザグループ作成 > グローバルなパーミッション変更 > 見直し

の流れで取り組んで、

プロジェクトロール追加 > パーミッションスキーム見直し > ユーザグループ再作成(名前変更できないし)

したら、ユーザグループに紐付けてる計画まで参照できなくなりました。

PortfolioとEasy Agile Story Map for JIRA

  • PortfolioとStory Mapでロードマップと価値の計画をする
    • 計画は見通すもの
    • ラッキングを精緻にするのはまた別の話
  • EpicはStoryマップの縦軸(アクティビティ)、Portfolioのユーザにとって意味のある大きな計画単位として捉える
  • StoryはStory Map上の分割ステップ、Portfolioの分割ステップとして捉える

トラッキング項目について

  • バグや個別に出てきた課題(タスク)などはエピックに紐付かなくてもいい運用とする
  • Portfolioでタスクもトラッキングして計画に入る設定にした
  • 重要視すべきは次以降のイテレーション計画とキャパシティ(ベロシティ上限コントロール)

プロジェクトスタイルとアドオン

  • Easy Agile User Story MapはScurmプロジェクト前提で、カンバンだとエラーがでる
    • プラグインがバージョンアップして対応
    • ただし日本語で使っていると課題タイプ名の変更が必要(課題タイプ名にEpic, Storyが入っているかで判断しているため)
    • カンバンボードで使う場合はエピックが必須になるので、簡易フィルタで見えなくする扱いができなくなった
      • エピックはラベルに近いので完了をしない
      • とりあえずエピックの優先順位を暫定的にLowestにした

作業ログの記録の仕方

  • デフォルトの設定では作業ログ記載できないので、時間トラッキングをonにする
  • 見積もり時間を使い切ってしまう作業ログを記録すると、Portfolio上の進捗は終わった扱いになる
    • 進捗管理はカンバンボードでしているのであまり気にしていない
  • プロジェクトの見積を Story Point -> Hour(1 * 2)で運用開始(Portfolio上)
  • 残がなければリリースはクローズにする

受入テストについて

ここがまだ運用としていけてないというか固まってないところです。ちなみにFeatureMapの時は、ストーリーにチェックボックスが作れたので、それでテストシナリオを作成していました。同様にTODO付けられるアドオンを探したんですが、7.1.9までしか対応してないようで、インストールすると警告が出るので、まだ導入を見送っています。

とりあえずの代替案としては、テキストのカスタムフィールド + テキストのマークの表現でなんとかする形に落ち着きました。(i)と(/)と(x)で表現されるマークで進捗を見れるようにしています。

ステークホルダーへの定期報告について

おそらくJIRAを導入したからといって、今redmineを見ない人が急に見てくれるわけではないので、定期報告みたいなものは結局なくならないし、続けた方がいいとは思っています。ただ、リリースの画面 or ScrumボードのバージョンレポートのPDF印刷が見栄えが良いことに気づいたので、次の定期報告からそれを使ってみようかと思います。

Githubとの連携

  • OrganizationでOauthキーとシークレットを発行してログインするだけ
  • コミットメッセージに課題IDをつけることによって自動的に連携
  • ポーリングしているようなので状況の反映には少し時間が掛かる

各スキームについてのとりあえずの理解と設定

  • 課題タイプスキーム > どの課題をセットにして使うか
  • ワークフロースキーム、ワークフロー > 状態遷移の定義(どういう遷移が可能か？)、だいたいデフォルト
  • 画面スキーム > ボード(プロジェクト)ごとの課題作成などの画面構成とそのスキーム、どの画面にどの項目を表示するか、課題のタイプごとに画面スキームを分けることができる
  • フィールド構成スキーム > フィールドと画面の紐付け、必須かどうかの決定などを行う

課題(というか要調査とかやりたいこととか)

社外からもアクセスできる環境への以降

  • 出張中とか自宅作業中とか
  • HSQLの検証環境にして運用しているので、外部データベースに移したい
    • 失敗したので再チャレンジ

タスクの完了とPortfolioの計画トラッキングの問題

  • カンバンでストーリーを完了したら、Portfolio上のリリースから消えてキャパシティが減った
  • 進捗度合いがあんまり見えないが、今は計画ビューとして割り切っている
    • 作業ログを入力すると進捗は見える
    • 完了の定義をどう運用しているかいろんな人に聞きたい

PortfolioのStageとSkill

  • 現状使っていない
  • カンバンのワークフローというよりも人員計画で主に使う
  • 仮想的人材を計画してステークホルダーへの要望出しとか

ServiceDeskを導入検討

  • 社内からの要望の起票や参照を匿名ユーザからできるようにしたい
  • 課題コレクターとプロジェクトのパーミッションスキームで実現可能ではないか、説

2016年9月の読書メモ

Kindle Unlimitedも図書館もまだ元が取れるくらいに活用が続いております。キャパオーバーになるくらい本が読めるって素敵です。読書は業。

今月の読書量

12冊ですね。今月はフィクションが少なく、仕事がらみの投資をしていたというのもあって、さすがに先月みたいなバカな量にはなってません。

白暮のクロニクル9巻

白暮のクロニクル 9 (ビッグコミックス)

白暮のクロニクル 9 (ビッグコミックス)

星を継ぐもの

星を継ぐもの (創元SF文庫)

星を継ぐもの (創元SF文庫)

この世界が消えた後の科学文明の作り方

この世界が消えたあとの 科学文明のつくりかた

この世界が消えたあとの 科学文明のつくりかた

いちばんやさしいコンテンツマーケティングの教本

いちばんやさしいコンテンツマーケティングの教本 人気講師が教える宣伝せずに売れる仕組み作り (「いちばんやさしい教本」シリーズ)

いちばんやさしいコンテンツマーケティングの教本 人気講師が教える宣伝せずに売れる仕組み作り (「いちばんやさしい教本」シリーズ)

迷って選んだ答えは必ず間違い

迷って選んだ答えは必ず間違い

迷って選んだ答えは必ず間違い

芸術がわからなくても美術館がすごく楽しくなる本

芸術がわからなくても美術館がすごく楽しくなる本

芸術がわからなくても美術館がすごく楽しくなる本

話し方のマナーとコツ

話し方のマナーとコツ (暮らしの絵本)

話し方のマナーとコツ (暮らしの絵本)

データ・アナリティクス実践講座

アクセンチュアのプロフェッショナルが教える データ・アナリティクス実践講座

アクセンチュアのプロフェッショナルが教える データ・アナリティクス実践講座

スクリプトドクターの脚本教室・初級編

スクリプトドクターの脚本教室・初級篇

スクリプトドクターの脚本教室・初級篇

日本の給料＆職業図鑑

日本の給料&職業図鑑

日本の給料&職業図鑑

エンジニアがビジネスリーダーをめざすための10の法則

エンジニアがビジネスリーダーをめざすための10の法則

エンジニアがビジネスリーダーをめざすための10の法則

会議のマネジメント

会議のマネジメント - 周到な準備、即興的な判断 (中公新書)

会議のマネジメント - 周到な準備、即興的な判断 (中公新書)

今月のベスト本

今月はいい本ばかりに出会ってて、難しいですねえ。1冊を除いて全部当たり。役立つというよりは、インパクトと敬意を込めて「この世界が消えた後の科学文明の作り方」を今月のベスト本にしたいと思います。

サービスの形を彫るためにWhenとWhereが重要だと思った

その他

もちょっと正確にいうと、それによって制約されるデバイスとタイミング、所要時間ですね。WhoとWhyは、サービスがあるべき価値を決定しますが、それがどのように実現されるかという制約をWhenとWhereが決めるから、UIとかユーザの操作フローとかいきなり考えるのではなく、まずは丁寧にシチュエーションとシナリオを物語っていけばいいのかな、と思いました。なぜか新幹線の中で。唐突に。

世の中の100徳ナイフ的なプロダクトはこの制約を考えるプロセスをサボったからではないのかなあ、とか思ったり思わなかったり。

rocker/rstudioイメージでplotを使うときに文字化けしないようにする

Programming

今読んでる本の写経で、Rを使っています。

アクセンチュアのプロフェッショナルが教える データ・アナリティクス実践講座

アクセンチュアのプロフェッショナルが教える データ・アナリティクス実践講座

せっかくなのでdockerであまり環境汚さずに、と思ってrocker/rstudioイメージを使っています。Webコンソールがあるので非常に便利です。

が、一つ難点がありまして、plotするときに軸名などに日本語が入ると、イメージに日本語フォントがないので文字化けしてしまいます。Webコンソールで文字としてやりとりするケースはWebコンソールで描画をするので、正しく日本語を表示してくれます。rstudioサーバで文字の描画までコントロールしなければならない時が問題のケースです。

Debian 7にIPAフォントをインストールする - Symfoware

この辺を参考に、コンテナにbashで入ってrstudioユーザでインストールしました。

一応、ホストでデフォルトでマウントしてくれるディレクトリなので、コンテナを立ち上げ直しても有効ではありますが、これだとコンテナ作り直した時が心配ですね。このケースであれば、ちゃんとローカルにディレクトリ作って docker run 時にマウントしてあげた方が安全ではないかと思いました。