問題解決に集中しない。プロジェクトに関係ある話のみにする。ホワイトボードに書き出すことにした。3人のチームなので今日は、10分で終了。いつもは問題解決をつい始めてしまい長引きがちであったが、こうして明確にルールを共有しておくと、互いに制止しやすくてなかなか良い。このスタイルでやってみて、また改良していくことにしよう。日本語訳は以前はhttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?ItsNotJustStandingUpにありましたが2017年2月2日現在以下にあります。スクラム」を読みたい人が集まる勉強会3回目。原則を語るにしては計画駆動との対比が多く、ちょっと読後感がすっきりしませんでした。「アジャイルの原則」の章なのにスクラムの話しか出てこないのもちょっと残念でした。スクラムにおけるアジャイルの原則という章だったら気にならなかったんですけどね。イテレーティブとインクリメンタルの話のところではスクラムでは、イテレーティブな開発とインクリメンタルな開発の両方の利点を活用する。することで、両者を個別に用いる際の欠点を無視できるようになる。書いてあるのですが、これは参加者でも引っかかっている人がいましたし、私もちょっと釈然としませんでした。両方の利点を活用するという点は良いのですが、欠点を無視できるようになるというのは説明しきれていないなと。予見と適応」ではコミットメントを先延ばしにし、重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。とし「判断することのコスト」曲線と「判断しないことのコスト曲線」が交わる最終責任時点がその瞬間であるとしています。主張は理解できますが、結局この曲線が明確になることは無いですし結局勘に頼らざるを得ないと感じました。アジャイルの原則自体はしっかりしたものだと思っているのですが、この章ではそれがうまう伝わってこない気がしました。作業者の手持ちではなく、作業の手持ちに注目せよは、あらためて思い返すことが出来て読んで良かった点です。この話はトム・デマルコの「ゆとりの法則」でも言われていることで再認識することができました。「稼働率」と「フロータイム」「リードタイム」「WIP」のあたりは製造業だとメジャーな話ですがソフトウェア開発においては、それほどは話題にならない気がします。勉強会でも、腑に落ちない人が多かったようです。空いた時間はもったいないので他の仕事を着手した方が無駄がないんじゃないかとつい考えてしまいますよね。完全版タスク管理の記事を読んでいると「マニャーナの法則」というキーワードがよく出てきます。Management)」を読んでみました。クローズドリストを使うという2つの原則のこととあります。「(行動)原則」の方が適切に感じました。「すぐやる」ことの弊害すぐやると「忙しいだけの仕事」ばかりが進み「本当の仕事」が進まないと指摘しています。新しくきた仕事にすぐとりかかってしまうのではなく、既存の仕事より価値があるかをまず考える必要があると説いています。「すぐやる」は自分の行動原則の一つなのでショッキングな指摘です。言われてみれば主体的な仕事よりも反応的な仕事に時間を使いがちです。「すぐやる」については「後回しにしてチャンスを逃す」ことのないようにする。先送りすることで増大するコストを最小化する。いうメリットがあるのも事実。このあたりは本書で言うところの「緊急レベルの判断」とバランスを取っていく感じなのでしょう。全員がマニャーナの法則をやるとどうなるか?個人個人がマニャーナの法則に従ってバッファリングすると組織全体のリードタイムが伸びるのではという懸念を持ちました。work)が多く発生することになるからです。このあたり要注意に思われます。緊急レベルを判断する入ってきた仕事はまず緊急レベルを判断するというのが本書の考え方です。緊急レベル3「明日やる」(ベスト)本書では「明日やる」がベスト。優先度設定に取り入れてみています。その日にやるとコミットしたタスクを入れておくクローズドリスト(本書ではクローズ・リストと表記)。タスクの優先度を1にすることでリスト化しています。処理する順番はファースト・タスクが最初で「明日のリスト作成」が最後です。それ以外はまったく自由。リストは作成することが必須とあります。リストを夜に作るのがまだ習慣にしきれていません。ちなみに本書ではタスクにかかる時間の見積もりについてはほとんど触れられていません。リストを完了できそうもない場合もいつもどおりリストを作成し翌日は「できるとこまでやる」「完了できない日が続くなら対策をとる」という感じになっています。リストで完了できなかったものは、「やり残し」フォルダに放り込み、ファースト・タスクで処理しましょうとあります。タグを付けるようにして実践中です。ファースト・タスクファースト・タスクは「毎日の最初に行い、そこから1日をスタートさせるのが望ましい仕事」とのこと。毎朝最初にできる仕事は1つしかないので、常に1つ。day)ファースト・タスクに向いている仕事は「やり残し」を片付ける仕事のシステムを修正するプロジェクトを進めるです。今は「やり残し」を片付けるのに使っています。先送りし続けることが減りました。実際のところ実際に一番最初にはやれてなくてまず「セットアップタスク」なるものをやってたりします。これらを前日に済ませるようにできれば本当のファースト・タスクにできるのかも。ダッシュ法ダッシュ法はポモドーロテクニックにつながるところを感じました。マニアックでテクニカルなやり方だというのと、マルチタスク型な印象なのとで今回はスルー。すべての仕事を半分にするプロジェクトをタスクに分解する方法。プロジェクトに対して具体的な行動を設定するのと同様、本書でも具体的な行動に落とし込むよう指導しています。その具体的なやり方として二等分法というのが紹介されていました。プロジェクトを二等分し、先にやる方をまた二等分にするというのを繰り返して「抵抗感が問題にならない状態」になるまで分割を続けるという方法です。全てをブレークダウンすることはせず直近取り組む部分だけ具体的にするというやり方がスクラムにおけるプロダクトバックログリファインメントの考え方に似ていて気に入りました。行動の合間に考える習慣をつける最後の方の「考える」ということについての話で「行動の合間に考える習慣をつける」エクササイズが紹介されていました。「毎日15分」など時間を決め確保する。邪魔が入らない場所でノートと筆記用具を用意し、浮かんできたアイデアや考え方をノートに書き留める。時間の終わりに近づいたら書いたものについて考える。良いアイデアや行動が必要なことに下線を引く。時間(期限)を決めその時間の最後まで考え抜くというのがポイントだそう。取り組んでみたいなと思います。冒頭にキーワードが説明されているのが良かった最後に本書の構成について。「ラベリング」が列挙されてそれぞれに簡単な説明がついています。簡潔でわかりやすく、本を読み進める助けになります。本では「はじめに」で第1章では◯◯、第2章では△△とずらずらと書かれていたりしますが、前提知識が無いとわかりにくい書き方のものが多いです。それに対して、本書ではキーワードという見出しでサマリと流れをうまく説明していて素晴らしいなと感じました(ちなみに本書も「はじめに」では構成が手短に説明されています)。メンバの1時評価の検討と入力を完了。半期末に各メンバが自己評価をしたあと振り返り面談をし評価を入力するという制度、どうもイケてない気がしてきています。事業の部長をしています。日記(兼パーソナルナレッジベース)です。※内容は個人的見解であり所属組織とは関係ありません。