Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

忙しいのに仕事が進まないのは、仕事に八方美人をしてるから - 仕事は人格を持っているという話

f:id:hirokiky:20190809185830p:plain
仕事には人格がある。八方美人をやめよう

  • 「大した成果をあげられてないのに、なぜか忙しい一日だった」
  • 「忙しく頑張っているのに、なぜか優先度を考えろと怒られる」

こう思ったことはありませんか?仕事を終わったあとにそう感じてしまう理由は、仕事に八方美人をしているからだと僕は考えています。

どういう意味でしょうか?八方美人は以下のような意味です。

だれからも悪く思われないように、要領よく人とつきあってゆく人。

僕は八方美人をやらないように心がけていますが、この姿勢は仕事にとっても大切だという話をします。 なぜ仕事が関係するのでしょうか。理由は、 仕事も人格をもっているから です。

まず、なぜ八方美人が人間関係にマイナスなのか

まず、人間関係における八方美人はなぜマイナスなのでしょうか?それは誰に対しても浅く、個性がなく、嘘が見えるからです。そんな人には、人としての魅力はありません。小手先のコミュニケーション術や、作った笑顔などは(悲しいことに)バレバレなものですよね。

人に好かれようとするよりも、自分の個性や魅力を全面的に出して、自分の心に実直に振る舞うほうが、結果的に良い人間関係を築けます(不思議なことに)。もちろんその振る舞いを嫌う人もたくさんでてきますが、その結果、本当に付き合っていくべき人や、愛すべき人との繋がりも強まるものだと思います。

なぜ八方美人をやめると仕事が捗るのか

この方程式は実は、仕事についても適応できます。本質的には急ぎでない仕事や、重要でない仕事にまでかまけていると、本当に今注力すべき仕事が手抜きになってしまいます。

仕事は人格をもっています 。「タスク」というと無機物のような感触がありますが、そうではありません。仕事は有機的で柔軟なもので、そこには色々な人格があります。 あなたに構って欲しいと常に思っている仕事や、魅力的ながらも推しが弱くすぐにどこかに行ってしまう仕事もあります。大事でない割に「自分は大事だ」と主張する仕事は、本当にたくさんあります。まさに、人間関係のように。

仕事は人格をもっている、の意味は

僕がこう考える理由は、 仕事には必ず他の人が関わっているから です(未来の自分を含みます)。仕事の後ろには、他の人の期待や、求めているもの、価値、やってほしいことがあるからです。仕事の人格とは、その仕事の裏で関わる人たちの気持ちのことです。1人の人間としての人格ではなく、複数人の特定の感情や要求をまとめた、抽象的な人格と考えられます。「仕事」、「タスク」、「Todo」と高度に抽象化しているので見えにくくなっていますが、仕事とは人付き合いと考えられます。

f:id:hirokiky:20190809184246p:plain
仕事の本質

仕事と言うと、絶対にやらなきゃいけない指示のように感じてします。無思慮に「やるべきもの」と認識されがちです。そんなことはありません。 「仕事さん」と仮想的な人を考えましょう 。そして「仕事さんが、何かを僕に期待している」くらいに思いましょう。「仕事さん」はたくさんいます。優先度も緊急度も違います。

人間は、仕事を石版に掘られた戒律のように考えすぎです。社長に言われようが、お天道様に言われようが、やらなくて良いことはやらなくて良いです。

「仕事さん」をあしらう方法

仕事にこそ、八方美人になってはいけません。優先度の低い急ぎのタスクに手一杯になったり、自分がやるべきでない仕事に首を突っ込んだり、面白そう・大事そうだけど人生の本質から遠そうな仕事にかまけてはいけません。鵜呑みにせずに、うまくいなすこともできるかもしれません。

f:id:hirokiky:20190809184328p:plain
仕事さんたち

色々な仕事さんがいます

  • 声の大きさ(誰が要求をあげているか)
  • 緊急度の高さ(今すぐやるべきことか)
  • 優先度の高さ(やる価値がどれくらいあるか)
  • 仕事としての質の高さ(要求がどれだけ深く要件に落とし込めているか)

ここでただ無思慮に「上から順に」、「声の大きいものから」、「急ぎのものから」対応してはいけません。 優先度や、背景にある要求、人にとってどれだけの価値があるものかを考えましょう。罠なのが、声が大きい人が言ったこと、緊急度が高いことを「優先度高」と捉えがちなことです。 「仕事さん」の言うことは鵜呑みにしてはいけません 。本当にやるべきことなんでしょうか?そもそも、その仕事の後ろには誰がいるんでしょうか?要件に落とし込めてるでしょうか?

まず落ち着いて、疑いましょう。考えましょう。 どうでも良いものはほっておくか、捨てるか、忘れるか、適度な妥協点で終われば十分としましょう。

ポイント:

  • 「仕事さん」がいるからといって、すべてやるべきという意味ではない
  • 優先度が高いことだけをやる
  • 緊急度は本質ではない
  • 仕事さんの言うままでない、楽な解決もできる

お化けになる「仕事さん」

そして、 仕事さんは「お化け」なこともあるので注意しましょう 。 「仕事」「タスク」「Todo」「Issue」として積み上がっていても、その実、時間とともに全く要求が無くなっている場合もあります。

f:id:hirokiky:20190809184503p:plain
おばけになった仕事

お化けの発生原因は2つです

  1. 時間と共に要求が別の方法で解決された、大きな問題にはならなくなった
  2. 勘違いだった、気まぐれでやりたいだけだった

お化けの仕事でも改善にはなるのかもしれませんが、本当にやる意味があるんでしょうか? 「仕事をやる意味」というと、どんな些細な仕事にも意味は存在してしまいます。それは時間の無駄です 。 相対的により意味が大きく、かつビジョンの実現に絶対的に必要な仕事だけをやりましょう。

ポイント:

  • 「お化けの仕事さん」は無視する
  • 誰の喜びにも、叶えるべきビジョンにも繋がらない仕事さんがいる
  • 仕事としてあるだけの仕事はただのお化けなので無視すべき、捨てるべき

大切なことだけ大切にする

僕たちがフルコミットすべき仕事は何なんでしょうか。僕の目の前には大切な仕事があるはずです。往々にしてそういう仕事は推しが弱いです。ですが、その仕事にこそフルコミットすべきです。ここでいう「仕事」は、何も職場で給料をもらう中でのタスクだけの話ではありません。僕の人生の中でやるべきこと、なすべきことは何かという次元にも拡張できます。

八方美人をしてしまうと、その大切で魅力的な仕事はどこかに行ってしまいます。 「忙しかったのに、仕事が捗っていない」のはなぜでしょうか。それは本当にすべき仕事に注力できていなかったからです。余計な「仕事さん」に構ってしまったのではないでしょうか。

僕の時間、費やせる情熱や愛は有限です。増やすことは無限のように可能ですが、人生というタイムリミットを考えれば有限です。 毅然とした態度で、うまく、仕事をあしらっていきましょう。そして注力すべき仕事に、今、全力を尽くしましょう。

まとめ

仕事が捗っていないのは、仕事に八方美人をしてしまったから。

  • 八方美人は人間関係でなく、仕事にも良くない
  • 仕事は人格をもっている
  • あしらう仕事はあしらっておいて、注力すべき仕事にだけ注力しよう

仕事さんを根本から消す方法や、仕事さんの質を高める(要件に落とし込む)方法については、また気が向いたらお話します。

記事が良かったと思う人はぜひ、ブックマーク、SNS投稿、ブログの購読をお願いします

他のオススメ記事

blog.hirokiky.org

雑談: 飯担当大臣、夕飯をハックする

最近、嫁さんがある事情で家事が一切できなくなってしまいました。 そこで僕が夕飯を作るのですが、せっかくなのでその記録を残しておこうと思います。

楽で、うまくて、栄養バランスの良い飯を考える

正直料理や家事に時間はかけたくないので、栄養バランスを取りつつ簡単に食事を用意するのは難しいです。 なので考えた結果、今はこういうふうに夕飯を用意しています

  • まとめ買いの時点で栄養バランスを考えて、作るときは好きに料理して食べる
  • 複数品目を作らずに、1品目に肉、野菜をたくさん入れる
  • なるべくまとめて作って、余ったら次の日の昼飯にでもする
  • 面倒なときはオリジン弁当

僕が作るとかなり自分の好きなものばかり作っていますが、栄養バランスの心配はありません。 栄養バランスは、まとめ買いする時点で取っておけば良いです。毎食では、肉と野菜と炭水化物をそれなりにバランス取って摂取していけば良いです。 調理の手間と片付けの手間を減らすために、おかずは一菜を理想と考えています。その一菜に、十分なタンパク質と野菜を含めるのが良いでしょう。

本当に毎食の栄養バランスを厳密にしたいなら、料理なんかやめて毎日COMPを食べるべきです。 一汁三菜やら三角食べやら言うくらいなら、COMPが一番です。毎 "口" すべての栄養が均一に含まれますからね。

以下、作ったご飯を記録しておきます。

鶏マヨポン酢

鶏肉をマヨネーズ、ポン酢を1対1にしたソースで漬けて焼きます。 焼いたあとにも、そのソースを足して軽くあえます。 このときはレタスを一緒に炒めて添えています。

豆苗豚キムチ

豚バラを炒めて、豆苗を炒めて、キムチでまとめる感じの料理です。 豆苗をサッと炒めるくらいにするとすごく美味しい。

View this post on Instagram

豆苗豚キムチを作った

A post shared by Hiroki Kiyohara (@hirokiky) on

鶏とキャベツのトマト煮

鶏肉、キャベツ、玉ねぎ、しめじをニンニクと生姜、オリーブオイルで焼きます。 火が少し通ったらトマト缶を入れてコンソメやら香辛料やらを入れたらできます。

タラのマヨネーズソテー

真ダラ、小松菜、人参を塩コショウである程度焼いて、マヨネーズを足してあえながら焼くと完成です。 初めて試してみたけどとても美味しかった。

一菜、ええやん

僕は三角食べというのが好きじゃないです。基本的に「ドーン」と何か一品ある食べ物が一番幸せです(ラーメン、ハンバーガー、サンドイッチ、丼物、パスタ、オムライスと、子供が好きそうなものが僕の好きなものです)。 なので、自動的に和食の基本である一汁三菜も好きじゃないことになります。

僕が夕飯を作ると一菜になりがちです。一菜か、一汁一菜。和食にすると単品が小さいので、納豆でバフをかけて一汁二菜くらいになるかもしれません。

とはいえ皿数が減ればそれだけ料理、片付けの手間が減ります。 忙しい中でもちゃんとご飯を食べるという観点では、一菜こそミニマルでかつ最強なのではないでしょうか。

御膳が苦手

そもそも三角食べが苦手なので、僕は御膳とか懐石とかが苦手です。 旅館に泊まったときの夕飯の懐石や、昼ゴハンの御膳や幕の内弁当、朝ゴハンのやたら品数の多い朝食が本当にダメです。

ちゃんとした懐石なんかは頭がパニックになるので、出されたときは頑張って1つ1つ攻略するしかないです。 でも自分で作れば好きなものが食べられます。

他にも料理が増えたら、気まぐれに追記していきます。

雑談: 子供のころの僕の変な言動

子供の頃、おさるのジョージという絵本を読んでいました。 今日話すのは「ひとまねこざる」というタイトルの本と、それを読んだ幼少期の私の変な言動の話をします。 (ふと思い出したから書きたくなっただけです)。

じてんしゃにのるひとまねこざる (岩波の子どもの本)

じてんしゃにのるひとまねこざる (岩波の子どもの本)

この作中でおさるのジョージは新聞配達を頼まれます。ですが、その途中で新聞を船の形に折って川に流してしまいます。 本には丁寧にも新聞で船を作る方法が書いていて、当時の幼少期の僕はぜひ新聞で船を折ってみたいと思ったんです。

そこで親に船を作りたいので新聞が欲しいと相談しますが、結果的に僕は泣き出してしまいます。

理由は作中に登場した「はやおきしんぶん」という新聞が、現実には存在しないからです。 僕は 「はやおきしんぶん」を使って船を折らないといけない と心底思っていて、「はやおきしんぶんが無いなら船は作れない」と考えて泣いてしまったんです。 そりゃ読売新聞やら日経新聞やらではダメです。はやおきしんぶんでないと、だって作中には「はやおきしんぶん」が登場していますから。

当時の細かい感情まではイマイチ覚えていないですが、ただ「はやおきしんぶん」にこだわっていたのは覚えています。 そのとき親がどうフォローしてくれたかは全く覚えていません(たぶん「こっちの新聞を使えばいいじゃない」と教えてくれたと思います)。 ただ僕は「なんでなんだ」と悲しかったのを覚えています。

今の僕なら「まぁテキトウな新聞で作ろう」と意図を汲んで思えますが、当時はそこまで考えられなかったんでしょうか。 今思えば笑い話ですが、親も苦労したのかなと思ってしまいます。

ぜひ小さいお子さんのいる人はこの本を読ませてみてください。 もし「はやおきしんぶん」でなきゃいけない、とその子が思い込み始めたら、たぶん将来の姿は僕です。

卑下すると自分にも他人にも良くないんじゃないかという考え

「悪く言っても、自分のことだから良いだろ」と言えばそうです。 でも僕は卑下することはすごく損失が大きいことだと思っています。

ここで言う卑下は、何かあるたびに自分(や自分の周りの人やもの)を悪く言う、癖みたいなもののことです。

卑下 自分をあえて低い位置に引き下げてへりくだること。

www.weblio.jp

もちろん個々人には好きに自分を卑下する権利がありますので、そこを脅かすつもりはありません。 ただ卑下することは自分にも他の人にもマイナスの影響を与えると僕は考えています。ここで、僕なりに気をつけていることを話したいと思います。

この文章は自戒です。受け取り方も自由です。

謙遜との違い

卑下と謙遜の違いはなんでしょうか。 語の定義としては、卑下は謙遜を含んでいそうです。 ここでは「プラスのチャンスがあるときにあえて悪く言う」を謙遜とします。卑下はそれ以外の、単に自分や身内を悪く言ってしまう癖や、悪い状況のときに自分をさらに下げることと捉えましょう。

褒められたときに「ありがとうございます。でもまだまだ頑張らないとですね」と謙遜して言えることは悪くないことだと思います。

自己批判、評価との違い

自分の悪いところを捉えるのが悪いことだとは思いません。

論理的な理由があったり、改善点を探すために自分を客観的に見るのは大切と思います。 感情的・反射的に自分を悪く言うのでなく、自分の性質や思考を外部からトレースできるのは良いことです。

ただ対象として「反射的な卑下」、「癖のような卑下」、「『そんなにあなたは悪くないよ』と言って欲しい卑下」をここでは扱います。

なぜ卑下しないよう気をつけているのか

僕が「卑下すること」を良くないと思う理由は2つあります。 1つ目はもちろん自分のモチベーションや可能性を潰すことにあります。2つ目は自分自身を卑下することで周りの人も下げてしまっているからです。2つ目は気づきにくいうえ損失も大きいので気をつけています。

  • 「私なんてダメです」と言うとき、あなたを好きな人の評価を下げてしまっている
  • 「私が作ったこれは役立たずです」と言うとき、一緒に作っている、関わっている人も下げてしまっている
  • 「私の仕事はダメだった」と言うとき、一緒に仕事をしている人や仕事を教えてくれた・教えようとしている人を下げてしまっている

卑下すると周りの信頼も失ってしまうのではないでしょうか。誰かが信頼してくれている僕を、不当に悪く言う僕は、信頼に値するでしょうか。

僕も自分自身や作ったものの悪いところを見つけるときはあります。僕の場合は「なんだこれは!ひどいな!」とあえて怒ってしまうほうがポジティブな改善にもっていきやすいです。ここは個々人の性格によると思いますが、マイナスに流れそうなときに断ち切るのが大切です。

ともかく卑下することで、自分のモチベーションや他人のモチベーション、信頼を潰しまいがちです。 卑下することで得られるものは少ないです

  • 「自分の悪いことは知っているから言わないで」というアピールがしたい
  • 「自分はこんなに悪い」=>「そんなことないよ」と言って欲しい(交流分析でいう)心理ゲーム

酒の席では許されるかもしれませんが、過度にこのカードを使うのは悪手に思います。 他の人からの信頼や関心、好意を自分の快楽に変換しているようなものです。

仕事や人生は波乗りのようなものだと思っています。自分へのポジティブなエネルギーや挑戦、報酬、改善、快楽をうまく波乗りするとうまくいくと思っています。まずは勢いをつけて、その勢いをなくさないように次の勢いに繋げていく、それが大切なんじゃないでしょうか。うまくいったら「よし!いいぞ!」と自分をあげていきたいものです。

未来の僕へ、卑下しそうなときはこう考えよう

  • 卑下するのは「自分が気持ち良いから反射的にやってるだけだ」と思い直そう
    • 周りの人はもうウンザリしているかもしれない
    • 自分だけでなく他人からの信頼も失うかもしれない
  • 卑下しそうなときは論理的に分析しよう
    • 本当に悪いのか?
    • 悪いとして、『まだ今は』悪いだけで改善できるはずだ
  • 良いところに目を向けよう
    • 褒めよう
    • 良いところをどう活かせるかを考えよう

自分の人生をより良くできるのは自分しかいません。

この辺りの本もオススメなのでぜひ下のリンクから買ってください。

嫌われる勇気―――自己啓発の源流「アドラー」の教え

嫌われる勇気―――自己啓発の源流「アドラー」の教え

Djangoのcacheのキーには必ず文字列を指定しよう

Djangoのキャッシュ(cache)にはキーを文字列として指定しましょう。

>>> from django.core.cache import cache
>>> cache.get("mykey")  # OK
>>> cache.get("1")  # OK
>>> cache.get(1)  # よくない

キャッシュバックエンドの実装によっては数値でも指定できますが、ドキュメントでは「キーは必ず文字列で」とあります。

key should be a str, and value can be any picklable Python object.

docs.djangoproject.com

だいたいのキャッシュバックエンドでは make_key を内部で先に実行するので、数値だろうが文字列に変換されるのであまり問題にはなりません。 例えば以下のような処理でも問題になっていない場合もあります。

>>> from django.core.cache import caches
>>> cache = caches["somemycache"]
>>> cache.set(1, "users-value")

user.id をキーとして使ってしまったときなど、キーを数値として渡してしまいます。 ちゃんと str(...) としておきましょう

Django2.2から、DBバックエンド(DatabaseCache)を使っているときに cache.get(1)cache.delete(1) をするとTypeErrorになります。

>>> cache = caches["..."]
<django.core.cache.backends.db.DatabaseCache object at 0x7f2d5ce37ac8>
>>> cache.get(1)
Traceback (most recent call last):
  File "/usr/lib/python3.7/code.py", line 90, in runcode
    exec(code, self.locals)
  File "<console>", line 1, in <module>
  File "/home/hirokiky/.../venv/lib/python3.7/site-packages/django/core/cache/backends/db.py", line 52, in get
    return self.get_many([key], version).get(key, default)
  File "/home/hirokiky/.../venv/lib/python3.7/site-packages/django/core/cache/backends/db.py", line 60, in get_many
    self.validate_key(key)
  File "/home/hirokiky/.../venv/lib/python3.7/site-packages/django/core/cache/backends/base.py", line 245, in validate_key
    if len(key) > MEMCACHE_MAX_KEY_LENGTH:

ここの validate_keymake_key より前に呼ばれるよう動作に2.2からなっていて、エラーになります。

django/db.py at 2.2.3 · django/django · GitHub

もちろんこの動作はバグではありません。もともと、cache.get などのキーには文字列を渡すべきです。 ですが、今まで動作していたり他のLocMemBackendでは数値でも動作していたりで問題に気づきにくいです。気をつけてください。

一応、DjangoTracに「Release Noteにこのことを書いたら」と起票しましたが、まぁ仕様どおり使ってないのが悪いので却下されるかなぁとは思っています。

#30625 (DatabaseCache backend raises TypeError if get/delete received key as integer.) – Django

仕事を人に任せられず忙殺されてる人へ: 小さな組織向け業務設計の方法

f:id:hirokiky:20180505200854j:plain

こんな悩みはありませんか?

  • なぜか忙しくてメインの仕事が進まない
  • 人に任せられない仕事を常に抱えている
  • 人に任せたは良いがうまくいかない

私はあります。日々仕事をする中で悩んでいます。その中で実践して、見つけたことを今日はお話します(まだまだ勉強中なのでフィードバックを貰えると嬉しいです)。

  • 忙しいのは「見えない仕事」に追われているから です。
  • 人に任せられないのは見えない仕事を定義しないから です。

ただしこの話は「手順書を書こう」という話ではありません。 むしろ手順書は無い方が良いです。

ではどう業務設計すれば良いのでしょうか? それを説明します。

対象の人

業務要件定義や業務設計というと、かなりお硬い印象があるかもしれません。 実際に「業務設計」などで検索すると硬い組織での情報が多くでます。 でも私は小さな組織にこそ業務設計が必要だと私は考えています。

数人規模の組織を対象にしています。とくに新しい事業を始めているチームやスタートアップを想定して書いています。私自身が PyQ のチームでの経験などを元にしているからです。 この記事で言う「業務設計」はあくまでも私の中での方法と定義になります。

見えない仕事とは何か

見えない仕事とは「業務として明確に認知されてないがやっている仕事」です(私が今しがた作った言葉です)。

  1. 「インフラの状態を確認する」など日々何気なくやっている仕事
  2. 「サポート対応」のようにぼんやり認知されているがフローや時間の使い方が明確でない仕事

今回の話では2のような「明確になっていない業務フロー」も改善の対象と考えます。 2を含めれば、組織の中にはむしろ見えない仕事のほうが多いかも知れません。 暗黙知として共有されているものの、何をすれば良いかや求める質は人によって違うことが多いものです。

業務になっていないことの問題は?

業務として設計されていない問題はなんでしょうか?理由は2つあります。

  1. 仕事として新しい人に任せにくい
  2. 任せたとしても品質や作業時間にバラつきができる

定義が曖昧なまま作業を依頼すると、個人の解釈やその人の中での「求めるレベル」に質は依存してしまいます。「なんでこれもできないの」、「なんで反応してくれないの」、「なんでこのレベルで出すの」など依頼者側は思いがちですが、単純に共有できていないのが問題です。

傾向として依頼する側はその仕事や事業により深く関わっていることが多いです。なので「意識レベル」のようなものは依頼される側よりも高いはずです。この意識の格差が軋轢を産んでしまいます。逆に考えれば、あなたにとっても「事務処理」などは重要でない仕事かもしれませんが、総務の人に取っては大切な仕事ですよね。

「それらを共有できてる人とだけ仕事をする」というのは1つの正解です。ですが、それがうまくいっているのは 仕事のできる人は自分の中で業務設計ができる からです。 永遠に居続けてもらえるわけではないですし、新しいできる人が脳内で業務設計するコストもかかってしまいます。自分にとっても覚えておくという見えないコストがかかっています。なので、簡単にでも業務設計をすることは大切です。

なぜ業務設計をすべき?

業務設計や業務の定義をするのは、「誰でも効果的に仕事をできるようにする」ため です。 上記のような問題を解決するために、先に決めておこう、明確にしておこうというのが業務設計です。

ただし、何でもかんでも業務として定義すれば良いという訳ではありません。 暗黙知で回っていて十分な業務はそれで良いです。業務設計をするタイミングは以下です

  • 何もできていないのに、なぜか忙しい
  • 人に依頼していて、かつ依頼される側の負荷や人によるムラが大きい

基本的には人と関わるときにコミュニケーションとして定義するのが一番です。 ですが、自分の業務を定義して改善していくキッカケになることを思えば、自分自身のために定義しても良いでしょう(明確でないものを改善していくことはできません)。

業務設計、定義の仕方

ではどう業務を設計すれば良いのでしょうか? 重要なのは以下を書き出すことです

  1. 「業務」の存在の明確化と細分化
  2. 背景、ビジョン、とりくむ姿勢
  3. 役割
  4. 評価指標の用意
  5. フローや流れ、やること
  6. テンプレートの用意、自動化
  7. (おまけとして)手順書の用意

「業務設計」というと一般的には最後の手順(マニュアル)を指すように思いますが、そうではありません。 多くの人はいきなり手順書や事例ベースの説明だけ書いて、本質の伝わらないドキュメントを量産しすぎです。

まずは以上の順でドキュメントに書き出すことが大切です。

1. 業務としての存在と細分化

まずは「その業務がここにある」が分かるだけでも大きな一歩です。 仕事には何があるかを細分化して書き出していきましょう。

例えば「サポート対応」という未定義の仕事を対象に考えると、以下のような内容があるのではないでしょうか。

  • サポート対応
    • お客様への質問への回答
    • 製品、サービスへのフィードバックの対応
    • 法人向けプランの問い合わせや見積もり依頼

細分化することで、明確にすべき業務に何があるのかがよりハッキリ分かるようになります。 これにより業務の目的やゴールが見えてきます。人間は名前をつけていないものを認識できません 。まず、「こういう業務があるな」と定義することから始めましょう。

2. 背景、ビジョン、とりくむ姿勢などのバックグラウンド

マニュアル化の問題は作業者を無知にしてしまうことです 。 そのならないように、背景の情報や、自分たちのビジョン、とりくむ姿勢があれば共有しておきましょう。「依頼者の期待するレベル」に引き上げるために、バックグラウンドの説明と共有が大切です。

  • システム系の作業であれば「背景」や「構成」を共有する
  • タスクや開発であれば「ビジョン」や「あるべき姿」を共有する
  • お客様対応や人とのやり取りであれば「とりくむ姿勢」や「マインド」を共有する

例えば「サポート対応」業務であれば、以下のような「マインド」を共有しておくと良いでしょう。

  • サポート対応にとりくむ姿勢、マインド:
    • お客様を助けてあげようという姿勢でサポートしよう
    • 何かできることは無いかと考えよう。お客様が成功するためには何ができるか考えよう
    • クレームはあくまでサービスへの不満として考え、自分の心への攻撃ではないと考えよう
  • サポート業務への姿勢:
    • なるべくFAQや回答のテンプレートを活用して効率化していこう
      • お客様も質問したりメールするのは大変

あなたの姿勢や背景の理解は素晴らしいものです。それを明文化して、関わるすべての人がその水準やポジティブな気持ちで仕事できるようにしましょう。

3. 役割を分ける

仕事の中で複数の役割があるのであれば、明確にしておきましょう。 とくに「どの範囲について責任を持つのか」を明確にするとトラブルを避けやすいです。

例えば「研修をする仕事」について役割を設計するとすれば以下のようになります

  • 講師
    • 研修当日に研修生が内容を深く理解することに責任を持つ
  • アシスタント
    • 研修当日に講師が滞りなく研修ができることに責任を持つ
  • マネージャー
    • 研修をしたいお客様の求めるレベルに研修生が学ぶことに責任を持つ
    • お客様とのやり取りが滞りなく行われることに責任を持つ
    • 研修内容、費用、日程、アサインする講師とアシスタントを決める責任を持つ
  • 総務
    • お客様への請求、お金のやり取りに責任を持つ
    • 研修に必要な新幹線のチケット、ホテルの手配に責任を持つ

このとき 役割は1人が複数を兼任しても良いと考えます 。1人で仕事をしているときは兼任が多くなります。ですが、「それぞれどういう役割があるか」を意識するとこでやるべき業務が明確になります。

4. 評価指標を決める

できれば業務について評価指標があるとより良いでしょう(必須ではありません)。 仕事についてどこまでのクオリティを求めるかが明確になるからです。

  • 求める指標が分かることで注力すべき点が明確になる
  • 指標を改善していくサイクルが生まれる

例えば研修後にいただくお客様のアンケートの結果などが考えられます。

注意したいのが、数値に対して早すぎる最適化をしないことです。 指標が良い指標であれば良いのですが、業務設計した最初は指標そのもののや取得方法の質が低いものです。指標がどの程度参考にすべき値なのかも共有しておくと安心です。

5. フローや流れ、やること、やらないこと

業務に「大まかにどういった流れがあるのか」を明確にします。 役割とあわせて明確にするとより良いでしょう。

例えば「お見積」であれば以下のようなフローが考えられます

  • お客様からメールでお見積もりの問い合わせをいただく
  • (事務)メールで一次回答をする
  • (事務)社内システムに見積もり依頼があったことを登録する
  • (経営者)担当者をアサインする
  • (担当者)依頼内容を見て見積もりをする
    • 情報が不十分であればメールで返信し、問い合わせする
    • 対面のほうが早そうであればお客様にヒアリングをするミーティングを設定する
    • ミーティングはお客様が良ければオンラインのほうが効率的
  • (担当者)社内システムで見積もり書を発行してお客様にメールする
  • ...

このように大まかな流れと、どんな役割の人が関わるかを明記すると良いでしょう。 これによって「作業の取りこぼし」や「誰にも触れられない仕事」が発生することを防ぎます。

「やってはいけないこと」があるのであれば明確に書いておくと安心です。 やることは書いていて 「やらないこと」「やってはいけないこと」が書いていないと、どこまで自由に考えてやっていいかが分かりません 。ある程度は自由に動けるように、やらないこと・やってはいけないことを明確にしておきましょう。

また、「こうした方が良いよ」というTipsもあれば書いておくと良いでしょう。 新しく仕事をする人がノウハウを身につけるよりも、教えてあげたほうが早いです。

6. テンプレートを用意、自動化

上記のフローについて「タスク」のテンプレートなどを用意しておくと良いでしょう。

  • 業務を追跡するタスクのテンプレートを用意しておく
    • フローをTodoリストにして順次進めるようにする
  • 作るべき書類やシートのテンプレートを用意しておく
  • 必要な作業を自動化して短縮できるようにしておく

このテンプレートがカッチリと決まっていると、作業者は「何を作れば良いのか」が明確になって安心です。また、仕事を終わりまでトラッキングするタスクがあれば「仕事の取りこぼし」も発生しませんし、「背景」や「姿勢」を説明したドキュメントへのリンクも書いておくことができます。

7. 手順書(はあまり大事じゃない?)

手順は、明確にどういう操作をすべきかを書いたものです。 これは操作方法を知らない人がどうすれば良いかがハッキリ分かるように決めたものです。

ですが、私個人としては 手順書はないに越したことはない と考えています。 理由は以下です

  • 簡単な画面の操作方法であれば一度伝えれば十分
    • 画面が分かりやすく、ミスや失敗がおこらない用に設計されているべき
  • 手順よりも「テンプレート」を用意したほうが効率が良い
    • 「メールを書く」作業よりも、そのテンプレートを用意した方が楽で早い
  • 自動化する
    • 仕組みで自動化したり、ヒアリングしなくて済むようにシステムを用意したほうが早い

手順書は画面が変われば壊れてしまいますし、手順通りでない場合の対応ができなくなりやすいです。 私は用意するコストの割に効果が薄いと考えています。

大事なのは上記の「背景」を共有しておくことと、テンプレートやフローを定義しておくことです。 それがあれば「業務」としては十分に明確です。

業務設計と聞いて手順書を用意するのは絶対にやめましょう。むしろ、一番費用対効果が悪いのが手順書です。

おわりに

「見えない仕事」があるから忙しい、「見えない仕事」だから人に依頼できないと話しました。 それには業務設計が必要だと話しました。業務設計には「明確化と細分化」、「背景」、「役割、「フロー」、「テンプレートと自動化」とおまけで「手順書」が大切と話しました。

今回の話は私が PyQ で製品開発をするなかや、会社での仕事を見直すときに使った考え方です。小さい組織にこそ大切な考え方だと思っています。 繰り返しになりますが、これはあくまでも私の考えであり、私なりの定義です。

謝辞

今回の内容は以下の「はじめの一歩を踏み出そう」という本から強く影響を受けています。 学んだ中で実践して、私なりに定義したのが今回お話したことです。

はじめの一歩を踏み出そう―成功する人たちの起業術

はじめの一歩を踏み出そう―成功する人たちの起業術

レッツトライ

明日からの仕事で、ぜひ参考にしてくれると嬉しいです

  • どういう「見えない業務」があるかを考えてみよう
  • 人に依頼している、一緒にやっているが明確でない業務はどれくらいあるだろう
  • 依頼したほうが楽になるなということはどれくらいあるだろう

できれば、今回の内容で業務設計をしてみて、フィードバックいただければと思います。 私もまだまだ勉強中で改良中の身です。ぜひ新しく事業を始める人たちの助けになり、私も勉強できればと思っています。

ウィーンモダン展に行ってきたWebアプリ開発者の感想

今日は、総合的な芸術、そして人の集まりというものの大切さを感じました。 ウィーンモダン展というものに先ほど行ってきましたのでその感想です。

artexhibition.jp

展示会として、行くべき?

個人的な感想の前に答えておきます。

今この記事を読んでくれているあなたは、千代田線乃木坂駅に行けて、1600円と1時間30分という時間を使えますか? Yesで、かつ興味があれば難しく考えずに行ったほうが良いと思います。 平日の4時に仕事を少し早く切り上げて行きましたが空いていました(スケジュールなどはサイトを見てください)。

この展示会について平たく言うと:

  • 美術品だけでなく1800年、1900年のウィーンの文化とか美術史にもついて知れてとても興味深い
  • 「そんなことよりクリムトの油絵がたくさん見たい」という人にはあまりオススメしない

美術品を眺めるというよりも、ブラタモリを見る感覚でも楽しめます。 僕は美術史の背景を教えてもらいながら美術品を見るのが好きなので良かったです。

まぁ、1パイント1600円するクラフトビール飲むなら、1杯だけ我慢して国立新美術館にいくのが良いんじゃないでしょうか。

個人的に良かったこと

エゴンシーレ

そもそも、私の個人的にはエゴンシーレの作品が見たかったのでこの展示会に行きました。 昔からシーレの作風や表現、人生などがとても好きなので地下鉄の広告でこの展示会を知ったときはウヒョウ!となりました。

ja.wikipedia.org

展示会でもエゴンシーレの自画像が見れたことはとても良かったです。ただ印象としては「ひまわり」のほうが予想を超えてすごかったです。 シーレのエンピツ画や水彩の人物画も多数あり良かったです。が、「大量」というわけでは無いのはもう少し寂しい気持ちになりました。 まぁでも実際に生で見れたのは本当に良かったので、エゴンシーレ美術館やプラハ国立美術館に行けということでしょうね。

www.musey.net

分離派ポスター

予想外、というか期待していない点でとても感銘を受けたのは分離派のポスターでした。

とくに「作品だけでなくポスターでも芸術性を発揮しよう」という総合芸術が素晴らしいと思いました。 私も PyQ のようなWebサービスを作っているので、その考えにはとても共感します。 例えばマーケティング用のクリエイティブや文章も、Webアプリケーションという作品の一部と考えられます。 分離派のポスターもアテナを描いたり、タイポグラフィにこだっていたりと大変面白いです。

クリムト

今回の展示会の目玉はやはりクリムトでした。 人生で死ぬまでに見れて良かったなという気持ちです。

ですがこれも予想外で、クリムトのアテナの絵や分離派のポスターなどが印象的でした。 アテナの絵の「やっていくぞ!」という気概は本当に良かったです。 こういうやっていく気持ちを素直にぶつけていくのは大切だなと思いました。

また分離派のポスター用の下書きなども見れて良かったです。 タイポグラフィのためにガイドの線を引いていたり、修正液で文字を直したりしているのが見えました。 芸術の後ろには数多くの習作や練習、計算があるものなんでしょうね。

印象派ポスターの1つ目は検閲を受けて一部が隠されていて、当時の保守的な雰囲気を感じました。 そこも、「歴史から描く」というこの展示会として良かった点ですね。

人の集まりが何かを生むのか

印象派にしろサロンにしろ、芸術のジャンルを超えて交流することで新しいものが生まれたという背景も展示会で描写されていました。 個人的にはこの点が感動して、「まるで現代のIT勉強会だな」という風に感じました。 アテナイのアゴラもそうですが、やはり人が集まって交流する場所には新しいものや素晴らしいものが生まれるものなのかもしれません。

DjangoCongress JPやコミュニティ活動をしていると大変なときや「意味あるの?」と不安になることもあります。 ですが歴史に学ぶと、そういったコミュニティ活動や人との関わり、対話、議論というのはとても意義のあることなんでしょうね。

まとめ

ウィーンモダン展はとても良かったです。 ただの美術展というよりも、歴史資料展や文化の変化を伝える展覧会としてとても良かったです (どうでも良いですが「シューベルト」と聞いてイメージするあの肖像画の本物を見れたのは何気に良かったです)。 個人的にはエゴンシーレの作品に触れられて嬉しかったです(他に見れる良い場所を知ってるという人はぜひ教えてください)。

またそこからWebアプリケーション開発やコミュニティ活動、組織運営というものについて刺激を貰えました。

ぜひ時間があればウィーンモダン展に行ってみてはいかがでしょうか。 1時間30分と1600円に見合うものは得られると思います。