カンバンおじさんvs子どもさん

実は、一度、件のブログを読んでこれは『いかんやつだ』と思いつつも流してしまっていた。それをもう1度目にする機会があり、読み直してみたら、やはり『根本解決にはならないのではないかなー』と思った。

そんなことを感じつつ、『顧客が本当に必要だったものは』を思い出してしまった。

https://img.atwikiimg.com/www49.atwiki.jp/aniwotawiki/attach/29495/2803/What%20the%20customer%20really%20needed.gif

 

で、これが件のブログ。

 

backlog.com

 

可視化ツールであるバーンダウンチャートは使いたくなるんですよ。可視化したい病に罹ると。気持ちはわからなくもないし、バーンダウンチャートを選ぶこともやってみることも悪手ではない、と思う。

 

ところで、我が家でも子どもの夏休みの宿題だか、お受験のダイニングでカンバンを使ってみてはどうかと子どもにご提案したことがある。

我が家では皆ダイニングに集まる習性があり、ちょうど、白く広い壁があるので『カンバンにはもってこい』な環境なのである。

そこでカンバンおじさんがムクムクと登場するのである。

どうやって進めたらいいかを悩んでいる風に見えると、『可視化したらいいよ』『カンバンいいよ』と勧めずにはいられない。

それが『カンバンおじさん』である。

ねぇ、ねぇ、とマスキングテープをビシッとはり、Do、Doing、Doneのレーンを作り、カラフルな付箋紙に文字を書いて、貼ってみせる。

『どう』とドヤ顔だったかもしれない。

正直、子どもさんも困っただろう、反応に。

 

2、3日後にそっとマスキングテープを剥がしたときに学んだことは、

『手法を使うことに興味は持たない』

ということである。

 

自分で自分を褒めるとすれば(褒める必要性はないが)、意思決定を本人から奪わなかったことである。使うか使わないかは子どもさんである。なぜなら、夏休みの宿題かお受験のどちらかは忘れたけれど、終わらせるのは子どもさんなのだから。

実は、これは意識的にやっていて、道具は(知らないので)存在することを視界に入るようにみせるが、それを使うか使わないかは本人の判断に任せる、という考え方に基づいている(だから強制はしなかった)。

これは

『自分をマネジメントするのは自分』

だから、と考えてるためである。誰かが(子どもが相手であれば親が)マネジメントするとしても、大体が関心を持っている間だけである。興味を持たなくなるか、区切りが来たらそれ以降はマネジメントしない。

放り投げられるのである。

そのとき誰が困るか。

子どもさん自身である。それは大人の、エンジニアの世界も同じである。マイクロマネジメントをし続けたらどうなるか。一番知っているのはエンジニアである親である。

 

話を引用したブログに戻すと、何がダメというか自分との考え方の違いは何かとというと、上述したとおり、(ブログの書き方、表現上のことだけかもしれないが)意思決定が子どもにないことである。

一見、タスクの意思決定は子どもさんがお持ちになっているが、実は、大事なところでパパさんが意思決定してしまっている。

これでは、次の冬休みに同じように宿題を計画的に終わらそうと子どもさんが思ってもらえるか、と危惧してしまう(そこまで心配する必要はないと言われそうだが)。

 

何が言いたいかというと、大人と同じで、必要にならないと使わないし、知らないと使いようがないということである。つまり、親やマネージャであるロールの人は、

『こんなのあるよ』

と何気なく視界に入るように知る機会を作るだけしかできないのである。

 

 

 

ポストイット 付箋 強粘着 ノート 75x75mm 90枚x5個 蛍光 654-5SSAN

ポストイット 付箋 強粘着 ノート 75x75mm 90枚x5個 蛍光 654-5SSAN

 
カンバン仕事術

カンバン仕事術

 

 

ダイニングテーブルには進捗を出す何かが住み着いている

この3連休、結局、遠出もせず、庭にも出ずに締め切りが近い作業をしていた。家から出たのは、土曜日の昼食と夕飯の買い物くらいで、あとはずっと家の中暮らしであった。

まあ、なんというか、締め切りを設けている作業の進捗を出すために、自主的にカンヅメになっていただけの話である。

その3日間、やっていたのは書き物で、PCでポチポチと文字を修正し、参考資料を探し求め、ひと通り形にしようと踠いていたのである。

それで、そのPCの作業をどこでやっていたか、である。

以前であれば、リビングを陣取って外付けモニターを鎮座し、胡座をかいてみたり、正座してみたり、座り方を変えながら締め切りの対応をしていた。

ところがここのところ、どうも床に直接座るのがいけない。耐えられないというか。続かないのである。

そう言えば、地ベタリアン(死語!)の前はソファーに座って作業をしていたような気がするが、その前となると寝室の小さな机だったかもしれない。

小さな机は狭いのでダメだった。少なくとも会議用テーブルくらいの広さと目の前の開放感は必要である。小さな机は物置き場になって久しい。

ソファーはしばらく続いたが、外部モニターを使う場合はそれができないのでソファーで仕事ができないし、そうなると元のリビングテーブルで仕事をすることになるのだが、辛抱できない。腰が悪いわけでもないのに。

結局、作業のときだけ、ダイイングテーブルに外部ディスプレイを移動して締め切りの対応をすることになった。

ダイニングテーブルは、うちの勉強机でもある。うちの子どもは自室も机もあるのに、勉強するのはダイニングテーブルである。多分、ダイニングテーブルに進捗を勧めてくれる何かが住み着いているのだろう。

だから、滅多なことでもない限り、自室で勉強しない。

そのダイニングテーブルの半分を借りて(後からの新参者だし)、外部モニターを持ち込んでPCをセットする。

資料を広げ、締め切りの対応に唸りながら、締め切りのそれを行ったり来たりするので牛歩以下の進捗しかでない。

リビングの椅子は、多くが座面が皮でフレームが木製で、それでいてカチッとしている。オフィスのようなソフトな座面でも背もたれがリクライニングするわけでもない。あの椅子は、あのままでいいのだろうか。まあ、食事ではリクライニングする方が身体に食事をひっくり返しそうになって返って危ないかもしれないし、キャスターはテーブルに手をついたりすると動いてそれも危ないかもしれない。

それはさておき、3日間ダイニングテーブルでカンヅメになっていたのであるが、お陰様で予定の進捗が出たのでまずまずである。

あとは子どもの自室が未使用であるから、ダイニングテーブルで行き詰まったら、次のカンヅメ先はそこをあてにしよう。

 

 

山善(YAMAZEN) サイバーコム 会議用テーブル(幅180奥行45) ブラウン MCT-1845H
 
Bauhutte (バウヒュッテ) PCデスク 昇降式 (幅120cm×奥行55cm) BHD-1200M

Bauhutte (バウヒュッテ) PCデスク 昇降式 (幅120cm×奥行55cm) BHD-1200M

 

 

課題設定のアプローチ(自分用のまとめ)

課題設定をする際に、どうも上手く出来ていないと感じられるのだが、これまでの経験から整理するとアプローチをパターン化できるのではないかと考え、自分用のメモとしてサマっておこう。

なぜ自分でうまくできていないと認識しているのにパターン化は出来ると思うかというと、他人には助言をできるからである。それが自分のことになるとうまく進まないのは経験が形式知になっていないからだろう、と仮説を立てたということである。

課題といっても事業企画での目線で整理するが、アプローチのモデル的には変わらないと思うので参考になれば。

現状調査を行う

在るが儘の現時点に取れる情報を収集する。

  1. 収集の際には、できる限り現場に赴く。
  2. 収集する情報は、収集リストを作成し、収集リストにしたがってエビデンスを確保する。
  3.  収集の際には、現地の担当者と会話し、なぜ今の状況があるか、現場の声を聴き、記録する。
  4. 収集中に、情報の聴き方、範囲を広げた方が良いと判断できる場合、広げて収集を行う。
  5. 別に調査時点での最新の技術サービスを調べる。
  6. Gartner hype cycle、Gartner Magic Quadrantでトレンドを調べておく。

これらにより、以下の観点で情報を整理する。

  • 現時点での実態を把握できる。
  • 現場の声(要望)を得られる。
  • Gartnerなどの動向で今後選択する技術の位置付けを知っておくことができる。

あるべき姿を設定する

以下の項目から、あるべき姿を設定する。

  1. 中期計画
  2. 経営課題
  3. 自社の規程
  4. 法令
  5. 業界ガイドライン

ギャップを抽出する

あるべき姿と現状調査から差異を列挙する。 

  1. 計画と実績
  2. 方針と実態
  3. 法令と運用
  4. 規程と監査結果

課題をリストする

いくつか抽出されるギャップから課題となるものをリスト化する。

  1. それを解決することでギャップの較差が解消するか
  2. ギャップを満たすことで解消されるリスクがある

上記の2つの観点でふるいに掛ける。

課題解決のアプローチ方法を検討する

設定した課題を解決するアプローチの道筋をつける。以下の並びは順番を表していない。適宜並べ換える。

  1. ステークホルダー
  2. スケジュール
  3. 活動目的
  4. 課題
  5. 体制
  6. 予算
  7. 事前調整

課題の設定アプローチが出来ない場合

自分で課題のアプローチを設定できない(=仮説を立てられない)場合は、ステークホルダに課題をシェアしてしまう。

  1. ステークホルダを集め、現状の報告を行う
  2. 課題アプローチのアイデアを出し合うミーティングを設定する

 

 ダー誕祭ですね。

AHMAD TEA (アーマッドティー) ダージリン 200g

AHMAD TEA (アーマッドティー) ダージリン 200g

 

 

 

 

 

 

 

 

 

 

 

 

 

エンジニアの沼落ち

エンジニアが参加する勉強会でのLTやカンファレンスでは、いわゆる常連さんを多く見かけると感じることはないだろうか。

参加者も顔なじみだったりするし、スピーカーもいつものメンバが幾らかの割合を占めている。

そういった常連さんのスライドを見ると、顔が売れているから壇上に立っているのではなく、常に何か新しいアップデートを差し込んでくる。そういったこともあるのでうかうかと気が抜けないし、差し込んでくるテーマが自分にとって興味深かったりするから困ったものである。

カンファレンスでは、そういった面白そうなネタが同じ帯の時間帯に複数設定されるため、自分の身体を仮想化して同時にいくつもの経験をしてみたいと思うことが少なくない。

カンファレンスの位置付けもあるのだろうが、実験的なワークショップやオリジナルのワークショップがあったりすると次は何時お目に掛かるか皆目見当もつかないから一期一会の世界となってしまう。

ここまでが前説であり、ネタ振りでもある。

LTでもカンファレンスでも常連さんたちがいて、そういった常連さんに限ってテーマが面白い(挟んでくる小ネタやギャグは滑りまくる方が多い)。

もし常連のスピーカーの方がこのエントリを読む機会があったら、カッコ書きのところで胸が痛むかもしれないが次は滑らないように頑張って欲しい。

さて、どうして常連さんは面白いテーマを持参してスピーカーを演じに来るのだろうか。

自分としては、そういったカンファレンスやLTの場は、アウトプットと宣伝の場であると捉えている。後者はさておき、前者のアウトプットの場としてのカンファレンス、LTというのはどう感じるだろうか。

わざわざ人前でアウトプットをしなくてもいいと思うか、それともスピーカーと同じように機会があればアウトプットしてみたいと思うだろうか。

エンジニアは、最小限のOJTであれ、OFFJTであれ、生存戦略としての自己研鑽であれ、多からず、少なからず、技術スキルと基礎スキルを体験から経験知を、書籍やマニュアルから形式知をインプットしている。

この見解については同意していただけるだろうか。

それを前提に話を進めると、そうしたインプットを続けているとエンジニアは専門性を持つようになり、特定のエリアで関心を深く持つようになる(はずだ)。

そこが、そのエンジニアにとって技術の沼になる。

関心を持って物事を眺めるようになると、関心を持っていないエンジニアと比較すれば切り口の新しい視点が生まれる。その切り口から、さらに新しい疑問を問い掛けられる。それでますます沼に沈み込んでいく。

面白いことに、その沼には先人が足の先から頭の先までスッポリと浸かって待っているのである。

先人もやはりエンジニアだし、そのエリアの名高いオジ様、オネエ様であるから、ニコニコしながら手招きをして、エンジニアを沼の奥底に誘い込む。

新しい疑問を持っているエンジニアに、オジ様、オネエ様は優しく相談事に乗る体で、その疑問に新規性を感じると、それを公募にしたらどうかとさらに沼奥底に引き摺り込みに掛かる。

公募が通ろうが落選しようがカンファレンスや勉強会に関わらせられ、また新たな世界の快楽をエンジニアの身体に覚えさせに掛かるのだ。

エンジニアは何時の間にか、壇上でスライドをめくり、滑る小ネタを挟んでいるのである。その講演が終わるとまた次のネタ探しを始める重度の症状を発するようになる。

こうして、小さなインプットが大きなアウトプットに繋がり、また次のアウトプットのためにインプットをするのである。

 気づけば、そのエンジニアも頭の先から足の先まですっかり沼に浸かりきり、新たなエンジニアを誘い込むようにあなたを待っている。

 

マンガ沼

ヒナまつり 15 (HARTA COMIX)
 

 ゲーム沼

 自炊沼

イワタニ カセットフー 達人スリム 【うす型コンロ / 高さ74mm】 CB-AS-1

イワタニ カセットフー 達人スリム 【うす型コンロ / 高さ74mm】 CB-AS-1

 

レンズ沼

Canon 単焦点レンズ EF50mm F1.8 STM フルサイズ対応 EF5018STM

Canon 単焦点レンズ EF50mm F1.8 STM フルサイズ対応 EF5018STM

 

 マキタ沼

マキタ USBアダプタ ADP05 バッテリー別売

マキタ USBアダプタ ADP05 バッテリー別売

 

 

 

 

OKRは導入しない

OKRを読み終わったので所感を。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

 

 

結論

OKRは導入しない。いや、OKRは導入できない。組織がMBOでやっているから。理由はそれだけ。

 

原田隆史監修 目標達成ノート STAR PLANNER

原田隆史監修 目標達成ノート STAR PLANNER

 

 

自分が経営する会社なら、OKRを導入しただろう。いや、OKRなんて名前はないが、既にMBOベースでOKR相当のことをやっているのでOKRを導入する必要がない。

OKRの良さ

OKRは、OKRのフォーマットに書き込み、それがいつでも見えるところに掲示しておく。ホワイトボードがあればホワイトボードに、壁があれば紙に書いて張り出しておく。

毎日、いつでも、OKRが視界に入る環境を作る。

 

f:id:fumisan:20180915090845p:plain

 これはカンバンをホワイトボードでやるのと同じだ。チームは、全員が同じ物を見ていなければならない。

だから見えるところに貼っておくのではないか。

OKRの良さは、チームの目標を常時貼っておくことである。

達成されないチームの目標も個人の目標は、その多くがexcelかwordかpowerpointのフォーマットに目標を書いた後、サーバやPCのストレージの奥底に収められている。

次に見るのは早くて半年後、最悪は1年後の期末である。

そんな運用で目標が達成できるわけがない。それに気づいたから、1on1をやってメンバにリマインドしているのではないか。

 

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

 

 

でも、毎日目標を自然とメンバの視界に入るようにできるのなら、チームの目標の達成のために活動することをお互いにフォローしあえるのなら、その時間もチームの目標達成に必要な活動に使えるではないか。

改めて何か別の活動をする必要がいらないのがOKRの良さなのだ。

MBOで十分やれる

それでもOKRには移行しない。組織がMBOを採用している(OKRを人事部門が知らないのかもしれない可能性がとても高い)ためだ。

ただ、組織がMBOを採用しているからOKRを採用しない訳ではない。

OKRではないが、OKRのようなものを実際やっているから、組織のMBOと自チームでOKRを採用するような無駄な二重管理をしないだけだ。

では、どうしたらMBOでOKRができているかに興味を持つだろう。

OKRなMBO

 年初にチームのMBOを作る。これがなければメンバのMBOに展開できない。チームのMBOに最初に書くことは、チームの存在理由を書くことにしている。

チームの存在理由は、チームが組織上に編成されたときに人事報に書かれたチームを創設したビジネス背景である。

それが存在理由。

それをチームのMBOに書く。

 そしてメンバにチームのMBOを説明したときにホワイトボードに書き込んだ様々なチームのディスカッションのスクショを撮り、チームのスケジュールに貼っておく。

このスケジュールは少なくとも週1回はチーム全員が見る。

1対1ではないが、チームのMBOがメンバの心にリマインドがかかる仕組みを作ってあるのだ。

チームのスケジュールはチームのMBOから今週やること、次回やること、その先々でやることを予定として入れておく。その予定を毎週見直し、チームとしてやらなければならないことをやるのである。

そうした繰り返しは、メンバの意思決定に反映される。メンバの行動に結果がついてくる。

だから、自分のチームにはOKRは要らない。MBOで十分なのである。

 

エンジニアが作るスライドが3ページ目くらいで紛糾する現象に名前をつけたい

最近、国際会議向けの資料提供の依頼があってスライドを作ったのだが、どうにもうまくまとまらない。依頼元のレビューを受けてもピンとこないようだ。

ピンとこないならそのピンは何かを話してくれればいいものだが、それはうまく言えないらしい。仕方がないので、何度か修正しては眺め、こんな感じかと見てもらうとやはり違うという。

さて、何がずれているのか。

エンジニアに資料を作らせると、いつの間にかエンジニアが読むことを暗黙に前提とした資料になっていることが多い。資料作りを依頼した側として資料確認をすると、ああ、違うよ、とすぐにわかる。

それは読み手が誰かを知っているからだ。でも、資料を作るエンジニアはそれを知らないか、伝えても書いているうちに忘れてしまっている。

結果的に、読み手がずれてしまいレビューで違うと言われることになる。

この『読み手』は何度となく言われても忘れやすいもののようだ。

ペルソナで設定したユーザがどのような行動をするかを書き出そうというワークショップをしても直ぐにペルソナのユーザ視点に切り替えることが難しいのは、そのユーザの設定と自分が違うからだろう。話しているうちに、自然とエンジニア目線に横滑りしていく。

エンジニアに限らず、人は自分が経験してきたことをベースにしか物事を考えられない生き物なのだろう。でなければ、ペルソナのユーザにスパッと視点が切り替わっても良いはずだ。それができていないのは、もちろん、そういった視点を切り替える場数で得る経験もあるのかもしれないが、そう簡単にはいかないものなのだ。

話を戻して、国際会議向けのピンがずれているのは結局、こちらが読者に当たる会議出席者のペルソナを理解できていなかったことが原因であったことに気付いたわけだが、そうした読み手に当たるペルソナが違うとどう影響するかは試作した資料を並べて眺めるとペルソナを意識してスライドを作らなければ受け入れられないということがわかる。

端的な違いを言えば、こう表現できるかもしれない。

  1. ペルソナを間違えた資料は、エンジニア視点が抜けきれておらず情報過多で資料のメッセージがペルソナには理解できない
  2. ペルソナを意識した資料は、(ペルソナに合わせて)資料のメッセージが概念的でシンプルである

この差は大きい。

ここまで資料の読み手をペルソナとして書いてきたが、ペルソナがわかりにくければ、役職に変えても良い。例えば、エグゼクティブが読む資料に技術的な情報をこと細かく書いても意味がない。

なぜなら、エグゼクティブは役職に応じた経営判断をするのが仕事だからだ。であれば、経営判断して欲しいメッセージを伝えなければならない。そこに担当課長レベルの資料を出しても役職に応じた意思決定をできる状態ではないから、資料の隅々を見始め、結果的に資料の不出来を指摘されるのがオチである。

それも宿題がいっぱいついて。

資料の読み手を考え、メッセージとして何を伝えるのか、それを終始忘れてはいけない(戒め)。

 

 

 これは良本だと思う。

 

仕事の、時間の、使い方

これは悪いお手本のようなものかもしれないので、文面どおりにやっても同じように出来るかどうかは、それは貴方がこれまでどれだけ仕事を事細かくチェックされないだけの信頼を貯金してきたかに依るかもしれないし、自分のポジションと貴方のポジションの違いからかもしれないし、チームで働くメンバとの関係かもしれないので、それらの状況判断をしつつ、適宜、お試しください。

仕事8

 自分は、あまりかっこいい話ではないかもしれないが、時間があればあるだけ仕事に使ってしまう性格のようだ。新人の頃、ひとりプロジェクトで先輩エンジニアから

『ここまでしか進捗していないのに、もう1000時間使ったのか』

 と呆れられたことがある。周りの先輩が『まぁまぁ』と割って入ってくれたのでそのまま流れてしまったが、その場面が強く印象に残っている。

仕事8割は、ご存知のグーグルの仕事の仕方に由来する。自分のメンバには

『仕事は8割で終わらせて、残りの2割を自由に使って。考えることに使って』

と繰り返し言っているが、実は自分ができていない。言わないからね。自分ができていないことは。

ただ、実際には、マネージャ業があるので仕事8割どころではない。実稼働の6割か5割かもしれない。そのくらいのリソースで出来るようにはしている。

仕事に自分のリソースを100%突っ込まなくて済むようにするポイントは、

『仕事を終えられる見通しをつけられる程度に仕事ができるようになること』

という他ない。それができるようになるためには、仕事の道筋をつけ、段取りし、必要な関係者を手配し、揃えながら1つずつ仕事を片付ける。

そういった、仕事の流れを組み立てるとき、自分の実力と仕事の難易度なり物量なりを推し量れる力を身につけなければ、いつ終わるか見極められない。

このいつ終わるか見極められるようになれるかどうか、これがミソ。

仕事中の勉強

仕事の中でアルゴリズムを調べて実装したのは勉強として扱って良いのか。機能比較をするために調査してメリデメ表を作って製品知識をつけるのは勉強と扱って良いのか。

どちらも、仕事の中でやっているのでいわゆるOJTの扱いとすればいい。OJTで今仕事で必要だからWebで調べたり、本を読んだりする。

では、それ以外はどうなんだろう。

自分は、あまり仕事の時間の中で仕事で必要ではない別の技術や方法論を調べることにあまり関心がない。

自分のパイを広げるために本を読むとか、自分が興味をたまたま持ったキーワードを勉強するのはほとんど、自分のオフの時間である。

上述の理屈(メンバへ言っていること)から言えば、同じように自分も仕事のリソース割り当てを2−3割はそっちに振ったほうがいいのだ。

ふと気づいたが、普段から作業にはアウトプットがつきものだと思っているので、そうした思考がそうさせているのかもしれない。

チーム活動

前にもエントリで書いたが、週次のミーティングを決まったテーマで使った残りをメンバに開放している。開放とは、メンバが自主的にやりたいことをやっていいということだ。メンバ全員であるテーマについて調べてみようとか、もくもく会とかしたいと言えば、それで使ってもらう。自発的な活動の中での気になるところだけ口を挟むか、キーパーソンを後で呼んで、それを伝える。

コミュニケーション

気になることはとにかく、直接声を掛ける。メールやチャットは、リマインダーとして使う。

声を掛け、気になることを確かめ、頼みごとをお願いし、くだらない話をして席に戻る。

このコミュニケーションの中に管理という概念はない。

メンバの管理

基本的にしない。

成人した大人なんだから。

やりたいと言えば『承認』の意思表示をする。やりたいと言ってきたことが手続きを考えていないようだったら、アドバイスをする。『担当のAさんに確認してから、申請処理した方が手戻りないよ』など。

事務処理能力

平社員でも、マネージャでも事務処理能力が求められる。これは組織の中で生きて行く限り必要な能力だし、個人事業主であれば、さらに重要になる。

こうしたやらなければいけない仕事(これも立派な仕事である)を諦めて、さっさと片付ける。それも何度もやり直しをしなくていいように済ませる。

そのためには、事務処理の受け手と仲良くなっておく必要があるし、仲良く頼めるフレンドリーで下手に出て物事を進めるスキルが必要になる。

 

 

 

ゾウの時間 ネズミの時間―サイズの生物学 (中公新書)

ゾウの時間 ネズミの時間―サイズの生物学 (中公新書)