ムダを減らして心穏やかに過ごしたい
はじめに
これは【その2】ドリコム Advent Calendar 2015 - Adventarの18日目の記事です 17日目の記事は m-szk さんの 去年の12月頃、ドリコムの面接受けてた。 - .txt です。
【その1】ドリコム Advent Calendar 2015 - Adventarもぜひ
おまえ誰よ？
ID: wasbi01 です。社内ではねこと呼ばれています。入社時はエンジニアでしたが、現在はジョブチェンジしてディレクターになりました。
何をやっているの？
肩書はディレクターですが、仕事内容はいわゆるPM*1が近いと思っています。
ものすごく平たく言うと、自分の身の回りの「ムダ」をなくすのが仕事だと考えています。 ムダとは、「達成したい目的の障害となるもの、不要なもの」のことを言っています。
一般的に、普段やっている仕事は、以下の4つのカテゴリに大別できます
- 一見必要そうに見えて実は本当に必要なもの
- 今かけているコストが適正か。いま出ている結果が限界か。
- 一見必要そうに見えるけど実はなくてもいけるもの
- なぜそれを必要だと考えているのか。どうすれば不要だという判断ができ、なくせるのか
- 一見ムダだしやりたくないけど実はないと破綻するもの
- 必要なもの、それが（目に見えないものでも）なぜ価値が生んでいるのかを考える
- やりたくないので、コストをかけずに出来る方法を模索します
- メリットを考えずに「やめよう」って言いがち。やりたくないから。
- 一見ムダだしやりたくないけど実は本当にムダなもの
- やめよう
経験上、真ん中の２つがやっかいなので、その２つについて話をします。
考え方
基本的にはエンジニア時代に学んだRailsの哲学がベースになっています
- 「同じことを繰り返さない」（DRY:Don't Repeat Yourself）
- 「設定より規約」（CoC:Convention over Configuration）
ただし、相手は書いたことをその通りにこなすプログラムとは違って、曖昧特性をもつ人間なのでもう少し付け加えます。*2
- 一度に認識できる数には限度がある
- 一般的には 7+- 2 くらいが限度と言われています
- 直感で判断することが多い
- 早い
- けど間違えることも多い
- 思考して判断するのは苦手
- 直感よりは正確に物事を判断できる
- けど遅いし疲れる
- 自分の見たいものを見るバイアスがかかる
- 自分の意見が一番正しいと思っちゃうのもこれ
こういった特性を持つことを前提として、一つ一つのムダ（と思われるもの）に対してチェックをかけてゆきます。
一見必要そうに見えるけど実はなくてもいけるもの
これは、プロジェクトや会社の中では当たり前に思えているものに多いです。 こういったものは普通プロジェクトの中からは気付きづらく、外から入ってきたメンバー*3が気づくことが多いです その為、新しいメンバーが意見を言いやすい状況を作ることを心がけています
新しいメンバーは、「郷に入っては郷に従えバイアス」がかかりやすいと感じます。
積極的に話を振ってみたり、自分から具体的に「そこまで言うの？」というレベルの話を出すことによって、相手からの話を引き出そうとすることが多いです。
この時、次の項目である「一見ムダだしやりたくないけど実はないと破綻するもの」かどうかと判断を誤ってしまうと破綻するので、対策の検討は要不要を含めて慎重にやります。
そうして見つかった「実はなくてもいけるもの」は、なかった場合のプランを考えてメンバーに伝え、「いらないね」という合意を得てからなくしにかかります。
一見ムダだしやりたくないけど実はないと破綻するもの
みんなやりたくないのですが、「破綻する」と言っている以上は何かしらの価値、恩恵があるはずです。 その価値は何なのかを見つけ出し、それ以外の点を徹底的に削ぎ落とすことが必要になります。
特に顕著なものは朝会です。 朝会はプロジェクトの状況を確認し、何か滞っているところ、滞りそうなところがないかをチェックする役割を果たしています。*4 これを検知するためにはどのような会であれば適切なのか。ここで効いてくるのが、直感と思考の話です。
何十人も関わる少し大きめのプロジェクトになると、朝確認すべき内容も多岐にわたります。ゲームであれば、ほぼ毎日あるリリースの向こう数週間分に対して、
- 基本機能拡張
- イベント
- ガチャ
- 新規キャラクター
- その他キャンペーン
といった内容の全てを確認しなければならなく理解するだけで大変で、とてもではないですが全てを把握しきれないです。 ましてや、一つ一つのタスクの内容について細かく状況を確認していると、タスクごとに思考による判断を巡らせなければならないためとても終わらず、朝会だけで疲れてしまいます。
こういった内容はプロジェクトの中でタスクがどのようなステータスを取りうるかを定義してしまって、タスクは必ずそのどこかにいる状態を作ってしまいます（これは直感で判断できる）。イレギュラーが発生するなどしてどうしてもまかないきれないものだけ、朝会終了後に関係者で集まって対策を検討する（思考で判断する）という流れを作ると、要件を満たしてかつトータルのコストが一番低く保てます。
こうして、朝会というルーチンのコストを下げることによって、本来やるべき仕事、やりたい仕事に割く時間と心の余裕を作れます。
終わりに
こうしたことを地道に繰り返して改善していくことで、少しずつムダなことを削減し、最終的にはみんながやりたいことに力を割けるようになれたらいいなと思っています。
で、こういうのってやってることは手元にあるものをうまく組み合わせてすっきりした仕組みを作るという点でエンジニアリングと変わらないと思っています。
そのため「プロジェクトマネジメント」という言葉はしっくりこなくて、「プロジェクトエンジニアリング（PE）」という造語を思いついてはやらせようとしたんですが、すでにそういう言葉があると聞いて落胆しています。
【その2】 19日目は mkmn さんの記事です。
【その1】ドリコム Advent Calendar 2015 - Adventar 【その2】ドリコム Advent Calendar 2015 - Adventar
