連載
» 2012年09月12日 18時40分 公開

説明書を書く悩み解決相談室:仕事のできを左右する「4つの力」を考える

「仕事」のできを左右するものは何でしょうか。実はとある「4つの力」があるんですね。今回はこの4つの力を考えてみたいと思います。

[開米瑞浩,Business Media 誠]

 アイデアクラフト・開米瑞浩の「説明書を書く悩み解決相談室」第43回です! 今回は、ある新入社員A君が入社半年後に書いた、ちょっとしたリポートを見ていただきましょう。

課題テキスト

 先週でOJTが終了しましたが、納期内に成果物を仕上げるのは想像以上に大変で、進捗は一貫して遅れ気味でした。原因としては、成果物のイメージがよく分からないままで仕事を進めていたこと、他に優先度の高い割り込み作業が入ってきたこと、採用したツールにバグがあって余計な手間を取られたこと、プログラミングに関する自分の基礎知識が十分でなかったことなどがありました。自分の知識不足は自分で解決するべきですから、引き続き経験を積んで知識を深めていきたいと思います。また、仕事の依頼に対しては成果物のイメージをしっかりと確認し、効率よく納期通りに納められるよう努力したいと思います。


 OJTが終了したばかり、という文中の記述からも分かりますが、いかにもまだ仕事に慣れていない新人のリポートという印象ですね。私も20年以上前にこんなものを書いたような記憶がありますが、正直、当時書いたものは恥ずかしいので読み返したくありません。

 もちろん、本当は「読み返したくない」なんて言っていてはいけないのですがね。自分自身の成長を目指すならば、顔を真っ赤にしながらでも人に見せて意見をもらい、今後の糧とするべきなのでしょう。

 というわけで今回の課題テキストは20年前の自分のリポートを読むつもりで考えてみることにしましょう。

良い点その1:誤字脱字がなく、文法的に破綻がない

 まず、良い点の1つは「まともな日本語の文章になっていること」。要は誤字脱字がなく、文法的にも破綻していないということです。当たり前のようですが、このレベルで問題だらけの文章を日々目にして頭を抱えているマネジャーさんも実際のところ少なくありません。

良い点その2:ある程度構造化できている

 もう1つの良い点は、内容がある程度構造化できていることです。つまり「進捗遅れ」は「問題」ですし、「成果物イメージがなかった」というのは「原因」、「経験を積む」のは「解決策」というわけで、

  • 問題→原因→解決策(方針)

 という形で構造化できています。「問題がありました」→「原因を調べたらこうでした」→「だから今後はこうします」というのは自然なロジックの流れですから、ここは評価できるところです。

 でも、これで十分というわけにはいきません。少々物足りないところもあります。

仕事のできを左右する「4つの力」を考える

 私が今回の課題テキスト原文を読んだとき、1つ疑問に思ったことがありました。それは「A君は人の手を借りなかったのだろうか?」ということです。

 ここで少し一般論を言うと「仕事」をするにあたっては何らかの「成果」を目指して自分の「能力」を投入します。しかし「能力」だけで成果が出るかというとそうではなく、仕事を邪魔する「マイナス要因」と、逆に助けてくれる「プラス要因」がなにかしらあるのが普通ですね。

 そう考えると「仕事」のまわりにある4つの箱はそれぞれ「仕事のできを左右する4つの力」と考えることができます。つまり、

  1. 成果物のイメージがハッキリしていれば、いい仕事ができます。
  2. 自分の能力が高ければ、いい仕事ができます。
  3. 邪魔が入らなければ、いい仕事ができます。
  4. 必要な助力が得られれば、いい仕事ができます。

 ということです。そういう視点で見ると、A君のリポートは(1)〜(3)についてはそれぞれいずれも「問題があった」と書かれていますが、(4)については何も書かれていません。ここが少々物足りないところです。

 A君は入社半年の新入社員で「能力」がまだまだ足りないことは明らか。となると、先輩からの「助力」は重要なはずですが、それをうまく得られたのかどうか、という説明がありません。

 ちなみにこのときA君に課せられていた仕事は「全部自力でやることが重要だから、人にアドバイスを求めてはいけない」……といった種類のものではなく、逆に必要ならどんどん人の知恵を借りて進めることを期待していたのに、A君はそれをうまくできていなかったというのが実態でした。だからこそ、A君のリポートにその点の反省がないのは物足りないところだったのです。

「フレームワーク」があると、新たな気づきを得やすい

 A君のリポートはもともと「問題→原因→解決策」という形である程度構造化できていました。これもよくあるパターンですし、悪くはないのですが、A君が自分の仕事のすすめ方の弱点に気がつくための役には立たなかったようです。

 ちなみに「特定の種類の問題に対して適用可能な特定のパターンの考え方」のことをよく「フレームワーク」と言います。「問題→原因→解決策」というのも、図1の「4つの力」もフレームワークの一種です。

 フレームワークを使うメリットの1つは「自力では分からない、新たな気づきを得やすくなる」こと。A君がもし「仕事のできを左右する4つの力」のフレームワークを知っていて、原文に書いた同じ情報をそれに当てはめて考えていれば「人の知恵を借りるのが下手」だという自分の弱点に気がついたことでしょう。

 この連載で私は何度も「構造化しましょう」と書いていますが「構造化する」というのはつまりフレームワークを見つけることです。フレームワークというのは、コンサルタントがよく使うカタカナ語で、一見ありがたそうに見えるかもしれませんが、別に大したものではありません。もし「えらい先生が考えたものをありがたく勉強して覚えて使うのがフレームワークだ」という印象を持っていたら、その印象は今すぐスパッと捨ててください。

 フレームワークなんて、インテリくさい用語ですが要は「構造」を見つければいいんです。「ああ、こういうパターンだな」というよくあるパターンを見つければいいんです。まずは自分で考えてみましょう。その姿勢があってこそ「えらい先生に学ぶフレームワーク」も役に立ちます。ぜひ、やってみてください。


 当連載では、「分かりにくい説明書を改善したい」相談を歓迎しております。「改善案のヒントがほしい」例文があれば遠慮なく開米へお送りください(ask@ideacraft.jp)。今回のような連載での紹介は、許諾をいただいた場合のみ、必要に応じて内容を適宜編集したうえで行います。

 当記事についてのご意見ご感想ご質問等は「twitter:@kmic67」宛でも受け付けております。中には記事では書ききれない情報もあります。物足りなく思った時はぜひ「twitter:@kmic67」宛に質問を飛ばしてみてください。

筆者:開米瑞浩(かいまい みずひろ)

 IT技術者の業務経験を通して「読解力・図解力」スキルの再教育の必要性を認識し、2003年からその著述・教育業務を開始。2008年は、「専門知識を教える技術」をメインテーマにして研修・コンサルティングを実施中。近著に『ITの専門知識を素人に教える技』『図解 大人の「説明力!」』、『頭のいい「教え方」 すごいコツ!』


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ

マーケット解説

- PR -