nDiki : 顧客

2017年2月12日 (日)

今日のさえずり: 子供の科学、二宮康明先生の紙飛行機付録が去年終了していたなんて……

2017年02月12日

[ 2月12日全て ]

2017年2月16日 (木)

今日のさえずり: ツールを変えれば組織改善になると思っているのでしょうか

2017年02月16日

[ 2月16日全て ]

2017年2月21日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の16回目。今日は第16章 ポートフォリオプランニング

これまで読んだ章の中で一番頭にすっと入ってこない章だったのは、あまりかかわってこなかった領域だからでしょうか。

ポートフォリオプランニングはプロダクト(あるいはその1リリース、プロジェクトなど)をどれぐらいの期間でどの順番でやるかを計画する作業です。

本書ではプロダクトのライフサイクル収益(プロダクトの生存期間中に見込める利益の総合計)が最大になるように優先順位を決めましょうと言っています。ライフサイクル収益は遅延コストと存続期間の影響を受けるのでこれをきちんと考えましょうとのことでした。

今日の発表者によると「ライフサイクル収益を使うのは社内政治の排除のため。ライフサイクル収益には利益以外にも社員満足度・顧客満足度・従業員満足度(離職率と採用コスト・回復コスト)なども考えれれる」といったことを CSPO 研修で聞いたとのことでした。社内政治排除のためというところが重要どころだそうです。

本書によるとポートフォリオバックログに入れる際は

コストや価値に関するちょっとした見解の相違で言い争いになって決断ができないのだとしたら、そのプロダクトの開発は却下すべきだ。

とのこと。

ほとんどの組織では、価値の高いプロダクトを開発する機会が有り余っている。価値を生み出すか疑わしいプロダクトについて、いつまでも議論をしている余裕はないはずだ。

と言い切ってます。迷ったら不採用という考えについて Joel on Software の採用面接ゲリラガイドを思い出しました。

[ 2月21日全て ]

2017年2月28日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の17回目。今日は第17章 エンビジョニング (プロダクトプランニング)。

「エンビジョニング」という言葉に馴染みがなかったので「プロダクトプランニング」の方がわかりやすいよなーと最初は思ったのですが、慣れてくればエンビジョニングでも「ビジョン」に意識が向いていい気がしました。

エンビジョニングのタイミング

何度も繰り返すアクティビティであり、一度やってそれで終わりではない。

これ系のアクティビティはどうしても半期毎のサイクルになってしまいがちなのですが、アジャイル的にはもっと早いサイクルにやった方が良いということですね。

エンビジョニングをやりすぎないようにエンビジョニングの完了予定日を設定しておくのは確かに必要だなと感じました。やろうと思えばいくらでもやれてしまうものなので期日を明確にした方が経済的でしょう。

エンビジョニングの参加者

最初のエンビジョニングで必須なのはプロダクトオーナー。いったんプロダクトの開発が動き出して以降のエンビジョニングにはスクラムチーム全体が参加すべき。概要レベルのプロダクトバックログの作成でストーリー記述する際もスクラムチームメンバ全員が関わった方が良いと言っています。

このあたり結構孤独にやっちゃうことも多いんじゃないかと思うですが、やはりチームでやった方が良いようです。

価値のカテゴリ

図17.3 で「ステークホルダーが得る価値の分野」としてカテゴリ分けされているのは地味に便利ですね。

  • 参入条件
    • ハードルをクリアする
    • リリース可能な最小限のフィーチャーをデリバリーする
    • SOX、FDA、HIPAAなどに準拠する
  • 使用可能性
    • 新たなマーケットを対象とする
    • 他のプロダクトやサービスを販売できるようにする
  • 差別化要因
    • 競合他社と差別化する
    • 顧客を喜ばせる
  • 妨害
    • 競合他社の差別化要因を無力化する
    • ハードルを上げる
    • 市場での注目先を変えることで、ゲームのルールを変える
  • コスト削減
    • 市場に投入する時期を早める
    • 開発工数や投入する要員を減らす
    • 利益を増やす
    • プログラミングの技術を高める

自分が取り組んできたものだと「顧客を喜ばせる」「要員を減らす」とかが多かったですが、製品・市場によっては確かに妨害とかもあるのでしょうね。

今日は参加者少なめで5人。23章までいれるとあと6回のところまできました。

[ 2月28日全て ]

2017年3月7日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の18回目。今日は第18章 リリースプランニング (長期計画)。

今日は7人参加。

タイミング

リリースプランニングは一度限りのものではなく、スプリントごと行うアクティビティだ。

他のプランニング同様リリースプランニングも一度限りのものではないと明言されています。章の後半で説明される進捗の把握をしながら、スプリント毎に見直されていきます。

ポートフォリオプランニングでは「終わることのない作業」、エンビジョニング(プロダクトプランニング)では「一度やってそれで終わりではない」とそれぞれここまでの章で書かれています。全てのレベルにおいて継続が求められます。

ただスプリントプランニングをスプリントごとにやるとすると、どの程度時間を使うことになるのかが気になるところです。1週間スプリントの場合だと、さっと済ませるか何回かに1回にするのかが現実的なところでしょうか。

プロセス

各リリースには、明確に定義されたリリース可能な最小限のフィーチャー(MRF)がなければならない。(中略)顧客視点で、実用最小限の製品となっていることを確かめるのだ。

今の仕事は「フィーチャーごとにリリース」という方針でやっています。1スプリントで完成できるように例えばバックエンドという PBI にして先に完成させデプロイしておくというのをやったりしています。しかしバックエンドだけではここでいう MRF ではないですね。

いまチームではこのデプロイもリリースと呼んでいますが、エッセンシャル スクラム的に考えるとそれはリリースではないと考えた方が良いのかもしれません。

「各スプリントで価値を届ける」ことと「各スプリントでデプロイする」は同義でないと考え直した方が良いようです。

「いくつかのスプリントの成果物をひとまとめにしてリリースする」というプランニングの場合もあるのですから、毎スプリント必ずリリースするということに無理にこだわらなくてもということでしょうか。スプリントが終わった時点で常にリリース可能な状態になっていることが重要ということでしょうか。

リリース制約

気がつくと「スコープを固定」と無意識にしてしまいがち。ステークホルダーに期日を約束していないと、ずるずるとリリースを延期してしまいがち。

「スコープを固定」になる原因は、全体的なスコープがあまりにも大きすぎることであることが多い。

とあり、ここでもできるだけ小さくというのが推奨されています。MRF をいかに小さく定義しておけるかがポイント。18.4 節では「常にMRFを調整し続ける。」と書かれていて、MRF も適宜見直していくべきです。

期日を固定する方式がスクラムの原則にうまく当てはまるということなのでリリースプランニングの際にきちんと意識できるようにしたいです。

スプリントマッピング

主に複数チームで協調してスプリントを進めていくための話。ここは困ることが起きた場合にまた読み返したい部分です。

[ 3月7日全て ]

2017年3月14日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の19回目。今日は第19章 スプリントプランニング。ここから「第IV部 スプリント」。スクラムチームにとって馴染みがあるパートです。

スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。

タイミングと時間と参加者

スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。

今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。

  • チームメンバが2時間のプランニングミーティングに耐えられない。きちんとスプリントプランニングするメリットを感じられていない。
  • 3チームのプロダクトオーナー(自分)が時間を確保できない。

もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。

プロダクトバックログアイテムにかけるキャパシティ

完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。

 スプリントのキャパシティ
   = PBI にかけるキャパシティ + スプリントバッファ + それ以外

予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。

今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。

作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。

プロダクトバックログアイテムの選択

基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。

完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。

ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。

タスク分解と作業時間見積もり

自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。

スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。

[ 3月14日全て ]

2017年12月15日 (金)

通院で休んだついでに蒲田をぶらぶら【日記】

今日は午後通院があったので有給休暇。午前中に床屋もいっておきました(9月18日より約3カ月ぶり)。

13:30 に予約していた病院ですが、13:16 に到着、13:35 には診察が終わって 13:40 には会計終了で予想外にあっという間に完了。検査結果が悪性ではなかったということで心も軽くなりましたし、ぶらっと散歩することにしました。ちょっと歩いたところにある蒲田へ。

むげん

image:/nDiki/2017/12/15/2017-12-15-135911-nDiki-1200x800.jpg

蒲田といえばむげん。

中学生の頃はチャリで通ってました。当時はメリケンサック・スリングショットなんかもあったような記憶があるのですが今日見た限りは無かったです。

京急蒲田駅

image:/nDiki/2017/12/15/2017-12-15-141857-nDiki-1200x800.jpg

そのまま JR 蒲田駅の方へ行ってもよかったのですが、京急の高架が見えたので京急蒲田駅の方へ。駅前の蒲田八幡神社を参拝したら、神社がまさかの「絵」で衝撃的でした(工事中につき)。

京急蒲田駅前も変わりすぎて気絶しそう。高架化されてからは乗り換えで利用することはあっても駅から出ることもなかった京急蒲田駅、こんなに変わっていたとは。高架化された京急駅は梅屋敷駅もそうですけれども、何かコンクリ感が強くで街並みを殺風景にしている感じがあります。いつかいい感じに馴染んでいくんでしょうけれどね。

アスレチッタ蒲田

image:nDiki/2017/12/15/2017-12-15-143201-nDiki-800x1200.jpg

京浜蒲田商店街あすとを抜けて JR 蒲田駅方面へ。蒲田ゲームセンターをまわる時のお店の1つ、アスレチッタ蒲田1Fのゲーセン、インターアクティブガーデン GIO 蒲田店が健在で嬉しくなりました。なお中学生の頃に補導されそうになったことのある近くのゲーセンはカラオケ蒲田東口店になってます(東京都大田区蒲田5-15-9)。

アニメイト蒲田

あとはグランデュオ蒲田(旧パリオ・サンカマタ)をぶらぶらし、ついでにアニメイト蒲田をのぞいて今日の蒲田ぶらぶらはおしまい。

チームメンバに「アニメイトは(Swarm で)チェックインするけど、メロンブックスにはチェックインしない」と指摘いただきましたがお察しください。……という訳ではなく普通にメロンブックスは対象顧客外だったりします。まあ、もはやアニメイトも対象顧客外で特に買うものもないのですけれども。

[ 12月15日全て ]

2018年6月6日 (水)

遅延コスト (Cost of Delay, CoD) #nNote

遅延コストの計算: アジャイルソフトウェア要求でフィーチャーの優先順位付けをする場合

アジャイルソフトウェア要求」による計算方法では3つの属性の和

[ユーザー価値] + [時間値] + [リスク軽減値]

としています(それぞれ他のフィーチャーとの相対値で10が最高、1が最低)。

  • ユーザー価値: ユーザーの目から見たフィーチャーの潜在的な相対的な価値。
  • 時間値: ユーザー価値が時間とともにどのように減少するかの相対的な見積もり(価値が急速に低下するなら高)。
  • リスク軽減/機会の可能性の値: フィーチャーによってリスク軽減される、あるいは新たな機会を得るという相対的価値(大きなリスク軽減につながる可能性がある、新たな機会が得られ可能性があるなら高)。

遅延コストの計算: アジャイルソフトウェア要求でエピックの優先順位付けをする場合

アジャイルソフトウェア要求」による計算方法では3つの要素の和

[ビジネス価値] + [時間価値] + [リスク低減/チャンス利用]

としています(値はそれぞれ 1, 3, 5, 8, 13, 20, 40, 100、あるいはその他の等級)。

  • ビジネス価値(BV): 収益・シェア・コスト削減・顧客の囲い込み向上についての相対的な価値。
  • 時間価値(TV): 時間が経つとどの程度価値が下がるかの相対的な価値。大きい値は価値が急速に低下することを表し、小さい値は安定していることを表す。
  • リスク低減/チャンス利用(RRV): 将来のエピックリスクを低減する価値があるか、他のビジネスチャンスを活かす価値があるかの値。

遅延コストの計算: アジャイルエンタープライズの場合

アジャイルエンタープライズ」による計算方法では4つの要因の和

[収益の増加] + [収入の維持] + [コストの削減] + [コストの回避]

としています(それぞれ週当たり/年当たりの金額)。それぞれの要因は下記です。

  • 収益の増加: 新規または既存の顧客の売上が増えるアイデア
  • 収益の維持: 収益・市場シェアを維持するアイデア
  • コストの削減: 現在発生しているコストを削減するアイデア
  • コストの回避: 現在発生していないが発生する可能性のあるコストを削減するアイデア(罰金の回避など)。
[ 6月6日全て ]

2018年6月7日 (木)

プロダクトの遅延コストの算出方法を考える

WSJF (重み付けされた最短の作業から着手)という手法を使い始めるにあたり遅延コストを算出方法を見直し中。

エッセンシャル スクラムでは遅延コストの出し方をいくつか紹介しています。その中の1つ「アジャイルソフトウェア要求」で提案している3つ要素の和として決める方法をまずは使おうと思っています。

アジャイルソフトウェア要求では「フィーチャーの優先順位付け」と「エピックの優先順位付け」のところでそのやり方が出てきますが、今はポートフォリオプランニングレベルで考えているのでエピックの方が考え方として近そう。

プロダクトについて

  • ビジネス価値(BV): 収益・シェア・コスト削減・顧客の囲い込み向上についての相対的な価値。
  • 時間価値(TV): 時間が経つとどの程度価値が下がるかの相対的な価値。大きい値は価値が急速に低下することを表し、小さい値は安定していることを表す。
  • リスク低減/チャンス利用(RRV): 将来のプロダクトのリスクを低減する価値があるか、他のビジネスチャンスを活かす価値があるかの値。

をフィボナッチ数列の値で相対的に見積もります(アジャイルソフトウェア要求だと 1, 3, 5, 8, 13, 20, 40, 100 という等級を例として出しています)。

そして3つを足した

 [ビジネス価値] + [時間価値] + [リスク低減/チャンス利用]

を遅延コスト(CoD)とします。

正直なところ「金額」と「金額変化度合い」とをごっちゃに足しちゃう気持ち悪さがあってちょっとすっきりしない感じはあります。あと3要素それぞれで相対で決めていくとすると、特定の要素が大きめになって遅延コストを支配する可能性も出ちゃいそうだなと。

とりあえずやってまた考えるという感じかな。

[ 6月7日全て ]

2018年7月26日 (木)

今日のさえずり: 駅の階段を上がる時、コパトーンの香りがした

2018年07月26日

[ 7月26日全て ]

About Me

Naney Naney

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

About nDiki

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。

#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。

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

Other Notes

ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。

月別インデックス
Process Time: 0.078485s / load averages: 0.23, 0.42, 0.49
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker