📚

思考の言語化と、技術的負債と、エンジニアリング

2020/10/18に公開

ポエム

エンジニアリング組織論

タイムマネジメント

idea

概要

Amazonで無料で売っていた（？）本を読んだら思いの外良かったので、そのシリーズの有料の本を読んでみたら、なんと、その話題とダイレクトに関連する話題がYAPC2019の講演(1/26の資料)に含まれていた事を知りました。昨日の今日ですね。
そこで、要点を押さえながら簡単に解説します。
ただ、簡単な解説なので、原本はいずれも読んだ方が良いと思います。
※この記事は2019年の1月に書かれたものを再録したものです。

その他の類似ポエム

有料の本

実践！　タイムマネジメント研修: より少ない時間で、より高い成果を出すために実践シリーズ

この本、タイムマネジメント研修という名前だから、タイムマネジメントを扱っていると思うじゃないですか。嘘ではないですが、タイムマネジメントの内容はごく一部です。
というのは、いくら直接的なスケジューリング技術を学んだところで、そのできた時間で不必要な事をやっていたのでは、結局のところ時間はできないわけです。そこで、必要な事に本当に絞って時間を使うための本質的な考え方についてが示されているのが、本書です。

本に書かれていないこと

一般的なタイムマネジメントという内容で想定される、例えば部下からの質問に捕まりすぎないように答える時間を明示して限定するとか、必ず相手の時間を使わないといけない電話は避けるとか、色々なところで聞く（しかしながらメリットもデメリットもあるので見極めないといけない）方法については書かれていません。

本に書かれていること

ある程度まとめると、以下のような内容になります。

思考とは言語化である、ということ
細切れになったタスクと時間のマッチング："クラスタリング"について
- 実は細切れになったタスクを細切れの時間でこなした方が集中している場合がある（まとまった時間は要らない）
  - タスクを細切れにすればどの時間でも入るので、まとまった時間が要るという先入観/固定観念を排する
  - ただし作業興奮が伴うような場合は継続した方が効率良いこともある（システム開発もそれに含まれる）
  - とはいえ集中しすぎると結局は効率が下がってくるので程度を見極める
- したがって細切れ時間には価値があるので、細切れ時間を占有しがちな悪い/非効率なルーチンワークをなくす
必要性の判断と過剰品質の抑止
- 作業は時間など用意された枠に合わせて膨張する（悪いルーチンもそれ）
  - つまり任意の作業は過剰品質に陥る傾向がある
- 仕事は目的→手段の連鎖によって成立している
  - はじめは状況からスタートするが、状況→目的→手段→目的→手段→目的→手段...
- 曖昧な内容でわかった気にならないように注意する
  - 人間は自分の必要なものよりも一段階抽象化した大きな言葉で依頼/話をしがち、それをきちんと掘り下げる
  - 抽象的なスローガンだけで満足しない、自分（たち）にとって具体的なところまで必ず落とし込む
- 「それがあるとどうなるか」と合わせて「それが無いとどうなるか」を考える
- 最初の目的（本来の目的）に立ち返る、末端の目的だけで考えない
  - 本来の目的を言語化する

少し補足をしておくと、言語化しない思考があるだろ、というのは全くその通りだと私は思っていて、言語化できない部分に本質があるとも思います。例えば芸術作品を作る思考をすべて言語化できたら、ある意味天才ですが、しかし天才では無いような気がしてしまいます。アスリートでもそうです、言語化できる事は重要ですが、本当の紙一重の部分は言語化できない何かも存在しているように感じます。しかし一方で、言語化しないと他の人にうまく伝わる形で落ちてこない、という事も言えます。
仕事の成果というのは、芸術作品のようなものを単独で作っていない限りは、他の人に伝えて・伝わってナンボという部分がどうしても存在します。さらに、この本の中で詳しく述べられるように、そのコミュニケーションの失敗や情報の偏在にこそ無駄な時間の本質があるという状況を踏まえると、その意味では思考を言語化であると言い切ってしまえるのです。

無料のスライド

２つのDXと技術的負債-YAPC Tokyo 2019
これです。

スライドのメインテーマと、処方箋としてのビジネス書

下の方に少し書いてある解説（？）から引用します。

（１）「エンジニアリング組織論への招待」の骨子である、不確実性を恐れる人間の本能を乗り越えて、それらに向き合える組織を作ることによって生産的なチームができる。

（２）そして、ソフトウェアを作るとは、「認識に齟齬がないほど明晰な言語に書き下すこと」であれば、これは情報の非対称性を減らすというコミュニケーションそのものだろう。

（中略）

にもかかわらず、この技術的負債現象が問題になる理由は何か。
それは、エンジニアと非エンジニアに情報の非対称性があり、それであるがゆえに
非機能要件のリストに過ぎない、コントローラビリティのためのアクションをとることができない。この非対称性こそが技術的負債と呼び合う現象を引き起こすトリガーである。

つまり、これは、非エンジニアとエンジニアの非対称性の問題なのだ。

※（１）と（２）の番号は私が付けました

このうち、（１）の部分については、まさにPMの話をするためにAmazonで無料の本を読んだら想像以上に良かった話（と本の読み方について）で紹介した本に含まれる内容に通じるものなのでした。こちらの本に記された、組織のあり方やPDCAに関する本質的な考え方というのは、まさに（１）を別の側面から述べたようなものになっています。
（ただし、一般的なビジネス書なので、エンジニアリングやエンジニアリングに合わせた組織の構造というような形では言及してはいません。特に、不確実性を軸としたまとめ方ということにはなっていないですが、PDCAの項で述べられるように「やってみないとわからないことだらけ」という部分に関しては、粗い解像度では同じ事を言っていると思います。）

（２）の部分に関しては、「認識に齟齬がないほど明晰な言語に書き下すこと」というのが今回紹介した有料本における「思考とは言語化である（言語化→思考）」という事と同じことを言っていて、コミュニケーションそのものであるというのも、有料本の主張と多く重なるものです。（細かい部分については末尾の注意を参照）

つまり、最新の講演で取り扱われている課題の本質的な解決策が、じつはビジネス書の中に示されているということなんですね。

もちろん、タイムマネジメント本では、技術的負債というものへの詳細な説明どころか簡単な説明も存在しませんし、エンジニア向けの本でもありません。
しかし、タイムマネジメント本で度々扱われる「在庫管理表」という主人公が抱える課題は、システムを開発している人でも非常に共感できるであろう、複雑な条件で出力する帳票です。この在庫管理表を、もし個人ではなくシステムが扱っていて、この帳票を出すためだけに意味不明なバッチ処理が存在している場面を想像すると、それは紛れもなく技術的負債であると言えるわけです。その意味では、ここでいう技術的負債が本質的に開発の問題なのかというと、そういう事ではなくて、開発というよりもビジネススキームというか人間の営み全般の抱える本質的な問題の一つの顕現である、という見方をすべきとなります。

でも技術的負債って、本当にそうなの？

上記スライドのメインテーマについては正しい話だと思うのですが、一方で、でも…と思う部分もあるので、それを一応書いておきます。（トゥートより）

私は本質的にひねくれ者なのか、技術的負債を判断のつかない非機能要件と定義すると、どうしても純技術的負債(例えば知識不足でメール送信元の逆引き設定してないとか、謎モデル作ってるとか、コピペ駆動で修正箇所が山ほどあるとか、インデント乱れとか、処理が遅いとか、その他素朴にバグってるとか！)が気になってしまう。
ただ、判断のつかない非機能要件のインパクトが最も大きいであろうというのはその通りで、昨日買って読んだタイムマネジメントの本の一番大事なテーマがまさにそれ。

一般に技術的負債というのは、確かにコミュニケーションロスや状況の変化に対応しきれていない過去の要件の積み重ねなどが含まれますが、単純に技術力の無い状態/人が書いたコードや、十分なテストができていないコードなども含まれます。そして、それらは技術の新陳代謝の速度と合わせて、単なる要件の陳腐化以上に重くのしかかるものでもあります。例えばセキュリティの問題などは、古くから多用されているサーバーでは沢山出てきますが、そうした意味での技術的負債は情報の非対称性を解決すれば良いというものでもないです。
もちろん、技術的な情報が組織の中で揃えば、しょぼい書き方をする人は減るでしょうが、必ずしもそれだけではない、という事は記しておきます。

そうは言っても、問題の根本的な部分を占めるのは、非対称性の部分であるということへの異論はありません。そして、それは開発に限った話ではなくもっと普遍的な話であって、例えばビジネス書には解決策が端的に示されている部分でもあったのでした。

結論

良い本だから、タイムマネジメント本を読もう！

appendix

注意…

有料本では情報の「非対称性」については言及していません。偏在していることまでしか言及をしていないのです。しかし、情報の非対称性は偏在の一つの形であり、情報の偏在＝理解していない情報の存在が無駄な仕事につながっているという主張をしているという点においては、「非対称性を減らすコミュニケーション」というのは「偏在を減らすコミュニケーション」という理解で良いでしょう。なお、情報の偏在の問題については無料本（＝チームマネジメント本）でも扱われています。

その他の雑多な感想

もともと、タイムマネジメントの本はプロジェクトマネジメントについての話をするにあたっての準備で読んでいたという背景があるので、感想を垂れ流していました。
その感想もまとめて添付してみます。

タスクの分割の話は追加しよう
手戻りの話からだな
細かく分けるのもそうなんだけど、システムみたいに積み上げるものはひとつひとつを確実に仕上げる必要がある
それをどうやって担保しながら作業するかという話

開発の仕事の場合は、よほどの場合を除けば常に開発をしているはずなので合間で時間を空けるとかはそんなに現実的ではないんだけど、かわりに思考停止して時間を使って作業してるところを減らすのと、そもそものタスクの手戻りや手が止まるレベルの思考停止や試行錯誤を減らして順調に流れるようにする。

「３０分かぁ、３０分じゃなんにもできないなぁ！」
言ってみたいな。5分でも仕事はできる(メール返信とか)けど、30分でも障害や改修のちょっとした事は１つ２つできる。昨日、30分で１つ直してリリース、20分で別の１つ直してリリースした。特定の処理をするときの保存項目の追加みたいな作業だけど。

すぐ後にメールの事は時間が伸びやすいタスクとして書いてあったw
ただ、社会人になってから時間が余るとか暇とか一度も思った事ないから、ある意味羨ましいかもしれない
どういう事をしてたら暇になるのかわからない感じ

受付業務で業務量に差が出るときというのは、引き受けた人が責任を持って処理しなければならないという、思い込みが原因であるケースが多いんです。

これは受付業務とかじゃなくても、どんな仕事でもそういう思い込み発生しがち
大半の仕事は、ある瞬間だけを切り取ればその人必要かもしれないけど、本質的にはその人が要らない形が会社として正しい。という考え方で仕事もタスクもこなしたい。

わかった気にならないようにするのは、打合せとかでとても大事。それを意識しないと、後の工程が進まなくなる。これは(自分が聞く方なら)聞く方の問題だと私は思うんだけど、そう思えるかどうかが勝負の分かれ目。自責に倒す傾向があると、じつはこの辺の話題は全て数年仕事すれば拾えるんじゃないかなあと思っている。仕事がうまくいかない一番大きな原因詰めていくと、自然とこの本に書いてある話になると思う。時間の使い方もタスクの分割も分かった気にならないようにするのも。

個人の作業的な仕事だと過剰品質になる傾向があるけど、開発の仕事は逆で、たしかに部分的に過剰品質になる事はあるけど、顧客の要求に対しては機能不足とか品質不足になりがち。これがシステム開発が本質的に難しい事を示唆しているんだろうなと思う。変なところが作り込まれてる場合はもちろんあるけど。

タイムマネジメントの本、本来のなぜなぜ分析では無いけど、何故なぜなぜという考え方が必要なのかということが書いてある。開発からしたらマジかよと思いがちかもしれないけど、実情はそんなもんだよなと思う話が沢山ある。
この本の登場人物も、一々子供っぽいように見えるけど、それは実際がそんなもんだという主張でもあると思う。例えば、講師が土曜日もスーツ着てて「こだわりあるのかな」とは普通は考えないだろうけど、でも考える人もいるし、ピンポイントにそういう事でなくてもそういうものだ、という話。

私たちは目的の連鎖のほんの入り口のところだけでわかった気になり、残りの部分を推測で組み立ててしまう。

これ、開発の仕事だと残りの部分を推測で組み立てようとすらしない人を沢山見かける。自分の仕事終わったら終わりパターン。だから過剰品質も見かけないというか。まードキュメント過剰という場合もあるんだけど、個々のプロジェクトで判断できる環境かどうかも結構違うからなあ。
目的ベースで相手のことを考える話は追加しよう。

タイムマネジメントの本も読み終わった。
タイムマネジメントというよりは、どちらかというと普通に無駄をなくすための方法なんだけど、本質的だからまーいいかなという感じ(みたいな書評あったけど)
本当は新人が読むべき内容だと思うけど、新人だと想像できないのかもなー
でも、感情移入はしやすいから、素直に読めるなら新人向けだと思う。
無料本も、たぶん本来的には新人時点で知っておくべき内容だと思う。