"BOKU"のITな日常

62歳・文系システムエンジニアの”BOKU”は日々勉強を楽しんでます

地獄行きのコードに善意が敷き詰められている/「プログラマが知るべき97のこと」から学んだこと(1)

自分が「プログラマが知るべき97のこと」のエッセイを読んで、気づきと学びがあったなと思ったことの「その1」です。

f:id:arakan_no_boku:20200405225853p:plain

 

今回のポイント

 

こちらはプログラミングをテーマにしたエッセイ集です。

xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com

97のこと・・と言いながら、107個ものエッセイがありますから、読んでいると色々な気づきがあったり、勉強になると思うことが多々あります。

今回は、そんな自分が共感して学んだこと「その1」として

地獄行きのコードに善意が敷き詰められている

にというキーワードで気づきがあったポイントを引用しながら書こうかなと思います。

 

デスマーチプロジェクトには「善意の人」がいる

 

俗に言う「デスマーチ (death march) 」に陥ったプロジェクトは何回も経験しました。

そういうプロジェクトには必ず「善意の人」がいました。

ユーザに対して「良いシステム」を構築してあげようとして、真摯にユーザの話を聞き、その要求を可能なかぎり実現させてあげようとして、時には、予算や納期の厳守を要求する会社側と熱きバトルを繰り広げたりする人です。

気持ちは凄くわかります。

自分もできたら、そうしたいなと思いますから。

でも。

お金も時間も人的リソースも・・有限なんですよね。

そういう経験があるので。

「地獄への道には善意が敷き詰められている」という言葉があります。

それと同じように、「地獄行きのコード」に善意が敷き詰められていることもよくあります。

良いプログラマになるためには、単なる善意だけでは不十分です。

自分が善意でしていることが本当に功を奏しているか、よく確認することが大切なのです。

 というのはよくわかります。

 

ユーザの言葉を頼りにしてはいけない

 

よく「 ユーザの身になって考える」という表現を使います。

なんか、簡単にできそうにも思えますしね。

ところが、そうは問屋がおろさない・・わけです。

ユーザの言葉を聞いて、ユーザの身になって考えたつもりのことが、あっさりとひっくり返されたり・・。 

別のエッセイで、こんなエピソードが紹介されたりしてますが、笑えないですね。

実際に似たようなことを経験した身としては(苦笑)

背景色は「黒」にして欲しい、ということでした。

その希望を基に、グラフイツクデザイナーのチームは、何百という数のマルチレイヤーグラフィックスファイルを作成しました。

製品を完成させるまでには長時間を要し、労力も大変なものでした。

しかし、大変な作業の成果を顧客に披露した時、私たちは驚くべきことを聞かされたのです。

製品を見た顧客は背景色についてこう言いました。

「ああ、私、「黒」って言いましたけど、あれは「白」っていう意味なんですよ…」

 とにかく、こういうすれ違いから「デスマーチ」は生まれていくのです。

 

ユーザの言葉をうのみにせず、観察する

 

じゃあ。

どうしたらいいんだよ!!

そう思うわけですが・・「そんなことがわかれば苦労はない」わけです(笑)。

でも、できそうなことは

ユーザが求めているものを正しく知るには、言葉を聞くよりも、彼らの行動を観察するほうがいいのです。

彼らの求めるものを頭で考えて1日過ごすより、わずか1時間でも観察をしたほうが得るものは多いでしょう。

ということですかね。

とにかく。

私達はどうしても、誰もが自分と同じようなものの見方や考え方をするはずと思っていしまいがちです。

・・・

ユーザの身になって考えるということがなかなか出来ないプログラマが多いですが、その理由もこの「先入観」にあると言っていいでしょう。

ユーザはプログラマのようには物を考えません。

 これを肝に銘じて、まったく未知の生き物のように観察する・・これが一番なのは経験からも確かです。

 

問題がおきた時も同じだよ

 

あるあるとして。

ユーザから問題発生の報告を受けても、再現しない。

そういうことも、よくあります。

たいてい、「なんか勘違いしてるんじゃないのか」とか、報告者の方を疑ってしまったりするのですけど。

問題発見の報告を受けたが、それを自分で再現できない場合には、報告者が実際にどういうことをしているのか、その現場を見るべきです。

ひょっとすると、あなたが想像もしなかったようなことをしている可能性があります。

予想とは全く違った発想、違った順番で行動していることがあり得るのです。

ということがあるのも事実ですからね。

上記のようなケースで散々揉めたあげくに、実際に現場に足を運んで使う様子を見ると、まさしく自分が想像もしていなかったような使い方をしていて、その手順の場合だけ再現するバグだった・・というオチは結構あるのです。

 

とにかく「NO」と言えるようにならないとね

 

とはいえ。

観察するだけでは問題は解決しないことが多いです。

なぜなら。

ソフトウェアが人気になり、ユーザが増えるにつれ、「あの機能を追加してくれ」「ここの動作をオプションでOn/Offできるようにしてくれ」という要望が出てきます。

実際にそうした機能やオプションが欲しいとおもっているのは、ごく一部であるにもかかわらず、声の大きいユーザからの要望を無視することができず、忠実に応えようとするあまり、あなたはそれをすべて実装してしまいます。

それだけでは、これが防げないからです。

実際「善意が敷き詰められた地獄行きのコード」は、こういう要望にこまめに対応していることによって生まれます。

ハッキリ言えば。

そんな要望をきくのは「善意」ではないと、個人的には思ってます。

それは単なる優柔不断であり、忖度以外のなにものでもないです。

結局。

こうした悲劇を避けるポイントはただひとつ、そうした要望に「No」といえる勇気です。 

なんですね。

うん。