職場のISTPをうまく使う方法(エンジニアに限ると思う)
最近、16タイプの診断(MBTI)を知って、僕はISTPというタイプであると判定されました。かなり当てはまっているなぁと思い、他の人からのISTPについての印象、逆にISTPの人の考えてる事なんかを面白がってnoteで読んでいます。
自分でも何か書いてみたいなと思ったので、初投稿です。仕事についてです。エンジニア職なので、エンジニアとしての話しかしません。
とりあえず、エンジニアというのがどんな生き物なのかを知ってもらうことから、本文を始めます。
■プログラマーの三大美徳
「プログラマーの三大美徳」という、プログラマーが自分たちの活動において大切にしがちな価値観をキャッチーにまとめた標語？みたいなものがあります。結構強い言葉だからなのか、あんまりいい意味で使われないこともあるのですが、座右の銘にしてもいいと思うくらいには、昔から気に入っている言葉です。
（エンジニア＝プログラマーではないけれど、そこはいったん目を瞑ってほしいです。）
プログラマーの三大美徳は以下の３つです。
1. 怠惰
プログラマーは怠惰な生き物です。つまらない単純作業は大嫌いで、どうにかしてそれをコンピュータにやらせようと日々考えています。例えば、Excelで定常的に同じような集計作業をしなければならないとき、すぐにそれをマクロ化したくなります。仮にそれがたった10分の作業であり、マクロの作成に数時間を要するとしてもです。
もちろん仕事ならば、作業効率の向上によるリターンと、効率化のために支払うコストとのトレードオフが判断基準です。
ただ、ここで言いたいのは「信頼できる作業手順があっても、より良い方法が存在することに気付いたなら、新しい方法で勝手にやり始める」性質があるということです。
2. 短気
プログラマーは短気です。自分たちは怠惰であるくせに、コンピュータが怠惰であることには強く腹を立てます。処理が遅ければサッサと動くように改修したくなります。画面に出るシステムからの指示が、ユーザーへの配慮の欠けた分かりにくいモノであれば、それを書き換えたくなります。
「完成」はなく「改良」を求める性質があります。
3. 傲慢
プログラマーのつくる製品には、多くの場合、仕様変更が求められます（リリース前、後どちらであっても）。
ですがプログラマーは傲慢なので、どんな変更が起ころうが、それに耐えられる拡張性を持ったプログラムを書けると、自分たちの能力を信じて疑いません。
以上がプログラマーの三大美徳です。このような考え方が美徳とされるわけで、かなりISTPっぽさが文化として根付いているように感じます。「ISTPはエンジニアに適正アリ！」とされる所以の一つではないでしょうか？
エンジニアのことをちょっとでも理解していただけたと期待して、ここからタイトルの内容に入っていきます。
■ISTP取説（計画、要件定義工程編）
ISTPは計画性がない、という解説が散見されるように思いますが、ちょっとステレオタイプ気味な理解のされ方が多いです。計画立案のすべてがまるでダメってわけではありません。
まず、ISTPは課題の解決のための具体的な手段を考えるのが好きと言われてますが、それには完全に同意します。
だからこそ、プロジェクト計画を立てるとき、プロジェクトで解決したい課題へのタスクバラシや優先順位付けは得意だし、大好きです。
旅行とかデートプランとか、課題でも何でもない、正直目的なんか無いだろっていうような物事に対しての思考が苦手なだけです。
お仕事では計画フェーズからISTPを頼ってください。竹槍で戦闘機を落とせ！のような無茶振りプロジェクトであっても、理不尽に反発するよりも何だかんだで竹槍をミサイルに改造する方策を考えはじめるのがISTPです。
ただし、「期間内でそのシステム作りきれる？」といったケイパビリティには興味を持たないので、必要と思うタスクならば、遠慮なく積みすぎることもありがちです。
「後続の工程で頑張ればどうにかなるでしょ。今は課題の解決のために必要なものを洗い出す時間だからいいよ。」とか思ってます。厄介なことに、周りに一切の期待もしてない自信過剰マンなので、「後続の工程でタスク溢れたら自分がリカバリーに入ろう。誰にも迷惑かかってないから大丈夫。」とか、プロジェクトにリスクを背負わせていることにも気づいていません。
一般には、そういったタスク溢れのリスクを感じたらシステムの機能を縮小するべきなのですが、これはユーザーにとって不都合となることは間違いなく、縮小の調整は容易ではありません。
かといってISTPが機能を削ろうとしないのは、別にユーザーへの遠慮とかではなく、本気で自分の力でやりきれる自信があるからです。その気になれば容赦なく機能を削れるメンタルも隠し持っています。
ISTPは、MECEに必要なシステム機能を洗い出し、伴うタスクを出すでしょう。間違いないものを出してるつもりです。ただし、タスクが計画にハマるとは言ってないので、注意してください。
■ISTP取説（設計〜製造工程編）
設計して設計書を書く工程を設計工程、また、その設計に従いプログラミングをするのを製造工程と呼びます。
ここはイメージ通り、楽しんでやってます。
ただ、「どうやって、どんなものを作るのかを考える設計工程」のほうが、「実際に手を動かしている製造工程」よりも楽しいです。これはISTPの「手触り感を大切にする」という特徴とは矛盾して聞こえるかもしれません。
システムは目に見えないデータ構造の概念であり、その形状はサーバーの中か、エンジニアの頭の中にしか存在しません。
ISTPに限らず多くのエンジニアたちは、設計書やプログラムのソースコードのことを「目に見えない概念を言語で説明しているドキュメントである」と認識しています（プログラミング"言語"と呼ぶことからも明らかです）。
エンジニアのものづくりはキーボードを通してではなく、脳内で発生しています。設計工程でものづくりをし、製造工程で脳にあるものをプログラミング言語を使ってコンピュータに説明してあげているのです。だから、設計のほうが楽しいです。
この工程では、作業の時間を与えて貰えれば満足です。時間の与え方ですが、作業中はチャットアプリとメールアプリを終了し、レスポンスが1〜2時間完全に途絶えることを許可してください。2時間後にはちゃんと返事するので。そうしてくれませんか。たのむ。
■ISTP取説（テスト〜リリース）
製造後は、その製品をテストし、最後にユーザーのもとへリリースします。
このテストからリリースにかけての活動は、設計したとおりに動くかどうかを確かめるだけなので、予め用意したテストプランを粛々と進めていくことになります。つまり、前工程までの楽しさとは裏腹に、単純作業の繰り返しです。
この工程では正直もうプロジェクトに飽きています。パフォーマンスも落ちます。何か新しいことを探し始めていますので、例えばその製品をリリースしたあとのバージョンアップ計画（機能の追加）など、テスト後にまた開発の楽しみがあると教えてみれば、多少元気になります。
本当はリリース後の運用とか、アジャイルの経験主義の話とかもISTPと絡められそうなので書きたかったのですが、長くなりすぎるのと、正直飽きてきたので、いったんここまでで投稿します。
あくまで上の話は僕の感じ方の話なので、エンジニアとかISTPとか、主語を一般化して書いたのはエンタメだと捉えていただきたいです。世の多くのエンジニアはとっても真面目でいらっしゃいます。
この記事が気に入ったらサポートをしてみませんか？