仕事のスピードは「はまる」時間の長さで決まる

こんにちは、NAEです。

本記事は2009年に公開された小野和俊さんの記事のオマージュです。

参考 プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ

ソフトウェア開発やプログラミングにおける「コツ」には、実は仕事の生産性をあげるコツがたくさん詰まっています。

特に「決める」「伝える」「動かす」系の仕事をしている人には得るものが多いはずです。

それではどうぞ。

仕事のスピードは「はまる」時間の長さで決まる

コンサルタントを始めてから今日に至るまで、
様々なタイプの人と仕事を共にしてきたが、
驚くべき速度で高い品質のアウトプットを出し続ける人には、
一つ共通の特徴があるように思える。

それは、「はまる」時間が極端に短い、ということである。

私自身、「風のコンサルタント」を指向しており、仕事速度を重要視している。
例えば平成28年の某クライアントにおけるデジタル策定プロジェクトでは、
役員への最終報告直前に知人でプロジェクトリーダーのA氏にレスキュー隊として呼ばれて、
2,3日で検討の全体像と、個別の論点*1における示唆やアクションプランを整理しきったのだが、
このときなどは、大体の経緯と方向性、過去資料のありかを口頭で聞いた後は、
ほぼまったく手が止まらず資料を書き続ける感じで最終報告向けプレゼンを作っていた。

「はまる」時間の長さは仕事の速度に直結するわけだが、
知的生産を行う人が「はまる」場合にはある程度の傾向があると思うので、
今日は「はまる」人の傾向と、その対策を考えてみたい。

言葉の定義が不適切

先日ネットで「わかりやすい資料を書くために必要な、たったひとつの単純な事」
という記事が話題になったが、この内容には私も全面的に賛成で、
言葉や用語、用例や適用範囲、など、とにかく文字として表れるものには、
必ず、例外なく、正しく誤解のない定義を徹底することが非常に重要だ。

不適切な言葉は、クライアントやメンバーの誤解を招き、まさかこの言葉がそんな
意味を持つとは思わなかった、という類のはまり方は本当に最悪で、
時間も無駄になるしモチベーションも減退するし、その資料を書いた人にはに
対しての信頼も失われてしまう。

一人で資料を書いているときでさえ、その規模がある程度以上になると、
自分が使った適当な言葉に自分自身ではまる、という三流パロディーのような事態が
起こりえるが、複数人で作業しているときに適当な言葉を使ってしまうと、
各所で「はまる」事態が発生し、仕事効率が激減する。

「とりあえず」書いた資料が悪さをしている

言葉の定義と同様に、どんな忙しい状況でも、「自分でも納得でき、人に見せても恥ずかしく
ない資料しか出さない」ことを守り続けることが重要である。

「今回は時間がないのでとりあえずこのまま提出します」といって提出した資料は、
多くの場合それ以降に軌道修正が難しい混乱の原因になるし、
場合によっては「今回」もその箇所が原因となって他の箇所で無駄な議論が発生し、
はまる原因となる。

「とりあえず」書いた資料とは、例えば次のようなものだ。

• 課題を根本解決せず、当面の回避策のみで強引に凌いでいる
• 「理由はよくわからないんですが、とりあえずこうやって整理するとまとまるので…」
• 「危険な臭い」のする論理展開
• 明らかに論点再整理の対象となるような、ロジックが極端に拙い資料

期日が迫っており、とにかく時間がない、というような状況だと、
つい「とりあえず」書いた資料を提出したくなるかも知れないが、
忙しいときこそ、「適当に書いた資料は出さない」ことを死守すべきだ。

最終報告書が完成した後に見つかった問題に対応するには、
最終報告書完成前の何倍もの手間がかかることを、
私たちは経験的に知っているわけだから。

「このままでは何かがおかしい」と感じながら検討を続けている

これは例えば、「もっといいやり方があるはずなんですけどね…」とぼやきながら、
あまり望ましくないと思われるやり方で検討を続けてる、というようなケースである。

「もっといいやり方がある」と感じるのは、今の検討の進め方や整理の仕方だと、
同じような論点を複数箇所に分散せざるを得ない、という状況だったり、
依存関係的にここにこんなコミュニケーションが入るはずないんだけど、という状況だったり、
意識する必要がないはずの別プロジェクトのマイルストンやアプローチを意識しないと課題が解決
しないような状況だったりする場合である。

そして、たぶん、その直感は合っている。

何かがおかしいなら、時間をかけてでもそのおかしさの根本原因を最初に確認しないと、
後ですべてをやりなおすことになる。「何かがおかしい」状態で作業を続ければ
続けるほど、後で必ず修正することになる資料を積み足して行くことになる。

フレームワークに振り回されている

ときどき、いざ課題を解決せん、ということで、頭で考えて大体の当たりを付ける前に、
突然フレームワーク2を引っ張りだして色々なところに論点を当てはめてみたり、
論点の仕分けに必要な情報を検索したり、プロジェクトの目的や前提を行ったり来たりして、
5ミリ方眼紙3の前で腕を組んで首を傾げ、一向に検討が進まない、という人がいる。

もしこういうはまり方をしやすい人がいたら、
その人に対するアドバイスとして、一度フレームワークを使うのをやめてみることを提案したい。

そもそも、最近のビジネス本や研修資料に掲載されているような便利なフレームワークが存在しなかった頃から、
先人達は課題解決を行ってきたのだ。

はまった時にまず最初に行うことは、フレームワークに当てはめることではなく、
「何が本質的な課題なのか」について、頭で考えて当たりをつけることだ。
そして、それに関連する過去資料や検討経緯を読んで状況を確認することだ。

課題を頭で考えることに慣れてくれば、
大抵の場合、5ミリ方眼紙さえあれば課題は割とすぐ解決できる。
そして、フレームワークが本領を発揮するのは、当たり（仮説）を付けていない人に対してではなく、
当たり（仮説）を付けているに対してである、ということを忘れてはいけない。

頭で考えて当たりをつけることができない人にとっては、
フレームワークは単に検討速度を遅くさせる混乱要因でしかない。

フレームワークに対する理解が乏しい

一つのフレームワークをある程度の深さで習得した人は、
「あのフレームワークで言うＸＸはこのフレームワークではどうカバーされているのかな？」
といった要領で異なるフレームワークに対しても理解が早いものである。

同様に、「このタイプの課題だったらこのフレームワークが使えてこの辺りに深掘りポイント
がありそうじゃない？あ、ほら、あった」といった要領で、たくさんのフレームワークの
「つくり」に触れたことがある人は、他のプロジェクトの課題に対する解決方針出しが格段に早い。

「つくり」を理解するには、単にフレームワークを使っているだけではダメで、
使うことになったフレームワークに「深入り」することが重要だ。

例えばただ4P*4を使っているだけでは、4Pの「つくり」のほんの一部しか理解できないが、
4Pを使った検討を何回もこなしていけば、4Pの「つくり」についての理解を深めて
行くことができる。

「最近ではＸＸというフレームワークがあって」というような表層の情報をたくさん
集めることよりも、少なくても良いので、これは使えそうだ、というものについて深入りして、
理論の構造や活用ポイント、根本となる思想や背景などを理解する方が、
速く検討を進め美しく資料を書ける人になるための近道だと思うわけである。

アセットの存在を認知できていない

新人コンサルタントの頃、某プロジェクトのとあるオフィスで、そこにいた先輩の人が、
「僕は新しいプロジェクトに入るときは必ずアセット*5にざっと目を通すよ」
と話していたことがあった。

これは新しいプロジェクトに参画するときのとても効率の良いキャッチアップ方法だと思う。

「頑張って資料作った後に、過去に既に議論され尽くしたことを示す資料があることがわかった」
というのも一種の「はまっている」状況であると言える。

また、単に検討工数が余分にかかるだけでなく、すでにアセットの存在を知っている人から
見ると、「わざわざ作ったからには何か違う検討が必要だったのでは」という風に見えて
しまい、考える時間を使わせてしまうこともあるので、注意が必要だ。

私は、「あるものは使い、無いものを作る」ことは仕事の大原則の一つ
だと考えているが、その観点から言っても、よく使うであろうということですでにアセットの方で
検討すべきポイントを用意してくれていたり、よく使われるフレームワークがあったりする場合には、
何か特別な理由がない限りアセットを使うべきだし、また、「どの辺りを見ればどの類の
アセットがある」という頭の中のインデックスを、企業にジョインする時に最初に頭に入れてしまうと、
こうした問題は起こりにくくなってくるだろう。

他にもいろいろとあるものの

他にも、資料が世代管理されていないとか、自己レビューのためのチェックリストがない、
といったような手戻り防止的な話もあるだろうし、仕事人としての「読み書きそろばん」
のスキルにまず磨きをかける必要がある、という場合もあるだろう。
また、ウェブの情報やフレームワークに頼りすぎて、自分で解決する能力に磨きをかけられていない、という
ような話もあるだろう。

が、今回、上に書いたようなことにテーマを絞りたかった理由は、

1. 適当に書いた資料は後でとても大きな被害をもたらす可能性が高い
2. たくさんのフレームワークの「つくり」に触れ、思想や活用法を熟知しよう

という二点を強調したかったからである。

もちろん、全く新しい未来のビジョンを描くタイプのプロジェクトなどは、
むしろ、「はまる」ことの連続だし、それが健全な姿だろう。

が、ひとたび解決すべき本質的な課題が見えてくれば、そこから先の作業で
「はまる」時間は極力少なくすべきだし、上に書いたようなことを
気をつけながら作業を進めるように習慣をつけていけば、
頭の中で全体像を整理しながらサクサクと資料を書く、という感じで
仕事が進められるようになってくるものだ。

編集後記

ぼくは大学院でソフトウェア工学を研究していました。

ソフトウェアをいかに上手く（品質）、早く（納期）、安く（コスト）作るか、その手法、技術、およびプロセスを研究する学問です。

ウォーターフォール、イテレーティブ、アジャイル、テストドリブン、エクストリームプログラミング、リファクタリング・・・

そんなキーワードに囲まれながら、研究実験のためにプログラムを書く日々を過ごしていました。

 

大学院を修了し、コンサルタントの仕事を始めてからというもの、コンサル仕事のベストプラクティスとソフトウェア開発やプログラミングにおけるアイデアは似ていると感じていました。

品質・納期・コストを気にするのはもちろん、仮説検証型の動き方、フレームワークや過去資料を活用した検討の効率化など、先輩からいただいたアドバイスの多くは「なんか聞いたことある」と感じていたのです。

そこでたまたま、冒頭のご紹介した小野和俊さんの投稿を見かけました。

7年前ということでかなりの旧聞ですが、書いてあることは非常に汎用的で、すべてのビジネスマンが読むべきものだと感じました。

 

プログラムとはつまり、物事の処理を最も細かな粒度で整流化し、誰が読んでも理解の齟齬が起きない言語で記述したものに他なりません。

したがって、それより粒度の粗い処理（業務フロー、戦略検討アプローチ等）や曖昧な言語（自然言語等）においてプログラミングで有用なアイデアの適用余地は多分にあるといえるのてはないてしょうか。

プログラミングには、仕事に必要なものがたくさん詰まっている。そう思わずにはいられないのです。

 

こういった考え方にもとづき、本当に仕事のスピードを3倍にしてみました。

きっかけは上司の無茶ぶりだったんですが、やってみればなんとかなるものです。

具体的な方法をこちらの記事で紹介しています。

https://work.naenote.net/entry/one_third_time_limit_innovation