nDiki : プラクティス

ざっくりわかるアジャイル開発勉強会

スクラムおじさんの、はらかち氏によるアジャイルソフトウェア開発についての勉強会「アジャイル開発勉強会」。マスター・センセイよろしくお願いします。

価値・原則・プラクティスが大切、原則があってプラクティスを実行して価値が生まれると。アジャイルサムライでこの原則を学びましょうということで、アジャイルサムライ第1章「ざっくりわかるアジャイル開発」を輪読。音読で順番に読むのかなり久しぶりだけれど、復習にいいかも。

• アジャイルサムライ

気付き

計画は変えていくけれど、立てないわけじゃない(はらかち氏)。

「アジャイル開発の原則: 『顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。』 p.8」はユーザーサポートでも「顧客満足を最優先し、価値のある回答を早く継続的に提供します。」と言い換えて原則とすべきだなーと。

スライド (はらかち氏)

http://www.slideshare.net/harakachi/20140709-36813334

今日のさえずり: コードレビューよりもペアプログラミングした方が的確に伝わる気がしてきた

• 00:46 「『メルカリはカスタマーサポートがすごい』というイメージが定着する状態まで持っていけるように努力をしています。」 / “メルカリの米国展開はどうなるか、国内フリマアプリ市場のこれからは--山田氏に聞く - (page 2) ...” http://bit.ly/1qA4iy2
• 06:55 ラジオ体操今日も。
• 18:42 今日もザザッとくるのか……。
• 18:47 「雨男じん」が外で出ていった。しばらくもうダメだ。
• 21:25 コードレビュー繰り返すよりもペアプログラミングした方が早くかつ意図が的確に伝わる気がしてきた(ただし相手が Emacs 使いに限る)。
• 23:33 とりあえずリーダブルコードの「2章 名前に情報を詰め込む」と「3章 誤解されない名前」を20回ぐらい読むとキラキラネームが減ると思う。
• 23:46 「県警音楽隊は演奏しながら、インターネットトラブルに巻き込まれないように呼び掛けた。」 / “サイバー犯罪防止でセミナー | 宇部日報社　このまちメディアWeb” http://bit.ly/1nwcT17
• 24:57 “Perlベストプラクティスのベストプラクティスじゃないやつをまとめてみた | おそらくはそれさえも平凡な日々” http://bit.ly/1uj3D5L

レクサー・リサーチ開発同窓会

2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!

COGS DINING KAGURAZAKA (コグス ダイニング 神楽坂)

手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。

• http://www.cogsdining.com/

ソフトウェア開発

現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。

大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。

• プロジェクト
  • ソフトウェアかんばん
  • ITS (影舞・Redmine) の利用
    • BTS やコミットメント・リストとして。
  • スタンドアップでの朝会
  • すごい会議
  • 成果物完成毎の記念撮影
• 情報共有
  • 社内 Wiki
    • 2002年3月初設置。
  • 社内 Blog
    • 2006年あたり(記事)
• 開発ツール
  • バージョン管理 (CVS・Subversion・Git)
  • pLaTeX2e を使ったドキュメンテーション
• その他
  • 書けなくなったホワイトボードマーカーはその場で床に投げ捨て

「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。

退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.

その他

同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。

そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。

今日のさえずり: 「なんで吉野家なのに2階あんの? なにこの都会。」

2015年08月28日

• 07:46 LED シーリングライト注文。
• 09:17 電車が駅に近づいてスピードを落としたところで、車掌さんが「○○駅です。どうぞ良い一日をお過ごしください。」とアナウンス放送したので、今日は良い一日にします。
• 09:36 「これ自体が山手通りなんじゃないのー?」(違います)
• 11:10 “情報処理学会デジタルプラクティス - 進化し続けるコールセンタへの道：ITpro” http://nkbp.jp/1ImOroW
• 11:10 “情報処理学会デジタルプラクティス - コンタクトセンタ運用効率化の取り組み：ITpro” http://nkbp.jp/1NDv6YI
• 14:22 「なんで吉野家なのに2階あんの? なにこの都会。」

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の14回目。今日は第14章 スクラムのプランニングの原則。

原則とは?

今回は「原則」の章ということで、今日の発表当番だった CSM の人があらためて「原則とは?」という点について掘り下げてくれました。「価値とプラクティスを結ぶ」原則について

「原則なしに上辺だけプラクティスを実行してても意味ないよ」

と CSM の人が語ってくれました。「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」についてその場でみんなで見返しました。

事業体としての価値観と原則、個人としての価値観と原則、そして開発プロセスフレームワークとしての価値観と原則と、この辺り自身でも整理しないとなと最近考えているところです。

プランニング

プランニングについては出来上がった計画よりも計画のための対話などのプロセスが重要なのだなと最近感じるようになりました。

• 事前にきちんと計画を作れると思うな
• 計画を守ることよりも、計画の調整や再計画を重視する

ということで継続的にプランニングし直していくことが大切なのだなと。

14.4 プランニングの選択肢は、最終責任時点まで変更可能にする

についてはここではかなりあっさりとかかれています。物事を進めるには常に大小様々な意思決定をしていく必要があるので、さらっと読むと気持ちわるい感じがします。ここは 3.3 節にも

重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とあるので、方向転換できない状態に早い段階でならないようにするといったところなのだと理解しました。

14.7 早めにリリース、頻繁にリリース

については原則として頭にいれつつ、実際には適切なフィーチャーが揃っているかをきちんと考える必要がありますね。あまりに小さなリリースすぎて早い段階でユーザーに見限られてしまう危険性や、頻繁な変更によってユーザーが負担を感じて満足度が低下してしまう可能性も常に意識すべきかと。

この章でも

この手法には限界もある。まずどんなプロダクトであっても、最低限これだけは揃えないとリリースできないし市場で勝負できないというフィーチャー群がある。

と言った上で

もし部分的にでもよいから少しでも早めに受け取りたいという業界を相手にしているのなら、小さい単位で頻繁にリリースするという原則はとても重要になる。

としていました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第23回 エッセンシャル スクラムを読む会 (最終回)

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変革するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

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

エッセンシャル スクラムを読む会のふりかえり

エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

• 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
• チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
• 原則大事(第3章・第14章など)。
• WIP を下げる重要性をあらためて学んだ。
• 準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

• プロダクトバックログリファインメントで1スプリントにおさまるように適切にプロダクトバックログアイテムを分割するの大変だよね。
• スクラムマスターと開発チームメンバ(エンジニア)との兼任が難しかった。
• スクラムマスターであると同時に組織図上のリーダーという立場でいると、自発的行動を促すのとある程度指示的に動かすのとの兼ね合いが悩ましかった。
• 困った状態であることにメンバが気がつくのを3カ月待った上で物理かんばんを導入してみた(すごい)。

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

• 2016年10月25日 第1回 第1章 イントロダクション
• 2016年11月01日 第2回 第2章 スクラムフレームワーク
• 2016年11月08日 第3回 第3章 アジャイルの原則
• 2016年11月15日 第4回 第4章 スプリント
• 2016年11月22日 第5回 第5章 要件とユーザーストーリー
• 2016年11月29日 第6回 第6章 プロダクトバックログ
• 2016年12月06日 第7回 第7章 見積もりとベロシティ
• 2016年12月13日 第8回 第8章 技術的負債
• 2016年12月20日 第9回 第9章 プロダクトオーナー
• 2017年01月10日 第10回 第10章 スクラムマスター
• 2017年01月17日 第11回 第11章 開発チーム
• 2017年01月24日 第12回 第12章 スクラムチームの構成
• 2017年01月31日 第13回 第13章 マネージャー
• 2017年02月07日 第14回 第14章 スクラムのプランニングの原則
• 2017年02月14日 第15回 第15章 さまざまなプランニング
• 2017年02月21日 第16回 第16章 ポートフォリオプランニング
• 2017年02月28日 第17回 第17章 エンビジョニング (プロダクトプランニング)
• 2017年03月07日 第18回 第18章 リリースプランニング (長期計画)
• 2017年03月14日 第19回 第19章 スプリントプランニング
• 2017年03月21日 第20回 第20章 スプリントの実施
• 2017年03月28日 第21回 第21章 スプリントレビュー
• 2017年04月04日 第22回 第22章 スプリントレトロスペクティブ
• 2017年04月14日 第23回 第23章 未来へ

マニャーナの法則本にある緊急レベルで Remember The Milk の優先度を変える

金曜日の会社帰りに買った「仕事に追われない仕事術 マニャーナの法則 完全版」読み終わり。

昨日 Remember The Milk の優先度をちょっと変えて

• 優先度 1: will do リスト(クローズドリスト)
• 優先度 2: 今日中にする緊急のタスク
• 優先度 3: 明日(翌営業日)やる
• 優先度 4: 明後日以降にやる

としてみています。今まではこの 1 と 2 を分けていなかったのを分けるようにしてみてます。その他のプラクティスはもうちょっと整理してから取り入れてみるつもり。

• 仕事に追われない仕事術 マニャーナの法則 完全版

今日のさえずり: 夜の米飯を減らすかなあ

• 22:17 『コミュニティ・オブ・プラクティス』を読み始めた。今のところ企業内のコミュニティの話。
• 22:21 足早に。 #photography RICOH GR III #GR #GRIII #GR3 https://t.co/ufiGJAaIJj
• 25:25 サラダチキン + 生野菜ランチ生活36日目。 体重の減りが微妙になってきている。あとは運動するしかないか。それとも夜の米飯を減らすかなあ。
• 25:30 胃がちっちゃくなってきた実感がある。

足早に。#photography
RICOH GR III #GR #GRIII #GR3 pic.twitter.com/ufiGJAaIJj

— Naney (@Naney) July 9, 2021

『amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法』

会議の資料は「箇条書きではなく文章で書く」のが Amazon のルールと紹介している書籍『amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法』が気になって全部読んでみた。

「会議資料の準備」と Amazon 流の「意思決定会議」「アイデア出し会議」「進捗管理会議」、そしてそのやり方の背景にある信条「Our Leadership Principles」との関係について読みやすくまとめられていた。

本書の内容は「Our Leadership Principles」という価値観・行動原則を体現したマネジメントや会議のスタイルだ。なので読んでやり方だけ真似てもうまくいかない。Amazon 流会議の紹介から同意できる大切にしたい価値観・行動原則を見つけ自分や組織に取り込みつつ、会議スタイルも参考にしていくのが良いのだろう。いや価値観・行動原則を取り込められたのなら、もう真似などせずとも自ずとイケてる会議スタイルになっていっているに違いない。

とはいえピンポイントで「なるほど」「やってみたい」というのもいろいろあったので、それはそれでピックアップして参考にしたい。

会議資料: 箇条書きではなく文章で書く

「箇条書きではなく文章で書く」については

いつ誰が読んでも確実に伝わる

と「伝えるための表現形式」として、また

きちんとした文章にするとなると、読んだときに辻褄が合わない部分が出て来ないように、最初から整合性をとらなくてはなりません。そのため、吟味に吟味を重ね、適切な情報を用いて推敲を重ねなければなりません。

と「書いて考えるための表現形式」として文章形式(ナレーティブ形式)の良さが説明されいた。

最近はできるだけ箇条書きではなく文章で書くようにしている。やってみると、なるほどそうだなと。お勧めのプラクティスだ。

会議資料: 定形フォーマットはつくらない

「定形フォーマットはつくらない」という話には唸った。

先人からの学びや自身の経験から「これは共通理解や意思決定に必要」という項目が自分なりにいくつかあって、ドキュメントの構成として意識していたりする。

しかしその構成に固執したり他人に強いたりすると、変化の阻害要因になりかねないと。定形にすると便利で楽だけれど思考の硬直につながりかねない。意識したい。

あとは

• プロジェクトリーダーが意思決定会議のオーナーになる。
• 本題から外れた意見をメモしておく「パーキングロット」を使って脱線から戻す。
• ソーシャル・コヒージョン (Social Cohesion) に気をつける。
• 「メトリックス・レビュー」と呼ばれる会議には、異常値の分析・対策検討など然るべき準備をした上で望むのが暗黙のルール。

は意識したりやってみたりしたいなと思った。

それから

• 意思決定会議で「What(何を) Who (誰が) When (いつ)」を明確に決める

というのは、『すごい会議』で学んだ

• 「誰が」「いつまでに」「なにをして」「どんな成果をだすか」を明確にする

というのと同じ普遍的な考え方だな。ガッツがいるのでついユルくなりがちだが、スピードと成果が圧倒的に変わってくるのでしっかり踏ん張ってコミット・リクエストしたい。

• amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法 (Kindle版)
• amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法 (単行本)

[ 読書ノート ]