優先順位-プライオリティ- と捨てる勇気。

ドラッカーのマネジメント（課題・責任・実践）（上）を読んだ。

これは今、お借りしているのだが、自分で購入することにした。

エッセンシャル版は持っているがボリュームが全然違うし、悩んだときの羅針盤になりそうな本だと思った。

ドラッカー名著集13 マネジメント[上]―課題、責任、実践

いくつか今の自分に大切なことを再確認できた。

優先順位

 

何もかもできる組織はない。金があっても人がいない。優先順位が必要である。あらゆることを少しづつ手がけることは最悪である。

いかなる成果も挙げられない。間違った優先順位でも、ないよりはましである。

ただし、優先順位を付けることにはリスクが伴う。高い優先順位を付けられなかったものは、事実上廃棄されることになる。

優先順位を付けるための公式はない。しかし、優先順位は付けなければならない。そのための装置が予算である。

ここから読み取れることは、優先順位が低いものはすべて捨てる勇気が必要だということ。捨てられないのであれば優先順位を付けている意味がない。

時間は限られている。だから優先順位が高いものから着手しなければならないのは当然だ。だが本当に大切なのは、優先順位が高以外のものを捨てる勇気である。優先順位が付けられていたとしても、様々なやるべきこと、テーマが視界に入ったら気になってしまう。一切気にならないようにすることが、焦点を当てるということなのだ。これはマネジメントの中でも非常に大切なことだ。メンバが、様々なものに手を出しすぎて、結局何もなし得ないことになる。

優先順位が高いもの以外は、捨てよう。

Joy, Inc 役職も部署もない全員主役のマネジメント

Joy, Incすごいいい本でした。

ジョイ・インク 役職も部署もない全員主役のマネジメント

アジャイル開発を実践している企業の方は必読です。

特にマネジメント層に読んでもらいたいな。

長時間労働・ブラック企業とか、ニュース的には暗い話題が多かった2016年でしたけど、最後にこの本が日本語で出版されて感謝しています。

2016年最高の一冊になりました。

日本企業も、こんな感じの会社・職場で満ち溢れればいいのに（笑

無理かなぁ。

なら、私がこんな会社創りたいなぁと思っちゃいました。西多摩に。

あー、海の近くにしようかな。千葉の一宮とかがいいかな。使われていない工場跡買い取って。プログラミング＆サーフィンでEnjoy Life!

そしたらこの本はバイブルになりますね。

さて2017年。私にとって、なんかの占いでは最高の年になるみたい。本当かな。

2016年印象に残った本は 1位：Joy, Inc

2位：トヨタの自工程完結

現場からオフィスまで、全社で展開する トヨタの自工程完結―――リーダーになる人の仕事の進め方

3位：HARD THINGS

HARD THINGS

4位：チームが機能するとはどういうことか

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

5位：リクルート事件・江副浩正の真実

リクルート事件・江副浩正の真実 (中公新書ラクレ)

2016年、全部で約120冊でした。Amazonで買ったものだけリスト。今年は読書量少ないと思ってたのに、結構多かったです。

1 ．ＮＥＴのエンタープライズアプリケーションアーキテクチャ　第２版 (マイクロソフト公式解説書)
2 「人を動かす人」になるために知っておくべきこと
3 ゼロ秒思考 頭がよくなる世界一シンプルなトレーニング
4 ベストを引き出せ―部下の業績を最大化するリーダーシップ
5 なぜか、「仕事がうまくいく人」の習慣 (PHP文庫)
6 ジョイ・インク 役職も部署もない全員主役のマネジメント
7 なぜ、戦略を実行するのはむずかしい？ 組織のなやみ研究所
8 「わかりやすい」文章を書く全技術100
9 Fifty Quick Ideas To Improve Your User Stories (English Edition)
10 コーチング一日一話 今日から始める「気づき」の365項目
11 モチベーション3.0 持続する「やる気!」をいかに引き出すか (講談社+α文庫)
12 プライマリー・グレートネス 幸福で充実した人生のための12の原則
13 成功する人は、2時間しか働かない: 結果を出すための脳と身体のピークのつくり方
14 ダイアローグ 対立から共生へ、議論から対話へ
15 私はどうして販売外交に成功したか (Life & business series)
16 “トークの帝王"ラリー・キングの伝え方の極意
17 徹底のリーダーシップ
18 テンプレート仕事術 ―日常業務の75%を自動化する
19 アナタはなぜチェックリストを使わないのか？【ミスを最大限に減らしベストの決断力を持つ！】
20 図解でわかる! 戦略実行読本
21 リーダーシップ・エッセンシャル
22 実行の4つの規律 行動を変容し継続性を徹底する
23 二年生いきいき学級経営―クラスの一体感が高まり、笑顔あふれる (教育技術MOOK)
24 有名企業からの脱出 あなたの仕事人生が〝手遅れ〟になる前に
25 弱者の戦略―人生を逆転する「夢・戦略・感謝」の成功法則
26 35歳から「一生、負けない」生き方 ランチェスター秘密の人生法則
27 しつもん仕事術
28 するどい「質問力」! 図解問題を1秒で解決する
29 人を動かす人の「質問力」: この「問題意識」が結果を出し、組織を強くする (単行本)
30 さとりをひらくと人生はシンプルで楽になる
31 スタンフォードの自分を変える教室 (だいわ文庫)
32 頑張るのをやめると、豊かさはやってくる
33 Q思考――シンプルな問いで本質をつかむ思考法
34 稼ぐまちが地方を変える―誰も言わなかった１０の鉄則 (ＮＨＫ出版新書　460)
35 超・箇条書き―――「10倍速く、魅力的に」伝える技術
36 コーチング・ワークショップ
37 ペアプログラミング―エンジニアとしての指南書
38 日本企業の社員は、なぜこんなにもモチベーションが低いのか?
39 現場からオフィスまで、全社で展開する トヨタの自工程完結―――リーダーになる人の仕事の進め方
40 実践テスト駆動開発 (Object Oriented SELECTION)
41 チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ
42 カイゼン 復刻改訂版
43 現場カイゼン―知恵と常識を使う低コストの現場づくり
44 なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
45 受注を勝ち取るための 外資系「提案」の技術---日本人の知らない世界標準メソッド
46 外資系コンサルのスライド作成術―図解表現23のテクニック
47 経営を見る眼 日々の仕事の意味を知るための経営入門
48 ゴーマニズム宣言SPECIAL　民主主義という病い (幻冬舎単行本)
49 リーン・シンキング
50 Coders at Work プログラミングの技をめぐる探求
51 トヨタ式「改善」の進め方―最強の現場をつくり上げる! (PHPビジネス新書)
52 トヨタの口ぐせ (中経の文庫)
53 トヨタ式A3プロセスで仕事改革―A3用紙1枚で人を育て、組織を動かす
54 ずるいえいご
55 たった一つを変えるだけ: クラスも教師も自立する「質問づくり」
56 GAMIFY ゲーミファイ―エンゲージメントを高めるゲーミフィケーションの新しい未来
57 内向型人間の時代 社会を変える静かな人の力
58 [CDブック] 相手にどんどん質問する英会話 (CD BOOK)
59 トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!
60 Harvard Business Review (ハーバード・ビジネス・レビュー) 2012年 05月号 [雑誌]
61 エッセンシャル思考 最少の時間で成果を最大にする
62 ゼロ・トゥ・ワン―君はゼロから何を生み出せるか
63 サーバントリーダーシップ
64 ハッカーと画家 コンピュータ時代の創造者たち
65 リーン開発の現場 カンバンによる大規模プロジェクトの運営
66 Making Software ―エビデンスが変えるソフトウェア開発
67 エクストリームプログラミング
68 XPエクストリーム・プログラミング実践記―開発現場からのレポート (The XP Series)
69 XPエクストリーム・プログラミング適用編―ビジネスで勝つためのXP (The XP Series)
70 ぼくのマンガ人生 (岩波新書)
71 手塚先生、締め切り過ぎてます! (集英社新書 490H)
72 企業変革力
73 響き合うリーダーシップ
74 ビヨンド ソフトウェア アーキテクチャ (Object Oriented Selection Classics)
75 Harvard Business Review (ハーバード・ビジネス・レビュー) 2006年 06月号 [雑誌]
76 リクルート事件・江副浩正の真実 (中公新書ラクレ)
77 朝ごはんの献立-12のシーンとおいしいごはん
78 藤原先生、これからの働き方について教えてください。 100万人に1人の存在になる21世紀の働き方 (DISCOVER21世紀の学校)
79 人生の教科書 よのなかのルール (ちくま文庫)
80 カンバン仕事術 ―チームではじめる見える化と改善
81 アジャイルソフトウェアエンジニアリング (マイクロソフト関連書)
82 スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
83 いまだ人間を幸福にしない日本というシステム (角川ソフィア文庫)
84 処生術―生きるチカラが深まる本
85 ([ふ]1-1)坂の上の坂: 30代から始めておきたい55のこと (ポプラ文庫 日本文学)
86 GEの口ぐせ (PHPビジネス新書)
87 「どこでも通用する人」に変わるリクルートの口ぐせ
88 リクルートという奇跡 (文春文庫)
89 リクルートのDNA―起業家精神とは何か (角川oneテーマ21)
90 実力派たちの成長戦略 (PHPビジネス新書)
91 35歳からの「脱・頑張（がんば）り」仕事術 (PHPビジネス新書)
92 アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ)
93 ホウレンソウ禁止で1日7時間15分しか働かないから仕事が面白くなる
94 外資系コンサルが実践している 英語ファシリテーションの技術
95 強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」
96 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
97 HARD THINGS
98 サーバントであれ――奉仕して導く、リーダーの生き方
99 CD付 英語のプレゼン 直前5日間の技術 (しごとのミニマム英語)
100 武器としての書く技術 (中経出版)
101 英文翻訳術 (ちくま学芸文庫)
102 スティーブ・ジョブズ 驚異の伝説 (PHP文庫)
103 日本語入力を支える技術　～変わり続けるコンピュータと言葉の世界 (WEB+DB PRESS plus)
104 ユーザーストーリーマッピング
105 ビジネスモデルを見える化する ピクト図解
106 自分のこと100言う英会話―シンプル自己紹介フレーズで英語が話せる!
107 描きながら考える力 ~The Doodle Revolution~
108 マインドセット: 「やればできる!」の研究
109 ビジネスは30秒で話せ！
110 民俗学の旅 (講談社学術文庫)
111 最速の仕事術はプログラマーが知っている
112 未来を創るスゴいベンチャー101
113 21世紀へ
114 アメーバ経営 （日経ビジネス人文庫）
115 稲盛和夫の実学―経営と会計
116 転職面接必勝法
117 生き方―人間として一番大切なこと
118 もう終わっている会社 (ディスカヴァー・レボリューションズ)

JPEGをDICOM形式に変換して出力する方法(C#)

前のエントリの逆バージョン。

kshimizu.hatenadiary.jp

当然、fo-dicomを使います。

github.com

Gistに最高な例がありました。

とりあえず下記でいけます。

gist.github.com

ただ、出力ファイルパスとファイル名が固定なので、 少しインターフェースを変えてあげて、以下のように呼び出せばOK。

 private void button1_Click(object sender, RoutedEventArgs e)
 {
      BitmapToDicom.ImportImage(@"入力パス", @"出力パス");
 }

DICOM形式の画像をJPEGに変換して出力する方法(C#)

fo-dicom.coreというライブラリがMS-PLで公開されています。

githubで公開されています。

github.com

Nugetで取得してください。

fo-dicomはたくさんのDLLを公開していますが、

fo-dicom.coreのみでOKです。

fo-dicom.coreにDicomImageというクラスがあるので、以下のように書けばOK。

private void button_Click(object sender, RoutedEventArgs e)
{
      var dicomImage = new DicomImage(@"ファイルのパス");
      using (var bitmap = dicomImage.RenderImage().As<Bitmap>())
      { 
          bitmap.Save(@"出力パス", System.Drawing.Imaging.ImageFormat.Jpeg);
      }
}

DICOMのサンプル画像は以下のサイトを参考にさせて頂きました。

d.hatena.ne.jp

JPEGの圧縮率を指定したい場合は、以下のサイトを参考にして上記コードを拡張してください。

品質を指定してJPEG画像を保存する: .NET Tips: C#, VB.NET

超・箇条書き

超・箇条書き―――「10倍速く、魅力的に」伝える技術

たしかにこのスキルがあると生産性が全然変わる気がします。 まとめてみました。

超箇条書き

背景

• 日本では箇条書きは好まれてこなかった。
• 日本では率直に意見を言うと成果につながらない傾向が強い。
• なぜなら、日本では意見と人格が同一視されがちだからだ。（他国では違う）
• しかし時代が情報過多の時代に移り、多くの情報から要点をまとめるスキルが必須である。
• そこで箇条書きに３つのポイントを加えた超箇条書きがこれからの時代必要になる。

超箇条書き

• 箇条書きに、「構造化」、「物語化」、「メッセージ化」を加えたもの
• 構造化：相手が全体像を一瞬で理解できるように幹と枝を整理すること
• 物語化：相手が関心をもって最後まで読み切れるようにすること
• メッセージ化：相手の心の響かせる行動を起こさせるようにすること

構造化

• 構造化の要件は「レベル感を整える(=伝えたいことの階層を揃える)」こと

似ているものを一つにまとめる

• 適切なグルーピングによって、全体像の把握が楽になる
• 「状態・現象」を伝える文と、「行為」を伝える文とを分ける

構造化のコツ１：自動詞と他動詞を使い分ける

• ある瞬間の静止画、すなわち「そのときの状態」を伝えたければ、ひとつひとつの文に「自動詞」を使う

• ある瞬間の動画、すなわち「誰かが何かに影響を与える行為」を伝えたければ、ひとつひとつの文に「他動詞」を使う 自動詞と他動詞の例： 自動詞: コップが落ちる、ボールペンがある、私は驚いた、彼は止まる 他動詞：　私がコップを落とす、あなたがボールペンを置いた、彼が私を驚かせた、非常ベルの音が彼を止める

• 体言止め（=動詞で終わる文章）は曖昧になるから超箇条書きでは使わない 例：コストの低下、売上の場像

構造化のコツ２：「直列と並列」で時間軸を整える

• 読み手としては時間軸が整理されるとストレスなく読める
• 現在->未来

構造化のコツ３：「ガバニング」で引き出しを作る

• ガバニングとは頭出しのまとめのこと 例：伝えたいポイントが３つあるときに、先に「ポイントは３つ」などと宣言すること
• メールにはガバニングが欠かせない。なぜならメールは読み飛ばされるメディアだからだ。
• 文だけでなく、構造でも語らせることができる。

物語化：相手が関心をもって最後まで読み切れるようにすること

• 生々しくない箇条書きは、いくら構造化されていても、相手に響かない
• そのために「フックをつくること」が求められる

物語化のコツ１：「イントロ」でつかみ、相手を引き込む

• アンサーファースト（ただし万能ではない。相手が背景をわかっていない場合は効かない）
• 相手の「期待」に合わせて、柔軟に考える

物語化のコツ２：「MECE崩し」で山場をつくる

• MECEでもれなくだぶりなく書くと、機械的になる。優先順位の高いもの、本当に必要なものに絞ろう
• 相対的MECEを使いこなす。 相手の関心や置かれている状況など、相手のコンテキスト次第ではじめてMECEと定義できるもの。 箇条書きで伝える際は、相対的なMECEで考えるべき。

物語化のコツ３：「固有名詞」で具体的にイメージさせる

• まず一般名詞を探す。
• 一般名詞を固有名詞に置き換えられるか検討する。
• 固有名詞を使うことで生々しくなる。

例：私は海外在住の経験があります。 →私はシンガポール在住の経験があります。

メッセージ化

• メッセージ化の要件は「スタンスをとる」こと。
• 自分のスタンスを明確にする。

メッセージ化のコツ１：「隠れ重言」を排除する

• 意味の重複は冗長なのでやめるべき。 例：顔を洗顔する、頭痛が痛い、など。

プレゼンにおけるNGワード集

• ～を改善する
• ～を見直す
• ～を推進する
• ～を最適化する
• ～のバランスをとる
• ～を徹底する
• ～を強化する
• ～を実行する

メッセージ化のコツ２：「否定」で退路を断つ

• 「何をしないか」を明示して、強調する

メッセージ化のコツ３：形容詞や副詞は「数字」に変える

• 生々しさには数字が大切。

アジャイルかウォーターフォールか、どちらが品質を「保証」できるのか -トヨタの自工程完結に学ぶソフトウェア開発-

トヨタの自工程完結とソフトウェア開発

言うまでもなく日本最強の企業トヨタ。トヨタ生産方式は、「リーン」として、その名を世界に知られています。 では、トヨタの中のソフトウェア開発はどうなっているのか？その答えがないまでも、トヨタのホワイトカラーはどうやって品質を高めながら生産性を高めているのか？ その手がかりになるような本です。（この本では、ソフトウェア開発には触れていませんが、トヨタの「スタッフ部門」（著書曰くホワイトカラー）にもフォーカスしながら2007年からトヨタ全社的に始まった 「自工程完結」を紹介しています。

ここでは、この「自工程完結」の考え方がソフトウェア開発にも応用できないか考察してみることにします。

現場からオフィスまで、全社で展開する トヨタの自工程完結―――リーダーになる人の仕事の進め方

トヨタにも「銀の弾丸」は無かった

組織の壁

トヨタ程の企業であれば、組織の壁なんて無いのだろう、と考えていました。私は様々な本を読んできましたが、GEやAppleには組織の壁なんて無いと思っていましたので（コンカレント・エンジニアリング） 、ましてトヨタにはそんなものがあるとは思いませんでした。 しかし、「自工程完結」を始める前のトヨタでは、組織の壁があった。 自工程完結を日本で試すために、全部門にまたがる問題であった車の水漏れ対策を「自工程完結」で進めた際に、以下のように書かれています。

日本に戻ってきて「活き活きしてないなぁ」と思っていた工場の雰囲気は、格段に変わりました。しかも、部門間の壁もなくなった。「そっちのせいでこっちが迷惑をこうむっているんだ」という空気がなくなりました。

水漏れ対策という、すべての部門にかかわる取り組みを進めたことで、「何がいちばん大事なことなのか」ということが共有できたからです。それは各部門がエゴを貫き通すことではありませんでした。みんなで良い車を作るということです。風通しも本当に良くなりました。

トヨタの自工程完結 p68より引用

非生産的な仕事

著書は、ヨーロッパで仕事をしてきたあと、日本に戻ってきて愕然とされます。 ヨーロッパのスタッフ部門とは仕事のやり方がまるで違う。日本では、何かを求めても、根回しから始まるというのです。 現場で権限委譲が進んでおらず、自らが決められない。上司に「お伺い」を立てる。 根回し、手直し、やり直し。調整会議、対策会議に明け暮れる毎日。これでは何も生み出せません。生み出すスピードが遅くなる。

大丈夫か、日本の産業界

トヨタにもある、ということは日本の多くの企業でもあるということではないでしょうか。 昨今の日本の現状を鑑みるとそう思わざるを得ません。 社内でごちゃごちゃやってる場合じゃないんじゃないですか。少子高齢化とか英語の壁とか、今までの文化とか、そんなんじゃないんじゃないですか。

アジャイルかウォーターフォールか、どちらが品質を「保証」できるのか。

自工程完結とは何なのか

水漏れ対策を例にとってみると、水漏れに対する検査は、車が組み上がった後に検査部門がやっていたとのことでした。 厄介なのは、それぞれのプロセス毎にチェックするのではなく、最後の検査で一度にチェックするので、どこに問題があったか把握するのに大変な労力がかかる。 車の組み立てだけでなく、塗装その他の工程も含めて、チェックしないといけない。すべての部門は「もしかしたら自分たちの責任ではないのではないか？」と疑心暗鬼になり、嫌な思いをする。ここでもまた組織の壁が生まれます。 ここで、銀の弾丸ではなく、それぞれの部門がしっかりと水漏れ対策をする、という地道なことを実行する。これがまさに「自分の工程」で「仕事を完結させる」＝「自工程完結」。 最後の検査をしなくてもいいぐらいまでのレベルで、水漏れを防ぎます。

言葉だけでは終わらない取り組み。 「自工程完結」は心がけではなく、すべての工程を洗い出して、見直して精査し、きちんと「何をすればいいのか」という行動まで落とし込まなければいけない。 だから、これをやれば確実に結果が出せると信じることができる、拠り所となる。

工場のみんなが愚直に、2000以上の水漏れに関係する作業を見直し、一つの同じ方向に向かって取り組みを進め、 生産性が上がり、結果が出る。後に回さないため、仕事がラクになる。モチベーションが上がるのが「自工程完結」。

そして一度、この体験をすると、工場内は自発的に動き出すようになったとのこと。 これはチームが自律するのと同じ効果かと思いました。

自工程完結の１０のメリット

1. 部分最適がなくなる
2. 上司が進捗確認できるタイミングを作れる
3. 上下左右のコミュニケーションが深まる
4. 各部署の固有の強みを最大限に活かせる
5. 部門内の情報共有が進む
6. 会議が減る
7. 理不尽なところが増える
8. 失敗が減り、妥協がなくなる
9. 生産性が上がる
10. モチベーションが上がる

アジャイル手法を導入する際の効果と似ています。

品質保証には２つの方法がある

検査の理念は、検査しないことにあり

豊田英二 トヨタ自動車株式会社会長

品質保証には大きく２つあります。品質を検査に頼るやり方と、品質を工程で作りこむやり方です。 前者は、第３者が良し悪しを判断し、悪ければやり直しを命じる。それに対して後者は、一つひとつの工程で良し悪しを判断しながら、最終的な品質を高めていく。 この後者こそが、文字どおり「自工程完結」の考え方です。

ただ、この考え方から最終検査をやめるかというと、そうでもなく、 「最終検査にて不具合が０件であること」、そうしてはじめてお客様に品質を「保証」できるということです。

工程の不安定さを最終検査でカバーしてはいけないのです。

ソフトウェア開発における「工程」とは？

トヨタでは、「検査に頼らないモノづくりをする」、「検査の理念は、検査しないことにあり」、「品質は工程で造りこもう」というキャッチコピーがありました。それらが「自工程完結」へ繋がります。 では、ソフトウェア開発における「工程」とは何でしょうか？ よく言われるのがウォーターフォール、V字モデルです。

一般的には、要件定義、基本（外部）設計、詳細（内部）設計、コーディング（実装）、単体試験、結合試験、システム試験というあたかも「工程」のような感じを受けます。 ですが、私はこの本を読み進めているうちに、これは工程ではないという考えに至りました。 要件定義をどれだけ綿密にやったとしても、ユーザの欲しいものはわからない。品質は、時間とともに劣化していく（ユーザニーズが変わるから）。 品質を決めるのは、ユーザである。ソフトウェアは、その名の通り「柔らかい」。変化可能である。 基本設計が抜群に出来たとしても、正しいソフトウェアかどうかは誰にもわからない。実装してみないと、ソフトウェアが正しく作られるかもわからない。ユーザや検査部門からのフィードバックがないと、その基本設計が正しかったかわからない。つまりこれは一つで完結した工程に成り得ないということです。 今まで言われてきた工程は、工程ではなく、フェーズのようなものです。

ソフトウェア開発における工程というのは、「ソフトウェアを考え始めてからユーザに使ってもらうまで」、だと思います。 スクラムで言うところの、スプリントが工程にあたります。 XPで言うところの、週次サイクル(Weekly Cycle)ないし、４半期サイクル(Quarterly Cycle)が、１つの工程です。

「自工程完結」をソフトウェア開発に応用するには

「自工程完結」は、まさに「アジャイル」。ただし、ソフトウェア開発における「工程」を勘違いするな

品質保証には２つの方法がある、で載せた図を見て驚きました。アジャイルの絵なのです。 細かいぐるぐるが何回も出てきます。そして「工程で品質を造りこむ」、工程は、スプリントです。決して基本設計や詳細設計ではない。 最終検査は必要ですが、不具合０件です。それが出来てはじめて「自工程完結」になっていると言えるでしょう。

ソフトウェア開発は「マニュアル化」できるのか

この本を読んでいて、違和感があったのが、ホワイトカラーの仕事の「マニュアル化」です。 プログラマーは誰しも、自分のやっていることをマニュアル化できるとは考えていません。 コーディングスタイルのガイドラインや、設計指針は必要だと思いますが、全てのステップが詳細に記録された「マニュアル」ではありません。 プログラミングは設計行為そのものであり、非常にクリエイティブです。おそらく、マニュアル化しても出来上がるものは異なるでしょう。 マニュアル化する時間があるなら、自動化しますよね。

個人ではなくチームで挑め

自工程完結も、当初は小さな取り組みから大きく発展していき、2007年にはトヨタの全社で実行されることになります。 この取組は個人では成し得ません。スクラムやXPもそうですが、必ずチームで挑む必要があります。

常に改善し続ける状態（=アジャイル)

アジャイルは、状態だと言われています。「常に改善し続ける状態」です。 自工程完結を読み、まさにアジャイルだと思いました。各工程が自律的に改善をし続ける状態になっています。 工場も活き活きとしたと著者は述べています。 そしてこの活動に終わりはない、ということで締めくくっています。 ソフトウェアにおいてもまさにその通りで、プロダクトの命が終わっても、チームが存続すればその意識は引き継がれます。 ソフトウェア開発は、終わりのない旅です。

Qiitaにも同じ記事を載せています

デイリースクラム（朝会）の開催時間

デイリースクラムの開催時間

本当に朝会がいいの？

全て、チームと目的に依存します。 デイリースクラムの目的を考えてください。デイリースクラムの目的は、チーム全員に状況を共有することです。 「チーム全員」というところがポイントです。全員が適切に無理なく集まれる時間帯であれば、いつでもいいです。 実施している組織が営業であれば、朝会のほうがいいかも知れません。その日やることを全員で共有するからです。 開発の場合は、その日やることにフォーカスするよりも、これまでやってきたことを共有する意味合いが強いので、朝に縛られる必要はないと考えます。

スクラムマスターは、チームメンバーが無理をしていないかを随時確認する

日本では根性論が多いです。決めた時間に必ずこないと、白い目で見られますが、なぜ来られないのか考えて見ることが大切です。 もし社内にいて、単純な不注意で集まれないのであればその人自身に問題があるかも知れません。しかし、何か外部要因が絡んでしまい来られないのであれば、 その時間帯を見直したほうが賢明です。日本では公共交通機関が主に電車やバスであることが多いでしょう。電車やバスは遅れやすいです。そのあたりを加味した上でのデイリースクラムの時間帯になっていれば良いと考えます。 また、子供を保育園に連れていく場合等もこれに当てはまります。保育園は保護者の出勤時間を把握して子供の登園時間帯を決めますので、雨が降ったから通常より早く連れていくなんてことはできないのです。一番怖いのは事故です。デイリースクラムに間に合わせるために、急いでしまう。急いだことによって二次災害を起こしてしまうこともあります。いつでもゆとりは大切なのです。 スクラムマスターは、スクラムが適切に運用しているかを把握する役割ですが、デイリースクラムに欠席者がポツポツと出る場合は、これらの環境も考慮した上で、時間帯の変更を提案しましょう。

ではいつがいいのか？

全て、チームと目的に依存します。ただ、日本ではお昼が良いのではないかと考えています。 交通機関の乱れも吸収できます。私の経験ではお昼ごはん前もしくはお昼ごはん後が良いと思います。 大切なのは、15分以内に終えるということです。タイムボックスです。「15分」が隙間的にある時間帯も利用価値があります。 例えば、12:00-12:45までお昼休みという就業規則の場合、12:45-13:00は皆意識せずにだらだらと休み時間の延長として過ごしてしまうのではないでしょうか。そのような隙間時間を利用すると良いと思います。

お昼ごはん前

• 前回のデイリースクラムから何をしたか
• 次回のデイリースクラムまで何をするか
• 困っていること

を全員が共有した後に、一緒にお昼ごはんを食べる、という流れになります。 困ったことをランチを取りながら検討してもいいかも知れません。効率的ではあります。ただ、お昼ぐらいは仕事のことを忘れたい、というメンバーが多い場合には煙たがられるかも知れません。

お昼ごはん後

• 前回のデイリースクラムから何をしたか
• 次回のデイリースクラムまで何をするか
• 困っていること

を全員が共有した後に、午後の仕事に取り掛かります。お昼ごはん後の眠い時間に、スタンドアップでミーティングをするために多少の眠気覚ましにはなると思います。

まとめ

結局はチームのために行うものですので、目的を明確にして、チーム内で議論をして決めれば良いと思います。 スプリント毎に時間帯を変えてみて、一番しっくりくる時間帯を決めるのもいいと思います。

Qiitaにも同じ記事を載せています