2019/12/02

antiタスク分解論

世の社会人の方々はなぜ作業をタスク化するのでしょうか？

それは多人数による作業分担を可能にするためです。

そしてなによりも作業見積もりを出すためです。

何かを始めるとき、それがいつ終わるのか、目安が必要です。

作業分量がわからないと、どれだけのリソースをアサイン(大人語)すればいいか分かりません。

成果物の内容が大雑把になればなるほど完成までの時間を予測しにくくなります。

「面接予約システム」だけだといつ完成するか予測しづらいですが、「登録日時の降順でユーザー一覧を表示する」であればなんとなく実装時間を予測できます。

このように、作業単位が細ければ細かいほど作業にかかる時間の予測がしやすくなります。

自分が自宅から会社まで歩いてどれくらい時間がかかるのか？はパッとは分かりませんが、最寄り駅から次の駅までの距離であればなんとなく所要時間の目処が立ちます。

その距離と所要時間を足がかりにして、あとは会社までの各駅間の距離を調べれば、会社までのそれぞれの駅間の所要時間の目処も立つようになります。

自宅から会社まで5駅だとすると、まず「A駅〜B駅」「B駅〜C駅」「C駅〜D駅」「D駅〜E駅」の4つの工程に分けることができます。

その中で「A駅〜B駅」で所要時間の目処をつけて、残りの駅間の時間も算出していきます。

それらをすべて合計すれば全体のおおよそ時間を算出することができます。

全体の工程を細かく区切ることにより、見積もりの精度を上げて、さらにそれを合算することにより全体の見積もりも算出できるようになります。

これが社会人の方々がタスク化を行う理由です。

全体を分解すればするほど、自分たちの仕事がいつ終わるかの正確な目安を得ることができます。

ゴールの見えない道を進むより、辿り着くべきゴールが決まっている道を進む方が安心感があります。

社会活動においては予算やリソースも限られているわけですから、ある程度、これはどれくらいで完成するか？という目安がないと走り出せないわけです。

たしかアジャイルやスクラムもそのような課題設定のもとに生みだされた開発手法だったと思います。

作業単位をなるべく細かく短く区切って、そこから作業時間を算出していって、工程を進めるごとに作業精度を上げていって、徐々に完成までの見積もり精度を上げていきましょう。最初から全行程の正確な見積もりは無理ですよ。そもそも最初に作ろうとしたものと最終的に出来上がるものは別物になりますよ。──といった感じです。

タスク分解はとても便利でいいものですね。

みんながタスク化して仕事を進める理由が分かりましたね。

今日書きたいことはそれくらいです。

……いや違います。真逆のタイトルを付けていました。

タスク分解にもデメリットはあるのです。

今回はそのデメリットのお話です。

前置きがクソ長くなりました。

このブログ内では何回も書いている気がするのですが「言葉」は世にある全てを表しているわけではありません。

タスク化は言ってみれば「作業の言語化」でもあります。

ということは言語にならなかった情報はすべて作業タスクから抜け落ちてしまうのです。

少し雑な例えになりますが、αシステムを作るためにA機能とB機能とC機能にタスクを分解してそれぞれに担当者を付けたとしましょう。

αシステムの仕様には上記の3機能しかないものとします。

であれば、全然問題のないように思えます。

「A+B+C＝α」なんだから何も問題ないのでは？と思うことでしょう。

しかし実際の「システム」はそんなに単純なものではないのです。

たいていのシステムは「フレームワーク」と呼ばれる開発基盤上に機能を載せていく感じで作られます。

そのフレームワークを準備するのは誰なのか？初期設定はどうするのか？そもそも開発環境は誰が作るのか？

などなど、実際に仕事を始めようとすると結構な量の細々した、タスク化されていない作業が発生します。

作り始めたら作り始めたで、A機能とB機能と同じ処理が存在するので処理をモジュール化(共通化)したい、みたいなことも発生します。

そうなるとA機能担当者とB機能担当者との間でタスクに存在しないコミュニケーションコストがかかってしまいます。

また、A機能作成中にA`機能も必要なことが判明するかもしれません。

作り終わったら作り終わったで、それぞれの機能をまとめてαシステムとして統合する作業が発生します。

3つの機能が相互に連携していないと一つのシステムとは呼べません。

タスクの連携にまつわるコストの話はこちらをお読みください。

このように目に見える表面上の作業は各機能作成だけですが、実際の作業となると実に様々な「やらなければいけないこと」が発生します。

完成までにおける実際に必要なすべてのタスクを事前に全てタスク化するのは人類には不可能なレベルで難しいことです。

実務をやり始めて、初めて「やらなければいけないこと」が可視化されるのです。

実作業前のタスク分解化には限度があるのです。

それを踏まえた上で先ほど挙げたアジャイルやスクラムという開発手法が提案されたのです。

タスクに分解したとしても、それを合計したものが全体全てになると思ってはいけないのです。

人類には、実行する前の段階で実作業上で発生するすべての作業を正確に定義する、などということはできません。

さらにタスク化には「作業を効率化させる作業」や「品質を向上させる作業」が発生しにくいという欠点もあります。

先ほどの例だと「処理のモジュール化をしたい」となったとしても「そもそもタスクになってないし、やったら互いに余計な作業が発生するから、気づかなかったことにしよう」となる可能性が高くなります。

この例に限らず「こうすればもっと良くなる」と思ったとしても「でもそれはタスクとは関係ないし、やったら余計に時間かかるし、やった結果、後で問題になったらやだな」となってしまって結局やらなくなります。

リーダーなりマネージャーに提案すればいいじゃん、と思うかもしれませんが、大抵の人は自分に与えられたタスクでいっぱいいっぱいなのでこれ以上仕事は増やしたくないのです。

タスクの分解化は見積もりと作業分担化が可能になる多大なメリットがあります。

しかし、タスク化されなかった作業によるオーバーヘッドの発生や、作業全体や最終的なゴールに対して作業員の意識が向かなくなるデメリットも発生します。

1から100まで発生する作業すべてを完璧にタスクに落とし込めない限り、タスク化の恩恵だけを受け取ることができないのです。

しかし、ほぼ全てがオートメーション化している工場などは、タスク分割による恩恵を最大限受けていると言えます。

刺身の上にタンポポを乗せる人は作業全体や最終的なゴール、ましてや隣のラインの人が何をしているのかすら気にする必要はないのですから。

Tag: 仕事

2019/11/06

志望動機

ある社長さんが「あなたの今までの成果を知りたい」と思っているところに「経験はないですが入社すれば誰よりも頑張りたいと思います！」と言ってきた人に対して「違う、そうじゃない」みたいなつぶやきをみたのでこれを書いています。

もっと具体的に言うと「趣味でRailsのシステムを開発運用しています。こちらがそのURLです」みたいな人が来て欲しいけど、入社希望の人は「御社に入社すれば誰よりも頑張ります。Railsを扱うことにもすごく興味があります！」みたいな人が来た感じです。

雇用側としては「Rails扱えるようになってから来てくれない？」という気持ちなんだと思います。

専門的な技術が必要な仕事なのに、未習得の状態で何故その仕事に就こうとするのでしょうか？

このような現象が起きるのは何故なんでしょうか？

答えの一つは人の能力を見抜くより、熱意や意欲という分かりやすい部分を評価するほうが簡単だからです。

熱意のある人とない人だと、雇われるのは熱意のある人です。

例えば、何も前提知識がない状態で人事の人がエンジニアの面接をしたら、まつもとゆきひろより松岡修造のほうを高く評価しそうな感じがしませんか？

このように、応募側が成果ではなく熱意を武器にしがちなのは雇用側に問題があると思っています。

ところで、多くの企業はビジョンやミッションといった存在理由を持っています。

ゲームの会社であれば「ゲームを通じて世界中の人々に楽しさを届ける」といった感じで。

そして、それをベースとして企業文化や会社としての個性を打ち出しています。

まぁ、あくまで表面上は、ですが。

ベンチャーや中小の歴史の浅い新興企業などは人の入れ替わりが激しく1、2年で所属する人がガラッと変わって、会社という箱は同じでも中で働いている人は全然違う人達になり、社内文化も変わってしまう、というのはよくあります。

なんだったらピボットして会社のミッション自体も変わったりします。

大企業でも配属部署によって人間関係も文化も全然違っていたりします。

この話はここではこれ以上しません。

とりあえず、会社にはビジョンやミッションがあり、企業文化という集団属性が存在しているのです。

そして、面接を受けに行くと会社で行っている事業なりサービスなりを説明されて「どうですか？楽しそうじゃないですか？」と聞かれるわけです。

自社のビジョンやミッション、企業文化との親和性を確認するわけです。

それに対して自分の思いを伝えないといけないわけです。

志望動機というやつです。

で、この「志望動機」がやる気アピールを引き出している犯人なんです。

「志望」というは未来に対するただの願望ですし、「動機」というのも自分の中にあるただの思いに過ぎません。

最初の例に上げた「Railsを扱うことにもすごく興味があります！」はRailsを扱いたいという志望も動機も含まれているので「志望動機」として成立します。

逆に「自分で作ったRailsのシステム」はただの成果物であって、志望にも動機にもなりえません。

志望動機はどうあがいても会社が向いている方向性と自分が目指している未来とに接点があるものでないといけないのです。

会社が「医療で世界を救いたい」と思っているところに「自国のアニメ文化を世界に広めたい」と思っている人が来てもマッチングできないのです。

しかし、実務として会社が求める人材が法律に詳しい人で、応募者がその専門知識がある人であるならば、志望動機が合わないだけで落としてしまうのはとてももったいないことです。

「自国のアニメ文化を世界に広めたい」と思っている人であっても、その人が医療に対しての技術なり知識があるのならば、医療で世界に貢献することはできます。

ただ、志望動機を第一ハードルとしてしまうと、入社するためには会社の目指しているビジョンに合った「志望動機」をでっち上げないといけません。

その結果、会社で扱うサービスなり技術なりについて自分は興味を持っていますよ、と表明することが自己アピールの最適解になってしまうのです。

そして、自分を相手側に合わせて何かをアピールしようとするとどうしても「〜がしたいです」という表現が多くなるのは仕方のないことだと思うのです。

自分の過去の経験と成果が会社のビジョンと一致しているとは限らないからです。

自分の歴史と会社のビジョンから逆算して、いい感じのストーリーを捻出しないといけないのです。

捻出されたストーリーはあくまで架空なので、当然、表現は未来形にならざるをえません。

逆に会社が求める実務能力を持っている人からすれば「僕それできますよ」ぐらいしか言うことがないはずなのです。

「PHPを書ける人募集」という募集をしたのであれば「僕はPHPが書けるのできました」だけで立派な志望動機になりえるはずなのです。

そこを募集要件以外の別のところで人を選別しようとするから「誰よりも勉強してアウトプットして結果を出したいと思っています！」という人が生まれるのです。

Tag: 仕事

2019/10/09

ふわふわ時間

今回は言葉の抽象度に関するお話です。

言葉の抽象度というのは、言葉の持つ解釈の幅広さです。

抽象度が高いほどより多彩な解釈することができます。

「建物」だと抽象度が高く、「東京タワー」だと抽象度が低い感じです。

詳しくはこちらを読んでください。

抽象度の高い言葉は使用コストが低いです。

ここでいう使用コストが低いというのは、色んな人に対して使いやすく、いろんな場面においても使いやすいという意味です。

逆に使用コストが高い言葉は、ある程度の語彙力と知識を持った人同士でないと使えない言葉です。

例えば「クソコード」は使用コストが低く、「オブジェクト指向のディシプリンに沿ってない」は使用コストが高いといえます。

抽象度の高い言葉は使いやすい分、意思疎通の正確さに難があります。

言葉の使いやすさと正確さの関係はトレードオフになっていることが多いと思います。

さて、抽象度が高く使用頻度の高い言葉の筆頭格は「ヤバい」でしょう。

日常的にとても使いやすく、かつ相手に対して共感を得やすいです。

とりあえず「ヤバい」といっておけば、とてもいい場合でもダメな場合でも、特に大したことがなくても、すべてのケースに置いて対処することができます。

何かを食べて美味しければ「美味しすぎてヤバい」になるし、不味ければ「不味すぎてヤバい」になるし、普通であれば「普通すぎてヤバい」という強引な解釈もありです。

「ヤバい」という言葉にはあらゆるコンテキストを内包してくれる懐の深さがあります。

それ故に、コミュニケーションにおける使用コストはとても低く、日常会話で多用されています。

そして、仮に相手に間違った解釈をされてしまったとしても、解釈の答え合わせをしない限りは穏便にコミュニケーションを進めることができます。

意思疎通の正確性の低いことを逆手に取り、発言した内容の責任の所在を有耶無耶にできるのです。

このような理由から、説明会見や国会答弁などの場では、具体的な言い回しは避けて、どうとでも解釈できそうな表現をひたすら繰り返すという現象が頻発するのです。

最近だと、小泉進次郎議員の発言は耳障りが良いが中身がない、と言われているようなことです。

使用コストが低い言葉は共感を得られやすく使いやすいのですが、その代償として正確さを犠牲にしているのです。

逆に使用コストが高い表現は、共感を得にくいですが正確性が高くなります。

だから、共感したからといって、その言葉や言説が現実を正確に捉えているわけではないのです。

いわゆる「分かった気になる」というやつです。

分かったという気分を感じられるのですが、正確性はないので実際のところは分かっていないのです。

おそらく、表現に対する正確性と共感性を同じ評価軸として脳が処理してしまったいるせいで、共感＝理解という解釈になってしまっていると思われます。

普段の我々はあまり言葉の持つ抽象度を認識せずに生活しているのではないでしょうか。

俗に言う「空気」や「常識的に考えて」というコンテキストに無意識のうちにかなり依存してしまっていると思います。

身近な例でいうと時間の表現の仕方です。

ただ単に「3時」と言った場合、それだけでは昼の3時(15時)なのか夜中の3時かの区別ができません。

しかし、たいていの人は日中に活動し、夜中は就寝している生活をしているので「15時」という24時間表記の正確な表現をせずとも12時間表記の「3時」という表現で大体通じます。

ここで「3時というのは15時のことですか？それとも夜中の3時のことですか？」と確認すると「常識的に考えて昼の3時に決まってるやろ」となります。

ですが言葉の持つ正確性は「3時」より「15時」の方が高いのです。

これがお昼の仕事をしている日本人同士の話であるならあまり問題は起きません。

しかし、現在はグローバル社会です。

国を横断したプロジェクトがあったとして、その中で時間に関する話を出す場合、24時間表記どころか、どこの地域の時間か？というところまで気を使わないと正確に時間を合わせることはできません。

ここまでくると「3時」だけだと0〜23時まで全ての時間に該当する可能性が出てきます。

日本の15時はロサンゼルスだと前日の23時ですし、ロンドンだと朝の7時です。朝の3時だった場合、ロサンゼルスだと前日の朝11時ですし、ロンドンだと前日の19時になります。

もはや日付を合わせるのすら混乱します。

ここで24時間表記に加えてさらに、その時間がどこの地域の時間かを伝えなければいけません。

「JST(日本標準時)で15時」とか「UTC(協定世界時)で06時」とかです。

身近な範囲だと「3時」で済んでいたものが、コミュニケーションの範囲が広がるにつれ「日本時間の15時」とまで厳密に言わないと正確に伝わらなくなってしまいました。

「3時」→「15時」→「日本時間の15時」となるにつれ、知っておくべき前提知識が増えていくことがわかると思います。

最初はアナログの時計盤だけ読めていればよかったものが、1日が24時間という知識も必要になり、最終的には地域によって時間が違っており、世界協定で各地域の時間が定義されている、という知識まで必要になってきます。

「いやいや、うちでは最初にプロジェクトで使う時間を日本時間として決めているし、それを全員に承知させている」となったら「3時」だけの表現でつつがなく仕事を回せるかもしれません。

しかし、あとからプロジェクトに入ってきた人がたまたまその周知を知らずに勘違いする可能性も残されています。

やはり伝達の正確さを考慮するなら多少言葉の使用コストが上がったとしても「日本時間の15時」と表現したほうが良いことになります。

ただ、家族との連絡で「今日はJSTの19時に帰るよ！」とLINEしてしまうと「なんでいちいちJSTつけてんの？」となるので、相手やコンテキストによって言葉の抽象度を柔軟に変えていくことも必要です。

抽象度が低くなるほど他人行儀感が強く出てしまいます。

言葉の抽象度の低さには、人との距離感が離れていってしまうという欠点が潜んでいたりします。

説明くさい人間が煙たがられるのはこのためです。

今までの話をまとめるとこうなります。

言葉には抽象度があって、その抽象度をしっかり意識しつつ、状況と相手によって使い分けれることが大事です。

やはり何よりまずは、言葉は所詮どこまでいってもメタファーでしかなく抽象的であり現実を完璧に表現することはできない、という現実を認識することが大事です。

Tag: コミュニケーション