もしも下っ端がリーダーシップの本を読んだら

www.amazon.co.jp

年末年始に読んだ本。140ページ程度。

自律したチームを作るためには、リーダーは一挙手一投足の指示 (how) ではなく、挑戦しがいのあるヴィジョン (Why) と、具体的なミッション (What) を提示する必要があるとのこと。具体的な制約条件も示すと尚よい。部下は具体的なミッションを如何なる方法でも良いので遂行する事が求められる。

自身の業務に当てはめて考えてみる。最近は来年度の実証実験実施に向けて、技術動向調査、ニーズの分析、それらを踏まえたコンセプト立案、要件抽出を行っている。

先の話と結び付けて考えると、コンセプトがヴィジョンで、要件が具体的なミッションに該当するかな、という感じ。そのように考えると、要件をクリアできるかどうかを仕様をふまえて机上検討し、それだけでは不十分な側面(主に実装に依存するところ)については実証実験を行うという算段である。

実証実験については、「できる」「できない」という話ではなく、「なぜそのような結果となるか」であるとか「どういった知見を蓄えたいか」といったアウトプットを明確にする必要がある。そうでなければ、本来自分たちで得られるであろうノウハウが水のように流れて行ってしまう懸念があるからだ。技術者にとってデータは命で、知見はひらめきを生む源泉になる。

話を戻すと、前提(制約条件)、コンセプト、そして要件をきちんと定めれば、あとはそれを共有し、「要件をクリアできるか検討する」というミッションを各自で分担して進めれば、あとは物事は勝手に進む筈であった。それがミッションリーダーシップだからだ。そういった意味では間違いはなかったのだが、一つ問題なのは、その分担を任せられる人があまり居なかったというところだ。

ASUS VivoBook その後

ASUS VivoBook E200HA has BSOD (Blue Screen Of Death) which code is 0x0000001d3 - yutakusto.hatenablog.com

上記のその後。

結局、収束したと思われるブルースクリーン問題であったが、その後頻発し、最終的に何度再起動してもデバイスが認識されなくなるという状況に追い込まれた。たまに認識されても、Wi-Fi に繋ごうとした瞬間にブルースクリーンになるので、無線 LAN のデバイスに問題があることには間違いない。

というわけで、ビックカメラに修理を依頼した。メーカ保証期間内である。ただ、店頭で動作確認したところ、何故か認識された上にきちんと Wi-Fi も接続できたので、もしかしたら家の無線 LAN 親機との相性(特定のフォーマットでフレームが来るとだめなのかも)でデバイスがやられると、デバイスまたは PC の一時記憶領域がおかしくなるのかもしれない。ここらへんは全然詳しくないので、とりあえずメーカに診てもらう事にした。初期化された上で「何も悪いところはありません」と返ってくるのではないかと思っている。

余談だが、ビックカメラオンラインストア経由で三年保証を付けて買ったものの、納品書には三年保証のコードが記載されておらず、店員に「三年保証が付いてないですね」と言われた。ウェブで確認すると確かに保証は付いているので、配送された時にきちんと確認した方が良いらしい。

2016/12/27 追記

メーカ修理の結果、基盤交換とストレージの初期化で返ってきた。基盤に不具合がみられる(結局、無線 LAN デバイスもオンボードなので)という結果だったそうだが、真偽のほどは定かではない。

自分たちの欲しい人材を定義しよう

内定が決まった学生に,(過度な)課題を(2月までは)出さないで下さい!!! - 柴田教授のひびきの放送局

どうして「入社前の学生に課題を与える」ような事態になってしまうのか?

企業は所望のレベルの学生を採用できないから

全ての会社がそうであるかは分からないが、少なくとも多くの会社は適切に学生を採用できていない。

例えば、うちの会社では「大学時代に情報科学を学んだわけでもなく、Linux を触った事があるわけでもなく、通信やコンピュータシステムに興味があるわけでもないのに、推薦で入社してくる学生」みたいなのがいる。人事が技術者の採用を甘く見ているという事もあるだろう。しかし、そもそもまとまった数の優秀(必要なスキルを有していて、意欲の高い)な学生を採用をする事が現実的に不可能という事が起きていると思われる。これは、世の中にいる学生が優秀ではないというわけではなく、優秀な学生を採用できるような優秀な企業は一握りという事だろう。

話を戻すと、上記のようなケースの場合は、ひとまず学歴の高い(いわゆる良い大学を出ている)学生を集めて、最低限必要な教育を施し、何パーセントかがまともに使えるようになればオッケーというような戦法になる。

理想としては、

  1. ある程度どの部署でも共通してあった方が良い知識(情報科学など、基礎的、学問に近いもの)を全体研修で行う
  2. 各部署で、その分野に特化した知識(例えばサーバを扱うところであれば、Linux などの OS の知識や、ストレージで使用する RAID の概念、ロードバランシングなどネトワークファンクションなど)

を段階的に学ぶのが望ましい。

実際には、各部署はそういった教育を体系的に施すような土壌が備わっていない(教育に力をいれるほどリソースが足りない、どのように体系立てた研修をすればよいか分からない)。場合によっては、全体研修を行うほど会社に体力的余裕がない。後者の場合は、事前課題というような形で大学に跳ね返ってしまう。

人事担当者の短期的な評価のため

そもそも新卒採用担当者はどのようにその実績が評価されるのか。

本来の目的は「会社の業績に貢献できるような人材を確保する」という事だが、新入社員が活躍できるのは 早くても 1 年はかかる。活躍の度合いによって、何年後かの採用方針を転換する事はできるが、その年々の採用について「上手くいったかどうか」を評価する術はない。

となると、人事の新卒採用担当者を評価するためには別の短期的な物差しが必要になる。例えばそれは、新たな採用ルートを開拓した、というものがあるかもしれないが、そういった評価のための取り組みに「事前課題を与えて採用する学生の能力の底上げを行なった」みたいなものがあったりするのかもしれない。

個人的に思うところ

新たな学びを始めるのに遅すぎる事はないとよく言われるが、大抵の場合は積み重ねだ。例えば、学問においては、義務教育をきちんと受けていればこそ、大学に入った時に種々の専門分野において理解が深まる(または効率的に理解できる)ようになる。音楽においても、ピアノで基礎的な感性を身につけた上で、個々の楽器の技能を深めるというプロミュージシャンが多い。

今の世の中、歯車になるような社員をたくさん採用するような時代ではない。自動化、高度化が進んでいる中で、単純作業者はホワイトカラーの中でも減っていく。会社は、本当に自分たちが必要とする人材というものが何なのかを定義し、それを取ることに執着するべきだろう。その人材が新卒かもしれないし、中途採用かもしれないが、少なくとも新卒は毎年何百人も取っているにもかかわらず、中途はそこそこしか取らないというのは、その会社における「考えられた戦略」に即しているのだろうか?

打ち合わせの中でどうやって業務を進めていくか。

打ち合わせは短い方がいいとか、会議が業務を停滞させるとか言われる。

それは一理あるかもしれないが、やはり一人でやっていても問題が生じる事もある。なかなか解決の糸口が生まれづらかったり、周りがそれを把握できないままずるずると進捗が遅れたりという懸念がある。そういったところもあるので、ある程度の打ち合わせや会議というのはせざるを得ない。

そういった前提の中で、如何にして内容のある打ち合わせを実施するかについて。

議論の前提と目的を明確にしておく

特に、新しい事をやろうとしている時に起きる事として、各々の知識や背景が共有できていないために「そうは言ってもこういう時はどうなるの?」というように議論が脇道にそれたり、下手をすると発散してしまう。場合によっては、そういった脇道に対して細々と議論を進めようとしてしまう事もある。

前提と目的を定める事で、「その話は前提から外れている」とか、「前提から外れているけれどケースとしてはあり得るので別に検討の機会を設ける」といった意思決定ができる。前提から外れている事は、本筋ではないはずなので、そこに対して無駄に工数をかけるのは良くない。場合によっては重要度が上がってくる可能性もあるが、それは別に検討すればよい。

議論の前には各自で主張や材料を用意しておく

よほどその分野に知見があるならばともかく、ノープランでいくのはやめた方がいい。知識レベルを一定に合わせるために人を集めるのは良くない。勉強は自分でするべきだし、わからない事を自分の中明確にしてから、他の人の時間を奪うべきだ。

議論の中で出たアクションアイテムは必ず書き留めておく

言うだけ言って忘れるパターン。業務観点で言えば、議論を深める事が目的をではなく、議論を深めた事で生じる懸念、課題をクリアしていく事が目的だ。

アクションアイテムについては必ず期限と責任者を明確にする

結局、気づいた人がベストエフォートでやるパターンというのは良くある。

その他

チーム形成の話にもなるが、リーダ、プランナ、レビュワ、サポータがいると一番上手くいくような気がする。

  • プランナ:情報収集をして、何をやりたいかコンセプトを提示する。
  • レビュワ:プランナの提示したコンセプトについて、いくつかの切り口(例えば技術的側面)で実現可否やどのようにしたら実現できるかといったレビューを行う。
  • サポータ:アクションアイテムを取りまとめたり、各自がタスクをこなす手助けを行う。案外いろいろとわかった上で行動する必要があるので大変。
  • リーダー:案件を進める人。各々にタスクを振り分けたり、責任を押し付けられたりする。

ASUS VivoBook E200HA has BSOD (Blue Screen Of Death) which code is 0x0000001d3

買って 2 カ月ほどの ASUS の PC について、ブルースクリーン (0x000001d3) が頻発するようになった。

OS のクリーンインストールをしても症状が改善されなかったので、BIOS が悪いかハードウェアが何かしら悪いかであることは間違いなさそうという印象。

しかし、しばらく見てみると、状況としては家の無線 LAN に接続して通信をしている時(ネットサーフィン、Skype, DropBox 上のドキュメントを読み書き)に発生しているようであった。また、起動した時に無線 LAN が認識されない場合があった。なので、無線 LAN のドライバが悪いのではないかと思い、ASUS のサイトから最新のドライバをインストールすることにした。

結果としては、最初にドライバをインストールしようとしたところ、別の要因でブルースクリーンになったものの、もう一度トライしたところインストール成功。今のところ、ブルースクリーンは再発していない。

しばらく様子見して、これでもダメだったら修理に出してみる事にする。そのために長期保証に入っておいたので。

I bought a ASUS Vivobook E200HA in the two month before. The PC has BSOD (Blue Screen Of Death) which stop code is 0x00001s3.

I installed Windows 10 again, but My PC did not go well. So it seem that the BIOS or other hard ware devices is wrong.

I check-up the PC and try to install the latest Wi-Fi driver in my PC because the PC has crashed when the PC connect to the Internet via my home Wi-Fi, especially using skype, read/write files on Dropbox, net surfing.

After installing, my PC seems to go well and be crashed.

目指せワークライフバランス確立

残業時間を減らす事になった話。

背景

会社の偉い人たちが「19:00 以降残業禁止!!」という方針を作った。昨今の社会情勢を鑑みた決定らしい。残業禁止にする以外に具体的な意思決定は無い(例えば、外部委託化を含めた業務のリストラクチャリングをするとか、業務の効率化のために新しいシステムを入れるとか)ので、今まで通り「現場で考えろ!」という強気の体育会系スタンスだ。裁量のある会社だ。

前提

フルに働いたとして、9:00 開始、19:00 終了、1 時間休憩という事で実働労働時間は毎日 9 時間という事になる。
ちなみに、水曜日はノー残業デーなので 17:30 退社。

前残業はオッケーかというところはグレーだが、前残業してトータルの労働時間は同じだとあまり本質的な話になっていないので、9 時間をやりくりするという前提にする。

なお、我々の部署に業務効率化ツールなどという都合のいいソフトウェアは存在しない。あるとすれば Windows から生じる Office 製品だけだ(Word, Excel, PowerPoint, Outlook, OneNote...)

目標設定

勤務管理システムで実績を見てみると、月の残業時間はおおむね 40 時間である。週に 10 時間くらいの残業という事になる。1 日はノー残業デーなので、4 日で 10 時間だ。すなわち、1 日あたりの残業時間は 2.5 時間という事になる。だから、9:00 に出社していれば退社は平均して 20:00 という計算だ。

という事は、毎日 1 時間早く帰れば達成である。水曜日以外の労働時間を 10 時間から 9 時間にするのだから、業務的には 10% 削減すれば達成できる数値。そう考えるといけそうだ。

現状分析

主な業務プロセスは次の通り。備考として、それぞれは完全に排他的にはなっていない(例えば打ち合わせと方針立てはオーバラップしている部分もある)。

  • 方針や戦略立て、ないしはそろった材料から結論を導くためのブレスト
  • 考えた事を資料化
  • 資料を使って報告(上司、グループ内、他部署など)
  • 打ち合わせ(社内外含む)
  • 技術動向調査
  • スケジュール調整、メール処理
  • その他雑務

これらの業務プロセスを組み合わせたものが業務フローとなるので、フローを作る。詳細は割愛するが、結局、フローを通していく上で必ず通るのが資料化と報告となった。体感的にも、資料ばっかり作っている気がする。という事で、資料作りを削減することにした。

ちなみに、削減するのは「コア業務、ノンコア業務」「クリエイティヴ業務、ノンクリエイティヴ業務」というマトリックスで切ったときに、「ノンコアかつノンクリエイティヴ」(要するにしょうもない作業)なところがベスト。資料作りについても、例えば部長レベルに報告するような場合は、それが一種のゲート(そこを通ればある種部内の総意と言える)なので、コア業務と位置付けてきちんと作る(部長をパスできれば、それは部外や社外に一応出せるものになるから)。一方で、グループ内のシェアについては、考えが伝わればよいので、まずはラフなものでよい(削減対象)という考え方。

削減方法

主に、「自分の考えを伝えるための資料作成」や「資料を作るためのたたき台」を簡素化するというアプローチ。

  • ブレストは紙とペンで行う。アナログに回帰。
  • 描いたものはスキャナで取り込んで Microsoft OneNote で管理。
    • 必要に応じて注釈などをワードでつける。

メリット

  • 手書きだと思いのほか頭が働く。楽器やってると頭がクリアになってくるので、やはり手を動かすというのは脳に良いのかもしれない。
  • 案外早い。文字はタイピングの方が早いが、ラフな図などを書くときには圧倒的に手書きが有利だ。

デメリット

  • 字が下手だと、何を書いているかほかの人が分かりづらい。
  • 注目すべき箇所を強調しづらい(スキャンする前に蛍光ペンなどで色付けした方がよい)。

KPI

ひとまず、下記が見えるようにエクセルで管理している。

  • 実労働時間を 9 時間以下に抑える。
  • コア業務に割く時間を 20% とする。

20% というのは パレートの法則 から出している。要するに根拠はなく、経験的なもの。

アウトプットが出せているかは KPI に含めない。何故かというと、アウトプットについては半年毎に査定を受けているから。すなわち、アウトプットは出す前提、別のところで管理されているから。

その他

今後の削減の方向性としては

  • メールでの情報共有をやめる(ほかの方法があるかは不明)
  • 打ち合わせの時間を減らす
    • 事前に自分の主張をラフな資料にまとめておく
    • 無駄口を叩かない
    • 無駄な打ち合わせに巻き込まれない
    • ToDo を明確にする

といったところ。動向調査といった外出はコア業務なので、なるべく減らしたくない。

加えて、9 時間で収まらないケースを想定しておく。例えば、部長よりもさらに偉い人に説明するための資料といった準備であるとか、検証や出張などで物理的に時間がかかってしまう(が、重要なので削減できない)ケースがそれにあたる。

KPI の達成状況を見て、うまくいきそうだったら継続予定。

社内に技術を持っている事の重要さ

ここ数年の考え方として技術は買ってくれば良いと思っていたが、最近はそうでもない、すなわち技術やノウハウを自社で持つのは重要なのかなと思うようになってきた。

まず、技術を買えば良いという考え方の理由としては、技術自体がどこの会社でもあまり差別化要素にならなくなってきた事が挙げられる。ある製品について、他者に絶対的に優っているから売れているという事例を挙げろと言われた時、そういうのはあまりないよね、という話になる。極端な話、大きい会社は競合の追従を金で解決するだけでも、そこそこやっていける。技術開発のスピードや陳腐化も早くなってきた上に、一つの技術が支配的状況を作り出す訳ではないという前提であれば、目利きのある人が必要な技術を買ってきて、それを組み合わせるのが良いという話だ。

一方で、そうもいかないと思うようになってきたのは、「それぞれの技術を自分たちの中に組み込みづらい環境がある」という事実だ。

1点目は、技術の切り売りが難しいという点。先にも述べたように、技術が状況を支配しないので、技術を作る人たちはソリューションとセットで考える時代に入っている。買い手によっては、そのソリューションではなく、そのソリューションに使われている一部分が欲しいという時もあるが、売り手はそれを許容できない(旨味があまりない)という話になる場合もある。そうなると、スピード感がいきなり落ちる。

2点目は、「使えるかどうかわからない技術の話を他企業に聞く」というのがなかなか無駄なエネルギーを使うという点だ。結局、何か課題を解決するための技術を探しているという状態というのは、具体的な実施計画がないいわば育つか分からないけどとりあえず畑を耕しに行ったり種まきをしたりという状態である事が多い。話を聞かれる方としては、「そこでうちに金払ってくれるの、それとも話聞いて知見だけ取って終わる気なの」という疑問が当然湧く。技術が欲しい方は話を聞かないとお金を払えるかもわからないけど、技術を持っている方はお金を払ってくれないとやはり話を含めて技術を出したくない、というチキンエッグになる。

自社で技術や知見を持てば持つほど、こういった企業間の硬直状態というのは生まれづらい。なので、技術を持っている会社というのは、この硬直を和らげる事ができるので、新しいものや組み合わせを生み出しやすいのではないかと思う。もちろん、一人一人がこういう話をすることに抵抗の無い状況(忙しく無い)であり、社内で情報の交換が頻繁に行われるという前提はある。