非エンジニアの業務にも役立つエンジニアの思考法

エンジニア
業務効率化
約5分で読了

SHARE

インプットポイント

エンジニアの思考法は、日常のルーチン業務の削減に役に立つ
日常のルーチン業務をエンジニア的思考で削減し、本来取り組むべき業務に取り組む工数を作りましょう

このマガジンをご覧の方は、どちらかと言えばいわゆるビジネス職（営業やマーケティング職）の方が多いのではないでしょうか。
そのような方々が、いわゆる開発職（プログラマー、エンジニア）に対して抱く印象といえば「やる気がない」「文句ばかり言う」「相手の気持ちを考えない」「自分勝手」などなど、決して良いものではない、というのが一般的な傾向であるように感じています。
しかしながら、生産年齢人口の減少やDX需要の高まり、それらに伴う採用難、またノーコード開発ツール等の登場により、非開発職の方であってもエンジニアリング知識やエンジニア的思考を要求される業務は今後増えていくことが予想されます。
また、一見ビジネス職とは水と油、全く相容れないように感じられるエンジニアの思考も、紐解いてみれば生産性の向上に繋げられる価値観も案外多いものです。
本日は、非エンジニアであっても業務に活かすことのできる、エンジニアの価値観や思考法についてご紹介します。

プログラマーの3大美徳

最初にご紹介するのは、プログラマーにとって大変に重要な資質を簡潔に表現した概念であり、プログラマー的価値観の根幹とも言えるもので、俗に「プログラマーの3大美徳」と呼ばれています。
プログラミング言語のPerlを開発したラリー・ウォール氏が提唱したものであり、

怠惰(Laziness)
短気(Impatience)
傲慢(Hubris)

と、キリスト教における7つの大罪のようなラインナップです。
一見、美徳とは正反対と思われるワードが並んでいますね。
しかし実際に意味するところは

怠惰：大量のルーチンワークを面倒がり、自動化する
短気：出来の悪いプログラムに憤り、より良いものを作る
傲慢：自らの成果物にプライドを持ち、常により良いアウトプットを出せるよう自己研鑽する

です。これは非エンジニアにとっても非常に納得感があるのではないでしょうか。
（余談ですが、エンジニア文化は多分に「空飛ぶモンティ・パイソン」から影響を受けていると言われており、このように敢えてイメージの悪いワードに真逆の意味を持たせる表現や、不条理な表現がよく使われます。おしゃれですね）

大量のルーチンワークを人海戦術で処理していた、またそれが可能であった時代と異なり、現代では決まりきった定型作業を人的運用で繰り返すのはコストが合わなくなってきています。

非エンジニアであっても、「プログラマーの3大美徳」を胸に、日々の雑多な繰り返し業務は可能な限り自動化し、自動化の精度を日々ブラッシュアップし、捻出した工数によりクリエイティブな業務に集中することで、常に自ら胸を張れるアウトプットを出し続ける、という姿勢が求められているように感じます。

（AmazonやGoogle等のシリコンバレーのテックジャイアントでは、2回以上繰り返し行う処理はプログラミングにより自動化する、という行動指針が価値観として染み付いていると聞きます）

KISSの原則

次にご紹介するのは「KISSの原則」と呼ばれるものです。

これは「Keep it simple, stupid.（シンプルにしておけ、この間抜け）」もしくは「Keep it stupid simple.（シンプルで愚鈍に保つ）」の略であり、もともとはロッキード社にて第二次世界大戦中の名戦闘機である「双胴の悪魔」P-38ライトニングや、ロッキードマーチン社時代にはスカンクワークスで超音速偵察機SR-71ブラックバードの開発に関わったクラレンス・レオナルド・ジョンソン氏が提唱した概念とのことです。

我々はVUCAの時代とも言われるような複雑怪奇な時代を生きているわけですが、複雑なものを複雑なまま放置してしまえば、いつかはその内容を読み解き理解することが出来なくなり、メンテナンスも改善も出来なくなってしまいます。

そのまま実現しようとすれば複雑になってしまうものこそ、いかにシンプルに出来るかを考え抜き、またシンプルな状態を保ち続け、常に改善が可能な状態を整えておくという考え方は、これからの時代全ての人にとって非常に重要な行動指針になると考えています。

YAGNI原則

最後にご紹介するのは「YAGNI原則」です。

これは「You ain’t gonna need it.（んなもん、いらんやろ）」の略です。
つまり必要なものは必要なタイミングで作るべきであり、いま現在必要でないものを、後から必要になるだろうという予測のもとで先に作っておく、というのは避けるべき、という考え方です。可能なかぎり在庫を持たない、トヨタのJust in time方式にも通じる部分があります。

（あくまで、リスクヘッジとして必要なものまで省くということではなく、必要になるか分からない将来の拡張性のために事前に手を動かす必要はない、ということを述べている点には注意が必要です。）

例として自動車を挙げれば、かつては当初2,000ccの排気量でリリースする予定のエンジンを、将来的に3,000cc超の排気量までの拡張を見越して設計しておく、ということは普通に行われていました。

しかし現在では、将来的な排気量拡張のためのシリンダースリーブの余裕は即ち余計な重量増を招き、燃費を悪化させる結果に繋がってしまうことから、最初から必要な性能を見極め、限界を狙った設計をすることが常識になっています。

極めて変化の早い時代に生きている私達は、いつか必要になるかもしれない（必要にはならないかもしれない）ものを転ばぬ先の杖として作っておくよりも、今現在必要とされているものに絞り、シンプルに作って素早くリリースする、という立ち回りが求められているのではないでしょうか。

まとめ

本日は、エンジニアの思考法を理解するための例として、プログラマーの3大美徳と、KISSの原則、YAGNI原則を紹介しました。

いつも不機嫌で、なにか頼めば嫌味を言われ、みんなで一丸となって頑張ろうとしている雰囲気に水を差すようなことしか言わない、とエンジニアに苦手意識を抱いているビジネス職の方も多いと思いますが、エンジニアの思考のベースとなる価値観の一端を理解することで、自身の業務にそのエッセンスを活かすことができるかもしれません。

特に営業の場面では、一見無駄な業務であってもお客様と一緒に汗を流した感を演出することで、信頼感を醸成し受注に繋げる、というテクニックも非常に有効であり、全てにおいて効率性を求めることが必ずしも正解であるとは言い切ることはできません。