ロッシェル・カップさんのトーク : シリコンバレーのスピードを身につける方法

ロッシェルさんのトークに行ってきた。ビデオはこちら(Facebook https://www.facebook.com/codechrysalis/videos/1566566250046015/?fref=mentions&pnref=story)

codechrysalis.connpass.com

よくまとまっていてさすがロッシェルさんだなぁ、と思った。聴衆はあんましソフトウェアとかシリコンバレーに詳しくなさそうな人が多くて、どの質問も新鮮だった。

 

特に最後の質問がすごく興味深くて、「シリコンバレーの企業は性善説の前提に立ってコントロールよりエンカレッジだというのはわかる。日本ではできないのでは?」というもの。

これはまさにNUNMIで元GMの従業員に対してトヨタが自律的な改善を教えたのと逆のことになっていると感じた。これは地域性でも民族性でもなくて。信頼の問題だったのだと気づく。トヨタと同じ国に生まれただけにすぎないな、日本人、って思った。

SQL Database の入り口

Azure の マネージドサービスで久しぶりにSQL Server のセットアップをしたら世界が変わっていたのでメモ。畠山大有さん、ご説明ありがとうございます!自力で調べると時間がかかるので先に調べてる人から聞くのは楽でいいです。

 

Azure PortalSQL Databases を選択して作る。データベース名は適当。

f:id:wayaguchi:20171101104504p:plain


Pricing Tier は料金プラン。プランは4段階。さらに性能としてDTU(アクセス数)とストレージ容量が調整できる。現時点ではストレージ容量は値段に影響しない。

f:id:wayaguchi:20171101104636p:plain

本番はStandardくらいからがオススメとのこと。月2000円しないのに、クラスタリングされてるとか素敵。

f:id:wayaguchi:20171101104821p:plain

一番高いプランでも10万円だった。一番安いリアルDBサーバより安そう。

f:id:wayaguchi:20171101105001p:plain

Collationは言語設定のデフォルト。日本語を扱う場合は、Japanese_CI_AS にしとくのがオススメとのこと。列ごとに設定もできるけど、ここで設定しておくとテンポラリのテーブルにも適用される。

f:id:wayaguchi:20171101105105p:plain

 

インスタンスができたところ。データ暗号化、自動チューニング、監査、脅威検知、地域分散、動的データマスクのオプションがある。有料だけど、なんか自分で設計しなくていいのやばいな。

f:id:wayaguchi:20171101105227p:plain

 

自動チューニングは、毎日問い合わせのデータをとっていて、インデックスの生成/削除をおすすめしてくれる。機械学習が使われている。

f:id:wayaguchi:20171101105512p:plain

 

脅威検知( Threat Detection )はサーバへのログインで地域が変なところから来たら検知するやつ。これが用意されているのはクラウドならではですね。

f:id:wayaguchi:20171101105612p:plain

 

基本的なメトリクスはデフォルトで取れてるので、自分で設定してた10年前くらいを思い起こすと、便利になったなぁ、クラウドすげぇなぁ、と思いました。

 

追記: アクセス元IPの許可

f:id:wayaguchi:20171101111307p:plain

f:id:wayaguchi:20171101111324p:plain

 

f:id:wayaguchi:20171101111337p:plain

 

ソフトウェア職人マニフェスト

Ron Jeffries たちが、2009年くらいから、Scrumとかチームのプラクティス中心になってしまったアジャイル業界を嘆いて、技術プラクティスの復権のためのミーティングを行っていて、そこで生まれたのがソフトウェア職人マニフェスト ( Manifest of Software Craftsmanship : ソフトウェア・クラフツマンシップ・マニフェスト) だ。

平鍋さんが当時行った翻訳はこれ

動くソフトウェアだけでなく、しっかり作られたソフトウェアを。
変化に対応するだけでなく、着実に価値を付加していくことを。
個人と相互作用だけでなく、プロフェッショナルたちのコミュニティを。
顧客との協調だけでなく、生産的なパタートナーシップを。

なぜか本編サイトにマージされていない。

Well-Crafted は「しっかり作る」よりもっと技術職人っぽく、「精巧に作る」、「巧みに作る」というニュアンスがあったらいい気がした。

Steadily Adding Value は「着実に価値を付加していく」で異論なしだけど、その技術的背景が大事な気がする。「安定的に価値を付加する」とか。Steadilyを調べたら「絶え間なく」なんてのが出てきたので、Continuous Delivery的にはこっちのほうがそれっぽい。

Community of Professionals は「プロフェッショナルたちのコミュニティ」は、たぶんコミュニティオブプラクティスからもじってるんだと思うけど、そのまま訳すと意味不明なのが難しいところ。個人と対話より、という文脈なのでただ複数形というより、主体と主体が積極的にコミュニティを作るというニュアンスで「プロフェッショナル同士のコミュニティ」とかどうかなぁ。

Productive Partnership は「生産的なパタートナーシップ」でこれは単に誤字修正で「生産的なパートナーシップ」としたところで、よくわかんない気もした。日本だとパートナーシップがちょっと活動というより関係に過ぎないっぽい匂い。形だけの関係でもパートナーって言っちゃうので感じ悪い言葉になってしまっている。「生産的な協業関係を」協調だけでなく何かを一緒に作るという意味で、協"業"するなんて言葉の遊びも入れてみた。

動くソフトウェアだけでなく、巧みに作られたソフトウェアを。
変化に対応するだけでなく、絶え間なく価値を付加していくことを。
個人と相互作用だけでなく、プロフェッショナル同士のコミュニティを。
顧客との協調だけでなく、生産的な協業関係を。

ちょっと平鍋さんに見てもらって、まだメンテされてるようなら、本家に送ってみようかな。

f:id:wayaguchi:20171009163440p:plain

Manifesto for Software Craftsmanship

 

とりあえず楽しくて、続けられるようなことを優先しよう

人生は誰とつきあって、なにに時間を使うかくらいしかコントロールできる変数はないのだろう。やりたいことと、すべきこと、つきあうべき人と、避けるべき人、楽しいことと、楽しくないこと、儲かること、損すること。ノウハウと機会の面で、誰とつきあうかは重要なんだけど、楽しく儲けたい人は、そうでない人を避ける傾向があるので、ゼロをイチにすることはできない。チャンスをつかんで、つながり続けるかどうかなんだろうなぁ。全然うまくできる気がしない...。とりあえず楽しくて、続けられるようなことを優先しよう。ジェフパットンが言っていたように、「あなたたちはバックログの奴隷ではない」のだから。だいぶムダなことしてると思う。すみません。

 

(2014年にFacebookに書いてたメッセージ)

教育心理学概論 三宅芳雄, 三宅なほみ

一昨年来、読書会をしたりしてアジャイル界隈で言及されている「教育心理学概論」はこちらです。放送大学のテキストで、他の先生からも同名で出ているのでご注意ください。講座用のテキストとして制作されたものですが、「人は学び続ける動物である、なぜならば」という問いからはじまる、故三宅なほみ先生の思考の展開を垣間見ることができる良書です。一章だけでもおすすめ。

「人は、学び続ける動物である。なぜそういえるかというと、人が問題を解いていたり、新しい問題の解を見極めたりする時どういうことが起きているかを詳細に観察してみると、人は、何かが少し分かってくると、その先にさらに知りたいこと、調べたいことが出てくることが多いからだ。人はなにも知らないから学ぶのではなく、何かが分かり始めてきたからこそ学ぶ、ともいえる。」(第一章 P.13-14)

子供の学びの過程とその効果についての実際の研究について言及した後(教科書なのできちんとしてます)、職業上の学び、組織での学び、ITを使った学びの支援なども展開されます。 個人的にはアジャイルとパターンと認知心理学が一つに繋がった本だと思いました(個人の見解です)。

著者の三宅芳雄・なほみの両先生は、認知心理学を学び、認知科学という新たな学問分野が生まれたときに、アメリカでそれに立ち会ってきたバリバリの研究者です。その後、日本に戻り、コンピュータのヒューマンインタフェースや、学習の仕組みをずっと研究してこられました。近年は大学を始めとして小中高の教育現場に自ら立ち入り、現場の先生方と協力して、研究の前に、研究対象となるべき「よい教育現場」を作るために尽力されてきました (  東京大学 CoREF |  )。 

 

 

 

教育心理学概論 (放送大学教材)

教育心理学概論 (放送大学教材)

 

 

 ちょっと手ごわいな、とおもったらぜひ、他の人と集まって協調的に読んでいみると良いと思います。そんな場所もあります。川鯉さんによる勉強会はこちら

educational-psychology.connpass.com

 

外から見ている限り、仕事って簡単に見えてしまう

外から見ていると、難易度の非常に高い達人の仕事でも、さも簡単にやっているかのように見えてしまう。....これを思い出すような体験をしたのでメモしておく。

 

スクラムの改善ワークショップで..

こないだ、旧知の方が勤めるある会社さんで、スクラムの基本を紹介するセッションをやった。3時間半から4時間で行うそのセッションでは、ピンポンゲームを使って、改善の仕組みを学んでいただくことが多い。今回はその旧知の方がピンポンゲーム体験済みだったので、ゲームの参加者グループからは外れてもらい、外部からの視点で見ておいてもらうことにした。

一通りゲームが終わり、全体のふりかえりをすることにした。協調問題解決の練習の一環として、参加者全員でそれぞれ気づいたことを付箋に書き出し、全体でまとめていくというプロセスをとる。まとまった付箋について、誰かに立候補してもらって、外側の人間(講師である私)に対して説明していただく。説明をすることで、よりよい共通理解を作ることができるという寸法だ。

いつも通り参加者から説明役の立候補を募ったところ、横に外れていた方が、「私やりましょうか?」と、手をあげてくれた。通常は参加者にお願いするのだけれど、今回は旧知ということもあり、その方にお願いすることにした。

説明を始めると、その方はまず付箋の大きなカテゴリだけをざっくりと説明した。そして、自分なりのアドバイスを始めた。これはちょっと私の意図とは違ったのだけど、面白いなと思ったので続けてもらった。彼はこう言っていた。

「客観的な視点でみると、こういう点がもっと改善できそうだと思いました」

もしかすると、これは世の中のマネージャーの人たちが多くハマっている罠なのかもしれない、と感じた。

 

 マネージャーの人たちがハマりやすい罠

手を動かしてなにかを作っていると、決して思うとおりにはいかないものだ。「全く無意味な失敗」も「文句のつけようのない成功」もめったになくて、そこそこうまくいくところとうまくいかないところ、やってみてはじめてわかることがあり、思いつくアイデア、次にやってみたいことが出てくるものだ。動作や表情に出ているかどうかわからないが、心と頭の中はグルングルンと回っている。

f:id:wayaguchi:20170904121231j:plain

しかし、外から観察していると、細かなことを無視して、全体を見通し「本質」が見える感じがする。やっていないので、心のざわめきも雑念もない。中の人では気づけない、価値ある仮説が見えた気がする。アドバイスしたくなる。そもそも参加していないわけだし、なにか貢献したくてウズウズする。その分野に経験があるし勘所もあるので、自分がしたような失敗を超えてもっとすごいところまでこの人たちならば行けるのではないか。できれば自分もそこに貢献できるのではないか? 

 

抽象化は悪 - チーム自身が獲得した情報量を活かそう

ちょっと待ってほしい。手を動かしている人たちの課題認識やアイデアを無視してはならない。実際にやってみて、また、これからもやっていくだろう人たちが、どのようなことを感じて、苦労して、学んで、これからどうしたいと考えているだろう?

先のゲームの話に戻ると、本当にすべきなのは、チーム自身の手で、チーム自身のふりかえりをしてもらうことだと感じた。そこで、こんどはチームの中から一人立ってもらって、今度は付箋の内容を忠実に紹介してもらうことにした。なるべく省略しないで、忠実に。意味がわからなかったら書いた人に補足してもらう。そうして、全体ではなく、実際に作業した人たち自身が、具体的にどんなことを考えたのかを知ることができた。

業務をしている人たち自身が、一番の解決者なのだ、ということを、私たちは繰り返し見てきたように思う。下の写真は、ヴァル研究所さんの総務部門の方々の看板を視察させていただいたときのものだ。このように、非IT部門の方々でも、自らが一番知っている業務を見える化することで、自分たちで解決していくことができる。カンバンの作り方をアドバイスしたくなってしまうかもしれないが、それだけで業務が良くなるとは思えない。大事なのは、現在どのような成り立ちで、どういう人たちが、どのように業務を回しているかであり、実際にやっている人たちだけが知りうる膨大な情報がそこにあるのだ。

f:id:wayaguchi:20161222201036j:plain

専門家に頼ることも必要なことがある - 必要な知識を高速に取り込む

もちろん、専門知識が不足しているという悩みもあるだろう。その場合は、教えてくれる人を雇って、教えてもらえばいい。コンサルタントというのは特定業務について教えてくれる人たちのことだ。自分たちの状況を整理して、新しい情報をもらい、改善案になりそうなアイデアを発想するための手助けをしてもらおう。一定期間業務を委託して、その間に学ばせてもらうというのでもよいだろう。専門知識を学べば、専門家ほどのアウトプットは出せないかもしれないけれど、少なくとも専門家の苦労のしどころは理解できるようになる。「専門家なのに、もっとうまくできないのか?」というような上から目線での評価はしなくなり、相手との協業関係を深めることが出来る。それは経済的にも価値がある。専門家は、よくわからない相手にはリスクバッファを積むが、わかっている相手にはいろいろと実質的に安く請け負えるように工夫してくれるものだからだ。よいパートナー関係を築くためにも、相手の痛みを知る必要がある。

 

現場の知識を活かすサーバントリーダーシップ

業務は複雑の一途を辿っている。最も状況をよく知っているのは、上司ではなく、業務を行っている個人ないしチームだ。マネジメントは、現場の知識・経験を最大限に生かさなければならない。

そのためには、必要な情報をすべて現場で共有し、自分たちの手で課題の定義を行い、解決への試行を繰り返さなければならない。そうしてチームが自律的に学ぶ状態を作り、チームでは解決できない課題へのサポートを行う。こうしたマネジメントスタイルを、サーバントリーダーシップという。問題解決をするチームに対して、ボスとして振る舞うのではなく、サーバント(執事)として振る舞うのだ。

私の経験上でも、上手なマネージャーは、多かれ少なかれ、上手にサーバントのような役割をこなしている。話を聞くのがうまく、必ず部下の意図を確認して、困っていることを聞く。自分で解決できそうなことは、発想の転換を促し、個人では解決できなさそうなことは引き取ってエスカレーションする。

簡単でもないし、誰にでも出来ることではないだろうが、そういううまいマネージャーが増えていくことを願っている。

 

 p.s. 上の写真のチームの事例は、こちらの勉強会で発表を聞けると思います。

connpass.com

熱意ある共犯者

「問題をいたいほどよく知っている人」が、熱意を持って改善のために努力するということ。

こういう人がいると、プロジェクトはうまくいくと固く信じている。言葉は悪いが「熱意ある共犯者」と定義したい。

 

2009年に参加した参加したカンファレンスで、住友信託銀行(当時)の小吉文子さんのセッションに参加して、こんなことを書いていた。

 

人事や総務といった業務担当の方を支援する仕事に最近関わらせてもらっていて、開発部門を支援するのとはまた違った趣があるのだけど、成功要因の根っこにあるのは、こういうことなんじゃないかという思いを強くしている。

 

ずっとこの思いは変わっていないし、誰かと仕事するときには指針としている。変化は情熱のあるエバンジェリスト(イニシエーター)から起こるものだろう。

 

もちろん仕事には様々な要因が影響し簡単ではない。共犯者の情熱も有限なので、途中で諦めてしまったり、中断して時期を待つこともある。元々の計画が挑戦的すぎて立ちゆかなくなることもある。しかし、火種がなければ火はつかないのだ。

 

自分がその火種なら、できることはなんでもやろう (Fearless Change のエバンジェリストパターン)。支援するマネージャーやコンサルタントやコーチなら、そういう人を探して手助けしよう。

 

以下、当時のブログから。

 

2009-11-05
DESIGN IT! Conference 2009 クラウド時代のユーザーエクスペリエンス(11月18日)
AgileUCD

http://kawaguti.hateblo.jp/entry/20091105/1257356060

 

住友信託銀行の小吉さんのセッションは、実は今回一番感動したセッション。

  • もともと銀行窓口業務をやっていて、複数のツールを組み合わせて使わなければならない現状に、「なんでこうなっているんだろう」と疑問をもっていた
  • ユーザビリティに着目した窓口新システムを作るための、インタビューが来て、「私がやらなければ」と思い、作る側にまわることになった(システム開発のことは全く知らないけど、勇気を持って飛び込んだ)。
  • 開発手法は、プロトタイピング + ウォーターフォールと定義していた
  • 現場の意見を聞き出したり、人が集まる会議で実際に使ってもらって、開発者が後ろで観察したり。ユーザビリティの手法をソシオメディア社からコンサルしてもらって、やった。
  • 現場のスムーズな移行も気を使って行った。
  • 1つの業務フローの例では、 3画面が1画面になり、入力が1/3になり、180秒が30秒に短縮されたとのこと。
  • 経営向けのアピールも行っていて、「現場の声」+「ユーザビリティ」を組み合わせてアピールすることで、システムの必然性と有用さをアピールした。
  • 企画担当と、開発担当は同席で作業を進めた。

 

感想

  • なにより、小吉さんのパッションに感動した。涙でた。
  • 「問題をいたいほどよく知っている人」が、熱意を持って改善のために努力するということ。
  • こういう人がいると、プロジェクトはうまくいくと固く信じている。言葉は悪いが「熱意ある共犯者」と定義したい。
  • UCDとアジャイルのメソッドを取り込むことで、開発者にも現場にも納得感の高いシステムづくりができたようだ
  • 企画者も開発者も悩みは多かったとのこと。いや、それは正常な悩みだと思う!あなたが悩むことで、他の多くの人の悩みが取り除かれる。それがシステムづくりってものじゃなかろうか。