Training for D-Day

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

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倍速く、魅力的に」伝える技術

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

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

f:id:kshimizu1226:20161013061752p:plain

超箇条書き

背景

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

超箇条書き

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

構造化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メッセージ化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

組織の壁

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

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

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

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

非生産的な仕事

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

大丈夫か、日本の産業界

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

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

自工程完結とは何なのか

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

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

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

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

自工程完結の10のメリット

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

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

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

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

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

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

f:id:kshimizu1226:20161004053247p:plain

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

デイリースクラム(朝会)の開催時間

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

本当に朝会がいいの?

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

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

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

ではいつがいいのか?

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

お昼ごはん前

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

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

お昼ごはん後

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

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

まとめ

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

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

チーミング Teaming -学習する組織-

チーミング

要約

様々な要素が絡み合い、複雑化する社会。そして仕事。 解決のためのマニュアルは存在しない。スーパーマンもいない。 チームで解決しよう。 チームが学習する組織となり、絶え間なく出てくる課題を解決していくにはどうアプローチすれば良いのか。

  • 学習するフレームを作ること
  • 心理的不安を無くすこと
  • 失敗から学ぶこと
  • 境界を繋ぐこと(組織や文化を超えた、より大規模なチーミング

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

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

チームの重要性、そしてチームをうまく機能させるための土台について詳しく書かれた良書。

チーミングって残念ながらネットワーク用語のほうが強くてググっても上位に出てこないんですよね。 (複数LANを"束ねる" 束ねて速度を挙げる or 冗長性確保 で、チーミング

背景

なにもかもが複雑になっていく。この時代に一人では何も成し得ない。不確実で予測不可能な現実。

そこで必要なのは学習である。 絶えず学習し、それを仲間と共有していく。 チーミングはそれを可能とする土台である。 今までのやり方は通じない。マニュアルはない。マニュアルを作っている時間もない。複雑すぎて作れない。でも課題を常に解決しつづけなければならない。そうしないと生き残れないのだ。 学習しながら実行する。それが現在の不確実で予測不可能な現実に対処する術である。

日本にはこんなことわざがある。三人寄れば文殊の知恵。 凡人であっても三人集まって考えればすばらしい知恵がでるものだというたとえである。

テイラーとフォードよ、さようなら。複雑適応系よ、こんにちは

組織におけるマネジャーの無意識の対応は、かつてない、互いにつながり合う、知識集約型の仕事の世界が必然とするものに、不意打ちを食らわせてしまう。 伝統的な経営管理論は、すでに見たとおり、とかく管理を課題評価したり組織を機械的なシステムとして扱ったりしてしまうのだ。

学習は不可欠であり、究極的には、支配を手放すことが求められる。 真のマネジメントとは、解放すること。

管理手法 実行するための組織づくり 学習するための組織づくり
雇用 体制順応者、規則を守る人 問題解決者、試みを行う人
訓練 学習してから行動する 行動することから学習する
業務評価 「あなたは」適切に行ったか 「私たちは」学習したか
作業体制 専門知識を分類する 専門知識を統合する
作業員に与えられる自由裁量権 選択肢の中から選ぶ 試行錯誤を通して試みる
エンパワーメントの手法 特別な状況が生じてやむを得ない場合は、従業員は台本から離れることができる 台本はない。即興で行動せよ!
プロセスの目標 異なる意見を追い払う 異なる意見を使って分析し進歩する
休憩時間 天気について 仕事について
事業目標 今すぐ利益を出せ 利益はあとで出せ
うまくいくとき 前方の道がひらかれている 前方の道がひらかれていない

実行するための組織づくりを体現したのがテイラーとフォード、学習するための組織づくりを体現しているのが、Google、GE、そしてトヨタだ。

チーミングを可能にするためには、既存の組織文化を変える必要があるかも知れない。 とくに変わるべきはマネージャーだ。マネージャーが旧来の考え方から離れられないのだとすると、その組織は永遠に変われない。

変化をひどく難しくしているのは、仕事に対する時代遅れの考え方の要素を、私たちのほとんどが、およそ無意識に持っているということだ。 知識ベースの経済がうまくいくのは、あらゆる階層の労働者を、誇りを持つ、自分で決定を行う大人へ回復させたときだけなのである。

チーミングの基本となる個人のスキル

様々な分野からの意見をまとめること、専門知識が多分野にわたるためにメンタル・モデルも多様である中でコミュニケーションを図ること、 加えて、大勢がともに仕事をする場合にどうしても生まれる意見の衝突を管理することである。

基本的には、

  • 学ぶこと(質問する、好奇心を持つ、傾聴する)
  • 教えること(コミュニケーションを図る、結びつける、明らかにする)

に関連する対人能力の向上の問題である。

効果的なチーミングの4つの柱

率直に意見を言う

チーミングの成功は、個人間でじかに、誠実な会話ができるかどうかにかかっている。会話には、質問すること、意見を求めること、過ちについて話すことが含まれる。

協働する

協働の姿勢と行動があって初めて、チーミングはプロセスを推し進めることができる。これは、チーミングを行う所定のグループの内でも外でも言えることである。

試みる

チーミングでは何度も試みが行われるが、これにより個人と個人の交流につきものの新奇さと不確実性を受け入れることとなる。

省察する

チーミングでは、プロセスと結果をしっかり観察し、明瞭に質問し、よく話し合うことが重視される。これは毎日であれ、毎週であれ、あるいはそのプロジェクト特有のタイミングであれ、仕事のリズムに応じて常に行われる。

チーミングを行うメリット

  • パフォーマンスが上がる
  • 職場環境が向上する

チーミングが成功する場合の状況

  • 行動1 学習するための骨組みをつくる
  • 行動2 心理的に安全な場をつくる
  • 行動3 失敗から学ぶ
  • 行動4 職業的、文化的な境界をつなぐ

チームメンバーの役割

権限を与えられたチームか、それとも技術に長けた補助スタッフか

言うまでもなく、権限を与えられたチームのほうが学習し、カイゼンし、よりパフォーマンスがよくなる。

専門技術の上での深いかかわりと、気持ちの上でのかかわり

メンバーは理由があって選ばれているのだと明確に伝えることが重要である。

プロジェクトの目的を伝える

向上心あふれる目的か、受け身で消極的な目的か

プロジェクトの特徴 学習フレーム 実行フレーム
プロジェクトを実行するときの、リーダーの自身に対する見方 待ち受ける困難を克服するにあたり、重要な立場にあると同時に相互依存している するべきことを承知しており、何をすべきか他のメンバーに命じる立場にある。
プロジェクトを実行するときの、リーダーの他のメンバーに対する見方 大切なパートナーであり、待ち受ける困難を克服するために重要な意見をくれる 脇役、あるいは部下
プロジェクトが生み出す状況に対する全体的な見方と、プロジェクトに伴う暗黙の目標 やりがいがあり、わからないことに満ちていて、新しい考え方や技術を試すチャンス。暗黙の目標は次に何をすべきかを知るためにできるだけ多くを学ぶことである。 ふだんと同じ、または「それほど違わない」。暗黙の目標は、仕事を片付けることである。

理想的な従業員の問題点

理想的な従業員であれば、持ち上がるどんな問題に対してもやすやすと対処できる。(むろんマネージャーの手を煩わせることなく)。大騒ぎすることなく、黙ってミスを直す。 そもそもミスをしない。なんでもそつなくこtなす。組織やプロセスに全力を注ぐ。

この従業員の問題点は、そういう人は組織が学習するのを困難にしてしまうことである。

学習する組織を作りたいと思っているマネージャーは、自分の考える理想的な社員をリフレーミングし、現状をそのままで良しとしない、うるさいほど質問する人を歓迎できるようにならなければならない。

心理的に安全な場をつくる

対人不安がないように努めなければならない。

失敗が緩和される。

チームワークが上手くリードされたチームのほうが、ミスの回数が多い。なぜか。 上手くリードされたチームは、心理的に安全な環境のおかげで、ミスについて報告して話し合うことがたやすくない、結果としてそれが日常茶飯事になるのである。

心理的安全を高めるためのリーダーの行動

無理に心理的安全を高めようとしてはいけない。リーダは以下の行動をとる。

  • 直接話のできる、親しみやすい人になる
  • 現在持っている知識の限界を認める
  • 自分もよく間違うことを積極的に示す
  • 参加を促す
  • 失敗は学習する機会であることを強調する
  • 具体的な言葉を使う
  • 境界を設ける
  • 境界を超えたことについてメンバーに責任を負わせる

境界を超えたチーミング

チリのサン・ホセ鉱山の事故の話。 驚異的なチーミングによって、33人の作業員が事故から70日も経過したが全員無事休出。

目に見える境界と目に見えない境界

境界とは、アイディンティティを同じくするグループ同士の間の区切りのことである。

当たり前になっている思い込み

専門化とグローバル化

境界の3つのタイプ

複雑な組織でのチーミングに突きつけられる、よくある3つの境界

  • 物理的な距離・・・分離による相違
  • 地位・・・格差による相違
  • 知識・・多様性による相違

境界を超えたコミュニケーションをリードする

上位の共通目標を設定する

学習の機会として共通目標をフレーミングすると、立場を対等にするのに役たち、意見を率直に言いやすくなる。

関心を持つ

他の人達の心を動かすものについて私たち自身の興味を深めていくことで、他人の考えや感情に対する関心を安心して表現できる環境をつくれることに一人ひとりが貢献できるようになる。

プロセスの指針を示す

どのような複雑なチーミングにおいても、全員が従おうと思うプロセスの指針を確立することが重要である。境界を管理するための戦略も不可欠だ。

チーミングと学習を仕事に活かす

学習しながら実行することと効率を追求しながら実行することの違い

効率を追求しながら実行する 学習しながら実行する
リーダーは答えを持っている リーダーは方向性を定める
決まった作業プロセスが導入される 出発点として意図的に仮の作業プロセスが設けられる
変わることは大変な労力を伴う仕事だと考えられる 絶えず少しずつ変わることが日常的になる
一方通行のフィードバックがなされる 双方向のフィードバックがなされる
社員の判断は阻止される 社員の判断は不可欠である
上司を恐れるのは普通のことである 不安があると試みや分析や問題解決が妨げられる
目標:今日にも利益を勝ち取ること 目標:長期的な価値を生み出すこと

ホンダ オデッセイ ロングボード中積み

ホンダのオデッセイを中古で購入しました。
f:id:kshimizu1226:20160815151556p:plain


ucar.subaru.jp
で購入しました。お世話になりました^^
スバルでホンダ車買っちゃってごめんなさい。
エクシーガクロスオーバー7はすごいいい車です。一度レンタカーで数日間乗りましたが、のりごごち最高。内装は賛否両論かも知れませんが、私はカッコいいと思う。

クロスオーバー7 | SUBARU

話はずれましたが、このオデッセイ アブソルート、2013年式の中古だったのですが、すごいキレイでした。
さすがカーセンサー認定(笑

しかも装備が充実してました。
あんまり詳しくはわかりませんが、アクセサリカタログを調べたところ、
サイドステップガーニッシュ
フットライト
インナードアハンドル&ドアポケットイルミネーション
フロアカーペット・マット
ライセンス・フレーム
ナンバープレートロックボルト
がついていました。

私は趣味でサーフィンをやります。ロングボードがメインです。
ロングボードは、長さが9'2で、279cmもあります。
前の車のフリードでは前座席を倒してギリギリ中積み可能でしたが、助手席は潰れます。
またサイドミラーも見えづらくなるため微妙でした。

ファミリーカーで且つ、サーフィンをときどきやるので、中積みできる車を探していました。
やっぱり最強はハイエースなのですが、ハイエースだと嫁さんが街乗りするにはちょっと。。
エスティマと悩みましたが、エスティマはなんとなく汚せないイメージがあり(偏見かも知れません)
ホンダオデッセイに行き着きました。

f:id:kshimizu1226:20160815151910p:plain

9'2 の板も車内に余裕で横積みできます。
これなら2枚ぐらい置けそうです。(7人乗りの場合。8人乗りだとセカンドシートがベンチタイプになるので、積めなくなります)



嫁さんもなんとか乗り慣れてくれて今では私より手馴れているかも(汗
色々なところで言われている、のりごごち、振動は確かに感じます。前車のフリードよりもガタガタ感を結構感じますね。

要件が変わりやすいときにだけアジャイルなのか

アジャイルなのかウォーターフォールなのか、という議論はしばしば熱く語られます。
よく言われるのが、要件ががっちり決まっているならウォーターフォールでしょ、ということです。
私は、違うと思います。

「要件と設計と採用技術が簡単(且つがっちり決まっている)であれば、ウォーターフォールでも良い」 と考えています。
いずれかひとつでも簡単ではないとなれば、スクラムなどの手法のほうが適していると思います。


f:id:kshimizu1226:20160802055125p:plain
ウォーターフォールが適しているのは、上記図の「単純」に相当するところですね。

簡単の定義は人のスキルに依存しますが、チームが複数人いて、全員が簡単と答えるなら簡単でいいと思います。
簡単の中身はしっかり確認する必要はありますが。

要件ががっちり決まっていても、チームとして設計または採用技術が簡単ではないと判断したら、スクラムを採用するべきです。
3~6ヶ月後に全く動かないシステムが出来上がる可能性が高いです。

逆にスクラムであれば、出来栄えは、少なくとも1ヶ月後、速ければ1週間で、そのチームが要望されているシステムを構築・実装できる力があるのかもおぼろげながらわかります。

逆にいうと、1-2週間でプロトタイプもしくは薄くスライスされた機能も作れないような実力では、予定通りシステムなんか作れないのです。絶対見積もりも甘いと思うし、計画に信憑性がない。マネージャーもメンバーのスキルを見誤っている可能性が高いです。だったら自分たち自身の実力を把握しながら、把握させながら、スクラムをやったほうがプロジェクトリスクが低いと考えます。
プロトタイプ作成時のコードもちゃんと見る必要があります。プロトタイプだから、スプリント1だからって構造がゴチャゴチャならすでに黄色信号です。