nDiki : プリント

スポンサード リンク

2016年8月15日 (月)

偏愛マップを交換しての会話楽しかった!

偏愛力 〜人付き合いがうまくいくコミュニケーションの基本50〜

今度イベント偏愛マップを使ったらどうかということで、実際にメンバで偏愛マップを交換しての会話をしてみました。実際にやってみると会話が弾んでめっちゃ楽しかったです。これは良い!

偏愛マップ作り

今回は私以外はその場でとりあえず15分で手書きで偏愛マップを作ってみました。私は事前に作りつつあるβ版のものがあったのでそれをプリントアウトして手元に用意し、他のメンバが書くのを眺めていました。

みんなが書いているのをみて興味深いなと思った点としては以下がありました。

  • みんな黙々と書くので静か。
  • 書いている途中にニヤリとしたり、つぶやいたりしている人もいた。
  • PC/スマートフォンで調べながら書いている人がいた。主に漢字を確認していたとのこと。
  • 最初のカテゴリ作りでちょっと迷っている人がいた。キーワードの具体的も結構個人差があった。
  • SNS のプロフィールで書ききっているよ」と言う人はそれ以上書き出すのに困っていた。

それほど下調べせず「偏愛しているものを書き出してみよう」でやってみるとこんな感じになるんだなというのがわかりました。ワークショップとしてやる場合は、ある程度偏愛マップのサンプルを用意したり書く時のポイントを説明しておいたりすると良さそうです。

偏愛マップを交換しての会話

書いたあとは偏愛マップを交換してのトークタイムです。2人の偏愛マップに共通点があったり、あるいは興味をもってもらって質問されたりするともう嬉しくたまりません。ついつい熱弁してしまいました。テンションが上がりますね、これ。偏愛しているものなのでテンションが上がらないわけがありません。

一方「ちょっと話す側に回りすぎたなぁ」と個人的に反省しました。普段以上に会話のキャッチボールを意識する必要があるようです。

それから会話の中で「別の偏愛」があることを思い出してしまい、相手に預けている偏愛マップを取り返して追記したくなることが何度もありました。手元にメモパッドを用意してメモっておけるようにしておくのが良いですね。

偏愛トーク楽しいです。

スポンサード リンク

[ 8月15日全て ]

2016年8月31日 (水)

月見バーガーと隣のグループのインターンの最終日【日記】

お昼は月見バーガー。今年初。ベーコンが美味しく感じられました。マクドナルド内では見える範囲で女の人3人が Pokémon GO をやってました。

それから今日は隣のグループに配属されていたインターンの最終日。成果発表会があったので顔を出しました。発表後に質問を振られたので「直接お話ししたことはありませんが、 Twitter では常々拝見しておりました。」と挨拶いたしました。スプリントのタイムボックスの中で期間中うまく何かを成し遂げていたようですね。お疲れさまでした。そういえば去年のインターンの方とは違って「無限コーヒー」は特に触れられていなかったので重要では無かったようです。

なお Blog を書くまでがインターンシップです。


[ 8月31日全て ]

2016年10月20日 (木)

安いプリンタにするかどうか

PIXUS MG3630

Windows PC が壊れたので、さすがに自分の MacBook Pro から印刷できるようにしないとなぁと思ったら、家にある PIXUS MP980OS X Mavericks までしかドライバがありませんでした。あちゃー。2008年に買ったのでもう8年前。機能的には困ってないんですけどねぇ。

キヤノンだと MG3630 か、TS6030 / TS5030 か。MG3630 だと家電量販店でも6,000円台。TS5030 だと 21,000円台 で TS6030 だと 27,000円台。MG3630 はランニングコストは他に比べてランニングコストが高いんだけれど、印刷枚数を考えるとトータルではやはりお得。

店頭サンプルの限りでは6色・5色・4色インクのどれでも写真プリントの品質の印象は対して変わらなかったのでその点ではどれでも良し。

あとは、給紙の便利さをとるなら TS6030 で、SDメモリーカード対応(が使っている)をとるなら TS5030。悩ましい。

ここ最近出費がかさんでいるのことを考えるとここは PIXUS MG3630 が有力候補です。


[ 10月20日全て ]

2016年11月15日 (火)

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

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

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

4.2 タイムボックス化

「締めくくりの促進」のところで

プリント最終日を厳格なデッドラインにすると、チームは期日どおりに仕事やり遂げようと熱心に働くようになる。

とあるのですが、ここはまだまだできていない感じです。終わらなかったら次で的な空気がまだあるのでここはメリハリをつけていけるといいなと思っています。

4.4 普遍のスプリント期間

チームが今のスプリント期間で仕事を完了できないということは、スプリントの期間を長くする理由にならない。(中略) それはスクラムチームが機能不全になりかかっている兆候であり、改善する機会なのだ。

単純に駄目だったと思うだけでなく、改善につなげていくというのが大事ということですね。

またスプリント期間を固定することについて「一定したリズム」になることを利点にあげているのを読みなるほどなと思いました。リズムがあると考える負担が減り習慣化しやすくなる気がします。

5.5 ゴールを変えない

基本ゴールは変更しない方が良いのですが現実にはそうも言っていられない状況も発生します。本書ではそこについては「実利的であるべし」として状況によって柔軟にとしています。

プロダクトオーナーがスプリントゴールを変更する必要性について、経済的な観点でざっくばらんにチームと議論できているものであれば、たいていのチームはその必要性について納得してくれるので、やる気も高まっていたようだ。

やはりチームで取り組むことなので信頼関係が常に大切だと肝に銘じることにします。


[ 11月15日全て ]

2016年11月29日 (火)

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

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

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

プロダクトバックログは、優先順位の高いものほど詳細度を上げて分割していく一方で優先度の低いものはざっくりとで良いというのがポイント。現実的で良いなと思います。2回から3回分程度のストーリーを準備完了状態で抱えておくのが経験的に良いとのことでした。

一方プロダクトバックログはリストなのでこの分解ツリーが見える化されていません。このあたりがちょっと扱いにくいなと感じることはあります。アウトライナーのような形でツリーで整理しつつ、その中でプロダクトバックログアイテムとなるところのみビューとして抽出して順序付けるものがあるといいのになと思うことはあります。

グルーミング(プロダクトバックログリファインメント)については

プロダクトバックログのグルーミングは、プロダクトオーナー主導で行う共同作業だ。

と書かれていてこれは「おっと」と感じたました。関係者でのグルーミングはおざなりにしていたなと。ここは PO の責任範囲だとあらためて把握。なおグルーミングはいつ行ってもいいとありました。

開発チームは、各スプリントの作業時間の最大1割程度までをグルーミング用に確保すべきだ。

とあり結構たっぷりだよなと思うわけですが、考えてみるといわゆるウォーターフォール開発でも初期の工程に時間をかけているわけですし、特別多い割合でも無いのかなと。

複数チームでプロダクトバックログをどうするかについては、1つのプロダクトバックログからビューでチーム別のプロダクトバックログを用意するのが良いとありました。理想的には確かにそうだと思いますが、そこまでやるとすると結構ヘビー級のツールが必要になって気がしてそちらの学習・運用コストが馬鹿にならないのではという印象を受けました。

何事もできるだけシンプルにしていきたいですね。


[ 11月29日全て ]

2016年12月6日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会7回目。今日は第7章 見積もりとベロシティ。

プロダクトバックログ見積もり

プロダクトバックログアイテム(PBI)の見積もりプロダクトバックログリファインメント(グルーミング)で行うアクティビティです。この時プロダクトオーナーやスクラムマスターは「実際に見積もる作業」には関わらないのがポイント

見積もりの最大の目的は、話し合う過程でいろいろな気づきが得られるということだ。

でなるほどと思いました。見積もられたサイズよりも、見積もるという過程を重視しているんですね。

ストーリーポイント

PBI の見積もり単位としてストーリーポイントと理想日を紹介しています。ストリーポイントはあくまで相対値なのでそのチーム内でしか使えない値です。プランニングポーカーのところで

多くのチームでは、1回のスプリントでこなせる最大のサイズを13で表している。

としているので、これが一つの目安でしょうか。それからストーリーポイントはベロシティと対にならないとあまり意味をなさないですね。

理想日の方はいわゆる人日。

ベロシティ

ベロシティで計測するのはあくまでも生産量であり(デリバリーしたもののサイズ)であり、成果(デリバリーしたももの価値)ではない。

ここは当たり前な感じではありますが誤解してはいけないところ。

計測で出てくるベロシティは見積もりの(精度ではなく)正確性によってかなり揺らぎがあると思うのですが、このあたりはチームが学んでいくことで安定していくものなのでしょうか。ベロシティに幅を持たせて表すと良いとありますが、どれぐらいの幅に収まっていくのか興味があります。

それからベロシティが上がるかという話がありました。ストーリーポイントとしては相対値なので上がらないはずですよね。アウトプットの絶対量は増えていくと思いますけれど。


[ 12月6日全て ]

2016年12月13日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。

スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。

技術的負債

技術的負債。当初は

意図的に手抜きをしてすばやく仕上げるという意味

技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。

からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。

技術的負債ですが

大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。

ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。

ただ

技術的負債の経済的意味についての適切な認識

については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。

技術者レベルでの技術的負債の可視化

  • 方法1: 障害管理システムに記録する
  • 方法2: 技術的負債を表すプロダクトバックログアイテムを作る
  • 方法3: 技術的負債バックログを作る

サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。

技術的負債の返済

  • 作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。
  • プリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。

あたりがポイント

「技術的負債返済スプリント」だとか「リファクタリングプリント」などといった言葉がチーム内で出てきたら、危険信号だ。

ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。

また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。


[ 12月13日全て ]

2016年12月14日 (水)

YWTM はやっていないことを書きにくい

1つのチームのスプリントふりかえりに YWTM をやってみているのですが、この手法だとフォーマット的に「やっていないこと」をやはり書きにくいですね。

やったことをふりかえるのにはいいのですが、チームで改善サイクルをまわすには KPT(KPTA) の方がやりやすいかなと感じています。


[ 12月14日全て ]

2016年12月16日 (金)

今日のさえずり: 1週間スプリントのチームは小まめにプロセス改善のトライができるな

2016年12月16日

  • 08:34 きのうはどうも!
  • 10:54 コインゲットしている音がどこかから聞こえてくる。
  • 12:00 1週間スプリントのチームは小まめにプロセス改善のトライができるな。
  • 20:15 iPhone 5c リセット完了。
  • 21:00 9月中旬に眼鏡を変えたの、今まで会社で誰からも声をかけてもらえなかったのでついに自分からアピールすることになった師走の金曜日です。

[ 12月16日全て ]

2016年12月20日 (火)

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

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

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会9回目。今日は第9章 プロダクトオーナー。

自分がプロダクトオーナーをしていることもあり発表担当をしました。

受け入れ条件の定義と検証

受け入れ条件が満たされていることを確認することがプロダクトオーナーの主な責任の1つにあげられています。これはスプリントレビューで行うのかなと勘違いしていたのですが、プロダクトオーナーによる受け入れ条件の検証はスプリントレビューまで待たずにスプリント実施のときに行うとあり、ここは学びになりました。スプリントレビューでデモが許されているのは完成した機能だけとのことです。

ただ CSM によるとプロダクトオーナーが忙しくスプリントレビューのタイミングになっているところも多いらしいです。

誰がプロダクトオーナーになるべきか

ネットサービス開発は商用開発にあたるので「顧客の声を代弁する社員(プロダクトマネージャーなど)がなる」に相当しますね。

その他の役割と組み合わせ

プロダクトオーナーとスクラムマスターを兼任するのはよくないという点については、それぞれ違う行動指針で動くものだからと CSM がいっていました。確かに。

プロダクトオーナーとして余裕があれば複数チームを担当するのもありと本書には書かれています。私はいま3チームをみているのですが、スクラムのアクティビティにかかる時間的に3チームが限界ですね。2チームまでが適切な感触です。

プロダクトオーナーチーム

チーフプロダクトオーナーという役割が出てきますが、チーフプロダクトオーナーは直接開発チームを見ないようなのでそれってもはやプロダクトオーナーじゃないんじゃないかと思ったのですがどうなんでしょうか。

プロダクトオーナー? プロダクトマネージャー?

勉強会ではプロダクトオーナーとプロダクトマネージャーの違いについてディスカッション。個人的にはスクラムだとスクラムマスターという存在がいるので、プロダクトオーナーの方が少し楽なんじゃないかと思っています(スクラムではない体制におけるプロダクトマネージャーに比べて)。

勉強会参加者にプロダクトオーナーになりたい人はと聞いたところ、やりたい人・やりたくない人双方いました。 CSM は(決して軽視しているわけではないけれども)「プロダクト」よりも「プロセス」の方が面白いからプロダクトオーナーになりたいとは思わないとのことでした。なるほど。


[ 12月20日全て ]

Related term

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS の企画開発を行うグループのマネージャーをしています。CS 向上・コミュニティマネジメント・ユーザーサポート・健全化などにも取り組んでいます。

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

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

月別インデックス

Process Time: 0.070244s / load averages: 0.38, 0.39, 0.34
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker