見出し画像

コミュニケーションは複雑なプログラミングであるという話

とにかく今脳内にあるものを吐き出しておくことで、あとで何か科学変化が起こるかもしれないことを期待して、雑でもいいからアウトプットするシリーズ5回目

4回目

人間を超絶複雑怪奇なオブジェクトと捉える

人間は、万を超える変数を持ち、万を超える関数を持つ、超絶複雑怪奇なオブジェクトと捉えてみる。


コミュニケーションを関数の入出力と捉える

例えば「挨拶」という関数に「おはよう」という入力をすると、大体の人からは「おはよう」という出力が返ってくる。
こう捉えると、プログラミングと本質は変わらないのではないかと考えています。


同じ関数でも出力が変わる

「おはよう」と返したら「おはよう」が返ってくるまでは良い。
これを10回繰り返したらどうなるか?
大体の人は「なんなの?」「バカにしてるの?」という出力に変わっていくはず。

この人間オブジェクトの「挨拶」という関数は、複数回同じ入力が来ると「嫌悪を含む疑問」を表明するような出力に変えるという処理が内包されていると考えられる。

人間オブジェクトの「関数」には、常に変動する多種多様な変数を参照した処理が組み込まれている。
その変数とは天気・体調・ストレス・気分などが考えられるが、人により参照する変数も処理内容も微妙に違う。


トライアンドエラーするしかない

内部処理は隠蔽されているのでどの変数を参照して、どのような処理をしているのかは見ることができない。
入力変数の値を変えたりして、繰り返し関数を実行して出力結果を観測すると一定の傾向が見えてくる。
このトライアンドエラーにより、やっと自分の期待する出力を得られる方法が見えてくる。


という考えになり、コミュニケーションはくそ面倒くさいプログラミング実装やんけ。。。という結論になりました。


ユニットテストしたくなる

こんな複雑怪奇なオブジェクトの関数には当然ユニットテストを入れたくなる。
同じ関数でもオブジェクトそれぞれで、処理に影響を与える入力変数が違ったり、内部変数も違ったり値も変わったりするので、画一的なユニットテストはほぼ不可能。

それでも、チームメンバーと連携しながら何かを成していくためには、オブジェクトの出力結果の予測・観測はする必要があるので、ユニットテストのようなことを普段からする必要があるし、やっていると思っています。

ユニットテストの例

「おはよう」と入力したら「おはよう」が返ってくる
 →今日もいつも通りの出力が返ってくるので、ここは問題なさそう

「今日なんか元気がない感じするけど?」と入力したら「ちょっとxxxがあって少しテンション下がってて…」が返ってくる
 →何かの変数が変わっていて、他の関数にも影響があるかもしれないな

「タスクで何か困ってることある?」と入力したら「特にないです」が返ってくる
 →「タスクの消化」関数の出力のために、不足している入力変数は足りていそうだな

このような感じで、普段よくされている会話は、複雑怪奇なオブジェクトの変数の状態や関数の出力について、レグレッションテストをしていると捉えることが出来るかなと思います。



おまけ: コミュニケーションが大事と言われる本質

自分も含めた複雑怪奇なファットオブジェクトの集合体が、連携して成果を出すためには、日々出力が変動するオブジェクトの変数の状態、関数の出力結果をユニットテストをしながら観測しないと、目的となる成果を出せないから。とも考えられるなぁと思いました。


時間: 60分




この記事が気に入ったらサポートをしてみませんか?