Cat's Whiskers

在宅勤務環境構築（デスク周り）の覚え書き

Sun, 11 Oct 2020 15:00:00 +0000

きっかけ

新型コロナウイルス感染症の流行に伴って、基本的に在宅勤務になった
少しずつデスク周りの環境を整えてきて、ようやく必要なモノが揃ってきたところ
構成が少し複雑になってきたので、覚え書きとしてまとめておきたかった

在宅勤務環境（デスク周り）に関する個人的な要件

（もともとオフィスではデュアルモニター構成だったこともあり、）それなりに大きなモニターで仕事がしたい
嫁も同じ部屋で仕事をしていて、オンラインミーティングのタイミングがかぶることがあるので、音響周りの対策を行いたい
仕事用・私用の Mac にて、周辺機器の切り替えを可能な限りスムーズにしたい

完成形（写真）

完成したデスク（2020-10-11 現在）

構成

デスクを上から見た際の構成図（2020-10-11 現在）

解決策

前述した各要件に対して講じた解決策を以下に記す。

1. モニター

はじめはデュアルモニター構成を検討していたのだが、3. の要件（周辺機器の切り替え）をクリアするのが難しかった。

デュアルモニターで且つ 3. の要件をクリアできるシンプルな構成にしようとすると、どうしてもデイジーチェーン ¹ 対応のモニターを最低一枚（+ 任意のモニターを一枚）購入する必要がでてきてしまい、コストがかさんでしまいそうだったので、最終的に 34 インチ（3440×1440）のウルトラワイドモニター 1 枚の構成にすることにした。

仕事用・私用の Macbook Pro 自体のディスプレイを含めた構成にするかについては、私用の MacBook Pro はサイズが 13 インチであり、前述したウルトラワイドモニターと比較して相対的にかなり画面が小さいものとなってしまうため、思い切ってクラムシェル（縦置き）での利用とする構成を採用した。²

2. 音響周り

2. の要件（音響周り）について補足すると、嫁の方は私がミーティングで喋っているのは特に気にならない（？）らしいので、私自身が嫁の声が気にならなくなりさえすれば本要件は満たされることとなる。もう少し具体的にすると、以下のようになる。

オンラインミーティング中に、私自身が嫁の声を聞こえなくなる
私とオンラインミーティングをしている人に、嫁の声が聞こえなくなる

一つ目の要件をクリアするのに、欲を言えばノイズキャンセリングヘッドフォンが欲しいところ（さらに言えば、同時に 3. の要件も満たすために、マルチペアリング対応の Bluetooth 接続のものであることが望ましい）ではあったが、すでに所持しているものが一つオフィスに置きっぱなしになっており、追加でもう一つ購入するのはコスト的に躊躇われたため、別用途で使用していた有線ヘッドフォンを活用することにした。ヘッドフォン自体は、3.5mm ステレオプラグにてモニターに接続しておくことで、モニターの HDMI の入力だけ切り替えれば接続される Mac も自動で切り替わるような構成とした。もともと使用していたものが、iPhone 購入した時に付属している有線イヤフォンだったので、こちらのヘッドフォンを導入しただけでもだいぶ目的に対する効果は得られた。

二つ目の要件をクリアするのには、シンプルに USB Type-A で接続できるタイプの指向性コンデンサーマイクを導入し、私の喋っている声だけを拾うように設置した。

3. 仕事用・私用 Mac における周辺機器の切り替え

今回の構成だと、基本的に仕事用・私用の Mac に接続される周辺機器は以下の 3 種類に分けられる。

USB Type-A で接続されるもの ³
HDMI で接続されるもの
Bluetooth で接続されるもの

USB Type-A で接続されるものについては、各デバイスと仕事用・私用の Mac の間に USB 切替器 ⁴ を設置することで、ボタン一つで入出力（Mac）の切替が行えるようにした。

HDMI で接続されるものについても同様に、各デバイスと仕事用・私用の Mac の間に HDMI 切替器 ⁵ を設置し、こちらもボタン一つで入力（Mac）の切替が行えるようにした。

Bluetooth で接続されるものについては、今回の構成だとキーボードとマウスが該当する。 Mac 間でスムーズに接続を切り替えられるという 3. の要件を満たすためには、マルチペアリング対応であることが必須条件であった。こちらの条件を満たすキーボードとマウスはそこまで多くはないが、1) 私自身が HHKB の信者であること 及び、2) Ergonomics マウスを探していたこと も相まって、必然的に以下のものを採用する運びとなった。

これらの構成により、以下の 4 ステップのみで仕事用・私用 Mac における周辺機器の切り替えが行えるようになった。

USB 切替器のボタンを押す
HDMI 切替器のボタンを押す
HHKB で接続先の Mac に割り当てたキーボードショートカットを押す
logicool MX Ergo の接続先切替ボタンを押す

今後の課題

概ね現在の構成に満足してはいるものの、もし可能であれば以下の点についての改善を行ってみたいと考えている。

現在使用している有線ヘッドフォンを、マルチペアリング対応のノイズキャンセリングヘッドフォンに置き換える
現在デスクの上に見えてしまっているケーブル・変換器・分配器を、机の下等見えない位置に配線する
仕事用 Macbook Pro の高さを調整するための PC スタンドを導入する
周辺機器の切り替えに必要なステップ数（現在は 4 ステップ）を減らす

参考: デイジーチェーン対応モニターの導入ガイド ↩
参考: 今回の構成ではノートパソコンスタンド PCスタンド縦置き２台収納ホルダー幅調整可能アルミ合金素材 OBENRI Vertical Laptop Double Stand for MacBook Pro Air Mini Clamshell Mode & All Notepc を使用してクラムシェル（縦置き）構成を実現した ↩
MacBook Pro の手前で、変換器によって USB Type-C への変換が行われる前提 ↩
参考: 今回の構成では USB 切替器、ABLEWE USB3.0 切り替え 5Gbps高速転送 PC2台用 4USBポートプリンタマウスキーボードハブなどを切替手動切替器 USBケーブル×2 （1.0m）付きを使用した ↩
参考: 今回の構成では HDMI切替器 GANA 4Kx2K HDMI分配器/セレクター 3入力1出力金メッキコネクタ搭載1080p/3D対応(メス→オス) 電源不要 Chromecast Stick/Xbox One ゲーム機/レコーダーパソコン PS3 Xbox 3D 液晶テレビなどの対応を使用した ↩

Jira REST API 利用のためのコマンドラインツール「jirest」

Sun, 29 Sep 2019 15:00:00 +0000

きっかけ

前職では、仕事柄 Jira の REST API を使用することが多々あったのだが、そのたびに公式マニュアルを確認して使い方を調べるのが億劫だった。
特にクラウド版の API はアップデートが多く、それに応じて公式マニュアルも頻繁に更新されるため、都度確認が必要になるケースが多かった。
REST API 利用時も、いちいちスクリプトにするまでも無いケースも多く、curl などでサクッと API が叩ければ良かった。

Jira REST API 利用のためのコマンドラインツール「jirest」

以下のようなことができる、コマンドラインツール「jirest」を実装した。

公式マニュアルを解析し、自動で最新の API 定義を取得
公式マニュアルに載っている Example (curl コマンド) を、ワンコマンドで実行
公式マニュアルの Example をベースに、ユーザーオリジナルなコマンド実行用テンプレートも定義可能

インストール

docker image として配布しているため、以下の手順のみで利用可能。

$HOME 配下に、jirest データ用ディレクトリ作成
```
 $ mkdir $HOME/.jirest
```

.bashrc に、以下の一行を追加

 alias jirest='docker run -it --rm -v $HOME/.jirest:/root/jirest/data okamotoyuki/jirest'

使い方

Jira Cloud インスタンス・ユーザー情報設定

以下のコマンドで、Jira Cloud のインスタンス・ユーザー情報を設定する。

$ jirest init

認証のためのトークンは、API トークンに記載の方法で生成可能。

API 情報取得

以下のコマンドで、任意の API 情報を取得する。

$ jirest describe

API 実行用 curl コマンド生成

以下のコマンドで、任意の API 実行用の curl コマンドを生成する。(即時実行はしない。)

$ jirest dryrun

ユーザー定義の API 実行用テンプレートが存在する場合にはそちらを利用してコマンドを生成、存在しない場合には公式マニュアル上の Example を元にコマンドを生成する。

API 実行にパラメータを要する場合には、ターミナル上でそれらの値の入力が求められる。

API 実行

以下のコマンドで、任意の API を即時実行する。

$ jirest exec

ユーザー定義の API 実行用テンプレートが存在する場合にはそちらを利用して生成したコマンドを実行、存在しない場合には公式マニュアル上の Example を元に生成したコマンドを実行する。

API 実行にパラメータを要する場合には、ターミナル上でそれらの値の入力が求められる。

API 実行用テンプレートの定義

以下のコマンドで、任意の API 実行用のテンプレートを定義する。

$ jirest edit

テンプレートには、{paramName} の形式で API 実行に必要なパラメータを埋め込むことができる。使用可能なパラメータは、テンプレート編集画面上部にコメントとして表示される。以下に、テンプレートの例を示す。

#       projectIdOrKey (string):
#               The project ID or project key (case sensitive).
#       id (integer):
#               The ID of the project role. Use Get all project roles to get a list of project role IDs.

curl --request POST \
  --url '/rest/api/3/project/{projectIdOrKey}/role/{id}' \
  --user 'email@example.com:<api_token>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '{
  "group": [
    "jira-developers"
  ]
}'

API 実行用テンプレートの削除

以下のコマンドで、ユーザーが定義した任意の API 実行用のテンプレートを削除する。

$ jirest revert

API 定義の更新

以下のコマンドで、公式マニュアルに基づいて API 定義を最新のものに更新する。

$ jirest update

API 定義のロールバック

jirest update にて API 定義を更新したことによって、何らかの問題が生じた場合には、以下のコマンドにて API 定義を安定版にロールバックすることができる。

$ jirest reset

おわりに

バグ・機能リクエストは GitHub issues で受け付けています。もちろんプルリクエストも大歓迎です。

キャリアについての考え方

Sun, 07 Jul 2019 17:00:00 +0000

きっかけ

今回の転職（2 回目）を機に、自身のキャリアについての考え方をまとめておきたかった。というのも、1 回目の転職のときとで、少なからず自身の考え方が変わっていることに気づいたためだ。

他の業界や職種の人にも当てはまるものかはわからないが、もしキャリアについて悩んでいる人がいたら、この記事が少しでも役に立ってくれれば嬉しいと思う。

一般的なキャリア形成の話

ビジネス書なんかでは、よくこんな図を見るんじゃないかと思う。 ¹

キャリア形成の 3 要素

仕事をする上では、必ず「会社に求められること」、「（自分に）できること」、「（自分が）やりたいこと」というのついて回るが、この 3 つの重なる部分が重なっている部分が大きいと仕事に対する満足度も高くなる、みたいなことが書いてあったと記憶している。

仕事をする上で、できることを増えていくのは当たり前だとは思うが、それにつれて会社が自身に求めるものも増えていくだろうし、それが自分のやりたいこととピッタリ重なっていれば自ずと仕事は楽しいものになるはずだ。

仕事に対する満足度が高い状態

これらを踏まえると、キャリアを形成する上では、上図のように 3 つの重なりが大きくなる方向に向けて行動すれば良いことがわかるので、考えられるアクションは以下のようなものとなるだろう。

会社に求められること × できること
- 会社に求められていることができるように、スキルを磨く
- 自分のスキルが活かせる会社に転職する
できること × やりたいこと
- 自分がやりたいことの勉強をする
やりたいこと × 会社に求められること
- 自分がやりたいことを、会社に対してアピールする
- 自分がやりたいことができる会社に転職する

また、どこの会社でもよく言われていることとしては、「3 年後、5 年後に何をしていたいか？」みたいな話があると思う。当たり前な話だが、前述したようなアクションを取る上でも無計画は良くない。きちんとゴールを決めて、「いついつ」までに「何」をやるみたいな計画は必要だ。

これらの考え方は、自分にとっても非常に理にかなっていて、過去に私が初めて転職した際には、こういったことを自分なりに考えた上で行動に移したのを覚えている。

人々の働き方の変化とキャリア形成

ここ最近、人々の働き方が変わってきている。終身雇用制は崩壊し、転職は当たり前になりつつある。また、フリーランスや副業なども珍しく無くなってきていて、働き方にも幅が出てきている。

そうなった今では、自分の所属する会社に求められているものだけを目指していても不十分なのは明白だろう。これらを考慮すると、昨今のキャリア形成を考える上では、既出の 3 要素に加え「市場が求めること」に目を向けることが、重要だと考える。

キャリア形成の 4 要素

ここでいう「市場が求めること」とは、取得が困難な資格だったり、英語が話せること、もしくは新しく普及したテクノロジーに関する知識・経験であったりと様々だ。一般に、転職エージェントや、企業のリクルーターなどが気にして見ているような「社外の人間が客観的にその人を評価できる類のもの」だと考えてもらえれば良いと思う。

終身雇用制が無くなりつつある今、「自分が今いる会社でしか活躍できない人材になってはいまいか」という漠然とした不安に駆られている人も多いはずだ。もちろん、自分が今いる会社と雇用契約を結んでいる以上、勤務時間内に自身の職務に対して責任を果たすのは大前提だ。というか、給料をもらっている以上その義務がある。ただ、もしそこに何らかの「余力」が生じている場合に、今以上に「会社に求められること」に注力して社内でさらに上の職位を目指すも、「市場が求めること」に注力して自身の転職価値を高めるも、その人の自由なのだ。さらに言うと、きちんと上司に相談し、そもそもの自身の今いる会社での職務の幅（つまり「会社に求められること」）を「市場が求めること」と交わる方向に広げてもらう調整まですると、「自身の職務のため」という大義名分を得た上で、「市場が求めること」にも挑戦できて、会社と自分のお互いにとって Win-Win の関係となる。

自身の職務を「市場が求めること」の方向に広げる

また、キャリア形成において考慮すべきパラメータが増えたことによって、自身の目標を管理する周期も自ずと変わってくる。

「市場が求めること」の変化は、予想以上に速い。（もちろん、この辺は業界にもよるとは思うが、全体として速くなってきているのは間違いないとは思う。）例えばエンジニア職だと、私が社会人になった 5 年前の時点は、AI や深層学習といった技術にはあまりパッとしない印象を持っていた。（もちろん技術的には面白そうではあったが、ビジネスに直結するようになるのはもう少し先の未来だと考えていた。）一方で、現在のエンジニア職の募集要項を見た場合、ほぼ必須条件と言っていいほどに AI や深層学習についての知識・経験が言及されている。他にも、ソフトウェア開発で使用されるライブラリなどを見ていても、2 ~ 3 年前には主流として使われていたものが、平気で廃れてしまっている、などといったことも珍しくはない。つまり、3 ~ 5 年単位での目標管理は、あまり意味をなさなくなってきていると、個人的には考えている。

ソフトウェア開発手法の一つであるスクラム開発では、2 週間程度の短い周期でリリースが行われる。この「2 週間」という数字にはいろいろと意味があるが、統計上「人間の能力では 4 週間以上の予定を正確に管理することができない」という事実が、背景にあると聞く。 4 週間以上先のことになると、人間はどうしても楽観的になりがちで、見積もりが甘くなってしまうらしい。

こういったことを鑑みると、目標は 1 ヶ月程度（約 4 週間）で見直し、「市場が求めること」やその他の要素を考慮しながら適宜調整するのが良いと思う。

目標管理の周期

短い周期で目標の見直しを行うことで、3 年 ~ 5 年経った時点で、当時立てた目標と、今の自分の目標が大きくずれているといった問題を未然に防ぐことができるはずだ。

おわりに

自身が今回転職した理由はいろいろあるが、基本的に前職は手を挙げれば自身の「やりたいこと」はやらせてくれる環境ではあったし、「会社に求められること」も「市場が求めること」とそこまで離れてはおらず、とても良い環境だった。

ただ強いていえば、たまたま去年一年で自身の中で大きなブレイクスルーがあり、特に自分の「やりたいこと」が大きく変わっていったのを感じていたのに対して、私がそれを会社側に伝える努力を怠っていたのが一番の原因だと思う。会社側は、私が以前に伝えていた目標に対してきちんとキャリアパスを用意してくれていたのに対し、自身がそれに応えられなかったのは申し訳無かったと思っている。

なお、本ブログの意図は転職を推奨するものではない。転職はあくまでキャリア形成の一つの手段でしかなく、大事なのはキャリア形成における 4 つの要素を意識した上で、それらの交わりを増やすために必要な行動を、短い周期で見直し、実践していくことの重要性が、本ブログで伝えたかったことである。

参考: 「ギャップはチャンスだ！」 ↩

macOS で自炊データを PDF 化する際の覚え書き

Mon, 29 Apr 2019 14:00:00 +0000

きっかけ

特筆するほどでも無いのだが、手元の自炊データ (e.g. JPG, PNG) をスマホや Kindle で読みたかったのがきっかけだった。

もちろんやり方はいろいろあるとは思うし、自動化も普通にやればできるだろうという見通しはあったが、いちいち毎回調べながらやるのも億劫なのでまとめておくことにした。

目標

JPG や PNG 形式の自炊データを、電子書籍リーダーで読める PDF 形式に変換する。

要件の整理

スキャナーやデジカメなどを使用して書籍を自炊した場合、各ページの画像ファイルが JPG や PNG など形式で大量に作成される。また、特に変わったことをしなければ、それらのファイルはページの順番に応じて昇順のファイル名が振られていて、書籍毎に書籍のタイトルの付けられたディレクトリ配下にまとめられていることだろう。やりたいこととしては、こうした大量の画像ファイルを元の書籍のページ順に並べて、一つの PDF ファイルとしたい。

上記をふまえると、変換処理を行う際に想定される入力は、書籍の画像ファイルの配置されたディレクトリへのパスであり、ディレクトリの構成は以下のようになっていると想定できる。

$ cd BookTitle      # 書籍タイトルディレクトリ
$ tree .
.
├── Page001.jpg     # 各ページの画像ファイル
├── Page002.jpg
├── Page003.jpg
.
.
├── Page198.jpg
└── Page199.jpg

また、PDF にする書籍がシリーズ物だったりして複数あるケースも想定すると、以下のような形でディレクトリが階層化されているケースも考えられる。

$ tree .
.
├── Series                  # シリーズ名ディレクトリ
│   ├── Subseries           # サブシリーズ名ディレクトリ
│   │   ├── BookTitle1
│   │   │   ├── Page001.jpg
│   │   │   ├── Page002.jpg
│   │   │   .
│   │   │   .
│   │   │   └── Page199.jpg
│   │   └── BookTitle2
│   │        ├── Page001.jpg
│   │        ├── Page002.jpg
│   │        .
│   │        .
│   │        └── Page199.jpg
│   └─── BookTitle3
│       ├── Page001.jpg
│       ├── Page002.jpg
│       .
│       .
│       └── Page199.jpg
└── BookTitle4
    ├── Page001.jpg
    ├── Page002.jpg
    .
    .
    └── Page199.jpg

このケースだと、異なる深さのディレクトリに階層に、書籍タイトルディレクトリが存在し、その配下に各ページの画像ファイルが存在する。

そこで今回の要件を、「上記のように階層化のディレクトリのルートへのパスを入力として与えた場合に、その配下に存在する全ての書籍（上記例における、BookTitle1 ~ 4）をまとめて PDF として出力すること」として定義した。

環境

macOS High Sierra

手順

要件が、以下の 2 ステップで実現できることは言わずもがだと思う。

入力として受け取ったディレクトリ階層から、書籍タイトルディレクトリへのパスを抽出する
各書籍タイトルディレクトリ配下の画像ファイル群を PDF に変換し、書籍タイトルのファイル名で保存する

今回は、これらの処理を Bash のスクリプトで実現する。

① 書籍名ディレクトリの抽出

やるべきこととしては、要件の整理の章で例として挙げたようなディレクトリ階層の中から、最下層のディレクトリのみを抽出すれば良いのだが、POSIX コマンドの中に単体でこれを実現できそうなものは無かった。（find コマンドのオプションなんかで実現できるかとも思ったが、無理そうだった。）

そこで Stack Exchange 上の Gilles 氏による回答を参考に find と awk のコマンドを組み合わせて、以下のような関数で実現した。¹

leaf () {
    { find "$1" -type d; echo; } | \
    awk 'index($0,prev"/")!=1 && NR!=1 {print prev}
         1 {sub(/\/$/,""); prev=$0}'
}

簡単に処理内容を説明すると、関数内 1 行目では特に変わったことはしておらず、普通に find コマンドで、入力として受け取ったパス配下のディレクトリを出力している。ただ、今回は最終的に最下層のディレクトリのみを出力したいため、後の awk コマンドでその判定を行う際には一行先読みを行う必要が発生し、関数内 1 行目の echo コマンドによる空行の出力はそのためのものである。

関数内 2 行目、3 行目の awk コマンドが少しトリッキーだが、以下のような処理を行っている。

入力行に prev 変数の文字列（一つ前の行のもの）が存在しないかどうかをチェックし、存在しなければ prev を出力
入力行の末尾のスラッシュを削除し、prev 変数にセット

なお、NR!=1 は awk の入力の一行目については print を行わないこと、関数内 3 行目の 1 は真偽値（True）を意味し、常に後続の処理を実行することを意味する。

この leaf 関数は、使い勝手が良いので、.bashrc なり .zshrc などに登録しておくと良いかもしれない。

② 画像ファイル群を PDF へ変換

いろいろな方法がありそうだが、王道の ImageMagick を使うのが一番手っ取り早そうだったので、これを使用した。²

macOS であれば、Homebrew を使用して、以下のコマンド一つで ImageMagick のインストールが行える。

$ brew install imagemagick

上記コマンドで ImageMagick をインストールすると、convert というコマンドが使用可能になり、以下のように画像ファイルを PDF へ変換が可能となる。

$ convert *.jpg BookTitle.pdf

変換対象の画像ファイルを上記のようにワイルドカード指定すると、ファイル名の昇順で PDF のページに変換される。

また、そのままの画質のまま変換を行うと、作成される PDF のファイルサイズがかなり大きくなってしまうため、以下のように -quality オプション (1 ~ 100) で画質を落とすことも可能。

$ convert *.jpg -quality 20 BookTitle.pdf

元の画像にもよるかと思うが、手元で試し感じだと quality は 20 程度にまで下げても、十分に文字の判読が可能な形で変換を行うことができた。

まとめ

以下のような Bash スクリプトを作成し、はじめに定義した要件の通りの変換処理を実現することができた。

変換対象の画像ファイルが存在するディレクトリを第一引数として指定し、画質を第二引数として指定（省略可能、既定値 20）することで、対象ディレクトリ配下の全ての画像ファイルを PDF に変換することができる。

$ ./images2pdf path/to/images 50

jira.atlassian.com の（歩き方ならぬ）走り方

Mon, 15 Oct 2018 08:00:00 +0000

はじめに

Atlassian では、製品への新機能追加や不具合の修正が以下のポリシーに基づいて実施されており、一つ一つの機能リクエストやバグレポートについては jira.atlassian.com (通称 : JAC) と呼ばれる Jira インスタンス上で管理されている。

JAC はインターネット上に公開されているため、誰でも自由に機能リクエストやバグレポートへアクセスし、その気になればチケット上に思いの丈をコメントとして綴ることも可能である。¹ さらに面白い点としては、機能リクエストに対してはコメントの他に投票を行うことも可能であり、リクエストへの投票数も実装される新機能を決める上での判断材料となる。²

このような形で利用されている JAC だが、現職では Atlassian 製品の仕様や不具合についての質問を受けることが多いため、JAC 上に存在する約 24 万件強 ³ のチケットの中から、如何に素早く適切な機能リクエストやバグレポートを見つけられるかが重要になってくる。

Atlassian の技術サポートのエンジニアは、（おそらく）本記事の読者の方々の想像よりもはるかに速いスピードで、狙った JAC 上のチケットを見つけ出すことができる。（と、若干煽ってみる。）ただ、それは製品知識や Atlassian の社内情報のみに頼ったものではなく、誰もが明日から実践できるような些細なテクニックの積み重ね ⁴ によって実現されていることを、本記事でお伝えできればと思う。

目標

本記事では、以下の 2 点を目標としている。

JAC 上に存在するチケットの検索スピードの向上
JAC に限らない、一般的な Jira チケットの検索スピードの向上

JAC の検索術

これから紹介する話は、どれもが JAC 上に存在するチケットを効率良く検索するための手段となっているが、中には JAC に限らず Jira インスタンス一般に使用できるものも含まれている。もし本記事の読者の所属する企業や団体でも Jira をご使用いただいている場合には、是非そちらでも活用していただければと思う。

① 敢えて Jira の検索機能を使用しない

JAC が Jira インスタンスである以上、Jira 自体の検索機能を使用してチケットを探さなければならないと考えてはいないだろうか？

もちろん、Jira そのものが提供する検索機能は非常に強力ではあるが、それはどちらかというと構造化された情報の検索についての話である。ここで言う構造化された情報とは、Jira のチケットに紐づくプロジェクト情報、チケットの種類、ステータス、担当者、作成日などを指して言っているが、例えばそれらの情報を上手く活用して 「JRASERVER プロジェクトに、2018/10/13 以降に作成された、ステータスが Resolved」 となっているチケットを探す、などといった場合には Jira の検索機能は有用である。

一方で、これらの情報をきちんと活用して JAC 内のチケットを検索することが、一般の製品ユーザーには若干難しいケースも存在する。例えば、使用している Jira アプリケーション上で何らかの不具合を見つけて、それが既知のものかどうかをチェックする目的で JAC 上のバグレポートを検索する場合を考えてみよう。現状で JAC 上には、Jira に関連するプロジェクトだけで JRASERVER, JRACLOUD, JSWSERVER, JSWCLOUD, JSDSERVER, JSDCLOUD, JPOSERVER, JPOCLOUD, JOPSCLOUD, BON の 10 個ものプロジェクトが存在する。 ⁵ また、不具合が Jira の内部で使用されている特定のプラグインに起因する場合には、更に別のプロジェクトにバグレポートが起票されるケースも存在する。そういった中で、いきなり JAC の検索機能を使用して、プロジェクトを限定して検索を行ってしまうと、見つけたいバグレポートがそのプロジェクト内に存在しなかった場合に、永遠にそのバグレポートに辿り着けいないリスクが生まれてしまう。

これらの前提情報を知らないユーザーにも、比較的敷居が低いのがフリーテキストでの検索機能を使用する方法になるかと思うが、ここで問題となるのが英語である。

基本的には、JAC 上のチケットは全て英語で記載されているため、テキストで検索する場合にも英語のキーワードを使用する必要がある。そんな中、私も英語ネイティブではないことで若干苦労しているのが、チケット内で使用されている微妙な言い回しの違いである。

過去に私が、Atlassian 製品を日本語で使用する場合に文字化けが発生する不具合を、JAC 上で調査していた時のこと。当時の私は、「文字化け」 = “garbled” という翻訳は知っていたが、なかなか目的のバグレポートに辿りつくことができなかった。結論から言うと、目的としていたバグレポートの中では文字化けという意味合いで “mangled” という単語が使用されていたため、Jira のテキスト検索にひっかからなかった。

Jira のテキスト検索機能では、形態素解析により単語の活用の変化 (例 : mangle ↔ mangled, garble ↔ garbled) などは考慮して検索を行ってくれるが、意味レベルで近い単語を類推してくれる程には賢くはない。そういった意味でも、ネイティブではない言語で（もしくはネイティブな言語でも）、Jira のテキスト検索機能を完璧に使いこなすことは、なかなか難しかったりする。

ここで思い出していただきたいのが、JAC は インターネット 上に公開されていて、インターネットの検索にはもちろん Google 検索が使用できるということだ。 ⁶ 具体的にやることとしては、以下のように Google 検索を行う際に “site:jira.atlassian.com” のキーワードを含めて検索対象のドメインを jira.atlassian.com に絞るだけである。

jira.atlassian.com にドメインを絞った Google 検索

こちらの方法での検索は、Jira 自体が提供するフリーテキスト検索と比べて以下のようなメリットがある。

通常の Google 検索同様、キーワードのあいまいさを許容した検索が可能となる
Google のランキングアルゴリズムの恩恵により、世の中で多く参照されているチケットには、特にたどり着き易い

もちろん、目的とするチケットがすでに Google の検索エンジンにクローリングされているかどうかなども関係してくるため、必ずしもベストな手段だとは言えないが、普段あまり JAC を訪れることの無い方々にとっては、比較的 ROI の高い方法だと考えている。（なお、私自身 JAC 上のチケットを調査する際の最初のステップとして、この手段を利用することが多い。）

② 不要な検索結果を削ぎ落としていくイメージを持つ

① にて JAC 自体の検索機能を使用しない方法の話をしたが、前述した通り、目的とするチケットが Google のインデックスに乗っていない場合には見逃してしまうリスクは存在する。そういった意味からも、① の方法については、「目的とするチケットが見つかればラッキー」 くらいの感覚で利用してもらえればと考えている。

そこで、次に考えなければいけないのは、如何に検索結果に 漏れがない ように JAC の中を検索するか、ということになる。この時点で、はじめて Jira の検索機能を使用することになるが、前述したような、JAC 上のプロジェクト情報、チケットの種類、ステータスなどの細かい定義は、単にそれらを知っているかどうかだけの話になってしまうので、ここではもう少し汎用的な話をしようと思う。

Jira 上でチケットを探す際には、おそらく検索条件を複数指定した上で、チケットの絞り込みを行うと思う。ただこの時に最も避けたいのが、比較的早い段階で目的とするチケットが検索結果から漏れてしまうことである。

前述した文字化けの不具合のケースだと、「チケットに “garbled” というキーワードが含まれる」 というある種の「不確実な検索条件」を検索の序盤から用いて、いきなり目的のチケットを見つけにいってしまっていることが失敗の要因となっている。今回のケースのように、指定した不確実な検索条件から目的のチケットが漏れてしまった場合、この後どのような検索条件を追加したところで、該当チケットにたどり着くことはできない。（もちろん、OR 検索を使用した場合はこの限りでは無いが。）

目的とするチケットが検索結果から漏れてしまう例

上記のような問題を防ぐためにも、JAC のチケットを検索する際は、初めは「確実な検索条件」から指定していき、不要な検索結果をある程度削ぎ落とした上で、はじめて「不確実な検索条件」を設定するのが望ましいと私は考える。

不要な検索結果を削ぎ落としていくイメージ

ここで言う、「確実な検索条件」としては、以下のようなものが挙げられる。

サーバー版の Jira Software を使用していて、不具合が Jira Software 特有の機能（ボード機能など）で発生している場合には、バグレポートの存在するプロジェクトについて project = JSWSERVER という条件を指定する ⁷
不具合が最新のバージョンでも発生している場合、バグレポートのステータスについて status not in (Resolved, Closed) という条件を指定する ⁸
不具合が特定の製品機能に対して発生する場合、text ~ "英語表記の正式な製品機能名称" という条件を指定する
- 現状では、JAC 上のバグレポートは Atlassian 社員のみが起票する運用となっており ⁹、Atlassian 社員はバグレポート内で正式な製品機能名称を使用するように心がけている

「確実な検索条件」のみを使用して、検索結果が 100 件程度まで絞り込めれば、チケットの要約だけ全件分チェックすることもそこまで難しくはないし、その状態からであれば「不確実な検索条件」を使用しながらの試行錯誤も容易いだろう。

また、テキストでの条件指定にもちょっとしたコツがある。 JAC 上のチケットには以下のようなテキストフィールドが存在している。

要約 (summary)
説明 (description)
その他のテキストフィールド（コメントなど）

テキストで条件を指定する際に是非一度考えてみていただきたいのが、「仮に今探しているチケットを自身で起票するとすれば、どのテキストフィールドにどういった粒度の情報を入れるか」 という点についてだ。

例えば 「日本語での利用時に、Jira のガジェットが、文字化けする」 といった不具合が、既知のものであるかを調査する場合についてを考えてみよう。特に変わったことをしなければ、検索条件は summary ~ "Japanese gadget garbled" や text ~ "Japanese gadget garbled" といった形になるのではないだろうか？

まずはじめに「日本語での利用時」に発生する不具合であることから「要約」フィールドに対していきなり summary ~ "Japanese" という条件を指定するべきか否か。基本的に日本語での利用で発生する不具合のほとんどは、マルチバイト文字に起因して発生するケースが大半であり、韓国語、中国語、ロシア語での利用時にも同様の問題が発生する可能性が考えられる。そういった場合には、もしその不具合を初めに見つけたのが日本語ネイティブ以外の方であれば、「要約」フィールドには “Korean” や “Chinese” などのキーワードが含まれているかもしれない。また、仮に私がこの不具合についてのバグレポートを挙げるとすれば、上記のように複数の言語で不具合が再現することをより端的に言い表すために、「要約」フィールドには “Multibyte” のように一般化したキーワードを使用するだろう。これらを踏まえると、summary ~ "Japanese" は、ある程度「不確実な検索条件」であることがわかるかと思う。

一方で、「Jira のガジェット」で不具合が発生する、という点についてはどうだろうか？もしその不具合が Jira のガジェットで発生するとすれば、”gadget” というキーワードは十中八九「要約」フィールドには含まれてくるだろう。そういった意味で summary ~ "gadget" は、「確実な検索条件」だと考えて良いと思う。

ここまででは「要約」フィールドについての話であったが、「説明」フィールドやコメントを含むその他のテキストフィールドはどうだろうか？先程の例だと、summary ~ "Japanese" は「不確実な検索条件」に分類されたが、これを description ~ "Japanese" もしくは text ~ "Japanese" とした場合にはどうだろう。

基本的に「説明」フィールドには不具合の詳細な再現手順が記載されるため、もし日本語ネイティブである私がこの不具合のバグレポートを起票したとすれば、ほぼ間違いなく “Japanese” というキーワードを含めるかと思う。また、もともと韓国語での利用時に発生するものとして起票された不具合でも、後から別の日本人ユーザーが 「この不具合は日本語でも再現する」 といった情報をコメントしている可能性もあるため、コメントに “Japanese” というキーワードが含まれている可能性は更に高い。文字化けについて言及している部分についても同様で、仮に「要約」フィールドや「説明」フィールドで “mangled” というキーワードが使用されていたとしても、コメントには別のユーザーが “garbled” というキーワードを記載している可能性が考えられる。

一般に、各テキストフィールドが含む情報の抽象度は summary > description > text (コメント等) の順に高くなっていて、情報量は text > description > summary の順に高くなっていると考えて良いかと思う。

一つの検索条件で、より多くの不要な検索結果を振るい落とすためには、抽象度が高く、情報量が少ない テキストフィールドを検索条件に含めた上で 「確実な検索条件」 となるのが望ましい。（例: summary ~ "gadget"）

一方で、「不確実な検索条件」によって本来振い落されてはいけない検索結果が振い落されてしまうことを極力防ぐためには、「不確実な検索条件」 がより 抽象度の低く、情報量の多い テキストフィールドに来るのが良い。（例: text ~ "garbled"）

これらを踏まえると、同じテキストフィールドの検索でも、当初想定していた summary ~ "Japanese gadget garbled" や text ~ "Japanese gadget garbled" などの検索条件よりも、summary ~ "gadget" and description ~ "Japanese" and text ~ "garbled" といった条件の方が、検索効率が良いのがわかるかと思う。 ¹⁰

③ その他のテクニック

その他のちょっとした検索テクニックを紹介する。

ⅰ. 「バージョン」のワイルドカード検索

まだ比較的最近の話ではあるが、Jira 7.9.x にて、ついに「バージョン」のワイルドカード検索がサポートされた。 ¹¹

これまで Atlassian 製品の管理者の方々は、アップグレードを検討する度に JAC にて、アップグレード先のバージョンで解消されている不具合・機能リクエストをリストアップするために、

project = JRASERVER and fixVersion in ("7.6.1", "7.6.2", "7.6.3", "7.6.4", "7.6.5", "7.6.6", "7.6.7", "7.6.8", "7.6.9")

のような途方もない JQL を書いていたかと思うが、現行の JAC はすでにワイルドカード検索に対応したバージョンなので、以下のようなシンプルな JQL で済む。

project = JRASERVER and fixVersion ~ "7.6.*"

ⅱ. ランチャーアプリを使用した Jira 検索

頻繁に Jira の課題の検索を行っていると、検索条件の入力のために一旦「課題ナビゲーター」の画面を開くことすら億劫になってくる。そういった場合には、是非 Alfred などのランチャーアプリを使用して Jira の検索を行っていただくことをオススメする。 Alfred には、Web Search 機能がデフォルトで備わっていて、予め Jira の課題ナビゲーターの URL を登録しておくと、アプリ上で数コマンド入力するだけで、すぐにアクセスすることが可能となる。これだけだと、ブラウザのブックマーク機能と大して違いは無いかと感じるかもしれないが、Alfred ではアプリからの入力を GET パラメータとして URL へ渡すことが可能である。 Jira では、http(s)://<ベースURL>/issues/?jql=<検索条件> という URL に GET アクセスすることで、直接チケットの検索結果が取得可能であることを利用し、以下のように Alfred 側で設定をしておくことで、アプリ上で入力した JQL にて JAC を検索した結果を即座にブラウザ上に表示することができる。

Alfred から JAC の検索を行うための設定

ランチャーアプリ上での入力 (JQL) が、上記図の Search URL 内の {query} 内に展開された上で、URL へのアクセスが行われる。

Alfred を使用した JAC の検索

この方法は、① で紹介した JAC にドメインを絞った Google 検索でも使用が可能で、上記の URL を https://www.google.co.jp/search?q=site%3Ajira.atlassian.com+{query} に変更するだけで、ランチャーアプリに入力した任意の文字列で JAC 内の Google 検索が可能となる。

私自身は Mac で利用可能な Alfred しか試したことは無いが、Windows にも同様のランチャーアプリは存在しているようだ。alternativeTo というサイトに、それらのアプリがまとまっているようなので、Windows ユーザーの方には是非お試しいただきたい。

おわりに

本記事に記載した内容は、JAC 及び Jira の検索におけるテクニックの一部に過ぎない。他にも様々なテクニックが存在するだろうし、人によって好き嫌いもあるだろう。もし本記事の読者が実践している、オススメのテクニックなどがあれば、是非私にも教えていただければと思う。

JAC チケットへのコメントには、無償で作成が可能な Atlassian Account が必要。 ↩
新機能の実装ポリシーにも記載があるように、投票数のみで実装される新機能が決定されるわけでは無い点にはご注意いただきたい。 ↩
本記事は、2018/10/12 22:00 時点の JAC のデータを元に執筆している。 ↩
本記事で紹介するテクニックは、私が個人的に気をつけていることで、Atlassian が会社として推奨しているものではない。 ↩
アトラシアン製品のバグ報告と機能リクエストをより適切にのブログに記載があるように、2017 年時点で同一製品のサーバー版・クラウド版に関する機能リクエスト・バグレポートは、それぞれ別のプロジェクトとして扱われるように変更が行われいる。 ↩
厳密には、Google の検索エンジンのクローラからのアクセスを許可している場合に限る。 ↩
サーバー版の Jira Software を使用しているケースでも、確認している不具合が Jira アプリケーション全般に起こり得るものである場合、チケットは JRASERVER プロジェクトに作成されるため、注意が必要。 ↩
各プロジェクトによって、解決済みを表すステータス名が若干異なるケースがあるので注意が必要。 ↩
アトラシアン製品のバグ報告と機能リクエストをより適切にのブログに記載があるように、バグレポートにはサポート窓口を通じて起票が可能。機能リクエストについては、引き続き JAC に直接起票が可能。 ↩
厳密には、その他の様々な前提条件によって、検索効率の良し悪しは変わってくる。 ↩
JRASERVER-24152 - JQL - Add wildcard functionality to versions ↩

Large-Scale Scrum

Mon, 09 Jul 2018 08:00:00 +0000

はじめに

少し時間が経ってしまったが、2018/5/7 ~ 2018/5/9 で、認定 LeSS 実践者研修に参加してきたので、簡単に内容をまとめておこうと思う。LeSS における細かいお作法は、全て公式ページの方にまとまっているので、本ブログでは研修を通じて特に興味深かった点に絞って書いてみる。

なお、本ブログの内容は Scrum の基礎を知っている人向けのものとなっている。Scrum 関連の用語は、日本語表記にしてしまうとどうもしっくりこない気がしたので、ブログ全体を通してあえて英語のままの表記とした。若干、ルー大柴間が否めない点については目をつぶってもらえればと思う。

Scrum と LeSS の関係

LeSS (Large-Scale Scrum) とはその名の通り、本来 7 ± 2 名程度のチームで行うのが望ましいとされている Scrum を、より大きな組織に適応するためのフレームワークの一つである。

同様に、Scrum 拡張の中には、SAFe や Nexus といったものもあるようだが、実際にどれを使用するかについては好みによっても分かれそうなところ。というのも、Scrum が「透明性」、「検証」、「適応」の実現に必要最低限のルールを定義しているのに対して、その拡張である LeSS, SAFe や Nexus は、どちらかというと Scrum の実践のためのプラクティス集的な意味合いが強く、適用する組織によってもベストな手法は変わってくると思われる。

今回は、私自身が LeSS の研修に参加してきたということもあり、LeSS を中心に本記事を書いてはいるが、私は SAFe と Nexus をきちんと勉強してはいないため、それらとの適正な比較などが行えていない点については予めご了承いただきたい。

LeSS の成り立ち

前章でも述べたように LeSS は Scrum をより大きな組織に適応するためのフレームワークである。つまり、LeSS はあくまで Scrum の一つの姿 に過ぎず、Scrum 自体に手を加えた別の何かでは無い。

本研修の講師で、LeSS の考案者の一人でもある Bas Vodde は、「私は、クライアントの組織に意図的に LeSS を導入したことは一度も無い。Scrum を導入していたら、自然と LeSS になっているケースがほとんどだった。」とも述べていた。

具体的には、以下の図を見てもらえるとイメージがし易いかと思う。

LeSS の成り立ち (※)¹

様々な組織に対して Scrum を適応するという Experiments (実験) を繰り返す中で、得られる知見をまとめたものが LeSS である。それらの知見についても、その抽象度に応じて Guides (ガイド)、Frameworks (フレームワーク) と段階を設け、それらの中心に位置する最も普遍的なものを Principles (原理・原則) として括りだしたようだ。

LeSS の概要

前章でも述べたように、LeSS は Scrum の一つの姿に過ぎない。ただ、LeSS は Scrum をより大きな組織に適用するために、いくつかの LeSS ならではの特徴を持っている。以下は LeSS の全体像を示した図となっており、ぱっと見では Scrum とほぼ同じように見えるかと思うが、大規模な組織に対応するためのいくつかの工夫が施されている。

LeSS の全体像 (※)

LeSS という考え方の一つのポイントとして、LeSS は複数の Scrum の集合ではなく、それ自体で一つの大きな Scrum である。具体的には、以下のような仕組みによってこのポイントを実現している。

LeSS における Team という用語は、Scrum 用語における「Scrum Team」のことではなく「Development Team」のことを示す
- 一つの Team には Product Owner (PO) や Scrum Master (SM) は含まれない
一つのプロダクトに対して、組織が大きくなり Team が増えた場合にも、必ず PO は一人のみ
- SM は、一人で複数 Team を見ることもある
一つのプロダクトに対して、Product Backlog も一つのみ
Product Backlog の粒度は、プロダクトの全体像が見えるように通常の Scrum よりも大きめに設定する
- e.g. LeSS: UI の変更 ↔ Scrum: ボタン A の変更
一つの Sprint の中で、Sprint Planning は二段階に分けて行い、一度目の Sprint Planning（上記図中の Sprint Planning 1）には、必ず全ての Team（もしくはその代表者）が参加する
Product Backlog Refinement には、全ての Team が参加する
Sprint Review には、全ての Team が参加する
Sprint Retrospective についても、Team 毎に行うもの以外に、Overall Sprint Retrospective と呼ばれる、PO, 全ての SM, 全ての Team の代表者が集まるものが存在する

LeSS がこのような形態を取っている理由は、LeSS においてプロダクトがどのように定義されるかに深く関わっている。こちらについては、次章のプロダクトの定義で説明する。

プロダクトの定義

LeSS における「プロダクト」の定義とは何か？ Less では一つのプロダクトを可能な限り 大きく 定義するのが良いとされている。

具体例を出してみよう。例えば、ある Web サービス（サービス X）を開発していて、そのサービス X を展開するプラットフォームが Web ブラウザ、iOS, Android といったように複数存在するとする。この場合にプロダクトを

サービス X (Web)
サービス X (iOS)
サービス X (Android)

のようにプラットフォーム別に定義するのではなく、まとめて一つの「サービス X」として定義することを、この場ではプロダクトをより「大きく定義する」と呼んでいる。

プロダクトを大きく定義する理由として、以下のような点が挙げられている。

プロダクト全体（上記例であれば、Service X 全体）での、要件の順位付けが容易になる
複数のプロダクト間で発生する重複作業を、極力減らすことができる
小さなコンポーネント（部品）を減らす
顧客視点で物事を考えやすくなる
プロダクトに関わる組織構成がシンプルになる

これらに共通して言えるのは、プロダクトを大きく定義することにより、プロダクトに関わる全ての人たちが、共通の「顧客価値」を認識して動きやすくなるという点である。

ビジネス書などで多く引用されている「3 人のレンガ職人」の寓話がある。²

旅人がレンガを積んでいる職人に「あなたは何をしているのですか」と尋ねると、職人は、険しい顔で「レンガを積んでいる」と答えた。別の職人にも尋ねたら、平気な顔で「壁を作っている」と答えた。さらに別の職人に尋ねたところ、喜びに満ちた顔で「大聖堂を作っている」と答えた。

大事なのは、あくまで自身が「大聖堂を作っている」ことを認識できているかどうかなのだ。

科学的管理法（テイラー主義）

科学的管理法とは、20 世紀初頭にフレデリック・テイラーによって提唱された、プロダクトの生産性向上のための手法であり、以下のような特徴を持つ。

マネジメント層と作業者に分離
作業は職能別に細分化して最適化
個々の作業者のスキルの違いは考慮しない、一律な作業時間による工数見積もり

これらの特徴を見てハッとする方もいるかもしれないが、工数を人月 (man-month) で管理し、PMO (Project Management Office) がプロジェクトを取り仕切るような開発スタイルと、どこか通ずるものがあるだろう。

科学的管理法は、基本的に作業者をただのリソースと見なす「リソース指向」に基づいている。リソース指向では、作業者はあくまでプロダクト開発の過程で消費される「リソース」でしかないため、常に計画に忠実に、一定のスループットで作業をこなすことを求められる。例えば、10km/L の燃費の自動車に乗った場合に、ガソリンは常に 10km/L のペースで消費されてほしいのと同じような感覚である。

科学的管理法が流行り始めた 20 世紀初頭では、高等教育を受けることができたのはごく一部の人たちであった。そういった時代の中では、一部の優秀な人材をマネジメント層に据えてその他の作業者を「リソース指向」で管理するこの手法は、一定の効果を上げていたようだ。ただ、その頃からすでに一世紀近くもの時間が経ち、日本に限って見ても国全体の教育水準は当時と比べても遥かに上がっている。科学的管理法を裏付けていた時代背景そのものが変わってきている今日、果たしていつまでも科学的管理法が通用し続けるのか。

LeSS はこの問題に着目し、前述した「リソース指向」とは対極的な位置に存在する「人間指向」に基づいた考え方を取っている。人間指向では、（当前ではあるが）作業者を「人間」と見なし、作業者が自主的に「学習」することを前提とする。つまり、作業者のスループットは作業者自身の「学習」によって改善されていくことが期待されている。

もちろん今の世の中でも、科学的管理法もしくはリソース指向が有用なケースもいくらかはあるだろう。ただ、昨今ではプロダクトへの要件は複雑化し、スピーディに変化していくことを考えると、それらの全てをマネジメント層が把握して、科学的管理法によってコントロールしていくことの難しさは容易に想像できるかと思う。

コンポーネントチーム vs フィーチャーチーム

Scrum では、Team のメンバーはクロスファンクショナル（機能横断）に構成されるのが一般的である。

LeSS では複数の Team が力を合わせて一つのプロダクトを開発するわけだが、その場合にも各 Team をプロダクトのコンポーネント（部品）によって分けることはせず、プロダクトのフィーチャー（機能）によって分けるのが望ましいと言われている。

なぜ、フィーチャーチームなのか。こちらについては、一般的な Scrum Team がクロスファンクショナルに構成される理由と大きく違いは無い。Team が顧客の価値（つまりフィーチャー）に直結しており、常に顧客目線でソリューションを考え易いことや、Team 間におけるタスクの依存関係を減らすことなど、様々なメリットが挙げられる。

コンポーネントチーム vs フィーチャーチーム (※)

ただし、上記図のようにフィーチャーチームの方では Team 間の作業の依存関係が減ってシンプルになっている一方で、複数の Team が同一のコンポーネントに対して変更を加える可能性が出てくるため、コンポーネント変更管理の難易度が上がっているのが見て取れるかと思う。実際のところ、この問題を人間の手作業のみで解決することは非常に難しいため、CI/CD のためのツールを導入することで、ソフトウェア的に解決することが求められる。

Definition of Done

通常の Scrum 同様、LeSS においても Undone（Definition of Done に含まれてはいるが、現時点では必ず毎 Sprint では実施できていないもの）が積み上がることは後の技術的負債となる恐れがあるため、適宜減らして行くことが求められる。

Undone がもたらすリスクと遅延 (※)

Undone に含まれやすい作業としては、セキュリティテストやパフォーマンステストなどが挙げられるが、こういった Undone を実際にどのように消化していくべきか。

例えば、Scrum では（もちろん LeSS でも）推奨されないものではあるが、「Release Sprint」と呼ばれる、プロダクトのリリース準備を行うためだけの Sprint を設け、そちらの Sprint を Undone の消化に当てる方法は存在する。そもそも Scrum では、全ての Sprint の成果物が Potentially Shippable Product Increment でなければならないため、「Release Sprint」の考え方自体が矛盾をはらんでいる訳ではあるが、実際のところ Scrum や LeSS を始めたばかりの Team だとこういったことはめずらしくはないようだ。

ただ、LeSS で扱う規模のプロダクト開発ともなると、Undone の消化のみを専門に行う部署、通称「Undone 担当部」なる部署が作られてしまうこともあるようだ。「Undone 担当部」という名前を聞いてもあまりピンと来ない方も多いかもしれないが、いわゆる一般的なソフトウェア企業に存在する「QA 部」、「リリース管理部」などが、「Undone 担当部」に該当するケースが多いようだ。

Undone の消化を Team 自身ではなく「Undone 担当部」に任せてしまうことは、Team のプロダクトに対する責任意識を損なうことに繋がるため、「Release Sprint」よりもむしろ避けるべきもの として研修の中では扱われていた。（なお、ここで述べているのはあくまで LeSS という文脈における「Undone 担当部」の話であり、組織や開発手法によっては「QA 部」や「リリース管理部」が必要となるケースもあるだろう。）

繰り返しになるが、あくまで Team は例外無く（セキュリティ、QA なども含めて）クロスファンクショナルであることが理想なようだ。

LeSS 実践のための Tips

講義の中で、LeSS 実践のための Tips がいくつか紹介されていたので、ここにまとめておく。

LeSS の導入

本記事では説明を省いたが、LeSS の中にも 2 ~ 8 つの Team で構成される Basic LeSS と、8 つよりも多くの Team で構成される LeSS Huge が存在する。この 2 つの中で、Basic Less の導入については、1 つの Team を徐々に増やしていくやり方ではなく、始めから Basic LeSS の構成（2 ~ 8 Team）で一斉に導入するのがが望ましいようだ。

また、上記理由からも 2 ~ 8 Team のコンポーネントチーム同時にフィーチャーチームに組み替えていく必要があるため、LeSS の導入には組織構造の変更を伴うケースが多い。ただ、そういった組織改革には必ずと言っていいほど反対勢力が存在する。その際に重要となるのが、少なくとも以下の図におけるキーパーソンには予め LeSS 導入の価値を理解しておいてもらい、協力を得られる関係を築いておくことだ。

コンポーネントチームの組織構造

このキーパーソンは、コンポーネントチーム型の組織構造において、ビジネス層とエンジニア層の狭間に位置する人物であり、エンジニア層に対する人事権を有している場合が多い。また、人事権を有していれば誰でも良いわけではなく、エンジニアリングに関する知識が全く無い層（例えば CEO など）だと、LeSS 導入後にエンジニア層の人々が「LeSS を やらされて いる」という感覚を持ってしまうようだ。

なお、この辺は言うまでも無いことかもしれないが、組織に　LeSS を導入する場合には、既存のコンポーネントチームにおいてアプリの開発を行っているチーム（上記図における App Team）の近辺から着手するのが良いらしい。具体的な理由については研修の中では述べられてはいなかったが、おそらくコンポーネントの性質上クロスファンクショナルな Team が編成しやすいことが要因だろう。

フィーチャーチーム適応マップ

「コンポーネントチームよりもフィーチャーチーム」、「Undone は少ない方が良い」といった理想はわかるが、実際これらを完璧に実践している Team というのもそこまで多くは無いだろう。

現時点で Team がこれらをどれだけ実践できているか、また理想の状態に向けて何をしていけばよいかを議論するためのツールとして、研修の中ではフィーチャーチーム適応マップというものが紹介されていた。

フィーチャーチーム適応マップ (※)

フィーチャーチーム適応マップでは、横軸に Definition of Done（現時点で実現できているものから順に、実現できていないものまでを列挙していく）、縦軸にチームが扱うことのできる技術スコープを取り、現時点で Team がグラフ上のどこに位置しているかをプロットする。次に、Team の目指す少し先の未来の状態をグラフ上に同様にプロットし、先にプロットした現時点の状態から未来の状態へ以降する上で、「何が阻害要因となっているか」、「具体的にどのようなアクションを取るべきか」を議論する。

大人数で実施する Ceremony

LeSS の概要の章でも簡単に触れたように、Product Backlog Refinement や Sprint Review などの Ceremony には、基本的に全ての Team の全てのメンバーが参加する。ただ、2 ~ 8 Team もの大勢のメンバーが一挙に集結する Ceremony の実施の仕方にはいくつかのコツがある。

Product Backlog Refinement については、以下の図のように複数 Team のメンバーでグループを作成し、グループ単位で Product Backlog Item (PBI) の精査や、必要に応じた分割を行う。

Product Backlog Refinement

Sprint Review

Sprint Review については、各 Team の代表者が成果物のデモを行い、それ以外のメンバーは他の Team の成果物を見て回る。（もちろん PO や Stakeholder も、同様に見て回る。）

バザー形式の Sprint Review

トラベラー

LeSS のように、複数の Team で開発をしていると、どうしてもそれぞれの Team が有しているスキルに差が出てくる場合がある。そういったスキルの差を埋めるために、LeSS では他の Team が必要とするスキルを持つ開発者を Team 間で移動させる「トラベラー（Team 間を旅する人の意）」という仕組みを設けている。

ただ、基本的に Scrum においては、Team からメンバーが減ること以上に、Team にメンバーが加わることによる生産性の低下を気にしなければならない。「トラベラー」の仕組みでは、受け入れ先の Team が「トラベラー」の加入を望んでいる場合に限り、 メンバーの Team 間での移動を許可している。

ソースコード管理

ソースコード管理に Git を使う辺りは一般的だと思われるが、以下のような使い方を推奨していた。

ブランチを切りすぎない
プルリクエストは使用しない

Git の思想からはかなり離れているような気もするが、ブランチを切りすぎて開発者が自身の（もしくは自身の所属する Team の）開発している部分しか見なくなってしまうことを防ぐ目的らしい。さらに言えば、コミットに問題があった際には、即座に誰もが気づけるように、開発者が皆 master ブランチに直接コミットをプッシュするのが望ましいという話だった。

正直なところ、現実世界においてこういったの運用が成り立つイメージは全く沸かなかったのだが（他の研修参加者も同様の感想を抱いていたようだ）、モブプログラミングなどを導入すると、わざわざプルリクエストを送るのが面倒になって形骸化してくるよね、という意見は研修参加者の間でも少なからず出ていた。

リモートワーク

ここ最近では、様々な企業でリモートワークの導入が進められているという話はよく耳にするが、Scrum あるいは LeSS という文脈に限った場合には、リモートワークを手放しで推奨することはできないようだ。

例えば、通常の Scrum の場合だと、以下のように Team は同一拠点で作業を行うことが推奨されている。

Scrum におけるリモートワークの可否

また、LeSS にまで話を広げると、Basic LeSS を構成する 2 ~ 8 Team についても、極力同一拠点で作業を行うことが推奨されている。

LeSS におけるリモートワークの可否

これらの理由としては、Team のメンバーが物理的に同一の空間で作業を行うことで享受できるメリットが比較的多いことが挙げられる。例えば、Sprint Planning などの Ceremony タイミングで Team のメンバーがリモートワークをしていて、それぞれが自身の PC を見ながら議論するのと、メンバーが一箇所に集まってホワイトボード上に作成した Sprint Backlog を見ながら（メンバー全員が、「物理的に」同じ方向を見て）議論するのとでは、だいぶ勝手が違うだろう。また、Ceremony 以外でも、些細なことを Team のメンバーに聞きたいのだが、チャットで聞くには少し内容が複雑だ、といったケースもあったりするかと思う。こういうケースでは、リモートワークよりも、オフィスなどのスペースに Team のメンバーが集まって作業をした方が、効率が良い場合も存在する。

とはいえ、働き方に多様性を設けようとした場合、リモートワークは避けて通れないのもまた事実である。研修参加者の中には、面白い方法でこの問題を解決している方がいた。その方の会社では、オフィスにおける Team のワークスペースに、常時接続型のビデオ会議システムを導入し、リモートにいる Team のメンバーと常にビデオコールでつながった状態で作業をしているとのことであった。この方法によって、リモートのメンバーとも同一拠点にいるのと近い感覚で作業ができているとのことであった。話が少し飛躍するが、最近では VR 機器を使用した会議なんてものも出てきているようなので、技術の革新によってこの辺の問題は今後さらに緩和されていくのかもしれない。

人事評価

LeSS に限らず、Scrum では Team 内の個々のメンバーのパフォーマンスよりも、Team 全体でのパフォーマンスを最大化する方向で物事を考えることが多い。そういう意味では個人の人事評価はどのように実施すべきなのかという話は、研修参加者の中でも自然と話題に挙がった。

研修参加者の方々が口をそろえて言っていたのは、「定量評価」の替わりに「定性評価」を導入するようになったという話だった。各メンバーの Team に対する貢献度合いは、わざわざ定量的に評価せずとも一目瞭然なようで、Team 内でもある程度コンセンサスが取れているケースが多いらしい。むしろ定量的部分に着目し過ぎると、個人が数字ばかりに気を取られるようになり、Team 内での助け合いが減ってしまう恐れもあるようだ。

特に面白かった話としては、今回研修に参加していた、とある会社では、そもそも人事評価という概念が無いらしい。そのかわりに、社員は自身の欲しい額の年俸を提示し、それらの希望に応じて会社の予算の中から給料が振り分けられる。一見夢のような制度に見えるかもしれないが、その一方で全社員の給料が社内で公開されることで、公平性が保たれているとのことであった。

おわりに

本ブログは、認定 LeSS 実践者研修の講義内容及び、研修参加者との議論の中で出てきた話を私の観点でまとめたものとなっている。私の現職における役割上、LeSS の導入を実践する立場にはいないため、本ブログに記載されている内容については、実際に私が LeSS の導入を行って検証したものでは無い点については予めご理解いただければと思う。もし本ブログを読んでいただいた上で、「この解釈は誤っている」、「実際にうちで導入した場合にはこのようになった」などのご意見があれば、是非コメントいただければと思う。

キャプションに (※) 印の付けられた画像は、https://less.works からの転載である。なお、これらの画像は creative commons ラインセンスの下での使用が許可されている。（参考: https://less.works/resources/graphics/book-images.html） ↩
【BOOKレビュー】チームの強化に役立ちそうな本──勝手にレビュー #002 より。 ↩

Cat's Whiskers

在宅勤務環境構築（デスク周り）の覚え書き

きっかけ

在宅勤務環境（デスク周り）に関する個人的な要件

完成形（写真）

構成

解決策

1. モニター

2. 音響周り

3. 仕事用・私用 Mac における周辺機器の切り替え

今後の課題

Jira REST API 利用のためのコマンドラインツール「jirest」

きっかけ

Jira REST API 利用のためのコマンドラインツール「jirest」

インストール

使い方

Jira Cloud インスタンス・ユーザー情報設定

API 情報取得

API 実行用 curl コマンド生成

API 実行

API 実行用テンプレートの定義

API 実行用テンプレートの削除

API 定義の更新

API 定義のロールバック

おわりに

キャリアについての考え方

きっかけ

一般的なキャリア形成の話

人々の働き方の変化とキャリア形成

おわりに

macOS で自炊データを PDF 化する際の覚え書き

きっかけ

目標

要件の整理

環境

手順

① 書籍名ディレクトリの抽出

② 画像ファイル群を PDF へ変換

まとめ

jira.atlassian.com の（歩き方ならぬ）走り方

はじめに

目標

JAC の検索術

① 敢えて Jira の検索機能を使用しない

② 不要な検索結果を削ぎ落としていくイメージを持つ

③ その他のテクニック

ⅰ. 「バージョン」のワイルドカード検索

ⅱ. ランチャーアプリを使用した Jira 検索

おわりに

Large-Scale Scrum

はじめに

Scrum と LeSS の関係

LeSS の成り立ち

LeSS の概要

プロダクトの定義

科学的管理法（テイラー主義）

コンポーネントチーム vs フィーチャーチーム

Definition of Done

LeSS 実践のための Tips

LeSS の 導入

フィーチャーチーム適応マップ

大人数で実施する Ceremony

Product Backlog Refinement

Sprint Review

トラベラー

ソースコード管理

リモートワーク

人事評価

おわりに

② 画像ファイル群を PDF へ変換

① 敢えて Jira の検索機能を使用しない

LeSS の導入