impedance(インピーダンス) 全てに抗え!!

この世の全てに歯向かい、抵抗することでしか存在を見いだせない愚直な漢のオルタナティブ? ブログ

「◦◦さんもダメだと言っていた。」とかいった発言。

よく議論する際に、たまに出てくる「◦◦さんもダメだと言っていた。」とかいう発言。
好きになれない。

といっても、「お前だって言ってんじゃねーか。」とか言い返されるとそれも事実で、
俺もついついこういう発言してしまうこともあったりする...orz

ただ、俺が好きになれないのは、少し違った意図でその発言をしている奴。

そいつは、発言することの本来の目的である、
「その発言によって、現状をより良いものにしたい。」ことを目的で発言をしていない。

そいつの狙いは、ただ一つ。
それを言うことで、これみよがしに自分の存在意義をアピールしたいだけ...
したがって、当然その発言そのものには自身のメッセージは存在しない。中身がない。

また、もしその発言が誤っていたものだとしても、自分自身にその発言責任はこない。
この場合だと、その責任については、「◦◦さん」にポイントが向く。
このように、主体となるものが発言した当人以外のものに向けられるようトリックが仕組まれてて、
自然とそれにに引っかかる。
その発言をする奴は、そんな狡猾な計算も考えに入れている。

ひな壇の上から意見なんて、聞くに値しない。ただのノイズ。
ノイズが大きいコンポは修理するか捨てるに限る。

しかし、今はゴミを捨てるにもコスト(お金)がかかるこのご時世。思わずため息がでる。

「最近の部下は精神面が弱い。」のか?

よく、「最近の部下は少し怒っただけで、意気消沈したりして、その後うまくいかなくなる。」というのをよく聞く。

 

確かにそれは、怒られた部下自身の精神面にも原因があるのかもしれない。

しかし、怒られた部下のその後の動向について、適切に評価しない上司にも問題があると思う。

 

怒った後、その部下が時間を要して良い方向に進んでいても、それを上司がきちんと見て、評価しているのか?

その部下の「反発係数」を正しく評価しているのか?

 

むしろ、そうでないのが多いように思う。

 

要は、怒られただけで反発されたり、意気消沈するようになったのは

部下の問題ではなく、上司が自分の都合だけで部下を怒鳴ったりしているのが

原因なのではないかと考えている。

それはすなわち、自分の都合だけで部下を操っているということであり、

部下を人格を無視した道具として操っているということ。

 

それでは、部下のスキル、モチベーションは低下することはあっても向上することはない。

 

「部下が伸びてこない。ついてこない。」と思っている上司、リーダ、同僚の方々。

あらためて考えて欲しい。

最大公約数?。最小公倍数?

会議とかでおのおの異なる意見が挙がった場合、

その異なる意見の中から、共通である意図をピックアップしてまとめたものを「最大公約数」と表現していた。

 

しかし、人によってはそれを「最小公倍数」とか言っていたりする。

 

どっちが適切なのだろう。

 

俺は、最大公約数の方が適切だと思うのだが…

終わりのないゲーム

よく、やり込み要素を盛り込んだエンドレスに楽しめるゲームってあると思うけど、

ああいった系のゲームって好きになれないんだよね。

 

やっぱりエンディング見たいのよ。達成感に浸りたいのよ。

 

ロングセラーになっているものや、もはやアートの領域にまで達している名作ゲーム。

それらは全て、ドラマや小説のような最後にあっと驚く結末や、爽快感を与える映像、音楽等、

そこまでゲームをプレイしたプレイヤーのステータスを上げるようなエンディングが必ず存在する。

要はゲームの終了するところについてちゃんと考慮されて構成されている。

 

終わりのないゲームなんて、アートでもエンターテイメントでもない。

ただの暇つぶしの作業。

 

以上。

 

追伸 : 久々のブログ更新。

おしゃべりな人間

やっぱりおしゃべりな人間にはあまり好感もてないな。

 

こちらの状況を考慮せずに、ズケズケズケズケとあれこれ話しかけてくる。

その話が聞き手を意識していない内容、話し方なので、話しかけられるほうからしたら結構負担である。

しかも、一度で終了せず、結構長びく傾向が多い。

逆にこちらの話には耳を貸さず、自分が話したいことを一方的に話す。

 

また、そういうおしゃべりな人に限って、逆に他の人から長々話をされてきたら不愉快になってたりする。

 

要は、そのおしゃべりな人は、「俺は正しいんだ。」、「俺は仕事出来るんだ。」、「俺は頑張っているんだ。」といった、

自分の自己顕示欲を満たしたいだけに話をしているようだ。

結局のところ利己主義で、自分の都合でしか行動していない。

 

本来、会話というのは話し手、聞き手双方のためとなるべき行為なのに、ずれているように思う。

 

以前一緒に作業していた上司で、必要以上に打ち合わせを開いて、1、2時間くらい長々話す人がいた。

こちらとしてはその時間をもっと有効なものに利用したいのに、それがそがれるのは残念に思っていた。

それと、拘束されていることにフラストレーションが蓄積していた。

もっと参加者の状況を考えて欲しかったととみに思う。

 

この「おしゃべりな人間は好きではない。」という思い、きっと死ぬまで変わらないだろうな。

 

久々のブログ更新。

テスト業務の進め方について

システムを構築する際、ユーザーに納品する前に一番最後に作成されたプロダクトについて、

意図したものとなっているかテストを実施する。

そのテストについて、詳細は各プロジェクトごとに異なるが、一般的には以下のように工程が組まれている。

 

単体テスト結合テストシステムテスト→運用テスト。

 

尚、工程を分割しているのは、納品するにあたって、

品質担保するために行わなければならないテストの内容が多岐にわたるため、1工程では全てを網羅しきれない。

そのため、テスト業務自体を幾つかの意図を持たせた単位(工程)に分割し、

その工程ごとに実施、管理することでテスト全体で漏れや重複がないようにしている。

 

ということは、その適切に分割された各工程ごと、その意図に応じたテストをくまなく実施していれば、

運用に耐えうる品質のものを提供できるはずなのだ。

 

でも、実際はどうか?

現実には、商用で何件かシステム故障を摘出されてしまっている。…orz

現実は渋い…。

 

上記にも書いたとおり、各工程でしかるべきテストを実施していれば、商用で問題は起きないはずだ。

ノーミスで十分なテストを行っているのであれば。

 

しかし、現実問題として、各種テスト工程でノーミスで十分なテストを行うことが可能なのか?

 

現実には、テスト作業を進める上、内外とわず阻害となるケースが発生し、残念ながら十分なテストが行いきれない。

そのケースを思いついた分だけ幾つか上げる。

  

  ・ 試験者のスキル

      試験者によって、その機能で行うべきテストの範囲の見極めが甘く、網羅性が不足してしまったケース。

 

      確認する箇所および、タイミングの誤り、試験手順の誤り、テストデータの誤りなどで

      実施したテストが意図したものと異なるものとなってしまったケース。

 

      テスト自体の難易度が高く、確認する箇所が多い、または複雑なため、

      十分に確認しきれないままテスト完了としたケース。

 

      また、試験項目票に則って試験していく上で、試験項目ではない箇所で故障発生している場合があり、

      その部分に着眼点を置いていないためを見逃してしまい、結果的に故障を摘出出来なかったケース。

 

      あと、あえて書くが、手抜きで試験実施を省略としているケース。

 

  ・ 時間的制約

      テスト期間が短いため、一部のテストが行えず、省略してカットオーバーを迎えたケース。

  

  ・ 環境的要因

      他システムとの連携試験時、他システム側に意図したデータが登録されていないため、

      そのデータを使った。意図したテストが行えないケース

 

      また、実際に他システムと連携しておらず、疑似的にそれを実現している環境での試験では、

      その動作が本来の他システムと連動したときのものとの違いにより、

      意図した内容の試験が行えないケース

 

  ・ プログラムの幾多の改修による適切なバージョンでのテスト。

      幾度もプログラム改修が適用されるため、納品されるバージョンでの試験が不足してしまう。

  

  ・ 提供した機能が実際に開放されるタイミングでの相違で発生する問題点

      機能自体はテストを実施し、商用に提供しているのだが、運用側の都合でその機能を抑止しており、

      その後、幾つか別の機能、処理のバージョンアップを行った後、既に提供している機能の開放を行ったケース。

 

      対象の機能にもよるところはあるが、

      このケースではテスト実施した環境と機能開放時の環境がイコールではないため、

      一度品質を担保して提供した機能が、その後のバージョンアップのため、意図した品質が保証されてない状態に陥る。

 

プロジェクトの性質、規模、期間にもよるところもあるだろうが、

結論として、上記に挙げた要因1つ1つ解決して、ノーミスで十分はテストは行いきるのはまず難しいと思う。

最低でも、1度だけのテストでは、行ったテストが十分なものには至らないと考えている。

  ※ だからといって、プロダクトに故障を混入させていいという理由にはならないが...

 

そこでテスト作業について、「何とかしてでも1回で完了させる。」よりも、

「どんなに頑張っても、1回では十分なテストは行いきれない。」という前提で、

テスト業務の各工程を組んだ方が有益なのではと思う。

 

具体的には、一連の試験終了後、冗長気味ではあるが再テストの実施。

特に有識者による再テストが望ましい。

といっても、機能全てを再テストするのは当然不可能なので、

一部のクリティカルな機能。またはスキルが十分でない人間が行った試験等に限定すればいいと思う。

  

または、既にリリースした機能について、以下のような再テストを行った方がいいと思う。

   ・ 前バージョン、および前の前のバージョンで提供した機能の再テスト。

        → ユーザにあまり使われていない機能のため、品質が安定していない。

   ・ 申告が多い機能についての再テスト。

       → 観点に漏れがある可能性があるため、再テストにより、品質保証する。

 

商用で故障を出してしまっている可能性があることを認めることになり、

ユーザ様には事実として言いにくい部分もあるのだが、

この既に提供した機能でも再テストを施すことは、品質を高めることに有効だと考えている。

実際、そこで故障を摘出することがあれば、その後のアクションにより

被害を未然にあるいは、少なく食い止められることも可能と考えている。

 

特に、特に、短いサイクルで結構な規模のシステムバージョンアップを求められるシステムでは、

テスト工程をただ単に直線的を進めるのではなく、

このように途中で厚みを持たせつつ、曲線的に進めていくほうが適切だと考えている。

社員に「挨拶がない」ことを不愉快に感じているある人へ

他社の方への挨拶がなくて怒るのはわかるが…。

社員から自分へ挨拶がないのがそんなに気に喰わないかねぇ。

 

自身がどんだけ会社の業績および社員への安定した業務、収入の確保に貢献してからいってほしいね。

会社の規模にもよるけど、そもそも、あまり交流ない人に対してまで挨拶を求めるなんて、

偉ぶりたいだけの自己満足としか思えないけどね。