エンジニアに必要な思考

目次

主軸2つ
レベル1_新人向け
レベル2_ある程度動ける人向け
レベル3_リーダーできる人向け
レベル4_ﾁｮｯﾄﾃﾞｷﾙ
要点まとめ

はじめに

この記事はSE（SI）としてプロジェクトに関わっていく上で持っておくといい思考法に関するものです。
割と主観多めなので、アレルギーのある方はご注意ください。

本題に入る前に

この記事を生かすために必要なことは以下です。
まぁきっと何をするにもそうなんですが...
ものすごい好き！とかでそんなの意識しなくてもガリガリやれる人は、本能的にできているので問題ないかと思います。

・謙虚
・トライ&エラー
・守破離

謙虚

謙虚でなければ、観測するデータにバイアスがかかります。
ここバグってるはずないんだ！という傲慢のせいで、エラーログがまったく別のものに見えたりします。

トライ&エラー

とにかくトライし、とにかく失敗したら調べて次またトライ。
百聞は一見に如かず、とにかく動かせばいいんだよ！！そのほうがはやい！！
ここでも謙虚に、「足りないオツムで考えるよりとにかく動かせ、機械のほうが賢い」と割り切れるかです。

守破離

学びのステップは大まかに3ステップになります。正直①と②は同時にできるので同時でいい。
①まずは周りにいる先輩やすごい人から盗み
②こんどはネットなどから、どんどん知識を吸収し
③最終的には、自分でソリューションを作る

「守」は、師や流派の教え、型、技を忠実に守り、確実に身につける段階
「破」は、他の師や流派の教えについても考え、良いものを取り入れ、心技を発展させる段階
「離」は、一つの流派から離れ、独自の新しいものを生み出し確立させる段階

守破離（しゅはり） の意味
※引用元: goo国語辞書

主軸

前置きが長くなりましたが、主軸はこちらになります。

1. ありのままの事実をとらえ分析する
2. 対象・相手をおもいやる

まずはこの2軸について説明します。

主軸その1

ありのままの事実をとらえ分析する

まずは無知の知を自覚するのだ。きみは何も知らない。
なぜ仕事してる？生きるため？ではなぜ生きている？楽しむため？それはなぜ？
無限に問いかけてください。
わかるわけがない。知っているわけがない。知る必要はそもそもあるか？

つまり、あなたの意見なんて知ったこっちゃないんです。言い過ぎ
それってあなたの感想ですよね？ って言われるような意見はいらない。

あるのは事実のみ。徹底的にありのままのデータを取る。とにかくデータ。データ最高。
ではどうやってデータを採取しよう？どのくらい？どんなデータが必要？いつまでに？どこに置く？

いつだって人間の行動は5W1Hです。基本的には5W1Hにのっとってデータを採取します。
いつ起きたバグ？どこで？なんの契機？何が悪かった？ etc ...

熟練すれば、「こういうときは、ッ..!! ここにきっと..! これが肝じゃぃ！！」みたいな変態みたいな観点から
核心をつく事実やデータを持ってこれるようになります。

人間は歴史を学びます。それはなぜか。
過去の事象、経験、データから未来を予測できるからです。
人の特権「学び」の最大の成果は、データ観測から始まる、分析結果を活かした行動です。
よって全ての基礎である、データ観測を正しく行いましょう。

主軸その2

対象・相手をおもいやる

チェス盤をひっくり返す という言葉があるようでして
「相手と自分の立場を入れ替え、相手の思考・戦略を推測する」
ことらしいです
ここでは
相手の置かれている状態、相手がいま持ってる前提知識を想定しようなっていう意味で使ってます。

いきなり「ねね、アレってやっぱアレだった？」とか言われても意味わかるわけがないですが
「昨日のテレビ番組の〇〇、やっぱりY〇utubeの引用だった？」と聞かれれば伝わります。

仕事中、要件の確認がしたいときに
「機能Aって〇〇ですか？」と聞くより、

「〇〇ジョブの要件の話で、認識合わせしたいんですけど、機能Aってあるじゃないですか」
「これ〇〇だと思うんですけどあってます？」
と、いまこの話題ですよアピールをしてあげると、とても伝わりやすいですね。

会話でなくとも
コードや設計書を書いているとして
誰のために書いてますか？
後の自分や、後の改修する人のために書きますよね？
システム開発ってそういうものなので、未来の人のために残しておくものです。
では、未来の人の気持ちになって書きましょう。
...ってだれだよ！ってなるので

エンジニアでもなんでもない道端のおっさんとか、小学生に対して説明するつもりで書きましょう。
するとどうなる？
親切に見えて無駄に長いドキュメントも、必要最低限の要点だけ押さえた文章になります。

また、関数のドキュメントなんかは、中で何やってるかも大事ではありますが
「どうやって使うの？」「結局なにをしてくれるの？」「入れちゃいけない値とかある？」「どんなエラー吐くの？」
が大事。
まぁだからJavadocでいうところの「@param」「@throws」とかがあるわけですね。先人たちによる理にかなった形態は
この人の気持ちを考えた説明が根底にあるのではないかと考えています。

では実践

レベル1_新人向け

1. ありのままの事実をとらえ分析する

結論が何かを一言で答えられるようにしよう。

1. 開口一番
   まずは結論をいきなりしゃべる癖をつけましょう。
   進捗どうですか？の質問に対して、「今これやってまして～」とかはいらない。
   一番最初に「順調です」「よくないです」を伝える。次に理由や細かい状態を伝えよう。

2. 中途半端は一番の敵
   あいまいなこと、中途半端な状態は、やってない状態より悪いです。
   言葉でも同じ。調査結果などでも同じ。
   言い切りの癖をつけましょう。けど嘘はいけません。
   100%は終わってないが8割くらい終わっているときに「ほぼ終わりました」は最悪です。もう破門です。
   8割終わってるときは「8割終わってます」って言いましょう。
   「あと少しで～」とかもいらない。「今日の○○時までに終わります」や「あと30分で終わります」という。
   さすがに未来のことについては根拠なんてなくてよい。終わらなさそうなら早めに「やっぱ終わんないっす」って言えばよろし。
   ※(実践した結果、さらに気をつけたいポイント)→簡潔にコミュニケーションを取ろうとするあまり、必要な情報を一回で収集できないことがありました。
   慣れてきたら、質問する前に回答の想定をして、「○○という回答だったらこれが必要になるな」など先のことまで考えられるように訓練していきたいです。

2. 対象・相手をおもいやる

言葉使いに気を付けよう。

1. 正しい名称で発言
   いくら短縮できそうだからって、いくら似てるからって、正式な名称以外を使わないこと。
   「データベース」と「テーブル」の違いだったり「API」と「IF」であったり
   すごい似ているが、場面によって別の捉え方もできちゃうSE業界の用語は結構多いです。学んでいこうな。
   似てるけど違う言葉を使ってしまうと、相手が
   「(…? たぶんこういう意味で発言してるんだよな) ○○のことであってる？」
   という、無駄な思考と、無駄な問い返しが生まれます。
   いくら長くても、定義通りの名称を常に使い続けましょう。確実に伝わるし、誠実な人ってイメージも付きますね‼やったぁ！
   ※(実践した結果、さらに気をつけたいポイント)→実施に現場であった例として、あるpropファイルが存在していて、あるドキュメントでは「プロパティファイル」、別のドキュメントでは「共通設定ファイル」と呼んでいました。
   元々ある資料で既に統一が取られていないことはザラですので、あくまで自分の発言は統一しますが、他者やドキュメントからのワードがブレブレの場合でも分かるように、「1通りしか覚えない」はお勧めできません。
   また、現場によりますがユビキタス言語を策定すると統制が取れます(参考)。参考記事にもありますがDDDなんかでは客先とのドメイン仕様周り等で、エンジニアとの常識がズレていることで客先言語、業界言語に準ずることが難しいことがありますので、共通言語はとても大切。バベルの塔を築くのだ

レベル2_ある程度動ける人向け

1. ありのままの事実をとらえ分析する

結論が何かを一言で答えられるようにしよう。

1. つまりなに？を自問自答
   これを日常でずぅぅぅぅぅぅぅぅぅぅぅっっっっっとやってください。
   癖になるまでやりましょう。
   ・ご飯がおいしい→つまり？→醤油ベースがおいしいと感じる→つまり？→自分は醤油が好きである傾向が強いと判断できる
   ・ソースの100行目がセットする値まちがえてる→つまり？→仕様通りでないプログラムバグを発見した→つまり？→報告/修正etc...
   ・ロジックの書き方がわからない→つまり？→○○の方法と××の方法がわからない→つまり？→調べてみる
   ・ロジックの書き方がわからない→で？→△△をしたいができない→つまり？→△△さえできればなんでもいい→で？→あれそもそもやる必要なくね？...
   ・何か問われたが何言ってるのかわからん→つまり？→相手が何をしたいのか、何を聞きたいのか知る必要→で？→質問し返す
   などなど。魔法の言葉「つまり」「で？」を癖にしましょう。
   ※(実践した結果、さらに気をつけたいポイント)→簡単に癖にならない
   これは習慣付けるテクニックなので本文とはずれますが、「朝食後に必ず本を2分読む」「電車に乗ったらY○utubeじゃなくて本を10ページ以上読む」等、無理のない範囲で必ず〇〇をする、という具体的な自分ルールを作ると良いです。

2. 対象・相手をおもいやる

前提を意識しよう。
言葉使いに気を付けよう。

1. 相手の前提を考える
   相手も仕事中です。こっちの都合でいきなり別の話題に頭を切り替えてもらうんだから
   親切に「いまからこの話しますよー」の準備運動させてあげてください。
   話題を持ち掛けるときは「○○の話なんですけど」
   細かい話をするときは「細かい話になるんですが」

2. 指示語撲滅
   相対的な言葉は、すべからく分かりにくい。
   そのとかそれとかの「こそあど言葉」は会話中ですら不要。なければないほど良い。
   （流石に直前までズットその話してて伝わるってときは良いが）
   「それがさっきの原因でした」とか言われると、「えっと、、○○だったことが、××のバグの原因だったのね？」って
   無駄ラリーになります。
   言葉を伝えるときは省略せず、楽しようとせず、しっかり全部伝えましょう。
   どうしても指示語を使いたいときは、身振り手振りで絶対に伝わるように「「「「これ！！！この今指さしてるこれ！！！！！」」」」ってくらいしちゃえばいいよ。

3. 体言止めを用いない
   体言ってなんだ？？？な人はこの記事が参考になるので読んでね。
   ドキュメント上で、「どっちの意味にもとれちゃう」は最悪です。書いてないほうがまだいいわ。
   ドキュメントは、信用できることが前提です。ので、誤った意味で理解したまま先に進んでしまいます。
   いつか大きな手戻りの原因となります。

- 「データを取得し、そのループで前の項目と一致しているか確認」
+ 「取得したデータでループする。関数preCheckで取得した項目と一致していればtrueを返却する」

レベル3_リーダーできる人向け

レベル2までが癖になっていると、レベル3以降は直感で進むことが多くなってきます。
ここからはSE系の業種に少し特化した思考に近いように思います。

また、こちらの記事 最初から強いやつの特徴にあるような項目は、レベル3までが出来ていることで全て実現できるように思います。

1. ありのままの事実をとらえ分析する

骨と肉を意識しましょう。
必要十分条件を意識しましょう。※数学よわよわな人はこちらを参考。

1. その事実は骨ですか？肉ですか？
   骨とは、重要なもの。肉とは、副次的なもの。
   DBでいえばマスタが骨で、トランザクションは肉ですね。
   ソースコードでえばビジネスロジックが骨で、バリデーションだったりが肉です。
   無論ケースによりますが。
   骨か肉は、おおまかに自分の中で基準を持っておきましょう。
   1次切り分けとして活躍します。

2. できたことをファイルツリー構造でまとめてみよう
   何かの案件dでむっちゃエラーとかが出たとき、とりあえず整理しますよね。
   整理の1次切り分けとして骨肉、次にカテゴリ分けのようなイメージで、ファイルツリー構造のようなイメージでまとめてみましょう。
   骨(だいじ)
   ├ ポイント1 - ...
   └ ポイント2 - ...
   肉(まぁまぁ)
   ├ データ不備1
   │ ├ 修正方針1
   │ └ 修正方針2
   └ データ不備2
   . └ 修正方針1

3. それ以外にないことの証明
   必要条件で解を求めると、漏れます。
   十分条件で見積りをすると、漏れます。
   早い話、「問題ないですか？」に対して「(一部分ダメだがあらかた)問題ないです」はやばいですよね。
   一部分ダメだがあらかた問題ない、は、問題ない　に必要条件であるが、十分条件ではないので、この受け答えがNGとなります。
   ここまで大袈裟でなくとも、細かい主語や目的語がないだけでコミュニケーションエラーが発生します。

以下を満たすxの解を求める場合どうしますか？

x^2-4x+3=0

例えば
x = 3を代入すると

9-12+4=0

となり、成立してますね。じゃあこたえは3です！！！！
とはなりません。

(x-1)(x-3)=0

と、因数分解を用いて、情報が等価のまま変形し、
積が0になる場合、2数のいずれかが0である必要があり、
2数いずれかが0であれば、積は0となるという0になるのに十分な条件
すなわち必要十分条件を用いて

x-1=0またはx-3=0

といえる。すなわち解は1と3、となります。
このように情報が等価なまま操作し、それ以外にないことを示しながら解を求める術を
中学校で習いましたね。

何かの対処をした際、それ以外に影響がないであったりこの対処だけで全て網羅できるのような
～が他にない を示すには骨が折れます。現実に起こりうる全ての事象を観測して否定しなければならないからです。
ゴールドバッハの予想という命題があるのですが、

4以上の全ての偶数は、二つの素数の和で表すことができる。
6以上の全ての偶数は、二つの奇素数の和で表すことができる。

などという予想です。あたかも、もうこれ既に定理だろって感じしませんか？
けどこれはまだ証明されてません。全ての数に言えるか保障できてないのです。だって数って無限にあるし。

ないもの探し。魔女裁判、欠席裁判、悪魔の証明なわけです。
これをうまいこと示すために、既存定義/定理を用いて、情報が等価なまま言い換えする、数学のような対処をする必要があります。

例えば影響範囲調査、障害報告時の再発防止策などですね。
それ以外影響がないって言えますか？それで再発防止になりますか？

SE業界は数学ほど厳しくないので
影響範囲であれば、参照のないソースやCRUDのないテーブルは範囲外としてよいし（場合によりますが）
再発防止もつまるところヒューマンエラーなんで、気を付けられる観点を増やそうぜってだけです。
ただし気を抜いていいものでもないので、数学的証明を常に心がけて臨みましょう。

2. 対象・相手をおもいやる

会話やドキュメントの無駄をなくしましょう。

1. 道端のおっさんにティーチング
   あ、実際にはやらないでね？
   ﾔﾊﾞｲやつ「疎通エラーの調査は、各ノード間をそれぞれ確認する必要があるんですよ」
   道端のおっさん「は？？」
   いいひと「まってまって。」
   いいひと「サーバ間での通信エラーの話なんですけど」
   道端のおっさん「ふむ」
   いいひと「例えば～」
   いいひと「サーバA→B→Cって通信してるとするじゃないですか」
   道端のおっさん「3人もいるのか」
   いいひと「エラーの原因がどこなのかって、A↔B間なのか、B↔C間なのかをそれぞれ調べなきゃですよね」
   道端のおっさん「なるほど、確かに」
   ...まぁ人のレベルに合わせて使う言葉を変えたり、段階を踏みながら相手の様子をうかがうことが重要ということです。

2. PREP法を用いる
   PREP法とはatom法律事務所様のショート動画などで使われている、構成法です。

Point→Reason→Example→Point
結論→理由→具体例→結論

の順に話を展開します。ただやればいいだけでなく、PREP法に加えて
話題を持ち掛けるとき、話の粒度を細かくするときは前置きするなど、はいつも通りやります。

質問する場合はこんなイメージ。

・(結論) 要件Aの話なんですが、機能Aの○○で設計修正が必要なので確認です。
・(理由) 実装の動作確認中、分岐パターンに漏れがあることが分かったので質問してます。
・(例) ソースベースになっちゃうのですが、「○○」ファイルの「××」行目のif文では分岐が足りず、
　　　　設計時の考慮もれで -ここで会話-
・(結論) じゃあ機能Aの○○はデータモデル的に考慮不要なので、設計は修正不要で認識しました。ありがとうございます、以上です

また、何かを質問され返答する場合はこんな感じ

Q. この技術課題について教えてほしい
・(結論) ○○が原因ですねー
・(理由) エラーログや○○から推測すると、これしか考えられないからです
・(例) 具体的にソースを追うと、○○ってなるので、デバッグしてみるといいかもですねー
・(結論) なので○○の部分を試したり、調べてみるとよいです！

レベル4_ﾁｮｯﾄﾃﾞｷﾙ

さて、こちらの記事 トップエンジニアから学ぶ技術より大切な考え方にあるようなことは、レベル3までを昇華すればいずれ到達するはずです。
しかしながら、それは自分が最強になって終わり。
ならばそのメソッドを、他者に提供出来るようになるのが次のステップですね。

この教典を作れるような、こういった思考法を他者に提示できるような人を
育てられるように、なりたいものです。

1. ありのままの事実をとらえ分析する

人の気持ちを理解しよう！（むり）

1. アドラー心理学かよ。
   定量的なものの観測は簡単です。
   他者の、人間の状態を正しく観測することは大変難しいです。
   しかしながら、我々人間は人間とかかわりあうことでしか仕事ができません。
   よって、人間の心の観測はとても大切です。
   心の状態は行動に出ます。
   よって、行動を観測し、その原因を推測することが大切であると考えます。
   ※→(さらに気をつけたいポイント)非エンジニア相手の会話が増えれば増えるほど、基本的な十人十色 常識とはなにか をしっかりと弁えた応対が大切です (参考)。住む世界がさまざまなため、自分にとっての当たり前を今一度見返すことが大切で、本当に「え、これ伝わらないか」「これ当たり前と思ってちゃだめか」が不意打ちで出てきます。

2. 対象・相手をおもいやる

ささやかな言葉のチョイスに気を使いましょう。
相手の考えをまとめられるワードチョイスをしましょう。

1. ひらがなの量、漢字の量
   「以上、宜しくお願い致します。」と
   「以上、よろしくお願いいたします。」って、どう思います？後者のがやわらかいですよね。
   「○○を修正してください。」と
   「○○なおしてもらえたらと！」だと、後者はやわらかくて明るいです。
   良い悪いはない。伝える相手がどっちを望んでいるかを考えて変えましょう。
   堅い表現のほうがよさげな人に対しては、読点や漢字をしっかり使っていけばいいと思うし
   やわらかめなほうがよさそうなシーンでは「！」とか使っちゃえばいいと思う。
   最後にこんな表面的なことかいっ！って感じですが、とても大事だと私は思います。

2. 相手の思考の軸 根幹を見定める
   人間の行動なんて単純です。
   深く考えているように見えて、様々なことを意識しているように見えて
   実際、奥底には1, 2個の大きな感情があるだけです。人間なんでね。
   私の場合は「きれいにやりたい」「すばやくやりたい」とかそんな感じです。
   だから「きれいにやるにはどうすべきか」を突き詰めました。
   すると論理最適解というものを導き出すことがよいと、インターネットに書いてありました。
   ではどう求める？
   それを突き詰めた結果、現時点で私なりに
   この教典が最適解であるとまとまりました。
   よって、突き詰めることと根底は何か把握すくことが、思考法を体系化する術なのではと思います。
   この2つを意識させ、伝導し、よいサイクルを生みましょう

要点まとめ

ありのままの事実をとらえ分析する

・開口一番→最初に結論
・中途半端は一番の敵→事実を「言い切り」
・つまりなに？を自問自答
・骨と肉を意識
・必要十分条件を意識。それ以外にないことの証明
・人の気持ちを理解

対象・相手をおもいやる

・正しい名称。勝手な略称禁止
・相手の前提を考える
・指示語撲滅
・体言止めを用いない
・人のレベルに合わせて段階を踏む
・PREP法を用いる
・相手の思考の軸 根幹を見定める

おわりに

この記事は経験に基づき構築したのち、様々な方に実践して頂いたうえで修正を加えております。
これからも内容を逐次更新してまいります。