仕事ができるとはどういうことか | One of 泡沫書評ブログ

One of 泡沫書評ブログ

世の中にいったいいくつの書評ブログがあるのでしょうか。
すでに多くの方が書いているにもかかわらず、なぜ書評を続けるのか。
それは、クダラナイ内容でも、自分の言葉で書くことに意味があると思うからです。

「仕事ができるとはどういうことか?」

よくある泡沫系ビジネス書のタイトルにありそうな文言だが、実際、「仕事ができる」というのは一体どういうことなのであろうか。

日常、業務を遂行していて、

「ああこの人は仕事ができるな」
「できると思ったけど意外に詰めが甘いな」
「この人はできないと思っていたけど、上司が変わったら人が変わったように仕事ができるようになったな」

というようなことはよくあるだろう。こういうことはおそらく無数にあって、それを体系化、言語化、あるいは抽象化したものがいわゆる「ビジネス書」を始めとする広義のライフハックになるのであろう。そのため、こうした類の本や記事は、表現こそ違えどだいたいどれも似たような話になってしまうのではないか。(何冊も買ったわたしが言うのだから間違いないw) 

わたしは受託開発を生業とする低レベル社畜のひとりであるが、一応、業界の末端に属するものとして「仕事ができるということは何か?」というようなことを、いつも考えてながら仕事している。職種的に「SE業界」などとひとくくりにされる我が愛すべき業界は、個別の業務を見ていくとあまりにも幅が広すぎて、総体として「コンピュータを扱っているから」というような雑な整理だと、とても一つの枠に収まるものではない。職種(アプリとかインフラ)だけでなく、顧客の業界や業種によっても何か微妙な感覚が違うし、コミットするフェーズやプロジェクトの規模によっても様相が大きく異なる。「SEだからこういうことをすればよい」というのは、例えば「データベースの管理をマスターせよ」「若いうちに資格を取っておけ」というようなことはまあ的外れでないとしても、全体としてざっくり「こういうふうにしたらいい」というようなことは、抽象的にすぎるきらいがあり、結局「意識が高くなる」だけであまり意味がないのではないか、と思っている。どこの業界でもそうだろうが…。

また、こういう話になると、どうしても元マイクロソフトのスーパーエンジニアであるとか、Web業界のスーパープログラマであるとか、そういう一部のチートな人たちが受託業界をdisりはじめるので、中の人にとってあまり生産的ではない。(主張はもっともなのだが、世の中の数万、数十万人もいるエンジニアが皆が皆同じようなレベルにあるわけがないだろう、ということ。別に海外のエンジニアが特段レベル高いわけではなくて、トップクラスのエンジニアは日本も含めて各国どこも似たようなものではないか。シリコンバレーだけは例外だとしても、他の国も似たようなものじゃないかと推測している。)

話が逸れたが、だからわたしは、具体的にこの業界で「仕事ができる」ためには、もっと個別の「ケーススタディ」を教えたほうがよいのではないかと考えている。後輩や新人などを育成したり、あるいは他部署から人が異動してきた、あるいはビジネスパートナと一緒に初めて仕事をするとか、そういう場面で、どうやってかれらにスキルトランスファーをすればよいだろうか? あるいは、自分がそういう立場になったとき、どういうアプローチをとれば、上司や顧客から「こいつは仕事ができそうだ」と思って信用してもらえるだろうか?

例えば、簡単なケースを考えてみる。

「わたし」の所属する組織は、業界では比較的名が通りはじめたグループウェア製品「A」を専門に取り扱う部署だとしよう。Aは米国の会社で製造されており、日本の法人が最近できたばかりだ。Aの国内シェアはまだまだだが、まったく売れていないこともない。まずまずの市場を抑えており、最近は引き合いも増えてきたように感じる。「わたし」の所属組織は、Aの販社として製品(ライセンス)の販売と保守サポートが主たる収益源となっており、たまにSIもやる、というビジネスをやっている。もちろんAだけでは売り上げが足りないから、場合によっては他のグループウェア製品も担ぐこともあるが、基本的な部門の方向としてはAを前面に売っていこうという戦略である。

さてそこで、「わたし」は製品の「保守サポート」部門に配属されたと考えてみよう。「わたし」にとって、仕事ができる、とはどういうことだろうか?日本の会社では、こういう場面であまりジョブディスクリプションが明確にされないことが多い。あまり詳しくは知らないが、所謂「外資系」企業も、日本法人の設立が古いところなどはわりと「現地化」してしまって、数字以外のところは殆ど何も指示されないことが多いのではないだろうか。この場合、「わたし」が何をすべきか、上司から達成基準を明確に示されればよいが、今回はそれがないものとする。つまり、部署に配属され、「君は今日からサポートをやってくれ。詳細はB君に指示を仰ぐように」と言われるだけで、他に何も情報がないというシーンを考えてみたい。

さて、「わたし」はどうすればよいだろうか?



…などと意味深な問いかけをしたが、もちろんこんなものに模範解答などあるわけがない。上司から具体的なことが何も示されていないのだから、特に達成することなどない、という意見もあるかもしれない。サポートの業務が何なのかわからないから、やりようがない、という人もいるだろう。いやいや、わからないのならB君に質問して聞けばいい、という人もいるかもしれない。これだけでは前提条件がわからないからやれない、という意見もあるかもしれない。色々なやり方があるだろう。

ただ、こういうときに、「こうしよう」とか「こうしたらうまくいきそうだ」というイメージが複数あり、かつ、そこにいたるまでの細かい質問に答えられる人は、所謂「仕事ができる」確率が高いのではないだろうか。

「こうしよう」というイメージは、自分だったら業務をこう回す、という一連のワークフローが見えているということだ。そこには当然、自分ひとりのテクニカルな部分だけでなく、組織の制約条件を考慮した「現実的な」方法があるということだし、必要に応じてほかの人や他部署、ほかのパートナを巻き込む力も含まれるだろう。また、細かいレベルでの質問に答えられるというのは、イメージしたワークフローが詳細なTODOレベルに落とし込めているということである。いざとなれば、常に自分が手を動かしてこうする、というイメージを持っているというのは、迫力があるものだ。さらに、そこからサポートの目的、収益モデル、必要な技術くらいを基本とし、さらにそこから、業界のシェア、他社の動向、自社のリソース状況などなど、ひとつの幹から枝分かれして色々な切り口で分析し、行動に落とし込めれば文句なしだろう。

ちなみに、わたしが「わたし」であったら、おそらくこうするであろう:

まず、保守サポートという業務の目的を確認する。問合せから問題クローズまでのリードタイムを短くすることが目的なのか、あるいは既存顧客からの満足度を最大化すればよいのか、このあたりを確認するだろう。大雑把に目的を確認するのだ。場合によっては、サポートの効率化をするよりも、メンバの育成を優先したほうがいいのかもしれないし、あるいはチームリーダは、この経験を通してわたしに製品のアーキテクチャを知ってほしいと考えているのかもしれない。調査に対してどのくらいのコスト(時間)をかけてよいのかも重要な変数である。

次に、必要な技術についてざっと確認するだろう。この製品のアーキテクチャを調べ、必要なマニュアルの入手方法や使用されている典型的な技術をおさらいする。必要に応じて、有償トレーニングの受講も検討し、上司に相談するかもしれない。色々と自由に試すことのできる環境がないなら、仮想サーバ等を準備できないかどうか検討することも考えるだろう。また、過去の問合せ履歴の視認性を確認したり、メーリングリストの有無、顧客との接点となる方法(メール、電話)等についても一応確認すると思う。これまでまったく使ったことがなければ、とりあえず適当なPCを準備し、インストールして色々といじるだろう。

また、現在のリソースの状況もみるだろう。サポートのメンバは何人くらいいて、どのくらいのスキルがあるのか。自分がその中でどういうポジションを期待されているのかも考えるだろう。技術レベルの底上げを期待されているのか、メンバ間のコミュニケーションコストを減らすことを期待されているのか、はたまたスペシャリストとして難しいインシデントを優先して捌くことを期待されているのか。もしくは、単に製品を覚える機会を与えられているだけなのかもしれない。

実際にインシデントをアサインされたらどうだろうか。まず、回答のルールはあるのか。自動回答でないなら、個別に担当宛にメールを返さなければならないが、このあたりはシステム化されないのか。なぜしていないのか。自分がするとしたら、どういう仕組みで自動化システムを作るだろうか。とりあえず手動でやるとしても、間違いがないように何らかの仕組み化をすべきだが、されているだろうか。等々、ひとつひとつのオペレーションにも自らの言葉で意味づけをし、現在の与えられた制約条件の中で、できること、間違いのないこと、効率のよいこと、改善できるところはないか、考えると思う。

当然、この先には、そもそもこのサポートビジネスを続けていくべきなのか、利益率はどうなのか、将来性はどうなのか、A社とのアライアンス状況は良好なのか、市場は拡大傾向にあるのか、などといった戦略面にも気を配っていく必要があるのかもしれないが、それはおそらくまた「次の話」であろう。しかしながら、こうしたことも当然、頭に入っていなければならない。

このように、頭に思い浮かぶことを書いていくと、あまりに多すぎてとても書ききれないが、こうしたことを一旦出しつくし、抽象化して捉えなおすとおそらく1ヶ月くらいでサポート業務で自分がやるべき業務フローが出来上がると思う。こういう態度が「仕事ができる」ということではないか、とわたしは考えている。もちろん、わたしはよかれと思ってやっているのだが、外から見たらどう見えるかはまた別なのだが…。

軽い気持ちで書き始めたが、やはり難しいものである。ビジネス書を一冊書ききるのもなかなか大変であろうw