nDiki : ワークフロー

第5回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会5回目。今日は第5章 要件とユーザーストーリー。

「5.3 改良し続ける」では要件の詳細化について書かれています。

いつかやるかもしれない(やらないかもしれない)要件よりも、すぐに取りかかろうとしている要件のほうが小さくて詳細化されている。必要になったときにジャストインタイムで、詳細化されていない大きな要件を小さくて詳細化された要件の集まりにするのだ。

必要な範囲で要件の詳細度を上げていくということを明確にしているのがスクラムらしいですね。ただ直近取りかかるものばかり意識していると、破棄する要件は減るかもしれないですが作ったものを捨てる(か、そうでなくても変更しなければならなくなる)こともありえるので、そのあたりの絶妙なさじ加減が必要でしょう。

このあたりが「5.5 詳細化レベル」での「ユーザーストーリーの抽象化階層」の話でフォローされている感じです。

ユーザーストーリーの作り方としては「5.9 ストーリーの収集」で「ストーリーマッピング」というテクニックが説明されています。

抽象的なユーザーの行為を、詳細タスクによって組み立てられるワークフローに分解する、というものだ。

ストーリーを時系列と優先順位の2軸で作っていくというやり方でなかなか良さそうでした。ひとまとまりのサービス/機能を作る時は試してみたいです。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

Alfred から一発で日時ファイル名のファイルを新規作成し Ulysses で開けるようにする

Mac ではもっぱらライティングアプリ Ulysses でノートをとっています。さっとメモをする時はあとで整理しやすいように日時がファイル名になっているファイル(シート)をぱっと新規作成して開きたいなと思っていたので方法を調べてみました。

x-callback-url が使える

Ulysses の Mac アプリケーションでも iOS アプリと同様に x-callback-url に対応しているようなのでこれを使うことにしました。

• https://ulyssesapp.com/kb/x-callback-url/

ターミナルで

 open ulysses://x-callback-url/new-sheet?group=/home/workspace/note\&index=1000\&text=`date +@:%Y-%m-%d-%H%M%S`

とすると外部フォルダ home の中の workspace/note の中に今の日時に合わせて 2017-08-24-130102.md のようなファイルが作成され、 Ulysses がアクティブになりそのシートが開いた状態になります。便利。

ちなみに Ulysses の外部フォルダ上のシートを新規作成して開くなら、同様の日時ファイル名のテキストファイルを作成し

 open -a UlyssesMac ファイル名

で開くようなスクリプトを書くのでも OK です。

Alfred から呼べるようにする

動作することがわかったので Alfred 3 for Mac から呼び出せるようにしました。

• https://www.alfredapp.com/

今日 Alfred を初めて入れてみたので workflow などの機能については良くわかっていません。まずは先のコマンド実行をアプリケーションにして Alfred から呼び出せるようにします。

アプリケーションを作る

1. Automator を起動
2. 新規ワークフローを作成
3. 「シェルスクリプト実行」アクションを右のペインにドラッグ&ドロップ
4. シェルスクリプトとして前述の1行コマンドを入力
5. 右上の実行ボタンを押して動作することを確認
6. フォーマットに「アプリケーション」選択し ~/local/Applications/new-note.app として保存(Alfred の初期設定ではホームディレクトリ以下ならどこでも OK)

これで option + shift で Alfred を表示したあとに new-note と入れて実行するれば、新しい日時ファイル名のファイルが作成されて Ulysses 上でシートが開いた状態になります。

これで Ulysses でさっとメモを取るのが一気に楽になりました。

[ ノート・日記はテキストファイルに ]

ワークフローを作る時は「誰が」「いつまでに」「なにをするか」を明確にする

「誰が」「いつまでに」「なにをして」「どんな成果をだすか」を明確にしてコミットしよう/リクエストしよう。

というのを自分の行動原則の1つにしています(完全に守れているわけではないのですけれども)。

今日、サービスの不具合管理のワークフローの見直しをチームでしていて、原案が気持ち悪いなと思ったのは「誰が」が不明確だったからでした。「気がついた人が」や「◯◯が役割の人が」は絶対誰もやらないケースが出てきます。思い切って個人に割り当てる(そして無理だった場合はエスカレーションする)ルールの方がきちんと仕事がまわります。

[ opinion ]

Developers Summit 2019 1日目 #devsumi

2015年・2016年・2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00～10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ

• スケール
  • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
• Scrum @ Scale フレームワーク
  • スクラムだけでもスケールする。
  • スクラムマスター(SM)
    • デイリースクラム階層。チームで解決できない課題を上位のデイリースクラムに伝えて解決していく(チームのデイリースクラムの方を1日の先にやる)。トップレベルは役員によるエグゼクティブアクションチーム(EAT)。 EAT もスクラムチームなのでスクラムの全てのアクティビティをやる。
    • SM で寄ってたかって協力。
    • マネージャーの仕事。
  • プロダクトオーナー (PO)
    • チームに1 PO。PO チーフ PO。チーフチーフ PO。
    • PO は上位のオーナーが絶対。
  • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
• PO
  • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

11:05～11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10～12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05～13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10～14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた ～spanner、GKE導入の実体験から得たこと～

株式会社コロプラ 廣本洋一氏

• コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
• コピーベースで新しいアプリケーションを作ることによる課題があった。
• ノーメンテナンス時間というポリシーを前提とした技術選択。
• オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15～16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末で退職済みということで、嗚呼となった。

16:20～17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25～18:45 【14-A-8】 「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーションと投票・発表のセッション。

Alfred から指定したチャンネルを Mac 版 Slack デスクトップクライアントで開く

 slack://channel?team={TEAM_ID}&id={CHANNEL_ID}

という URL で Mac 版 Slack デスクトップクライアント上で指定したチャンネルを開けるということがわかったので Alfred でワークフローを作って開けるようにした。

deep linking を使うだけなら認証・承認まわり関係ないのでお手軽。

TEAM_ID と CHANNEL_ID はデスクトップ版のサイドバー上のチャンネルでリンクをコピーして確認。

• Deep linking into Slack clients | Slack

Alfred のワークフローをまとめる

Alfred からテキストノートに書き込んだり開いたりするワークフロー、ちょっとした亜種(書き込むファイルの違いとかタイムスタンプの有無とか)毎にとりあえず複製してアレンジして増やして済ませていたのだけれど、さすかにごちゃごちゃしてきたのでようやく1つにまとめることにした。

フローの途中で変数を設定して run scripts しているシェルスクリプトの動作をコントロールする形でまとめた。

ああ Alfred の Android 版が欲しいな。

nNote ノートテキストファイルを Alfred で一発で開けるようにした

Alfred からテキストノートに書き込んだり開いたりするワークフローを整理していて「そういえば最近 nNote 活用していないな」と気がついたので、その日の nNote ノートテキストファイルも Alfred からさくっと一発で新規作成 & iA Writer でオープンできるようにしておいた。

[ ノート・日記はテキストファイルに ]

Pixel 4 撮影からの私的 Lightroom ワークフロー

Pixel 4 で撮影してそのまま Lightroom で現像/編集し、あとで PC 上の Lightroom Classic 管理に移す私的フローを明確にしてみた。2年前に書き出した手順のアップデートである。

【Pixel 4】Pixel 4 で撮影しシェアできる画像を書き出して使う

1. Pixel 4 で撮影する。
2. Lightroom に写真(DNG または JPEG) を追加。
3. Lightoom で編集。
4. 「JPG を保存(小)」(JPG・2048px・画質90%)で書き出し。

【PC】オリジナル画像ファイル・書き出したファイルの保存

Pixel 4 上の下記のフォルダを FolderSync Pro で Dropbox に同期するようにしてある(記事)ので、そこからオリジナル画像ファイル・書き出したファイルを PC 上の保存先フォルダに移動してリネームする。

• DCIM/Camera/
  • Pixel 4 のカメラが保存したオリジナル JPEG ファイル
• Pictures/RAW/
  • Pixel 4 のカメラが保存したオリジナル DNG ファイル
• Pictures/AdobeLightroom
  • Lightroom で書き出した JPEG (SNS などにシェアしたであろうもの)

JPEG ファイルを編集した場合は、現像設定を含まないオリジナル JPEG ファイルをここで保存しておく。 DNG ファイルから現像の場合は現像設定未書き込みファイルまでは保存管理していないのでスキップ。

【主に PC】現像設定が含まれる画像ファイルの保存

Lightroom Classic を起動し、 Lightroom と同期されているのを確認したあと以下の手順で。

1. DNG ファイル(現像設定はメタデータ書き込み済み)を別フォルダにコピーしリネーム。
2. JPEG ファイル(現像設定はメタデータに書き込み済み)を別フォルダにコピーしリネーム(ベース名の末尾に -Lr をつける)。
3. Lightroom Classic でコピー先のフォルダを同期しカタログにのせる。
4. Lightroom で画像を削除。
5. Pixel 4 の Google フォトアプリでデバイスから各画像ファイルを削除。
6. (必要があれば)現像設定が含まれる画像ファイル(DNG/JPEG)から元サイズで JPEG で書き出して、仕上げ済みのフォルダへ移動したり Google フォトにアップロードしたりしておく。

現像設定をメタデータとして書き込んだ JPEG ファイルは、一般のアプリケーションで開いても編集前の画像しか見えず区別しづらいので -Lr をつけるルールにしている。

背景

昨年11月2日に Pixel 4 に乗り換えてからはや7カ月。評判の良い Pixel 4 のカメラだが、画像処理の結果によっては撮った写真に好みではない不自然さを感じることがままある。 Pixel 4 は(どこまで生なのかわからないが) RAW 画像形式でも同時に保存ができるので、 JPEG 画像が好みではなかった場合には JPEG 画像からの補正以外にも RAW 現像という選択肢もあるのは嬉しい(色合い以外は Pixel 4 内で画像処理されたものの方が綺麗に感じることも多かったりするわけだが)。

前のスマートフォンに比べてカメラの性能がずっと良くになったのに「家に帰って仕上げてから」という意識が強くて外出先でその場でシェアするという活用が最近できていなかった。これでもうちょっとサクサクっとその場でやっちゃう意識がもてるようになるといいな。

日次・週次・月次まとめをいい感じにやりたい【日記】

週次報告・月次報告が少し増えてきたので、日次ノートから週次レポート・月次レポート化していくワークフローとドキュメント管理について整理しなおし。

日次・週次・月次の階層別にデータを表示(あるいは入力)したうえで考察を書き込めて、あとでそれぞれ日次・週次・月次のビューを作れるようなドキュメント管理をしたいなあ。できればテキストファイルベースで。

Alfred でのノートテキストファイル作成ワークフローのバリエーションを作りすぎた

• 日別の「デイリーノート」
• ちょっとした「ノート」
• ちょっとした公開用の「nNote」

に加えて

• 「issue ノート」
• 「thoughts ノート」

も Alfred ワークフローで一発作成できるようにしてあったのだけれど、ちょっとやりすぎで最後の2つはすぐ使わなくなったので削除。