※本記事は、NorthDetail Advent Calendar 2020の一環として投稿しています
Northdetailの近藤です。
今年もクリスマ・・・アドベントカレンダーの季節がやってきました。
私のアドベントカレンダーのテーマは、「どのような案件、役割でも使えそうな（自己）管理系のTIPS」です。
ソフトウェア開発者はもちろん、その他の業務に関わる人にも利用できそうなものを選んでいます。
ひとつひとつのTIPSは些細なものですが、たくさん集まればきっと役に立つ…かもしれません。
作業の手順をリストに書き出すことで、手順の流れやその内容の改良をし易くなります。
何かしらの作業を行うときは、無意識のうちに自分にとってやり易い方法を採用しがちです。「指先の器用な人が爪で金庫を開ける」という言葉があります。自分のしようとしている方法が適切かどうか見直す機会を作るのは大事です。
また、作業リストを作っておくことで、他人に作業を委任するときに作業齟齬を減らして引き継ぐことができるようになります。
当たり前だと思っていることでも、状況や環境に結びついて記憶していることは少なくありません。出かけるときに普段使っている鞄を別の鞄に変えただけでも忘れ物をするようになることがあります。チェックリストは、状況や環境に左右されずに残り続けるので、変化や人の曖昧さ（気分や調子のぶれ）をサポートしてくれます。
ただし、チェックリストはなぜその項目をチェックするのかという理由を理解し、内容をアップデートしていかないと形骸化してしまい、いい加減な扱いをされる恐れがあります。
物事をプロス（賛成）とコンス（反対）のそれぞれに分けたリスト。プロスリストとコンスリストの２つがくっついた形になります。リストの各項目に重要度などの点数をつけることもあります。
何かを判断する際に、良い面だけの事柄や悪い面だけの事柄というのは滅多になく、良い面と悪い面の両方を持っていることが一般的です。それも自分の立場や状況によって、同じ事柄でも良い面に見えたり悪い面に見えたりします。
プロコンリストは良い面と悪い面に分けて事柄の要素を書き出し、それらのバランスをみて総合的に良し悪しを判断します。
良し悪しの判断は主観的なものになりますが、自分がなにを良い・悪いと判断しているかが明確になるので、他者への説明材料としても使うことができます。
他の人に任せることができる内容のリスト。どんな内容なら、誰に安心して任せることができるかを予めリストにしておくことで、作業が溢れそうなときに他の人の力を借りやすくなります。人の力は自分自身の力に加えて、協力してくれる他者の力を足した合計になります。委任リストを作っておくことで、自分一人分の力を超えた仕事にも対処できるようになります。
人のコンディションは一定していないのが普通です。調子の良い日もあれば悪い日もあり、１日の中でも調子のいい時間と悪い時間があります。自分のコンディションの波と、波を生む要因を理解して、それに合わせた作業をすることで、全体として作業品質がよくなります。
作業を実際に処理する前に、処理の品質と効率を上げるために次のようなことを考えます。
当たり前のことのようですが、意識していないと自分の馴染んでいる方法で処理したくなり、優先順位付けや作業効率化が見過ごされます。
考えておくだけでも効果はありますが、文字に書き出すとより効果的です。
処理を完了した後は、実際の処理手順を書き出してストックしておきます。
これには次のようなメリットがあります。
（TIPS 1の作業手順リストと同じ）
ロジックツリーは、問題や概念を段階的に細かくしていく図です。
ロジックツリーという名称でなくても、どこかで目にしたことがあると思います。
考え事、検討事項、悩み事などをロジックツリーに書き出すことで、自分がそれらの事柄をどのように認識・理解しているかが一覧になります。これを人に添削してもらうことで、見落としている事柄や自分には無かった視点を見つけることができます。
※法則の内容について説明すると１記事が埋まってしまうので、ここではかなり省略しています。
物事の80%の部分は20%のもので成り立っているというもの。
何しらの制約がある作業をする場合、最初に全体の80%に影響する20%の部分から初めます。すると20%の時間で80%の完成度のものが出来上がるので、残ったリソースで完成度を81%から徐々に上げていくことができます。
逆を言うと、80%のリソースを使っても全体の20%にしか寄与しないことがあるので、どの部分が物事の中核になるか見極める目が大事になります。
複数の要素からなる物事は、その要素の中で最も低い（小さい）ものが全体の基準になるというもの。
四角形のコップの側面が、それぞれ15cm、13cm、11cm、5cm、の長さでできているとすると、コップには5cmまでしか水が入りません。リービッヒの最小律は植物の成長についての説ですが、転じて複数の要素のうち最も小さいもがその性能になるという説明に使われることがあります。
ソフトウェアは複数の機能が組み合わさってできています。あるタスクの処理能力は、最も弱い機能の処理能力によって制限されるという場合でもリービッヒの最小律を見ることができます。
ソフトウェアではボトルネックという言葉の方が馴染みがあるかもしれません。注意すべきなのは、最も弱い部分を補強するのが常に良いことではないということです。最も弱い部分は最初にシステム異常が発生する箇所でもあるので、エラーの発生をある程度コントロールできるという意味でもあります。全てが同一の強度を持っていると、異常がどこから起きるか分からなくなり、起きた場合も対処がより大変になる傾向があります。
仕事に必要な時間は割り当てられた時間を全て使用するまで増加するというもの。
プログラムが動くのに十分なだけのリソースがあったとしても、時間の経過とともにリソースの上限いっぱいまでリソースを消費するようなプログラムが書かれるようになり、最終的にすべてのリソースを使い切ってしまいます。
高級言語でのプログラミングではメモリの消費やCPUクロックの最小使用が大事とされてきましたが、ハードウェアの高性能化に伴い、メモリは節約するよりも安全に使うことに重点が置かれ、クロック数を抑えるよりも可読性がよく保守しやすいコードの方がよいとされるようになっていきました。
開発においては、初期のプログラムは安全で確実に動作するものを作り、後から時間があればリファクタリングをしようという方針を取ることがあります。しかし、リファクタリングにゴールの基準を設けていなければ、リファクタリングの基準はどんどん上がっていきいつまでも終わらなくなることがあります。
能力主義の社会では、有能な人物は出世し続けるが、やがてその有能さが発揮できない段階まで出世すると、その役割に対しては凡庸な（または無能な）人物として評価され、やがて全てのポストが無能な人物で締められるようになる。
優秀なプログラマーがその優秀さからチームリーダーやチームマネージャーに昇任することは、ソフトウェア開発では珍しいことではありません。しかし、優れたコードを書く能力とリーダーやマネージャーとして必要な素養は同じではありません。
あるポストについている人が期待する能力でないとしても、それは構造上の問題で個人を責めるものではないかもしれません。
能力不足で説明が可能なことに、悪意があると思ってはいけないというもの。
優れたプログラマーでも、あらゆる分野のプログラミングに十全であることはありません。ましてやたまたまソフトウェア開発の担当窓口に割り振られた顧客が、ソフトウェア顧客として有能ではなくても不思議ではありません。単に知識や経験の不足で開発者と足並みが揃わなかったとしても、そこに悪意を見出すのは尚早かもしれません。
相手が悪意を持っているのではなく、能力が足りなくて困っているのだとしたら、開発をよい方向に変えられるように働きかけることができるかもしれません。
