nDiki : ワークフロー

ワークフロー - workflow

ビジネスプロセスの「自動化」。

web

スポンサード リンク

2015年11月30日 (月)

「なぜ Excel 方眼仕様書だと駄目なのですか?」

先週ワークフロー改善内容についてレビューしたところ添付されていた仕様書フォーマットサンプルが Excel 方眼紙だったので、これを機会に止めましょうとお願いしておきました。 そうしたところ今日になってツッコミをいれた人と同じグループの別の人から「なぜ Excel 方眼仕様書だと駄目なのですか?」と質問されました。即答するとなんか適当なことを言ってしまいそうなのであとで回答しますねと答えておきました。

Excel 方眼仕様書をもらった時の嫌だなという感情は「ファイルでの管理だから」「Excel だから」「方眼スプレッドシートだから」など複数の混ざり合った理由からやってきます。

この中で「ファイルでの管理だから」「Excel だから」は環境によっては排除できない場合もあるし、ユースケースにあっている場合もあるので単純に良い悪いとはいえません。

しかしながら「方眼スプレッドシート」で書かれた仕様書というのはいつでも不便なので止めて欲しいです。書かれている文章の部分が論理的な入力になっていないのが一番嫌な点です。1文毎に別のセルに書くとか、字下げは次の列のセルからとか、箇条書き項目ごとに次の行のセルとか。仕様レビュー仕様変更での更新が非常にやりにくい。説明を書き足しにくい。

だからといってシート毎に大きな図形を貼ってその中にテキストを書けば良いといったものでもありません。それこそ方眼にする理由はないでしょう。

編集を阻む仕様書は、仕様の品質を上げるコストを高くするのです。

スポンサード リンク
[ 11月30日全て ]

2016年11月22日 (火)

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

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

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

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

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

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

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

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

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

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

[ 11月22日全て ]

2017年8月24日 (木)

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

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

x-callback-url が使える

UlyssesMac アプリケーションでも iOS アプリと同様に 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 から呼び出せるようにしました。

今日 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 でさっとメモを取るのが一気に楽になりました。

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

[ 8月24日全て ]

2018年2月14日 (水)

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

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

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

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

[ opinion ]

[ 2月14日全て ]

2019年2月14日 (木)

Developers Summit 2019 1日目 #devsumi

image:/nDiki/2019/02/14/2019-02-14-145351-nDiki-800x1200.jpg

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)
    • プロダクトオーナー (PO)
      • チームに1 PO。PO チーフ PO。チーフチーフ PO。
      • PO は上位のオーナーが絶対。
    • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
  • PO
    • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

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

*1 どんなプロダクトバックログをいくつ用意すべきかを考えるにあたっては、基本原則がある。プロダクトごとに、プロダクトバックログをひとつ用意するというルールだ。-- エッセンシャル スクラム 6.7

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人の著者(や関係者)によるプレゼンテーション投票・発表のセッション。

[ 2月14日全て ]

2019年11月25日 (月)

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

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

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

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

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

[ 11月25日全て ]

2020年1月8日 (水)

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

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

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

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

[ 1月8日全て ]

2020年1月9日 (木)

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

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

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

[ 1月9日全て ]

2020年6月1日 (月)

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

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

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

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

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

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

  • DCIM/Camera/
  • Pictures/RAW/
  • Pictures/AdobeLightroom
    • Lightroom で書き出した JPEG (SNS などにシェアしたであろうもの)

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

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

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

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

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

背景

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

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

[ 6月1日全て ]

2020年7月14日 (火)

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

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

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

[ 7月14日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.050853s / load averages: 0.48, 0.66, 0.45
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker