リーンを一言で言うと

テイラーの思想について調べていた。
「単純労働者には計画させるな、考えさせるな、そのほうが効率的だ」ということのようだ。

impro-club.com

フォードはテイラーの思想で大量生産方式で成功した訳だが、TOYOTAはどうなのかなって思って調べたら、Agile Japan 2009の記事に行き着いた。

http://www.agilejapan.org/session/Keynote_1.pdf

守破離に繋がりますね。

大野耐一の言葉があって、胸に刺さった。
やっぱり昔の人は偉いなー。すごいなと。わかってんじゃん。
テイラーじゃないね。

そうなるとリーンって一言で言うと何だろうって思ってググったら

www.atmarkit.co.jp

こんな感じだったので自分なりにまとめてみた。

リーンを一言で言うと、「Time to Market」。

顧客に価値のあるものを最速で届ける。

そのための改善活動として、バリューストリームマップ(VSM)を書いて無駄工程を洗い出すんですよね。

子育てエンジニアの時間管理術

夫婦共働きで片方がエンジニア、片方が看護師さんというシチュエーションです。
看護師さんは不定期で月４～６回ほど夜勤がありますので、私は家に帰る必要があります。

子供は３歳、７歳で保育園と小学校。
保育園は07:45-18:15まで。
小学生は学童と登下校含めて07:45-18:00まで。

エンジニアの業務時間は08:45-17:30まで。
自宅まで20分。そこから保育園は5分という環境的にはなかなか良い環境です。


仕事が終わらない、だから迎えにいけないという言い訳は全く通用しませんし、
ただでさえ子供たちにも負担をかけているので、子供たちからみて「家に帰ったけど誰もいなかった」なんてことはあってはなりません。少なくとも今はまだ。


自然と以下のようになります。

• 帰る
• 集中できる時間を作る
• 1日に使える時間は5時間として計算し、ゆとりを持つ
• 時間内に如何に成果を出すか考える
• 大きな問題は熟成させる期間を持つ

私はだいたい7年間くらいこの方式で、毎月残業がほぼ0です。温い環境だと言われればそれまでなのですが…。
蛇足ですが、毎月残業がほぼ0だと、自分の時給も計算しやすいです。

帰る

帰ることに挽き目を感じてはいけません。帰るのです。定時にならずしてもやるべき成果が出たら帰っていい。
エンジニアって本来そうゆうものです。時間で稼いでいる訳ではない。バイトとは違います。
心理的なことかも知れませんが。「必ず帰る」には、確固たる決意が必要です。
とにかく帰りましょう。

集中できる時間を作る

設計や実装はなかなか短時間では難しいので、集中できる時間を作ることが大切です。

• 意識的に集中する。（今　か　ら　俺　集　中　す　る　。）
• 開発時はメールを一切見ない。メーラーは立ち上げない。（ちなみに、メールは全部見ません。すげー溜まってたら捨てちゃいます。急ぎなら電話して系）
• ポモドーロ・テクニックを使い、集中時間のリズムを作る。
• 社内調整やメール整理等は、出社前の時間を15分ほど使い、１日のスケジュールとTODOだけは出社前に把握しておく。（割り込みはウェルカム）

1日に使える時間は5時間として計算する。

1日を8時間計算でタスクを積んでしまうと、割り込みをウェルカムできませんし、全部が時間通りに進むわけではないので破綻します。
1日は5時間程度使えると考えたほうが良いです。
人間は機械ではないので、ゆとりを持たないと良い集中ができません。

時間内に如何に成果を出すか考える

• これってそもそも何のためにやるんだっけを考える。やらなくていいことは捨てる。
• やるとなったらとにかくまず荒くてもいいから終わらせることを目標にする。体裁とかどうでもいい。
• 目標時間のうち、５分の１ぐらいの時間を目安でまず終わらせる。１時間なら10分ぐらい。あとはフィードバックループを3-4回使う。
• すぐにフィードバックをもらう。（自分で溜めない）
• もんもんとしない。もんもんとしたらすぐ誰かに相談する。（言葉にすることで整理できることもあるし、相談することで良いアイディアを貰えることもある）
• Plain Text(プレインテキスト）が一番汎用性があるので、プレインテキストで終わらないか考える。
• ExcelやWordやPowerPointなどのOffice系のツールは、使い所を誤らない。なんでもかんでもExcelは絶対NG。保守性が悪い。

大きな問題は熟成させる期間を持つ

5時間で大きなシステムのアーキテクチャ設計は難しいです。色々と考えることがあります。
大きな問題ほど、予めやばそうな雰囲気は前もってわかると思います。この辺は経験値かも知れませんが。
そのような場合は、問題を把握して、少し考えつつ、寝かせて期間を取ります。
良いひらめきや思考が、そのための時間を取っている訳ではないのですが、だんだんとカタチを帯びてきて、頭の中でまとまってきます。
最後には、例えばドキュメントにまとめたり、図を書いたり、表にまとめたりできます。
これは思考の整理学で学んだことです。
大きな問題は熟成させる。集中してその期間を取らない。
例えばアーキテクチャ設計に１週間かかります！とかだと、良い設計はできない。
そのためのタスク時間は不要。
１週間のリードタイムは必要だけど、タスクとして作らない。頭の隅で考える。

参考文献

思考の整理学

思考の整理学 (ちくま文庫)

ポモドーロテクニック

アジャイルな時間管理術 ポモドーロテクニック入門

エンジニアのための時間管理術

エンジニアのための時間管理術

禁酒

リーダーシップの本とか、スクラムマスターとか、アジャイルコーチとか読んでいると、


チームに自律して頂くには、自分自身も律する必要があるという想いに至りました。


「酒、タバコ、ギャンブル」いずれも自分を律する必要がある。
そこかよ
と突っ込まれそうですが、まずは身体（とお金）が資本です。
最近では、「ネット、アニメ、ゲーム」らしいが…。


私はタバコもギャンブルもネットもアニメもゲームもやらないので、残るは「酒」のみ。
ネットってどうゆう意味なんだろう。ネットって息を吸って吐くのと同じレベルじゃないの？


ということで、禁酒してみようと。
基本的にほぼ毎日飲んでました。だいたい、缶酎ハイ１～２本＋日本酒１～２合ぐらいですね。
ただ、これまでも1日休肝日とか設けても効果があるのかないのかわからないので、ここは思い切って、「家では飲まない」という目標にしました。

ちなみに、私の奥さんは夜勤等がある仕事で、且つ子供が小さいので（7歳、3歳）飲み会や外食には1月に1回行くか行かないかです。

同僚からは、付き合いの悪い男と思われているでしょう（笑）



そこで、以下を読んでみました。

禁酒セラピー [セラピーシリーズ] (LONGSELLER MOOK FOR PLEASURE R)

9/2に読了し、1週間、今のところ辞められています。というか、無理なく辞められている。
売り場にも行きたくないし、飲んでいる人を見ても羨ましくないし、むしろ「あーあ、身体に悪いのになぁ」という哀れみの目を向けているような感じ。
この本は隅から隅まで読まないといけない構成になっていますので、もし禁酒を試みようとしている方は是非購入して頂きたいのです。 辞められた理由は、単に以下を刷り込まれるだけ。

「酒って身体に悪いから」

「ただ、合法ってだけだから」

「だんだんと侵食されてくんだぜ。麻薬と一緒だよ。」

呑んでも、何も解決しないじゃん。これまで、呑んだことで、何か解決したことある？代わりに身体が蝕まれていくだけだぜ。

ただの幻想だよ。虚しいだけじゃないか。

酒飲まない代わりにお金が浮くぜ。一般的に一生で酒に費やす金額は1800万だ。

っていう感じですが、私はまんまと刷り込まれました。

個人差はもちろんあると思いますが、禁酒をしたい！と考えている方は、是非よんでみることをお薦めします。

Visual Studio + TypeScript + ASP.NET MVC5 + knockout でのソリューション構成のプラクティス

Visual Studio を活用し、ASP.NET MVC/C# + TypeScriptで
中規模～大規模なWebアプリケーションを構築する際のプラクティスを探っている。

以下のサイトのサンプルが非常に参考になった。

blog.indivirtual.nl

ソリューション構成は以下のようになっている。

ASP.NET MVC5のコントローラー、モデル、ビューのモジュールを分割している例に出会ったことがない今までない。
この例も分割はされていない。

Dataモジュールとして、Model層（Data Layer)（例えば、実際にDBにアクセスするなど）がモジュール分割されている。
これは割と良くあるパターンだと思う。

Webパッケージ内に、Sourceディレクトリを作り、その中でAppとLibを分けている。
Libは外部コード(bootstrap等）
Appは自前で書くコードで分けられている。

この後が非常にわかりやすいのだが、Components毎、ビュー毎にTypeScriptとViewが作られており、KnockoutのBindingをうまくディレクトリ構成でもわかりやすく配置している。
これが現時点では、おそらくベストプラクティスだと思う。これ以上キレイな例にあったことがない。

個人的には、Visual Studio + TypeScript + ASP.NET MVC5 + knockout の組み合わせでソリューションを構築する際には、
まず上記を参考にして作ると良いと思う。

大規模になるとどうなるのだろう。個人的にはやはりASP.NET MVC5のMVC部分のパッケージ、特にView部分だけは分けたいと考えるのだが・・・。

The Road from Project Manager to Agile Coach プロジェクトマネージャーからアジャイルコーチへ

Lyssa AdkinsのCoaching Agile TeamsのWill I Be a Good Coach? から気になったところを抜粋。

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))

The Road from Project Manager to Agile Coach プロジェクトマネージャーからアジャイルコーチへ

• プロジェクトマネージャーとアジャイルコーチは、チームに対してのアプローチが全く異なる。
• プロジェクトマネージャーは、計画、コントロールし、全体を監督する。
• アジャイルコーチはガイドする。
• プロジェクトマネージャーの成功は、プロジェクトの成功です。
• アジャイルコーチの成功は、チームの継続的改善とチームのハイパフォーマンスの追求です。
• 両者はまったく異なった焦点を持ち、まったく異なった行動をします。
• この考え方の違いにより、プロジェクトマネージャーがアジャイルコーチになるにはより多くの時間がかかります。（それが私(Lyssa Adkins)でした）

以下の表に、あなたがコーチになるための考え方の変換をまとめました。

プロジェクトマネジメントの信念	こう置き換える
計画し、計画の通りに仕事をします。	”計画すること”は重要だが、計画自体は役に立たない。
要求（スコープ）・時間・コスト（予算）の３つの制約は互いにトレードオフの関係にあり、コントロールできる。	時間と予算（チームの人々）は一定を保つ。 要求（スコープ）のみが変動である。
計画は、アクティビティの段階（要件、設計、開発、テストなど）を通してプロジェクトを完成させるにつれ、時間の経過とともにより正確になります。	計画は常に変更され、チームの実際のパフォーマンスに合わせて調整されるため、計画は時間の経過とともに正確になります。
時間通り、予算以内、要求通りであることが成功です。（QCDの達成が成功です）	顧客が必要とするビジネスバリューを顧客が得ることが成功の目安です。
要求（スコープ）の変更は受け付けません。プロジェクトの後半にそれが必要な場合は、変更要求として扱います。	要求（スコープ）は柔軟なままです。どんな種類の変更も、プロジェクトの後期であっても、受け入れます。ウェルカムです。
プロジェクト全体をコントロールすることが私の仕事です。	プロジェクト全体をコントロールすることは可能ではありません。チームをアジャイルの安全地帯にいれることが、唯一コントロールできることです。 だから、私はチームがよりアジャイルをうまく使えるようにコーチします。
タスクを完了し、成果物を提供することは、進捗と価値の提供を示します。	納品された最終製品のみが進捗と価値の提供を示します。

一般に、計画駆動プロジェクトマネジメントの根底にある信念は、この単純な事実に打ち消される：重力は働く。

• 顧客のニーズが変わった：重力。
• チームができることは、彼らにしか知られておらず、時間とともに変化する。：重力。
• 世界は信じられないほど速いペースで動き、誰も予見できない状況を作り出す。：重力。
• 他人はコントロールできない。コントロールできるのは、ただ一人。自分だけ。：重力。

アジャイルは、重力を受け入れ、その実践と原則の中で引力に対応する。





Lyssa Adkinsの書籍はこれしか読んだことがないのですが、非常にためになります。示唆に富んでているですよね。

Facilitate the Sprint Review by Scrum Master or Agile Coach スプリントレビューをファシリテートする

ScrumにおけるSprint Reviewは非常に効果的なセレモニーであるにもかかわらず単純な発表会で終わってしまう運用をしているチームも多い。
Sprint Reviewをうまく活用すると、ステークホルダーやエンドユーザとチームを密接に繋がらせることができる。ビジネスはもちろんだが、人間的な繋がりをも持たせられる。心理的な壁を取っ払えるのだ。
こうなるとその製品は改善の道を直走ることになる。
前提として自分たちのプロダクトを作る時間を削ってしまうということを念頭に置きつつ、互いの時間を各人がリスペクトしながら進める必要がある。


Coaching Agile Teamに"Facilitate the Sprint Review"として、
Agile CoachとしてどのようにSprint Reviewをファシリテートするか記載があったので、かなり端折っているが意訳してみる。


Sprint Reviewの目的は主に以下の５つである。

• 調整(True-up)
• 発表会(Show and tell)
• 直接的なフィードバックを得る(Get direct feedback)
• 気づきを共有する(Offer insights)
• 助けを求める(Ask for help)

調整(True-up)

チームは、スプリント開始時にプロダクトオーナーとそのスプリントで達成するべきストーリーまたはプロダクトバックログアイテムを コミットメントしている。
スプリントレビュー時には、それらが成し遂げられたか、成し遂げられていないか、明らかにする。
成し遂げられたかどうかは、各ストーリーまたはプロダクトバックログアイテムの受け入れ条件で判断する。

発表会(Show and tell)

スライドやエクセル、上っ面のプレゼンではなく、実際の製品で何が達成されたかを見せる。製品を動かす。
ここで言う製品は、Potentially Shippable Product Incrementのことである。

直接的なフィードバックを得る(Get direct feedback)

ステークホルダー、消費者、作った製品のエンドユーザから直接フィードバックをもらう。
製品は役に立つのか？
彼らの目的を果たすものになっているか？
この製品を見て、他になにか閃かないか？

気づきを共有する(Offer insights)

ステークホルダーに、チームがどのように一緒に働いているのか、組織の大まかな状況を把握してもらうことができる。
もしチームがSprint Reviewの前に振り返り(Retrospective)を開いていたなら、そこでの（プロダクトオーナーやステークホルダーに伝えるべきと感じた）気づきを伝える。
これによってステークホルダーがチームをバックアップしてくれるかも知れない。

助けを求める(Ask for help)

アジャイルコーチやプロダクトオーナーが解決できない、チームが直面している大きな障害物を上げる。
これらの厄介な障害を全員に共有し、外部ステークホルダーへのヘルプを要求するようにスプリントレビューを使用する。
せっかくたくさんの人間が集まる場なので、利用しない手はない。

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))

多くのチームでは、「気づきを共有する」と「助けを求める」をやっていないのではないだろうか。

上記５つの目的を念頭に置きながら、以下の質問に気を配る。

• チームメンバーはお互いにどのように交流しているか？他のチームとコラボレーションしているか？半分は発表者に注意を向け、半分はその他に注意を向けよう。その効果は？
• プロダクトオーナー、消費者、ステークホルダーとチームメンバーの間の対話は自然か？
• プロダクトオーナー、消費者、ステークホルダーが、チームに暗黙のうちにバックログを追加していないか？
• プロダクトオーナーは、依頼を管理するためにプロダクトバックログを使っていたか？よく周知されたビジネスバリューや他のプロダクトバックログ・アイテムとの比較を通して、依頼受け入れ・拒否の判断がクリアになっていたか？
• 誰かがいじめられたり、なだめたれたりしていなかったか？
• チームメンバーは、互いにスムーズに注意を払いましたか？
• 話したいと思ったすべてのチームメンバーが話せましたか？
• 会話の中に、アジャイルの理解に対する誤解や誤用はありませんでしたか？

（コーチとして）Sprint Review中は、断片的なワードをメモに取りましょう。

Hyper-V Windows 2016 server Windows10 インストール方法とか探してて思ったこと

Hyper-Vで遊んでみたいと思いネット検索していると、
富士通やNECで作成されたインストールガイドというものが出てくる。

[Windows Server 2016 Hyper-V インストール手順書 ]

https://www.support.nec.co.jp/DownLoad.aspx?file=WS2016_Hyper-V_install.pdf&id=3140105457

 [Hyper-V よくある失敗集]

http://jp.fujitsu.com/platform/server/primergy/technical/construct/pdf/hyperv-note.pdf

[Windows Server 2012 R2 Hyper-V 導入・操作ガイド]

http://jp.fujitsu.com/platform/server/primergy/technical/construct/pdf/win2012r2-hyperv-guide.pdf

 非常に素晴らしいのだが、逆に外国企業ではこうゆうのがない。ググっても出てこない。やはり、外国ではSEは自社内に大勢いて、インストールとかは自社内で完結するのだろうか。

上記の対象読者は誰なんだろう。富士通製のサーバを買う人って何人ぐらいいるんだろう。このガイドのために工数どれくらいかけているのだろう。ペイしてるのかなぁ。

ソフトを他人に作らせる日本、自分で作る米国

上記の本を昔読んだが、タイトルの通りだと考えてしまった。