はじめに
この記事は本の感想文？的なものです。
普段、仕事で SIer さんと話す時に説明がうまく出来ないのは何故だろう、と悩んでいたところ
とあるツイートを見てこの本を購入しました。
Amazon (アフィリエイトじゃないよ)
今後のエンジニア人生に役立ちそうだったので本を読んで思ったことを共有します。
(となると、読書感想文とはまた違うかも)
何故、SIer さん (仮) に説明することは難しいのか
ここで言う SIer さん (仮) とは、例えば React について知っている自分と対照に、
自分の知っている分野に疎い・あるいは知っているが学び始めたばかり、といった人のことを指します。
言っても伝わらないだろう、という予測
そういった人たちと話す時、大抵の人はなるべく専門用語を使わないようにすると思います。
「ここはメモ化したほうが〜」とか言っても伝わらないだろう、ということを予測するのは簡単ですよね。
言い換えて伝わるのなら苦労しない
先ほどの話を例に挙げるなら、メモ化というのはキャッシュ化です。
「キャッシュ化」と言い換えてもまだ伝わらない可能性があるので、もうちょっと噛み砕いてゲームで言うニューゲームとセーブ & ロードに例えると伝わるでしょう。
ですが伝わるのはあくまで「メモ化」の概念で、それがプロジェクトの何に活きるのかというところまでは伝わりません。
なので、僕たちプログラマは何故メモ化が必要なのかを説く必要があるのですが、
- メモ化が達成出来ることを再び噛み砕いて説明する必要がある
→ 「何度も一から描画をしようとすると Chrome が重くなっちゃいましてぇ〜……」 - その達成できることは、本当に SIer さんが求めているものなのか考える必要がある
→ 納期優先にして欲しい - 仮に求められていなくて、でも自分はどうしても必要と思っていて、それをどう説明すれば……
→ ？？？
といった感じで、言い換えるだけで伝わるほど単純では無いんですよね。
人はそれぞれ違うスキーマを持っている
本の中で「人にはその人の生まれ・育ち・立場などが影響して、必ず思考に偏りがある」と説明されており、またその偏りのことをスキーマと呼んでいました。
つまり、僕はプログラマとしてのスキーマ、SIer さんは SIer としてのスキーマを持っており、同じプロジェクトに携わっている二人ですが、実は全く違うことを考えているかもしれない、と言うことです。
僕にとっての「品質」は、主にコードの質の高さのことを指しますが、SIer さんにとってのそれは、設計書の品質だったり、あるいはひょっとすると納期を守ることも品質のうちに入るのかもしれません。
なので、単に「メモ化していないから品質が低い」と説明しても、SIer さんの心には響かないわけです。
自分と相手が違うスキーマを持っていると理解するのは容易ですが、その上で相手がどういうスキーマを持って話しているか、
また相手のスキーマに合わせて自分の意見を通すにはどうしたら良いか考えるのは非常に難しく、だからこそ前項のようなことが起こってしまうんですね。
相手のスキーマを理解するための試み
なので、一緒に仕事をする相手のスキーマを理解するということは、おそらくプログラムのスキルよりも必要なスキルなんだと思います。
では、具体的にどうやって相手のスキーマを理解して行けば良いのか僕なりに思ったことを共有します。
まずは相手の話を聞く
今のプロジェクトに一度話しただけでレベルの違いを分からせられてしまったエンジニアがいたのですが、
その人は自分がたとえ真逆の意見を持っていたとしても、まずは必ず相手の理解から入ろうとする方でした。
「どうしてですか？」
「あ、つまり⚪︎⚪︎ということなんですね！なるほどです！」
「僕は××と思ってるんですが、どうすればお互いハッピーになれますか？」
実際の会話の内容はもう覚えていないのですが、会話していてとても気持ちが良かったことは強烈に覚えています。
なので、相手のスキーマを理解することももちろん大切ですが、「まず理解しようとする」ことが円滑なコミュニケーションへの第一歩なのかもしれません。
相手と同じ言葉で話す
これは Youtube の恋愛大学 (😅) みたいなチャンネルで女の子をオトすテクニック (😅) みたいな動画で紹介されていた方法なのですが、
相手と同じ言葉で話すと、仲間意識が高まって心を開いてくれやすくなるそうです、、笑
まぁこれは、恋愛というスキーマを持った人が説明しているから「女をオトす」だとかそっちの話になっているだけであって、
実際は同性と仲良くなる方法の一つとしても有効だと思います。
よくある「同じネタ (内輪ネタ) で何度も盛り上がる」とかまさにそれですよね。
エンジニアの世界でも似たような感じで、ドメイン駆動設計のプラクティスの一つに「ユビキタス言語の策定」があります。
プロジェクトに関わるすべての人の間で同じ言葉を使い、コミュニケーションを円滑にすすめるためのものらしいです。
スキーマの概念を知った今では、この「ユビキタス言語の策定」の真の意味は「お互いが持つスキーマの距離を物理的に近づけていくこと」にあると思います。
なので、ただ同じ言葉を使うだけではなく、同じ言葉を使った上で相手のスキーマ理解に努めれば、より高い効果を発揮できるのではないでしょうか。
スキーマの差異を理解した上での行動
スキーマの差異を理解した上で実践したこと、それは折衷案を挙げることですね。
先日、ある SQL クエリ仕様が冗長になっているのを見つけてすかさず SIer さんに報告しました。
どうなっていたか簡単に書くと、
- バグ的問題はないが、冗長になっているところが直感的ではなく今後バグを生む可能性
- 効率的に書き直せる
- 類似の書き方になっている箇所が他にもある
といった内容でした。
要するに、「今は問題ないけど後々問題になる可能性が高いから今のうちに直して品質をあげたい」という気持ちで問題を報告したわけです。
それに対し、結局のところ SIer さんには納期的な問題で対処するのは難しいと断られました。
いつも通りなら僕が報告した問題はこのまま海の藻屑になって消えるのですが、
真に問題なのは問題を問題と認識されずに消えていくこととそこで気づき、
折衷案として「この問題は今対処できない技術的負債とし、リリース後に対処出来るよう課題管理して欲しい」とお願いしました。
この折衷案を出せたとき、なんか自分の中で爆発したような感覚がありました。
「自分、成長したな〜〜」とか「これはクリティカルに決まった……！」とか、まぁ要するに自己肯定感が爆上がりして、
「何回説明しても伝わらない」はなぜ起こるのか？を読んで本当に良かったと思ったわけです。
最後に
生成 AI が猛威を振るっている今、エンジニアはもちろんコードを書くことも重要ですが (これについては本の後ろの方で書かれています)、昔よりはコミュニケーション能力の高さにも重きを置かれているのではないでしょうか？
僕はこの「何回説明しても伝わらない」はなぜ起こるのか？を読むことで、コミュニケーション能力の正体が明らかにできましたし、「ユビキタス言語」のような、今までなんとなく良いと思っていたことの裏付けを取ることもでき、エンジニアとしてのレベルを一つ上げられた気がしております！
なので！良かったら！買ってみてください！！眠いから終わり！！