突如として大変な案件に放り込まれた話
4 月から体制変更という事で、突如として（予告はあったものの）大変なプロジェクトに放り込まれることとなった。
OODA に当てはめると下記のような感じ。
状況把握
一週間の状況を観察すると、以下のような状況であった。
スケジュールが明確となっていない
一つずつのプロジェクトの完了時期は明確になっているものの、それまでにどういうステップをどの時期までに実施するかというものが明文化されていない。ガントチャートもなければ、プロジェクト計画書もない。そのため、アクションアイテムもない。
要員計画が明確となっていない
スケジュールが怪しいので、要員計画もざっっくりとしている。現状、3 人がアサインされているが、これが適正人数なのかも評価できない状況となっている。
予算管理ができていない
スケジュールが怪しいので、やはり予実管理もできない。よそからみると、突然お金を使いますと言い出し始めたり、いつのまにかお金が使われているような状況に見える。
方向性
- 個々がパフォーマンスを出すためには見える化が必要
- どのプロジェクトも現状不確定要素が多く、詳細なガントチャートを作ることはしない
- 各プロジェクトの目的を明確にした上で、その目的を達成するための条件を Mission を定め、それぞれの Mission の期限を仮設定する
- Mission をドリルダウンしていき、アクションアイテムを設定する
- アクションアイテムも、当然、進捗が上がれば消化されていくが、逆に、アクションアイテムを消化する事や状況の変化、新たな発見によってアクションアイテムが増えるケースもある。
- アクションアイテムの総数はプロジェクトの完遂に近づくにつれ漸近していく
- 初期のヴェロシティはアクションアイテムの総数を増やす事で評価する事になる
- 中期、後期にしたがい、アクションアイテムの達成率が重要な指標になる
- 各プロジェクトの一元管理ができてきたタイミングで、お金の予実管理もできるように統合していく
判断
- プロジェクトの遂行についてはチーム内のリソースにて消化していく
- お金の管理については、部全体の最適化が必要であることから、別途部として体制を構築した上で管理フローを整理する
通訳について
今日、中国の企業の人たちとミーティングする機会があったのだけれど、相手の考えが全然理解できなくて困った。
相手の人たちは中国出身であり、そのミーティングに参加した同僚も中国出身であったため、ミーティングは中国語で行われ、自分だけのために通訳が入るという状況であった。
会話のペースが早いというところもあったが、基本的には通訳の人は適切に通訳をしてくれていたように感じる。しかし、その訳された言葉が全然頭に入ってこない。
普段日本語や（拙い）英語でどうしているかを考えてみると、全ての文章一つ一つを理解しようとはしていない。おそらく、聞いた文章を一字一句書けと言われれば、無理だ。会話であれば、せいぜいアクセントの強い単語をピックアップして話の流れを感じ取っているだけだろうし、文章でも拾い読みする事が多い。引っかかるところがあれば、会話の場合はインタラプトすればよいし、文章であればきちんとその部分だけ読み直せばよい。
通訳を介すると、そういったメリハリがなくなってしまう。通訳の人も、私見を排除する目的であえてアクセントといった抑揚をなくしている（淡々と翻訳していく）のかもしれない。そういった言葉は、少なくとも自分の場合は頭に入ってこないし、通訳によるタイムラグがあるため、適切なタイミングで割り込みもかけれない。
よくよく考えてみれば、日本語でも、淡々と読み上げるだけのプレゼンや、カミカミのプレゼンなんかはちっとも頭に入ってこない。それは、無意識のうちに強調されたワードだけを頭で拾っているからなのではないかと思う。逆に、言えば、どうでもよいところは流暢に失敗なく読み、必要なところだけ強調して話せば、聞き手はあらかたわかった気になれるのではないか。
話を戻すと、自分の言葉で喋る事、相手の言葉を理解する事は、お互いの理解をスムーズに深めるためには重要なのではないかと感じた。世の中には、「英語なんて勉強しなくても、必要なな時には通訳を雇えばよい」という意見もあり、それも一理あると思う。しかし、自分が使える言語で会話をするというのがニュアンスを感じ取って理解するためには不可欠だなと思った出来事であった。
プレゼンのストーリーラインテンプレ：新規技術導入編
メモ。
- プレゼンのストーリーライン形式のためのテンプレ
- 会社に勤めている技術者向け
- 新しい技術の紹介用
- 質問に答える形式でストーリー形成
- 聞きたい事が次のスライドに来るような流れをデザインするため
- タイトルは質問回答形式にする必要はなく、前スライドから誘導できればそれでよい
何故、その技術の話をしようと思ったの？
話がしたいというのは、何かしら腹づもりがあるから。聞き手は、自分にメリットがある話の方が興味を持ちやすい。なので、まずはニーズを話す。
- 何故その技術が必要か？
- どういったニーズがあってこの話を取り上げているか？
その技術って何なの？
ニーズがわかると、その技術に興味がようやく出て来る。ここで、技術の概要とその技術が生み出すメリットについて触れる。概要がわからないと、メリットに説得力が出てこない。逆に言えば、紹介程度のプレゼンであればメリットが伝わる程度の概要が望ましい。
- 概要
- メリット
- ニーズにマッチする理由
じゃあすぐに使おうよ
メリットを聞くと誰もが思う。何故今まで使っていないのか。それは往々にして、現状の環境ではデメリットが出るからだ。
- 現状の環境では使えない理由
- 特徴を踏まえたデメリット
じゃあ使えないじゃん
デメリットがあってもあきらめてはいけない。解決すれば上手くいくという希望が必要。
- そういうわけでもない
- 前提や環境をどう変えていけば適応できるか
いったんまとめるとどうなるの？
だいたいここら辺で比較材料がそろうので一度頭を整理してもらう。
- メリット、デメリットをいったん整理
- 何を変えていけば適応が見込めるか
よそはどうなってるの？
ここで、自分たちの整理が妥当なのかが気になる。簡単なのは、競合がどういう、腹づもりなのか考察すること。メリットデメリット整理と、他社動向に辻褄が合っていれば、ひとまずロジックに間違いはないという結論が出せる。また、自分たちの戦略立案の材料にもなる。
- 業界の動向
- 競合他社
- 整理したメリットやデメリットを踏まえた、競合他社の戦略の考察
- 何のためにやっているのか？
- リスクやデメリットをどうとらえているのか？
自社はどう進めるべき？
最後に、取り巻く外部環境、自分たちの状況を踏まえて結論を出す。
- 自分たちの現状分析
- メリットデメリットを踏まえた取るべき戦略
成長について
最近、楽器を弾くのをやめてしまった。実際には、全く弾かないという事でもないのだけれど、少なくとも練習は一切しなくなってしまった。楽器を弾く事に成長の可能性が見いだせなくなったためだ。
最近明確に認識出来るようになった事がある。自分にとって、飽きるかどうかは成長の要素があるかどうかで決まるという事だ。上達しなくなるとやめてしまう。もちろん、上達というのは自分と向き合うという側面もあるので、しばらく上達しないような期間でも根気よく続けていけば、ある瞬間からまた成長が見込めるという事もある。ただ、今の時期はそういった部分に根気よく時間を割くような状況ではないというところが大きい。
まぁそれは置いておいて、成長するためにはどうしたらいいか、という事について考える。
そもそも成長とは何か。これは、「今まで出来なかった事が出来るようになる」という事だ。成長の可能性があるという事は、「今まで出来なかった事が出来るようになる可能性がある」という事だ。
「今まで出来なかった事が出来るようになる」ためには、二つのアプローチがある。
- 自分の capability を上げる
- 自分の capability を別の領域で活用する
前者は、楽器でいうところの「ベースを弾き続けてその腕を上げていく事」であり、後者は「ベースの弾き方を応用して、ウクレレを弾く事」に近い。
後者については、それを成長とみなせるかは微妙なところである。潜在的に出来ていた事が、明確に実証されただけとも言える。一方で、実は「ベースを弾く」という限定的な技術を蓄えていただけかと思っていたが、実際には少しの改変で応用できるような、汎用的な技術を蓄えていたとも捉えられる。そういった認識が出来るようになれば、今後は知識や技術はなるべく汎用的な形に変換して自身のスキルとしていこうという意識が生まれるので良いかもしれない。
ある知識やスキルというのは、それ自体がある分野でさほど先進的ではない場合にも、別の領域に持っていったら先進的な概念に早変わりするという事がある。ドラえもんの未来の道具は、未来の世界では当たり前という事と同じだ。そうなると、組み合わせる事自体が先進的な概念になる可能性があるし、組み合わせるに当たって先進的な視点が必要となる場合もある。特に後者の過程では成長が見込めるのではないかなと思う。
個人の状況としては、効率を優先するあまり、組み合わせによる成長ばかりにウェイトを取りすぎている気がする。特に 30 歳を過ぎてからはそれが強い。歳を取って新たに学ぶ意欲が低下している兆候かもしれない。なので、意識的に基礎的な知識を一つずつ積み上げていくという事をやっていかないと、長期的な成長が期待できなくなる可能性があるなと思った。
生産性について
最近、日本の生産性が低いという話をよく聞く。OECD 調べらしい。うちの会社でも生産性を上げましょうとか、そのためにも労働時間を短くしましょう、という事を言われる。
そもそも生産性とは何か？
そもそも生産性とは何かという疑問が湧く。なんとなく、何かを生み出すための効率っぽいけど、実態は不明である。
調べてみると、生産性というのは、入力と出力の比率であるとのこと。入力は労働力であったり、お金であったりする。出力はほとんどの場合、お金（利益など）になるようだ。
OECD のいう生産性というのは、労働生産性であり、定義としては下記のようになる。
GDP: 国内で一定期間内に生産性されたモノやサービスの付加価値の合計額
参考
http://www.jpc-net.jp/intl_comparison/
http://www.esri.cao.go.jp/jp/sna/otoiawase/faq/qa14.html
という事で、OECD 評価を得るには、
- 国内で
- 少ない人数で
- 沢山のお金を稼ぐ
事が労働生産性を上げるためには必要ということになる。企業レベルであれば、これをそのまま当てはめて指標としても問題なさそうであるが、部署レベルでみると別の指標が必要になる事もありそうだ。
今回は、別に OECD の評価に対してどうのこうの議論する事が目的ではないので、OECD の生産性の話はここら辺にしておく。
ここまででわかった事は、
- 生産性といっても解釈は沢山あるので、何かしらの定義が必要
- 単純にニュースなどが取り上げている「OECD の労働生産性」をそのまま部署レベルで適用させるのは難しい。労働生産性（の効率化を企業が望んでいるのなら）の意図を崩さない形で、部署レベルでの労働生産性をはかる指標を別に定める必要がある
という事。
技術系の部署の場合
次は技術系の部署を前提として、インプットとアウトプットに何を定めるべきかを考える。
アウトプット
まず、アウトプット。技術系の部署は、直接モノを売るわけではない。モノやサービス、またはその素材を作っているといえる。ここからして、OECD の言う労働生産性が当てはまらなくなる。
候補としては、生み出されたモノやサービスが一つとしてある。
- リリースの数
- お客さんに提供できた機能の数
これは直感的かつ、そもそもの労働生産性の概念とも辻褄が合いそうだ。企業が労働生産性を測る際には、サービスから得られる対価（利益）をこれらの数で割れば、リリース一つあたりの生産性が出せる。そのリリース一つをどれだけの人数で生み出したか、といった値も出せる。このやり方のデメリットとしては、短期的な評価はしやすいののの、長期的な（数年かかるような案件）については評価ができないというところ。要するに仕掛り中のものについては「生産性がない」という判断になる。
他の候補としては、立てた目標の達成度合いというものもある。こちらは、長期的なモノ（数年かけてようやく製品として出せるような技術開発や研究開発）の評価がしやすいだろう。進捗率が良い、すなわち生産性が高いという考え方になる。このやり方のデメリットとしては、そもそもの KPI の確からしさが怪しいというところだ。進捗率 150% となった場合に、そもそも立てた目標が簡単すぎたという可能性もでてくる。そういうわけで、この方法は実際のところ使えないだろう。
そういうわけで、アウトプットの落とし所としては、先に述べたようなリリース数といった定量的に判断できるものが望ましいというところになる。中長期的な仕掛り中の案件については生産性に反映されないという欠点はあるものの、将来的な生産性向上のための投資と捉えればよく、そういった中長期的な仕掛りも踏まえて生産性のコントロールをしていく事が管理者の役目になる。例えば、生産性が高い状況であれば、より中長期的な仕込みに注力させるようにすれば良いし、生産性が落ちてきた場合には、中長期的な案件について（致命的にならない程度に）優先度を下げて対応する、といったところ。
どちらにしても、アウトプットとして定めた値以外のものについては、いくら生み出そうと頑張っても評価に乗ってこないというジレンマがある。例えば他部署が困っているところを技術的に解決してあげたとしても、それはアウトプットにならない。まぁ、アウトプットとしてカウントできるように計算式を作ればよいのだろうけど。
と、いろいろ考えたところでふと思いついたけれど、研究開発なんかやる部署は、特許の数であるとか論文なんかを成果としている。たしかに、特許は将来的なお金の種になるかもしれないし、論文についても知見をアウトプットしているとみなせる。論文は学会などで出さなくても、社内の知見として蓄えておけば、誰かがみる事で最終的には会社の利益に貢献できるかもしれない。
インプット
続いてインプット。
まず考えられるのは、総労働時間。労働人数はなかなか増やせない（増やしても生産能力が上がるとは限らない）ので、極端な話としては残業時間が短い方が生産性が高いという評価ができる。これだけで評価しようとすると、「こんなにたくさんの仕事を処理しないといけないのに」とか、「仕事の量は減らないのにどうすればいいのだ」という話が紛糾する。要するに「入ってくる業務の量」が生産性を測る指標に含まれていないのはアンフェアという事。
入ってくる業務の量を定量的に判断するのは難しい。アウトプットの項で触れたようなリリースの数というのも、視点を変えれば「処理すべき業務の量」と言える。定期案件と非定期案件とに分けて、非定期案件の数の多さによって生産性が測れるようにしてもよいかもしれない。言い換えると、「非定期案件が多い状況下でも予定していた定期案件のアウトプット（リリース数など）が適切に出せていれば、生産性が高いと評価できる」といった具合。
ただ、これもいろいろとこねくり回して虚像を作り上げるよりも、労働時間の変数だけで潔く評価した方が、全体最適化の観点ではブレがないような気がする。
まとめ
いろいろと考えると、会社の言っていること（早く帰れ。働く時間は減らしてアウトプットは同じにしろ）とか、やっていること（論文や特許の数を成果とする）とかは案外、的を射ているのかもしれないなと感じた。
こういうのは、考えようが考えまいが結論は同じだったりする事も多いけれど、何故かを理解出来ておいた方がモチベーションは上がる（腹落ちしやすい）ので、いろいろと疑問に思って調べるのもいいのではないかと思う。
ASUS VivoBook その後2
ASUS VivoBook その後 - yutakusto.hatenablog.com
上記の更にその後。
MAC アドレスを調べて診たところ、修理前と変わっていない。基盤だけ変えたのか、そもそも交換したというのは嘘だったのか。さすがに基盤のシリアル等々はメモしていなかったのでどうだかわからない。
そうこうしているうちに事象が再発した。ググってみた上でいろいろ考えた結果、とりあえず Wi-Fi のドライバを古いバージョンにして様子を見てみることにした。ドライバの不具合の可能性でこのような状況になっているのならば、再起動でひとまず直りそうだし、そもそもデバイスが全く見えないという事象が起こる事もない気がするのだけど、一応。
事象が再発したら、もう一度修理に出す事になるだろう。リーズナブルな PC にはそれ相応の問題があるというのは覚悟していた（ので 3 年保証にも入っておいた）が、まさか Wi-Fi にハマるとは思っていなかった。
2017年1月10日
結局ダメだったので再度ビックカメラに。
店員さんに状況を説明し、修理へ。
- 再発している
- ソフトウェア的な不具合はない（店頭でいくつかのプロセス等を確認してもらい、ハードウェアの問題という事で合意）
- 基盤交換との報告が前回あったが、MAC アドレスが変わっていないので、無線 LAN モジュールは交換されていない。今回は無線 LAN モジュール含めて、不具合ある箇所の交換および修理を希望
2017年1月20日
ビックカメラの修理受付センターより連絡受領。メーカーより基盤不良が疑われるので基盤を交換するとのこと。基盤は交換済みであり、それでも再発している事から、再調査を依頼。
もしも下っ端がリーダーシップの本を読んだら
年末年始に読んだ本。140ページ程度。
自律したチームを作るためには、リーダーは一挙手一投足の指示 (how) ではなく、挑戦しがいのあるヴィジョン (Why) と、具体的なミッション (What) を提示する必要があるとのこと。具体的な制約条件も示すと尚よい。部下は具体的なミッションを如何なる方法でも良いので遂行する事が求められる。
自身の業務に当てはめて考えてみる。最近は来年度の実証実験実施に向けて、技術動向調査、ニーズの分析、それらを踏まえたコンセプト立案、要件抽出を行っている。
先の話と結び付けて考えると、コンセプトがヴィジョンで、要件が具体的なミッションに該当するかな、という感じ。そのように考えると、要件をクリアできるかどうかを仕様をふまえて机上検討し、それだけでは不十分な側面（主に実装に依存するところ）については実証実験を行うという算段である。
実証実験については、「できる」「できない」という話ではなく、「なぜそのような結果となるか」であるとか「どういった知見を蓄えたいか」といったアウトプットを明確にする必要がある。そうでなければ、本来自分たちで得られるであろうノウハウが水のように流れて行ってしまう懸念があるからだ。技術者にとってデータは命で、知見はひらめきを生む源泉になる。
話を戻すと、前提（制約条件）、コンセプト、そして要件をきちんと定めれば、あとはそれを共有し、「要件をクリアできるか検討する」というミッションを各自で分担して進めれば、あとは物事は勝手に進む筈であった。それがミッションリーダーシップだからだ。そういった意味では間違いはなかったのだが、一つ問題なのは、その分担を任せられる人があまり居なかったというところだ。
