∑考=人

そして今日も考える。

企業がグローバルリーダーを求めるわけ

今日からグローバル研修初回。これから半年間、月一で実施される。グローバルリーダーなんて微塵も興味はないのだけれど、部長命令で泣く泣く参加することになったのだ。中途半端に英語ができるとこういう悲劇を招いてしまうことがよくわかった。

 

私は基本的にグローバルで働きたいという感覚がない。また、グローバルに働きたいという人の気持ちに一切共感できないし、非論理的だと思っている。なぜなら、グローバルに働きたいならば、日本の会社に入るべきではないからだ。

 

留学経験などから「海外の人とコミュニケーションをとるのが楽しいから」とかいう人もいるけれど、はっきり言ってあきれてしまう。外国人と話をするのと、海外で仕事をするのは全く違う話だし、それが同じだったら、人と話すのが好きな人はみんな仕事大好きってことになる。そんなわけはない。

 

そう、「グローバル」という言葉を付けた分だけ、仕事の抽象度が上がってしまうのだ。だって「グローバルな仕事」がそもそも何なのかが全くわからない。営業、開発、研究、人事、これらの分類だって決して具体的なわけでもないが、これらすらわからない。グローバルな場で働けたらこれら全て何でもいいのだろうか。このあたりが不可解極まりないのだ。

 

ちなみに企業がグローバル人材を求めているのは、グローバルという言葉の抽象度とも私は密接に関係していると考えている。今世の中の流れは非常に早くなっているし、グローバリゼーションも進んでいる。当然、そこそこ大きい会社であれば、従業員を養っていくためには国外の需要に目を向けていかなければならない。かつ、経営の多角化を進めていかなければならないのだ。

 

となると、会社としてはどんな国でビジネスをするのかも予測できなければ、どんなビジネスをすることになるのかも予測はできないのだ。そして、それはいつから始めなければならないかもわからない。明日から必要、という可能性だってある。

 

となると、会社としてはどんなビジネスをすることになるかわからないが日本以外の国でも仕事ができる(仕事を引き受けてくれる)人が欲しいのである。こういったふわっっとした人物像のことをカッコよくグローバル人材と定義しているのである。煌びやかなイメージがあるが、企業にとってはただの便利屋さんなのである。

 

リーダーも同じ話だ。仕事内容を表す言葉ではなく、役割である。とどのつまり、グローバルリーダーは、「抽象」+「抽象」で本質的な何かを指しているわけではなく、ただ単に華やかな印象を与えるためだけに作られた言葉なのだ。日本人がこういう言葉に弱いことを知った上で使っているのも癪だし、こういう言葉に釣られてグローバルな仕事がしたいという人にも少し嫌悪感を抱いてしまう。

 

なのでおそらく、「アフリカの貧困問題を解決するための仕事がしたい」みたいに具体的な欲求を持っていると、グローバルで活躍するチャンスは激減する。逆にそういう仕事にチャレンジさせてもらえる企業であれば、非常に良い会社だと考えていいだろう。

 

何にせよ、グローバルな場で何がしたいか、の方がよっぽど大切だと思う。というかそれがないと、グローバルな場で働くことなんて不可能だろうし、生きた英語も学べない。TOEICで高得点を叩き出して満足していても現場でビジネスマンとして通用しない、みたいなことになるのだ。

 

自分はこういうことをやりたくて、それをするには今の日本では難しいし、海外の人とも協力する必要があるから、グローバルな場で働きたい、みたいな考えを持っていると応援したくなると思う。

 

例えば、最新の人工知能を使った新しいサービスを作りたくて、そのためには最先端の海外で情報を獲得する必要があり、そしてそれらの情報を理解するためには英語が必要だし、現地の人からの投資が必要、だからグローバルで働きたい、みたいな。

 

ただ、まぁこういうことを本気で考えている人はやっぱりもう海外の会社で働いていると思うんだよなー。

目標を達成したい全ての人に 〜アプリリリースのお知らせ〜

Androidアプリ、作りました。

 

f:id:n1dalap:20170123231117p:plain

 

無料です。課金制度も広告もありません(少なくとも今は)。単純なアプリですが、ブログも書かずに結構真剣に作ったので是非とも使って下さい。

 

Google Play で手に入れよう

 

 

はい。サブタイトルの通り、タスク管理のアプリです。ただ、普通のToDoリストではなくWBS用のアプリです。

 

私が今の会社に入ってよかったと思えることの一つに、「WBSを頭の中で考えられるようになったこと」というのがあります。

 

WBSとはWork Breakdown Structure の略で、直訳は作業分解図などとも言われるみたいです。とある大きなゴールを達成するために必要な作業を分解し、それを繰り返して、細かい作業(タスク)に分解したものです。主にシステム開発の現場などプロジェクト型業務の組織で使われてます。

 

WBSの重要なポイントはMECEである(漏れや重複がない)こと、そして実行可能なレベルまで具体的になっていることです。この2点が不十分なWBSをもとにプロジェクトを進めると必ず問題が起きます。

 

タスクの漏れがあると、誰もその仕事をやらないのは当然として、最も注意が必要なのが具体性です。人間は何から手をつけてわからない仕事をついつい後回しにしてしまいがちだからです。だからこそ、実行可能な具体度で記述しないといけないんです。

 

逆にこの2点さえ満たされていれば、プロジェクトの成功確率はぐっと上がります。他にも、そのプロジェクトを完遂するためには何をしなければならないのか、今やっていることは何に繋がっていて、他にはどんなタスクが残っているのかを理解することができるんです。

 

で、これはチームで仕事するからでしょ?と思うかもしれませんが、個人だって全く同じ話です。例えば、「ダイエットする」を目標に掲げたものの、結局先延ばしにして、気がついたら年が明けて「今年こそは!」なんて言っていないですか。こうなってしまうのは意志が弱いからではありません。「ダイエットする」が何をすることなのかが漠然としてしまっているからです。

 

例えば、「ダイエットする」といっても、大きく二つのやり方があります。それは「食事を減らす」こと、そして「運動をする」ことです。さらに食事を減らすといっても、朝食を抜くのか、夕食を抜くのか、間食をやめるのか、いろいろと選択肢があります。

 

そしてそれを決めない限り、いつまでたってもダイエットはできないのです。つまり、「ダイエットする」という目標達成のためには「ダイエット方法を決める」というタスクが必要なのです。

 

加えて、「ダイエット方法を決める」ためには、どんなダイエット方法があるのか、そして、それぞれのダイエット効果およびメリットやデメリットを知っておく必要があります。すると「ダイエット方法について調査する」というタスクも必要なことがわかります。

 

そして、「調査」の仕方も具体的にすると、「ダイエットの特番を見る」、「ダイエット本を読む」、「ダイエットに成功した友人の話を聞く」などの方法が考えられます。どうでしょうか。今すぐダイエットはできないですが、「ダイエット本を読む」ぐらいなら簡単にできる気がしませんかね。

 

と、上記のような思考を助けてくれるのがWBSです。実際には下記のようなツリー構造のリストを作るイメージです。

 

ダイエットをする

 ダイエット方法決定

  ダイエット方法調査

   ダイエット本読む

   ダイエット成功者の話聞く

   ダイエットの特番見る

  ダイエット方法比較検討

   代表的な方法を5つピックアップ

   メリットデメリット整理

   ダイエット方法選択

 ダイエット実施

 :

 効果測定

 :

こんな風に表現すると、今何をやっていて、あと何をやれば目標達成できるのかもわかりやすいですし、シンプルに「進んでいる感じ」がしてモチベーションもあがります。あなたが普段たった一行で表現してしまっている行動も実はもっと細かい作業が積み重なってできている、ということがわかるでしょう。

 

正直言うと、このアプリは私自身が使うために開発しました。仕事でバリバリ使うほどにリッチではなく、かつToDoリストほど柔ではないものに仕上がっています。なので、個人として使うのに最適なのではと考えてます。

 

「まぁ無料だし試しに」ぐらいの感覚でインストールしてもらえれば、と。ぜひともよろしくお願いいたします。

 

人生を消費するフェーズ

人生を消費するフェーズに入っている。最近は強くそう思う。

 

厳密には生まれた瞬間から我々は人生を消費している。しかし、子供の頃は消費というよりは投資としての側面が大きかった。なせならば、色んな経験から様々なことを吸収し成長していけるからだ。どんなに無駄なことをしても、それが将来何らかの役に立つという名目があり、それすなわち投資だったのである。

 

一方で、大人になると、投資という側面は非常に小さくなる。将来のために苦しい時間を過ごしていることを投資と呼べば聞こえはいいが、実際にはただただ時間を消費しているだけかもしれない。

 

大人に対して使う「成長」という言葉も最近は違和感を感じるようになった。正しくは今対峙している仕事に順応しているにすぎない。子供の頃なら新しい知識やスキルをどんどん蓄積していくことはできたが、大人は何かを得るとその代償に何らかの知識やスキルを失っていったりする。

 

だから、人は創出することを望むのかもしれない。自分の中に何かを蓄積し続けることはできないけれど、一時的に蓄積したものを使って何かを外部に残すことはできる。例えば、今の私に3年前に自分が書いたことと同じことは書けないけれど、今になっても自分が書いたものとして残っている。

 

実績とか経験もどちらかというと、残せるものではある。ただ、私は過去の実績とか経験とかよりも、今の自分がどうか、というところにどちらかと言えば重きを置いてきた。

 

ただ、今の自分を維持していくのもこれからは大変になっていくのだろう。昔なら当たり前にできていたことができなくなったりすると、人の能力というのは絶えず失われていくものだと痛感する。

 

私は何を残したいのだろうか。

社内業務最適化を阻む要因

私の会社には無駄な仕事が多い。というより、ほとんどの中規模以上の会社であれば、無駄と思える仕事がゴロゴロしているはずだ。正確に言えば、かける労力、コストに対しての入りが少ない仕事である。

 

撤廃する方向で進めても、「この仕事をやらないとこういうリスクがある」とか「こういう場合に困る」とか言い出すコンサバ軍団が必ずいるからだ。本当に価値が全くない仕事であれば、議論に上がる前に誰もやらなくなっている。

 

というわけで、私はこの手の仕事、特に定常的な業務に関しては割と積極的にツール化を進める。あるエクセルのシートの内容を別のシートに転記する、ある条件にマッチするデータだけを抽出する、とか、お決まりのメールテンプレートで依頼するとか。なるべく、長期的に使うことになりそうなものを優先的に作っている。

 

ただ、私は自作のツールを社内の標準にはしないことにしている。

 

普通に考えれば、自分以外の人もツールを使った方が組織全体としての効果は増える。だから、私も若手の多くがやらなければならない面倒な仕事を最適化したことがある。

 

ただし、ツールありきの仕事を標準化してしまうことにはリスクがある。それは大きく2点、保守・運用が必要になること、ツールに習熟する必要があることである。

 

1点目の理由「保守・運用」の担当を逃れるため、私は自作ツールは展開しない。ツールと言うとチープな印象を受けるが、単純なシステムである。世の中で今なお大多数の人に使われているシステムには必ず保守・運用を担当する人がいる。会社としてシステムを作っているのであれば、保守部門、運用部門など専属の要員が必ずいるのだ。

 

システムを使う人はただシステムを使うだけなので、自分でシステムを直すことはできない。そんな、「壊れた時に自分ではどうしようもないもの」を自分の生活基盤に組み込むことはできないのが人間である。

 

別にシステムに限った話ではない。例えば車。直してくれる人がいないのであれば、車を買う人は激減するだろう。ただ、モノで言えば寿命と共に故障していく場合がほとんどなので、最悪新品に買い換えれば済む話であるが、システムは言ってみれば、新品の時点で既に故障していることがほとんどであるので、保守・運用は必須と言える。

 

で、個人でツールを作ると、必ず保守・運用も自分でやる羽目になる。「だってそのツールのことわかっているのは作ったあなただけでしょ?」という理屈である。当然社内のこととは言え、ボランティアでやっているだけなので、こんな理不尽なことはない。だから他の人に使ってもらうことになっても、私は非公式に渡すことにしている。

 

さらに長期的に見ても、自分(開発者兼保守者)がいなくなってしまった時に、残された担当者だけでそのツールを運用していくことができなくなってしまう。結果的に、使われなくなり、また手作業に戻る、ということがままならないのだ。

 

2点目がツールの習熟。これはシステムを導入する時も同じ話で、業務のやり方が変わるとやっぱり戸惑ってしまう人が多い。で、だいたいの場合、「前の方が使いやすかった」とか、「どうすればいいかわからない」、などと言い出す人が後を絶たない。

 

何かを変えたときに聞こえてくるコンサバ軍団の決まり文句である。もちろん、ツール自体をいかに使いやすく、直感的にできるかという点について、開発者は考えなければならないのは事実だ。

 

しかし、恩恵を授かるつもりがあるなら、自ら習熟する姿勢を持つべきではなかろうか。車の運転に技能が必要だから車に乗らない、などと言っている人は技術の恩恵を決して受けることはできない。自転車だって同じだ。どんな道具もある程度使い方を覚える必要はある。

 

ただ、会社にいる人というのは、総じて今の自分のままでできる仕事を好む傾向にある。先ほどの保守についても全く同じである。別に開発者が私だからと言って、私が保守をしなければならない、なんて買い被り過ぎである。

 

私に言わせれば、誰でも少し調べれば、マクロの仕組みを理解して、自分の思い通りに直すことは可能だ。そのぐらいのレベルのものしか作っていない、というより一人で仕事の空き時間に作れるものなんてその程度が限界だ。

 

しかし、これまたそういう活動には興味がない人が多い。顧客に直結しない仕事、裏方の仕事、地味な仕事、そして評価されない仕事をやる人は少ない。これは組織としての問題ではあるのだけれど。

 

これが一般の企業なら別に上記に述べた問題からツール化を避けるのもいいのかもしれない(生産性が停滞するのでお勧めはしないが)。ただ、私たちはシステムを作っている会社である。だから、私は言いたい。お前たちは技術者ではないのか?と。

 

他人が作ったツールを使いにくいと言う前に、どうすれば使いやすくなるのか考えろ。ツールにバグがあった場合の心配をするのではなく、ツールのバグを直すためにはどういうスキルが必要なのかを考えろ。こんな姿勢の人達が良いシステムの提案ができるはずもない、と私は思うが。

 

でも、私たちはもう技術者の集団ではないのだ。だから同僚の技術に対する姿勢を問題視したところで仕方がないと諦めている。私はそもそも自分がやりたくない仕事をやらないためにツール化しただけなので、そのせいで自分の仕事が増えたら本末転倒であるし。

新年に「今年の目標」を設定するという奇妙な行いについて

あけましておめでとうございます。新年になったということで「今年の目標」的な投稿を色んなところで見かけますね。で、まぁ私も今年の目標とかを少しは考えてみました。

 

が、何も思いつきませんでしたね。というか、今年の目標を新年に考える意味なんてあるのか?という疑念の方が強くなってしまいました。だって去年考えた「今年の目標」なんてもう忘れてますし。逆に覚えてる人いんの?

 

うん。確かに、年が明けたら「今年の目標は・・・」みたいなこと考えるのは結構恒例行事になってる節があるけど、今年が終わるときに今年一年どうだったか振り返ってる人なんていないっしょ

 

念のため言っとくと、「去年は楽しい一年だった」とか、「どこどこへ旅行へ行けてよかった」とかそういうことを思い出すことが振り返ることではないですからね。昨年立てた目標設定に対してどうだったか考える。これが本当の振り返りですよ。まぁやらないでしょうね。仕事みたいだし。

 

でも新年になってから設定する目標を考えるぐらいなら昨年を振り返った方がはるかに意味はあるんですね。てか後で振り返らないなら目標なんて立てる意味ないでしょう。

 

あと、”今年の”目標というのも考えてみると変な言葉ですよね。例えば、「今年こそは痩せる」という目標はありがちですけど、いやいやいや。それ”今の”目標じゃないの?って感じです。今すぐはやらないけど、今年中には・・・みたいなニュアンスで使ってる時点で努力する気ないでしょう。

 

本当の目標は常に「今の目標」であるべきですね。結果を出すには時間がかかりそうとか、オーディションが1年後だから、といった理由で”今年の”目標だったとしても、そこに対して今から進捗させる覚悟があるならもう今この瞬間の目標といって差し支えありません。だから、今年の目標は・・・なんて言ってる時点でスタート負けしてますし、叶う確率も下がります。

 

こうやってよくよく考えていくと、新年に今年の目標を考える行動というのは、本当に何の役に立つのかわからない奇妙な行動なんですよね。「目標があった方が人生は充実する」という格言めいた言葉だけを鵜呑みにした結果と察します。

 

残念ながら新年の目標を考えたくらいで人生は充実しませんが(涙)、これは言ってみればもう文化なんでしょうね。正月には初詣に行く、ぐらいの慣習です。そこに深い意味や合理性はないんです。だから、あまり気張らず、おみくじを引くぐらいの遊び感覚でやるのが正解なんでしょう。

分業体制に潜むデメリット

今世の中は分業が加速している。というよりは、分業して、専門性に特化していかなければ、競合他社との差別化を図ることが難しいからだ。そもそもの原則として、分業した方が効率的に仕事を進めることができるのは明白である。

 

ただ、分業したばっかりに上手く行かないと感じることも結構多いんじゃないだろうか。つまり、分業にもデメリットはありますよ、というお話だ。

 

私が今のチームでよく感じるのは、分業が進みすぎたばかりに作業の重複が結構発生することである。システム開発なんかをやっていると、業務系のSEと基盤系のSEに分かれて分業することも多いのだが、結局結合試験とかを始め出すと、全く同じ試験を別々に二回やる、みたいなことが頻発する。

 

そもそもシステムの構造上、基盤システムの上に業務APが乗っかっているので、業務APの試験を実施するためには、基盤システムを動かさなければならないし、基盤システムの試験を実施するためには、何かしら業務APを利用しなければならない場合もあるのだ。

 

分業していなければこれらの試験は一度で済む。まぁ分業が悪い、というよりは分業するための仕掛け作りを怠っていることが真の原因なんだけど。特に分業しているものを連結する場合には、分業したまま進められる作業、一緒にやった方が効率的なものをキチンと仕分けておく必要がある。

 

でも、この「仕分け」という作業をほとんどの人が意識していない。なぜならば、分業した人たちの責任範囲を超えてしまっているからだ。自分たちが考えるべき範囲でもあるけど、相手が考えるべき範囲でもあるよね、という仕事は総じて責任が不明確になり、問題を起こしやすい。システム開発でもインタフェース部分で故障が多く発生するのはこういった人間の心理も大きく関係している。

 

なので、プロジェクトマネージャーならグレーゾーンについて注意をしなければならないし、もし自ら監視しきれないのであれば、キックオフ(プロジェクト開始)の段階で、チームの中で主となるチームを決めておくのが良いと思う。さっきの例で言えば、業務Tにも方式(基盤)Tにも影響があるものについては業務Tが主管とする、といった感じで。少しでも曖昧な部分を無くさなければならない。

 

同じような話として、分業体制にすると、自分たちの仕事を進める上で、他チームの情報なりスキルなりが必要になる場合が必ずある。この他チームへの依頼作業というのが不毛で、非常に骨が折れる。以下はかなり極端な例ではあるが、こんな感じである。

 

1日目:

「この資料を元に〇〇の設定を反映して下さい」(業務T → 方式T)

2日目:

「この資料だけだと具体的な設定値に落とし込むことができないので、条件を整理してください」(方式T → 業務T)

3日目:

「どういう形で整理すればいいのかわからないので、フォーマットを提供して下さい」(業務T → 方式T)

 

もはや、要件定義の縮図である。全く持っているスキルや知識が違うチームに対して何かを依頼して、期待通りの結果を得るというのは実は結構難しいのである。

 

加えて、これは私の予想だけど、どうも分業体制に慣れている社会人は自分がボールを持っている状態を必要以上に嫌う傾向がある。理由は簡単で、「この仕事については〇〇チームへ依頼中です。」と言えれば、自分たちには何も非がないように振る舞えるからだ。

 

よって、一度依頼が発生すると、本当の仕事が全く進まない不毛なキャッチボールが繰り広げられる。結果進捗が遅延すると、「そんなもん連帯責任だ」といってもほとんど響かない。分業体制は個々の責任を明確にしているだけに連帯責任は追求されにくいのだ。

 

分業をしていなければこうはならない。しかし、分業をしていても、こういった機会を極力少なく余地はあるように思う。

 

ほとんどの場合、特にチームレベルの分業なんてものは十分に最適化されていない。なんとなくこの仕事はこのチーム、あの仕事はあのチームぐらいで分けられている。

 

できれば、各チームが持ち得る情報とスキルを整理した上で分業した方が良い。体制を考える上で、その人が持っているスキルをベースで考えることが多いが、その人が持ち得る情報という観点もあった方が良いと個人的には思う。

 

なぜなら、ぼぼ全ての仕事は、必ずスキルと情報をセットにしなければ成し得ないからだ。この辺はプログラムと全く同じである。だから、情報のやりとりが煩雑になりすぎるようであれば、分業化する意味はない。情報を仕入れるルートを変更したり、そもそもの体制を見直す必要がある。

 

とりあえず、分業こそが最も効率的だ、と考えるのは浅はかで、分業化するからこそ注意しなければならない点があり、それは大きく、責任範囲の明確化と伝達情報量の極小化である。これらを踏まえて仕事を進めることが大切なんじゃないか。

生産性

日本人の生産性は低い。理由は主に三つだと私は考えている。リスクを許容できない精神的弱さ、中庸を重んじる論語的思想、そして労働時間に対して支払われる報酬システム。これらが上手く絡み合っているせいで生産性はガタ落ちである。

 

日本人は総じてリスクを回避しがちな人種である。例えば、大学受験となると、複数の大学を受験し、就活の時期になると、複数の会社の面接に進む。もちろん、リスクヘッジは必要だし、リスクは回避できるに越したことはない。

 

ただし、上記の例はリスク分散といって、リスクマネジメントの一つの手法であって、それが完璧な対応策というわけではない。何より気に留めておかなければならないのは、リスクを分散したところでリスクがなくなるわけでもないし、実は全く反対の手法であるリスク集中の方が効果的な場合だってある。

 

そして、本当に一番考えなければならないのは、リスクを回避するためには、お金と時間が余分にかかること、である。

 

会社に入ってずっと思っているのは、皆”とりあえず”リスクを避けようとすることだ。「どこまでのリスクは排除し、どこまでのリスクは許容するのか」という定量的な考えを全く持っていない。

 

一つの例として、自宅の鍵の数による行動の変化は興味深い。鍵が一つしかない家に住んでいるときには鍵を一つしか閉めていなかったのに、次に引っ越した家に鍵が二つついていれば、ほとんどの人は二つとも鍵を閉める。

 

これは自分の中でのリスクに対する定量的な考え方をもっていないからである。とは言え、そこまでやる必要ある?ではなく、手間もほとんど変わらないし二つ閉めといた方が安全だろう、という風に考えるのが人間の自然な心理なのだ。

 

ただやっかいなのは、一度高くなったセキュリティレベルを下げることには抵抗を感じてしまうことだ。例えば、オートロック付きのマンションに住んでいた人がオートロック付きではないマンションへ引っ越そうとすると不安になったりする。これも人間の自然な心理なのだ。「子供の居場所を常に把握していないと不安」だから携帯を子供に持たせるなんて、一昔前の大人は思っちゃいなかったはずである。

 

つまり、何も考えていないと、ほとんど起こるかもわからないリスクに膨大な時間とお金を奪われていく方向に流れてしまうのだ。だから価値を創出する時間に多くを避けなくなっている。なので、不祥事を避けるためなどと言って、簡単にルールを作らないことだ。

 

たぶん海外の企業が結構有名な企業でも裁判沙汰になったりするのは、「これ以上のリスクに対しては対策を打たない(お金と時間が無駄だから)」と腹をくくっているからだと察する。私も明日からは家の鍵は一つしか閉めないと今決めた。

 

次が、中庸的な思想である。端的に言えば、全部頑張りましょう、というスタンスだ。

 

仕事を速く進める上で大切なことの一つに優先度付けというものがある。どの仕事が最優先で、どれを後回しにしてもいいのかを考えて本当に今やる必要のあることから片付けるという考え方だ。

 

でも、私は日本人の優先度付けはあまりに不完全だと思っている。それは、優先度が低くても、いずれはやるもの(やらなければならないこと)として常に考えられているからだ。

 

それでは、タスクの順番が変わるだけで、仕事量としては何一つ変わらない。(もちろん、ここではタスクの組み替えによって無駄な作業が省かれるケースは除外している。)優先度の低いものは無駄だから無くすべきでは?という発想がまるでない。これは先に述べた過度なリスク回避にも起因するところだ。

 

システム開発などをやっていると、試験工程というものがある。もっとも理想的なのは、作ったプログラムの全てを試験することで、完璧な品質が確保できる。ただし、基本的にはそんな膨大な試験をすることは労働力的に不可能である。だから、影響度の高いバグは無くすべく、かつなるべく少ない労働力で試験をするテスト技法が存在する。

 

しかし、試験を考えだすと、これもやった方がいい、あれもやった方がいい、というのが沢山出てくる。大きな影響はないし、やる必要ないのでは?と言っても、「念のため」とか「一応」やった方がいい、という結論が出ることがほとんどだ。

 

結果的に、あんまり試験としては効率的ではなくなり、稼働が逼迫するケースが多い。システム開発に限らず、「念のため」とか「一応」の仕事が日本のサラリーマンの仕事の半分以上を占めているように思う。「一応ここまではやっておくか」という言葉が脳裏に過ったら本当にこれやる必要あるのか?ということを考えてみよう。

 

三つ目が、労働時間に対して支払われる報酬システムである。日本型企業のほとんどはこのシステムで動いている。SIerなどはまさにこの代表例で、これだけの人がこれだけ沢山働く必要がある(何人月かかる)からこのシステムは〇〇円です、という契約がほとんどだ。そのシステムが運用されてどのくらいの利益が見込めるからとか、システム自体の価値は一切加味されていない。(加味されていたら、とっくに倒産していると思う。)

 

だから、生産性を高くすることによって売上が減少するというパラドックスに陥ってしまうのだ。だから生産性を上げることに関心のない管理職は多いし、いまだに過去の生産性を基準として見積もりを行っている現状である。

 

サラリーマン個人というミクロの視点で考えても同じことだ。2週間で終わると思われていた仕事が創意工夫によって1週間で終わらせることができたとしても、残りの1週間休めるわけではない。

 

他の人の仕事が与えられたり、と当初予定していた倍の仕事量を与えられるだけである。もちろん、給料は変わらない。つまり、仕事をダラダラやっている方が給料的には割がいいことになる。

 

それでも、私は生産性を上げた方がいいと思っている。チームとしての生産性を上げることはもう半ば諦めてしまっているが、個人としての生産性を上げておくにこしたことはない。

 

確かに日本型企業ではあまり給与には反映されないし、余計な仕事を与えられることも多いけど、それだけ仕事の幅は増えるし、たぶん評価には繋がる。仕事の幅とか評価とかどうでもいいなら、あんまり仕事が進んでないフリをしてサボることだってできる。

 

生産性を上げるためにぜひとも覚えておいた方がいいと思う具体的なスキルはVBAマクロ、VBSなどのプログラミングである。

 

たぶんクリエイティブな職種の中にも定常的な業務とか、決まりきった仕事は沢山あるはずで、これらの決まりきった仕事というのは、大抵自動化ができる。特に、あまり価値がないと考えられている仕事の多くに自動化の余地が残されている。

 

本来論で言えば、自動化するよりも前に、無駄な仕事と再定義して無くすべきなのだろうが、大きい企業とかだとこの無駄な仕事を無くすためのコストが尋常ではない。自分の課長や部長でさえ権限を持っていないがルール化されているような仕事が多い場合は、それを無くす方向で頑張るよりも最低限の労力でこなす方法を考えた方が得策である。

 

月に一回決まったテンプレートで出さなければならない報告書とか、エクセルへの手入力作業とかも、必ずどこかに自動化の余地が残されているし、そういう「今後長期的にやることが決まっている作業」を自動化しておくと、それだけ費用対効果は大きくなる。

 

もちろん、自動変換機能を使うのもいいし、メールテンプレートを複数用意しておくのも工夫としてはありだ。ただ、プログラミングの考え方を持っていれば、もう少し複雑な処理も簡単に実施できる。

 

一例として、私は転入書類を自動で出力するマクロを作ったことがある。

 

転入者(プロジェクトに新規で参画するメンバ)が入ってくると、必ず書かなければならない書類が5枚ぐらいあって、かつそれを格納するためのフォルダを作ったり、それぞれの情報を管理するために管理簿に転記したりと、普通にやると一人の対応だけでも一時間ぐらいかかる作業があった(今も存在している)。

 

しかし、複数の申請書に書く内容は結構重複してたりして、手入力だと非常に無駄が多い。こんなときに、マクロを使うと、一箇所に入力した情報を元に申請書に転記したり、管理簿に転記したりを一度に実施することができる。かつ複数の人がいてもそれほど時間は変わらない。たとえマクロを作るのに2,3時間かかったとしても、すぐに元は取り返せる。

 

こんな風にちょっとでも生産性を向上させる方法を考えながらやっていると、確実に価値の低い仕事にとられる時間は減って、仕事も面白くなっていく。

 

インプット本はこちら↓↓

 

自分の時間を取り戻そう―――ゆとりも成功も手に入れられるたった1つの考え方

自分の時間を取り戻そう―――ゆとりも成功も手に入れられるたった1つの考え方

 

 

生産性―――マッキンゼーが組織と人材に求め続けるもの

生産性―――マッキンゼーが組織と人材に求め続けるもの

 

 

 上は個人向け、プライベート目線、下はチーム向け、ビジネス目線。一見、同じ人が書いたとは思えないけど、言ってることはほとんど同じだったり。

隠蔽体質の正体

進捗の報告会で「うちのチームは特に問題はありません。」という報告が続くプロジェクトはだいたいヤバいです。俗に言う、隠蔽体質です。若手の私が言うのもなんですが、チームとしてはかなり末期の症状だと言ってもいいでしょう。というのも、プロジェクトという未知の物事に取り組む上で問題が起こらないはずがないからです。

 

実際、私が前回やっていた開発プロジェクトもこう言った状態が永らく続いていました。しかし、現場にいた人間としては明らかに稼働不足、品質も穴だらけ、様々なリスクを積み残している状態でしたね。

 

それでも、進捗報告の議事録を見ると、毎週「特記事項なし」なんて描かれているんですよ。「特記事項なし(笑)」とかにした方がリアリティがあって面白いなーとか思いながら見てました。

 

だから、後になってめちゃくちゃ品質が悪いことが判明して、人員を慌てて投入したんですが、時すでに遅し、でした。幸か不幸か、プロジェクトが途中で中断になったので、結局大事にはなりませんでしたけど。

 

実は進捗の遅れとかって、品質を下げることで割とカモフラージュできるんですね。品質は可視化の仕組みがないと目には見えないですから。人間心理として、そういう楽な見掛け倒しの対策に逃げ込みやすいという教訓を学びましたね。

 

にしても、なぜ人は問題を隠してしまうのでしょうか。その理由をちょっと考えてみました。

 

①自分の評価を下げたくないから

確かに問題を発生させるとその人が無能なせいだと考えられる可能性はあるでしょう。でも、ことのほかプロジェクト型の業務について、問題が発生したときに問題を発生させた人のせいだと考える方がよほど無能じゃないっすかね。

 

毎日同じことを続けていて、決まったやり方が具体的に決まっているルーティンワークならわかりますけど、先に述べた通り、プロジェクトは新しいことの連続だし、状況も日々変わるんだから、問題が発生しない方がよっぽど不自然でしょ。

 

それでも「問題があります」というと評価が下がる可能性はやっぱり残るんですね。例えば、社員の9割が隠蔽体質人間で構成されていれば、相対的に見て「こいつに問題があるのでは?」と思われがちです。なので、評価が下がるのを恐れて言わない、というのもまぁ理由としては成立してるんだろうな、という印象です。

 

ただし、私が働いてきた肌感覚として、評価云々を理由に問題を隠す人は、かなり少数派です。むしろ多いのは以下に述べる二つの理由で隠蔽する人たちです。

 

②被管理稼動が増えるから

仮に、あなたが管理職だったとして、あなたの部下のAさんは一言指示を出せば、品質の高い成果物を納期までにきっちり仕上げる人。もう一方のBさんは一言を指示を出しただけでは、全く的外れな成果物しかできない挙句、納期も少しオーバーしてしまう人だったとしましょう。

 

この場合、どちらをよりウォッチするか。当然Bさんですね。上司として、Bさんの問題のフォローをしていかなければならないので、そのためにより細かく進捗を管理したり、品質をチェックする必要性が増えます。要するに上司の管理稼動が増加するわけです。

 

しかし、これはあくまで上司目線に閉じた話。じゃあ全体で考えるとどうなるか。上司がBさんのフォローに入るのだから、Bさんの稼働は減るのでは?と思いきや大間違いで、Bさんの視点で考えてみても、実は被管理稼動が増加します。

 

Bさんは被管理者として、進捗、品質が上司に伝わるように細かくデータを残す、それらのデータから資料をまとめる、資料を使って実際に上司に報告する、など、本来であれば必要のなかったはずの作業が増加するんです。

 

この手の仕事ってほんとくだらないですよね。私も細工は流々仕上げをご覧じろタイプで管理されるが本当に嫌なため、よほど大した問題ではない限りは「問題ないです」と言ってしまいます笑。チームで働く者としてはあまり推奨できないやり方です。

 

ただ、この理由も実は決定打ではありません。本当の理由はたぶん次のものだと考えてます。

 

③自分の裁量で何とかできると思っているから

私もこれなんですよね。確かに今遅れてるけど、最終的に帳尻を合わすプランが自分の中にある。メンバレベルでは実現性も高そうだと。でも、それをちゃんと論理的に上司たちに説明して納得させることに稼動を使ってるとちょっとやばいな、みたいなことが結構頻繁にあるんです。②の理由との複合するケースです。

 

80%どうにもならないなら、「問題があります。」とエスカレーションはするでしょう。でも、プロジェクトとしての及第点は何とかとれるだろうという自信があると、問題として定義されないんです。

 

これが「自信」であればいいですけど、「過信」だった場合は炎上が待ち構えています。(聞いた話では、みんな自分の裁量で何とかなると過信している人がプロジェクトに限って炎上する傾向があるらしいです。)なかなか難しいところですが、ダメな時はダメだと冷静に判断できる姿勢が求められるようです。

 

どうでしょうね。同業者の方なら共感はしていただけるのでは、と思ってますが。でも私が言いたいのはこの先で、①〜③の原因を深堀すると、全ての元凶は上司すなわち管理職、PMであるということです。

 

①の「自分の評価を下げたくないから」と部下が思うのは、繰り返しになりますが問題を起こさない部下を評価してしまう上司の姿勢が無能過ぎです。そもそも問題がないのなら管理職なんていらないんで、人件費下げてください、って感じです。

 

②の「被管理稼働が増えるから」と部下が思うのは、被管理対象となったとして、上司が何の対策もしないからです。管理職の方の中に、部下にアドバイスをするのが仕事だと思っている人が多いですけど、私たち部下が求めているのは基本的にアクションですので。自分たちにできなくて、上司にしかできないことは要員を増やすことぐらいだと私は思っています。

 

③の「自分の裁量で何とかできると思っているから」というのも、結局のところ、上司という存在がその程度の人間だと見くびられている証です。はっきり言って、見くびってます。

 

また、こういう現状を踏まえ、「問題をちゃんと報告するように」とか催促してくる人もいます。もちろん何もしないよりははるかにマシですが、当の部下は自分で何とかできると思っているので報告のしようがありません。

 

部下任せになるのではなく、私たちのレイヤーからは見えない問題を発見するぐらいの洞察力と、迅速に対策を打つ行動力を見せて欲しいものです。そういう上司の印象が少しでも部下の中にあれば、「実は問題があるんですが・・・」と言いやすいものです。

 

ちょっと自分の隠蔽体質度を振り返ってみてはどうでしょうか。

ノート何冊使ってる?

私が会社で使っているノートは今ので23冊目である。普通の一般のB5サイズ位のノートだ。私が入社して2年半ぐらいであることを考慮すると、だいたい一月に一冊は使っている計算になる。

 

「え、なんでそんないっぱいノート使っているの?」と驚かれることの方が多いので、たぶんこの消費量は一般的ではないのだろう。確かに周りの先輩たちを見ても、私ほど頻繁にノートが新しくなったと感じる人はいない。

 

加えて、私のノートは非常に汚い。たぶん私以外の人間には読めないぐらいの字で書いているし、構成自体もよく分からないものになっている。あんまり他人のノートを見る機会は少ないけれど、私のものよりはまとまっていることが多い。

 

でも、私は自分のノートの使い方が間違っている、とは思っていない。ただ、コンピュータに喩えるならば、一般の人は主にHDDとしてノートを使っているのに対し、私は主にメモリとしてノートを使っている。それだけのことである。

 

そもそも何のためにノート書いているのか。これを明確にした方がいい。たぶん、学校でちゃんと勉強してきた人は、先生に言われた通り、黒板の内容をノートに書き写すのが当たり前になり過ぎて、その意味を考えてこなかった人達だ。

 

先生が黒板に書いた内容を書き写す、というのはHDD的にノートを活用する方法である。あとで復習できるように、時間が経った時に教わった内容を見直せるように、情報として残しておくためのノート、というわけである。だから当然、綺麗な字で綺麗な構成で書いておくことが望ましい。

 

しかし、例えば、教科書に全く同じことが書いているならどうだろう。ノートに書き留めておく必要は全くない、ということになる。だからこの場合、ノートをとる必要はないのである。ちなみに私は高校生の途中でこのことに気付いてからは、一切ノートをとっていない。当然、学力にも何の影響も及ぼさなかった。

 

ただ、私は大学受験の時に膨大なコピー用紙を使って勉強をした。定かではないが、5000枚以上は使っている、と思う。演習問題を解いたり、単語を覚えるために一時的に使っていた。その時の自分が考えたり理解したりするためでしかないから、使い終えたらゴミ箱行きである。これがメモリ的にノートを使う、ということだ。

 

社会人になってからのノートの使い方も受験期のコピー用紙と同じである。情報を残すためには使っていないし、残すための情報があったら、電子ファイルとして残しておく。そもそもノートを家で管理してまた見直す、なんて今の時代にやってられるかよ、って感じだ。

 

ちなみに林修先生曰く、

いわゆる悪筆で、もじょもじょと謎の線を書きつける天才タイプは、溢れるアイデアに手や言葉が追いついていかない傾向がある。そもそもノート自体が、のちに人がみるための記録ではなく紙上で書きながらリアルタイムに思考するためのツール。つまり勉強は他人のためではなく、あくまでも自分のため。考えること自体が楽しいという脳の持ち主で、その延長上で勉強ができてしまう。

だそうだ。

 

ノートを綺麗に書くのはやめて、殴り書きでも沢山書いてみると、それだけ思考は活発になるんじゃないだろうか。

休日に外出するなんてもったいない

私は休日のほとんどの時間は家で過ごしている。もちろん、たまには会社のイベントに参加したり、彼女とデートしたりもするけれど、基本的には家にいる。いわゆるインドア派である。

 

休日に外出しないなんてもったいない!と考えている人もたくさんいるだろうけど、私はむしろ休日に外出する方が明らかにもったいないと思う。それはせっかくの休みだからゆっくりくつろいだ方がいいとかそんなことではない。「家賃にいくら払ってるの?」ってことだ。

 

私は今家賃9万円ぐらいのところに住んでいる。はっきり言って馬鹿にならない値段だ。しかし、東京で都心からそれほど離れていない場所に住むなら一人暮らしでもこのくらいにはなる。一ヶ月30日として、1日3000円はかかる計算だ。

 

でも、よくよく考えてみると、平日は仕事だから家にいる時間なんて1日の半分ぐらいである。忙しい人なら寝床としてしか家を使っていないかもしれない。こんな人が休日まで外に出かけてしまったとしたら。毎月半分ぐらいは使ってもいない家のために数万円も出費していることになるのだ。

 

また、家をほとんど使っていないにもかかわらず、ほんの数日で家は汚れていく。掃除をしたりと管理の費用、時間が別途発生するのである。どうせなら家を活用した方がいいだろう。と私は思う。

 

もちろん、私みたいに大半を家で過ごす人にとってはそれほど損をしている気分にはならないかもしれない。でもほとんど家を使っていない人にとってはどう考えても損である。

 

シェアハウスとかが流行ってきているのは、確実にこういった家賃の無駄があったからで、家賃が無駄になっていることを認識している人がいるからである。そして、そう遠くない未来には「家を持たない人」が一定数現れてくる、と私はひそかに思っている。

 

考えてもみてほしい。人が家を持つのはもちろん「住む」ためであるが、もう少し細分化してみると、「寝る」ため、「食べる」ため、「テレビを見る」ため、「洗濯する」ため、などいくつかの機能に分けることができる。

 

で、本質的に現代人が使っている家の機能は実はたった二つしかない。それは「寝る場所」としての家、「所有物の貯蔵庫」としての家である。家で食事をしたり、テレビを見る人はたくさんいるだろうけれど、それらが理由で家に住んでいるわけではない。私たちはたった二つの機能のために家を買ったり借りたりしているのである。

 

昔はきっと家の役割がもっと沢山あった。家を構えないとできないことが沢山あったのだ。しかし、現代は家の機能のほとんどがサービスとしてアウトソースされている。コインランドリーに行けば洗濯ができるし、銭湯で体も洗える。ネットカフェでインターネットにも接続できるし、スマホでテレビも見れる。夜になればビジネスホテルで寝ればいい。

 

ただ、問題もある。一つは、就寝コストが未だに割高なことだ。先ほど、1日寝るだけで3000円とあったが、1日寝るだけで3000円ならビジネスホテルに泊まるよりも確実に安い。ネットカフェならやや価格は下がるが、確実に睡眠の質は下がってしまう。

 

だから、「寝る」機能のためだけに家を持つとしても今はそれが合理的なのである。その理由は、ほとんどのホテルが「寝る」以外の機能を沢山搭載しているラグジュアリーな形態をとっているからだ。今後は「一泊790円※ただし、朝食なし、風呂なし、自販機なし、漫画なし、テレビなし」みたいなサービスが登場することを期待している。

 

もう一つの理由は、貯蔵庫としての役割を果たすサービスの実現は極めて難しいことだ。

 

今でも、レンタル倉庫というサービスは存在する。月額2000ぐらいから利用できるので、価格的には申し分なさそうである。でも、ここに家のものを全て預けられるかというと、そうはいかない。そんなことをしたら、毎日そのレンタル倉庫まで通ってから出かなければならなくなってしまうからだ。

 

これは当然のことで、家で物を保管することの意味は「いつでもすぐ使えるように」するためである。家が住む場所である前提があるから、家を貯蔵庫化することに価値が生まれるのである。

 

逆に言うと、いつでもすぐ使えるのであれば、家で保管する必要はない、ということでもある。一番のいい例はお金だ。今のご時世に持っているお金を全て家で保管している人がいるだろうか。いない。なぜなら、お金はもうすでにいつでもすぐ使えるものになっているからである。

 

お金みたいに、その媒体自体に価値の本質があるわけではないものについては、こういった移管が発生しやすいが、物自体に価値の本質があるものについてはかなり難易度が上がってしまう。

 

例えば、洋服は家にないと困る。いつでも使えるといい、というよりも家から出る時に必ず必要だ。とはいえ、物流システムが今よりもっと進化して、今まさにいるところに洋服を30分ぐらいで届けてくれるようになれば、最悪なんとかなるかも。洋服を電子的に管理するアプリは既にあるし、こういう発想が出てきてもおかしくない気がする。

 

まぁ私は「パーソナルスペース」としての家に一番価値を感じているので、家に住まないという選択は考えてないですけどね。

ワーカホリック

前回の記事は、実は音声入力で書いた。HeySiri、OKGoogleなど、近年の音声入力の技術は目覚しいものがあると思う。シンプルに音声聞き取りの精度がかなり上がっている点が凄いと思う。

 

また、正しく音を認識するだけではなく、文脈から適切な単語を予測変換するし、文節の区切りも概ね問題はない。ここまでの精度になっていると、文字で入力するより音声で入力してしまった方が圧倒的に早く文章を作り上げることができる。

 

ただ、もちろん音声入力も完璧ではない。複数の単語を入力して検索、みたいな時にはもうほとんど何の障害もなく利用することはできるが、やはり長文を書く場合にはまだまだ音声入力では不十分に感じる点がある。

 

それは句読点である。前回のブログは読点(、)が一切入っておらず、非常に読みづらいものになっている。ちなみに句点(。)は入っているが、あれは後から適切な箇所にキーボードで入力しただけだ。リズムを工夫して発声しても、句読点までは予測しきれないらしい。今後改善を願うばかりである。

 

さて。話は変わって、過労死について。私もどっちかというと、過労死する可能性のある側の人種だと思う。社会人になってから意外と自分がワーカホリックであることに薄々気づいてきた。

 

真面目で責任感の強い人間が陥りやすいと言われるが、これは多分正しいのだろう。私は自分のことをあんまり真面目だとは思っていなかったが、社会にいる人の多くは不真面目で無責任である。

 

一番厄介なのが、「自分が何とかしなきゃ」みたいな考えのない人に限って、やたらと人の心配をしたり、助言を与えたりする。いや、あんたたちが全く頼りにならないからこっちが多少無理して仕事抱えるしかないんですよ、と言ってやりたいところである。

 

でもそうやって抱えこむと消耗する。おそらく、うつ病とかになってしまう人は全部頑張りすぎているんだろうと察する。

 

ただ、私は働き過ぎでうつ病とかにはならない気がする。全部をちゃんとやっているわけではないし。自分がちゃんとやりたいことだけちゃんとやっている、という感じだ。自分がちゃんとやらないと組織に影響がでかい、とかは一切気にしていない。影響がでかいなら尚更私一人に任せる方に問題があるし、何かあっても自分に責任がとれないことはわかっているので。

 

もちろん、抱える仕事の量は多くなってしまっているし、労働時間も相変わらず長いけれど、別にそこにあんまり問題意識はない。もちろん早く帰れるに越したことはないし、作業を効率的に終わらせるようには努める。でも、どうせ早く帰ってもやることはないし、うちは残業代もだいたい出るので、プラマイゼロだ。

 

そもそも仕事というのはすべて目的があるから、よほど嫌いな作業でない限り、あるいはよほど目的に共感できない限り、それなりにやっていて面白いものだ。こういう思考回路が、やっぱりワーカホリックなのだろう。

 

あくまで今ぐらいの労働量であれば耐えられる気がするが、今の2倍ぐらいの残業時間になったら会社辞めるだろうけど。

他人に優しく

電通の新入社員が亡くなったニュースが話題になってますね 。 何でも過去にも同じようなニュースがあったとかなかったとか。

こういう事件が起こるといつも残業時間を規制する方向に事は動いたりするんだけどそれって本当に根本解決になってるのかね。

まあ結論から言うと残業時間を規制したところで労働時間は減らない。 確かに残業時間は減っているように見えているけれどそれはデータとしてそう見えているだけであって実際はそうではないと僕は思う。

ただ正直言って僕の会社だって労働時間は決して少ないほうじゃないし同期に話を聞けば結局サービス残業でまかなっているという話もよく聞く。

その理由を考えたことがあるだろうか。

仕事量が多いからである。 もちろんその背景には日本人が仕事のやり方が下手くそで世界の中でも生産性が低いから、という見方はできるかもしれない。

けれど本質的には違う。 日本に伝わるお客様は神様という思想のせいである。 僕たちは消費者として振る舞うとき、労働者に対して過酷な要求を突きつける。そしてそれらに応えようとしてきたのが日本の労働者である。

だからこそ日本は世界に比べて品質の高いサービスや製品を提供することができている。その結果消費者としての私たちが裕福な生活を送ることができているのは事実だ。

しかし私達は純粋な消費者ではない。すなわち消費者であって労働者でもある。 そして消費者である私たちが豊かになる一方で労働者としての私たちはどんどん過酷になっているのだ。

その結果が過労死うつ病そして自殺である。 確かに局所的に見れば電通の働き方やその制度に問題があったかのように見える。

しかし本当に問題なのは電通のその先にあるお客様、クライアントの厳しい要求、さらに言えばそのクライアントの先にいる消費者、コンシューマーの厳しい要求であったに違いない。

だから僕は過労死をなくすためにはまず他人に厳しい社会を脱する必要があると思うんです。

KPT法でプロジェクトを振り返ってみる

リリースは問題なく完了しました。これをもって私の人生初プロジェクトも完了。来週からは休む間もなく基盤系エンジニアにシフトチェンジします。気持ちを切り替えていかないといけませんね。

 

新しい環境に気持ちを切り替えて臨むのも大切なことですが、プロジェクトを終えたら大抵の場合はそのプロジェクトについて振り返ることが推奨されています。たぶん、うちの会社に限らず、プロジェクト型の仕事をしている組織はやるんじゃないでしょうかね。その中でも有名なフレームワークKPT法と呼ばれるものです。

 

KPT法とは、Keep・Problem・Tryの頭文字を取ったものです。プロジェクトを振り返って、良かったこと・今後も続けていきたいこと(Keep)、悪かったこと・問題点や反省点(Problem)、それらを踏まえ次にやっていきたいこと(Try)に分類し、今後に繋げていくための方法論です。一つの節目となったいい機会なので、個人的に振り返ってみます。なんか問題思い浮かばないですが・・・。

 

■Keep

・設計書を読み込んだ。

・便利ツールを何個か作った。

・お客さん先で説明、質疑応答をした。

・担当システムを納得いくまで操作した。

進捗管理ツールを活用した。

・ToDoリストを活用した。

・問題が起こっても範囲を限定化し、暫定対処により対応できた。

ソースコードを修正した。

・テストケース設計について勉強した。

・試験機器のエラー対処法を理解した。

・未経験の業務を他人から情報を集めて一人で遂行した。

 

■Problem

・他人への仕事依頼が遅かった。また、依頼の仕方が曖昧なことが多かった。

・設計の際に、曖昧な仕様、設計漏れ、両システム間の整合性エラー、既存仕様の踏襲誤りが目立った。

・試験項目作成時に観点漏れがあった。

・労働時間が長かった。

ソースコードの品質を担保できていなかった。解読できなかった。

・試験シナリオの効率化が不十分だった。

・仕様に対するこだわりが弱かった。

・朝会があまり機能していなかった。

・スケジュールのリスケが多かった。

・インフラ周りの業務に対するチームの関心が薄かった。

・一人で仕事を抱え込みすぎた。

 

■Try

・わからないことがあったらまず設計書を読む。

・人手をかける必要のない作業は既存のツールを適用・もしくは自分で作成する。

・エラーと対処法を蓄積するための仕組みを用意しておく。

・チームの関心が薄い作業に対する重要性及びリスクを説明できるようになる。

・他者へ明確な指示(目的→成果物イメージ→方法・条件など)を出す。と同時に他者の結果の正当性チェック観点を検討しておく。

・仕事の依頼のGoサインは素早く、締め切りを明確に。

・既存を安易に踏襲しない。既存と類似の部分、既存と異なる部分を棲みわけた上で参考にする、という姿勢を貫く。

・業務の目的・業務フローを理解した上で仕様を定義する。どれがいいかを多角的に表して選ぶ。

・打ち合わせの目的を理解し、不毛だと感じたら、頻度を減らすか、無くすか相談してみる。(多分無理だけど。)

・試験項目数は品質水準の数値で満足しない。出せるだけ出して、後から削るか検討する。

・小さい作業もスケジュール化・タスク化しておく。

・Rv時にはチェック観点を作っておく。必要な資料もまとめておく。

・協働者任せにせず、わからないことを掘り下げて聞いていく。

 

まだまだ他にもありますけど、こんなところですかね。まぁ次はプロジェクトの特性とかも変わりますし(そもそも維持だし)、どこまで反省が役に立つかはわからないですが、こういうちょっと抽象化された教訓って案外いろんなとこで役に立つもんです。ダルいですけど、やっといて損はないと思います。

 

同業者の方はチームとしておそらく実施していると思いますが、チームでやるのは当然として、個人だけでやってみると本音が出せるのでオススメです。(チームでやると、ん!?それ本当にKeepなのか!?みたいな発言も出たりするので。)

 

ちなみに、KPT法をやっていて思ったんですが、何が良くて何が悪かったのかを後から振り返れるような材料を残しておけるのが理想ですね。チームが良かったと思っていることが本当に良かったのか、チームが悪かったと思っていることが本当に悪かったのか、感覚だけに頼ってしまうと危険ですからね。

 

まぁ、とりあえずは振り返ってみる、ということが重要だと思ってやってみるといいでしょう。

燃え尽き症候群にどう対応するか

明日からリリース対応で地方へ出張することになった。念のため補足しておくと、「リリース」とは開発したシステムを市場へ初めて投入することを指す。つまりは、システム開発プロジェクトの終焉、というわけだ。同時に、私たちの仕事が全て完了することを意味する。

 

考えてみれば、社会人になってからは一度も足を止めたことはなかった。こなしてもこなしても様々な角度から生み出される仕事、降ってくる仕事。目の前の仕事を捌くのに必死だった。もちろん、休みはキチンと取れるのだが、私は抱えているタスクがあればついつい休みの日にも仕事の段取りなどを考えてしまうタイプだ。

 

抱えているタスクがたくさんある、という状態はあまり健全だとは思っていなかった。なぜ休みの日にまで仕事のことを考えなければ、と思った時もあった。しかし、いざ抱えているタスクが全て無くなってしまうと、結構退屈で、無気力状態になる。嫌なことからやっと解放された!という感覚は驚くほどに少ない。

 

俗に言う、燃え尽き症候群という奴だ。私は人生の節目節目で何かを頑張ってきた後は必ずこう言った精神状態に陥る。バスケを引退した時もそうだし、最初のバイトを辞めた時もそうだった。

 

大学受験時なんかは特に顕著で、大学合格が既に決まっているのに、無性に勉強したくなる時があった。まだ自分の中での自分が勉強した結果に納得がいっていなかったのである。とは言っても、目的がないのだから勉強する意味もなく、結局何も手につかなかった。たぶん私は何かにハマると、誰かに「ストップ!」と言ってもらえなければ、ひたすら完璧を目指し続けてしまうタイプなのだろう。

 

燃え尽き症候群というと、なんだかたいそうな病名っぽいけれど、私にしてみれば、一生懸命打ち込んできたことに打ち込めなくなったのだから、喪失感を抱くのは当たり前じゃないか?と思っている。慣れ親しんだ親友と絶縁して落ち込まない奴なんていないはずだ。逆に言えば、燃え尽きるということはそれだけ精一杯やったことの証でもある。

 

ただ、いつまでも燃え尽きているわけにはいかないのが人生である。特に仕事は会社がある限り会社員である限り永遠に続いていく。学生の頃は受験終わったから春休み、とか、期末テスト終わったから夏休み、とか、何かやり遂げた後のリフレッシュ期間みたいなものがあった。

 

しかし、社会人にはこの、「ちょっと休憩」、という概念が存在しないのだ。私も今週のリリースが終われば来週からは別のチームで、全くやったことのない仕事をやらなければならない。燃え尽きている暇なんてないのである。

 

では、急激に下がったモチベーションをどうやってあげればいいのか。

 

私の経験から言うと、低いモチベーションのまま、燃え尽きた状態のまま、何かに取り組め、という回答になる。もちろん、世間にはモチベーションを上げるための方法論がたくさん出回っているし、それらを試してみるのは一つの方法としては悪くないかもしれない。

 

ただ、個人的にはモチベーションなんてものは後からしかついてこないものだと考えている。そもそも、モチベーションなんか無くたって何かに取り組むことはできるのだ。「モチベーションがないので何もできません」、と全てモチベーションのせいにする人は、モチベーションがあれば全く苦しまずに何かに取り組めるという幻想を抱いているのである。はっきり言って、生きていて苦痛が伴わないことなどない。

 

やる気のない中、新しい情報を得たり、新しいことに打ち込み出すのは確かにしんどい。成長率もそれほど高くはないだろう。しかし少しずつ着実に今までの自分の中に変化を生み出すきっかけとして残っていく。理解度が高くなると、人間はその事象に少なからずハマっていくものである。何かにハマっていくと、それがモチベーションにも繋がるのだ。

 

モチベーションなんてなくても行動はできる。

仕事場における教育とは

本気で社員の教育を考えるのであれば、”どういう人材に教育していきたいのか”を明確に定義した上で、その人材像になる上で大きなプラスにならない仕事は与えないことだ。私はそう思う。

 

例えば、雑用という仕事がある。誰もやりたがらないが、誰かがやらなくてはならない、そして誰にでもできる簡単な仕事であるがゆえに大した価値はない仕事だ。主に新人のうちは担当することになるだろう。

 

ただ、雑用の価値を説いてくる会社はおそらく非常に多い。おそらく、今の上の世代の人達も自分たちの若いころに雑用をやらされた経験から、雑用の重要さを語っているんじゃないか。

 

確かに、雑用をするときにも自分の頭で考えて工夫を凝らすことで、作業に意味を持たせる余地は十分にあるだろう。また、雑用のこなし方一つで評価が変わってきたり、信頼を得ることができたり、より責任ある仕事を任せてもらえるようになったりする。そういうサイクルが会社の中で回っていることは確かだ。こういったプロセスが当たり前に存在しているため、「どんな経験もいずれは役に立つ」という考え方が定着している。

 

しかし、肝心なのは”どの程度役に立っているか”、すなわち費用対効果の観点である。将来の人材像が決まっていて、3年間雑用ばかりをやってきた人間と3年間将来の人材像へと向かうための業務に取り組んで来た奴のどちらが成長しているか。考えるだけバカバカしいとは思わないだろうか。

 

はっきり言って別の会社にアウトソーシングしてしまった方がいい。コスト面で検討した結果、派遣を雇うと高く付くから、自社内でやりくりする、という判断をしてしまう会社は多いが、それは短期的な効果しか見ていない。

 

付加価値の少ない仕事をアウトソーシングする(BPO)のは今では当たり前の考え方になっているし、そもそも長期的にみれば、付加価値の高い仕事をさせること自体は売上の増大や社員の教育にもつながってくるはずだ。

 

とは言え、初めから新人に責任のある仕事を任せるのはちょっと、、、と考えるのが普通だろう。でも、それははっきり言って上司や先輩の能力不足、稼働不足の側面もあるんじゃないだろうか。仕事を任せたとしても、うまくリスクをマネジメントした上でフォローする能力があれば、大きな失敗は防ぐことができる。

 

外部から高いお金を払って講師を呼んでくるぐらいなら、初めから新人に責任のある仕事を任せて、フォローに回る先輩や上司の負担を減らすことにコストをかけるべきだ。

 

余談だが、DeNAには研修制度がないらしい。プロフェッショナル仕事の流儀でDeNAの社長が、「社員を育てるのは研修制度ではなく、良質な仕事だと考えています」とその理由を述べていた。この言葉には非常に共感できたのを覚えている。

 

「教育する」というと、さも他者を直接的に成長させるようなイメージを彷彿とさせるが、せいぜい出来るのは「本人が学習できるための環境を整えてあげること」でしかない。

 

これは別に会社でも学校でも同じ話である。ただ単に良い授業をたくさん聞いていたって、偏差値の高い生徒は生まれない。良質な問題と、その問題を解くために必要となる材料をいかに上手く提供できるかがポイントなのである。

 

本当に社員を教育させたいのであれば、まずは良い仕事を沢山与えることだ。私はそう思う。