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

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

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

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

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

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

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

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

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

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

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

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

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

その他

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

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

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

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

知識と技術の違いについて

今の部署に異動した時に別のグループのリーダと話をしていた中で感じた事。

そのグループは、提供しているサービスの中で生じている技術的な課題をソフトウェア観点で解決するような業務を行っている。曰く、そのチームのある分野における知見は世界的に見てもトップクラスであるとのこと。

一方で、凡ミスを行うケースもあるという。ある製品の導入やパラメータ変更の提案が来たとき、その変化による品質劣化を予見出来ず、結果としてサービスに対して悪い影響を与えてしまうというケースもあるという。そういった問題は、後になって振り返ると「当然そうなるよね」と結論付ける事ができる程度の混入であるという。

この二つの事実は、同じグループで起きているという。一つの結論として、グループの人数が多いことによるスキルのばらつきがあるという事で、勉強会を開くといったところで解消を図っているという。

具体的な解決方法については正直自分にはまだ確たるものは出てこないが、こういった事象を説明するにあたって必要なのは、知識と技術を明確に分ける(定義する)という事ではないかと感じる。

何が言いたいか。

知識というのは、知っているという事だ。「ジャガイモの芽に毒がある」というのが知識にあたる。技術はどうか「ジャガイモの芽を取る技術」なんかはあるかもしれない。「できること」であるというのは、技術を説明するための一要素だろう。

ところで、先進的な仕事をするためには知識を活用できなければならない。例えば「シチューを作る」というところで、「ジャガイモを使いたい」というモチベーションが生まれ、その中で「ジャガイモの芽に毒がある」という知識をもとに「ジャガイモの芽を取る」というスキルが必要になる。重要なのは、シチューを作るという工程の中で、「ジャガイモの芽に毒がある」事に気付けるか、「ジャガイモの芽を取ろう」という発想になるかどうかだ。シチューの例で言えば当たり前じゃないかという話になるが、それが複雑な構成、複雑な装置、複雑なパラメータで形成される場合、何がジャガイモの芽になるかすら見当がつかないという事もある。

「知識を身に着ける」という事は「ジャガイモの芽に毒がある事を知っている」という事。「技術を身に着ける」というのは「シチューを作る時にジャガイモの芽を取るという発想ができる」という事なのかなと最近は思っている。

本人の資質

最近うちの会社にやってきた人から聞いた中で、特に共感した話。

会社に勤めている人について、その人が偉いかどうかは、その人自身ではなく、その人についている役職や地位ないしは会社自体で決まる場合が多い。

例えば、大手の電機メーカに新卒で採用されたとする。下請けの会社の人は自分よりも年上であったりする。会社の中でも幾分立場が上の人にも関わらず、得意先だからという理由だけで、新入社員に対してへりくだった態度をとったりする。これは、新入社員が優秀だからとか偉いからとはではなく、彼自身が得意先である大手電機メーカの社員であるからだ。要するに、本人の資質とは何ら関係がない。

新入社員を例にとるとすごく分かりやすい、すなわち勘違いしづらいけれども、これが中途半端に経験を積みだすと、切り分けが難しくなる。お客様の立場に慣れてきて、その環境での業務に慣れてくると、自分の能力が上がったのかそれとも単にちやほやされているだけなのか区別が付かなくなる。しかし往々にして、自分の能力というよりかはやはり与えられた環境が力を発揮しているケースが多い。要するに、決定権が備わってきたとかは、(本人の努力の結果が含まれているにせよ)やはり本人の資質とはあまり関係ない。

一度、利害関係が全くない状態の相手と交渉を開始すると、自分の仕事というものはいかに会社の威を借りてきたかがわかる。まずは相手に、自分たちと関わるとメリットになるかを見せないといけないし、話を聞かないと後悔するというように思われないといけない。いや、もしかしたらそのアプローチすら違うのかもしれない。Win-Win もなにも、まずは相手に喜んでもらうところから始めないといけないわけで。

個人的メモ

異動した部署は裁量労働制ということで、家でも仕事できるような PC を探す。
会社の PC にリモートアクセスするだけなので、マシンパワーは要らないので軽くて安くてキーボードがまともなやつということで、ASUS で良いかなーと思っている今日この頃。

http://www.biccamera.com/bc/disp/CSfGoodsPage_001.jsp?GOODS_NO=3467345