Training for D-Day

ブログの内容は個人の見解であり、所属する企業を代表するものではありません。

久々に英会話

ひょんなことからまた英会話が必要になったので、今回はガチで学習を進めています。
目標は、3月末までに簡単な自己紹介と、英語で会議のファシリテーションを進められるレベルになりたい。

まずは基本文法の復習から、1日15分ぐらいでduolingoを進めています。今やっと68%。これが無料とは信じられない。文法傾向が強いですが、非常に良くできています。続けやすい。いまのところずっと無料でやってます。
問題に間違えると、ライフが減るのですが、それを回復するのにお金がかかったりするのですが、数時間経つとライフが回復するので、それを待てば良いです。

www.duolingo.com

12月いっぱいはduolingo。
1月に入ってからは、以下の本を2ヶ月間みっちりやって、すべて暗唱できるようにします。

外資系コンサルが実践している 英語ファシリテーションの技術

外資系コンサルが実践している 英語ファシリテーションの技術

最後の1ヶ月は、Coaching Agile Teamのフレーズかなぁと考えています。

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

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

例えば、以下のような質問をさらっと口から出るようにしたい。
In case of sprint planning...

  • If the goal of this sprint were a newspaper headline, what would it be?
  • What is the team composition for this sprint?
  • What is the total team capacity for this sprint?
  • What are the hightest business value product backlog items?
  • What are the concerns about these product backlog items?

あとちょっと気になる以下の本。

増補改訂版 リーダーとして話すための英語パワーフレーズ3000 MP3・CD付き

増補改訂版 リーダーとして話すための英語パワーフレーズ3000 MP3・CD付き


でもジタバタせずにやりきることが重要…だけど難しいんですよね。
今までの傾向から絶対目移りしちゃうのです。

iPhone x シルバー vs スペースグレー

今使っているiPhone 5s は16GBでもう容量がほぼ空きがなく、写真とか全て削除しても容量が足りないとiPhoneに怒られる。毎日怒られる。

iPhone 8 Plus買ったけどゴールドの色が気に食わないので、売ってしまった。 iPhone x 色で 迷うー 迷ってはいられない感じなのだけど、迷う。

いい比較画像がないか探してたけど、以下のYoutubeが良さそう。 店舗にいっても並んでないから。

youtu.be

これを気にAndroidへ…とも思ったけどibooks縛りがあるので踏み切れない。

やっぱりスペースグレーかな。

リーンを一言で言うと

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

impro-club.com

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

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

f:id:kshimizu1226:20171021063411p:plain

守破離に繋がりますね。

f:id:kshimizu1226:20171021063421p:plain

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

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

www.atmarkit.co.jp

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

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

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

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

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

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

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

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


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


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

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

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

帰る

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


集中できる時間を作る

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

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

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

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

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

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

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

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

参考文献

思考の整理学

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

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

ポモドーロテクニック

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

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

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

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

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

禁酒

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


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


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


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


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

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

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



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

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

禁酒セラピー [セラピーシリーズ] (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


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

f:id:kshimizu1226:20170910071913p:plain


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))

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)でした)

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

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

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

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


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





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