ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

上司の人たちの頭の中を想像しないと、下が意見を言っても通らない、かもかも

2005-06-04 18:17:38 | 開発ネタ

 ものものさんの、「たまゆら雑記」の「IT:ソフトウェアテストが開発のコストを下げる」をみて、まあ、いちゃもんの世界に近いのですが、ちょっと気になったので、ひとこと。


若者達から「私たちは理解できますが、上が分かっていません。何とかしてください。」とよく言われます。


 についてなのですが、この若者は、上司の頭の中を考えて、言ってるのかどうかが気になります。
 上司の頭の中を考えないと、上司の言ったことを真に受けて、意見が受け入れられないどころか、不当な評価を受けてしまう危険性もあると思います。




 で、上司の頭の中から考えると、たぶん、この「ソフトウェアテストが開発のコストを下げる」で言っていることは、上司たちが経験した、第三次オン(*一番最後に注として説明)時代の開発方法について、言っているように聞こえます。

 そこに、若者が、上述の「ソフトウェアテストが開発のコストを下げる」のような話をしても、

 上司としては、

 「若い人たちは、今の今まで、自分たち(=上司)を否定してきて、オブジェクト指向だ、なんだーかんだあ!って言ってきたのに、急に、今度は前のやり方がいいといわれても。。。

  こいつ、単に流行りを追っていってるだけで、(=青い鳥を追いかけてるだけで)

  自分たち(=上司)が指示する、第三次オンからの流れ
  (=この流れと、UMLを合流させたのがExcelシートになる。
   実は、Excelシートは、オブジェクト指向の欠点を補強するために、
   ”あること”がされている。上司はたぶん、それを説明してくれている
   けど、部下は、たぶん、それを聞き流している)
  について、腰をおちつけて人の話を聞こうともしないで、
  UMLツールはあーだこーだといってたくせに

  今度は、それで問題が起こったら、よその、お偉いさんの話きいてきて、元に戻すんかい!

  人の話を聞いて、自分で確かめて、ものを言えない。
  たんに、偉い人の本を読んで、話を聞いて、無批判に迎合してるだけ、
  だめだ、こいつ」

 っていう評価にならないかなあ。。。

 っていうのが心配。

(もちろん、上司は、心の中でおもっても、そんなことは言わない。「若い人なんて、乗せちゃってなんぼ」(たしか、バレーボールJTのセッター竹下さんのことば)なので、「うーん、俺には分からない」とかいって、ごまかし、部下の機嫌をとることと思われる)





 第三次オン当時の開発の流れ、一応おさらい。

 これは、設計者である、SEさんが、テストデータをつくり、その間に、プログラマがプログラムを作成、プログラムが出来たときに、そのテストデータを利用し、検証するという方式だったよね。じゃないと、検証できないじゃん。

 プログラマがテストした結果OKだった、テスト部門がテストした結果OKだったといっても、設計した本人の意図が、正しくプログラマやテスト部門の人に伝わっているかどうかわからない。そこで、SEがつくった、テストデータで、その内容を確認するっていうわけ。

 で、この流れは、いまだにExcelシートを使った設計書ではできるようになっていて、フリーフォーマット部分に、サンプルデータ例として、のせることが出来る。
 そのサンプルデータをもとに、設計者は、プログラマさんに、確認して欲しいのよ。。

 つーこと、わかってる?
 ちゃんと、あのデータで、テストしてるう??
 してないでしょー、つーか、みてないでしょー

 あの、サンプルって、だてに書いてるんじゃ、ないんだけど。。。(^^;)
 このサンプルデータは、結構、作ってると思う。

 それと、テスト仕様書を作った人、「テスト項目のサンプルデータを作ってください」とか
 「テストデータ生成するんで、ここに、こういうデータを入れてください」
 って言われたことなーい。
 それって、「効率がどーのこーの」って説明されたかも知んないけど、

 本当は、もともとの意味は、ちがうのよ。




 SEさんがサンプルデータを作るのが筋。

 ただ、テスト項目を、SEと違う人が作っちゃった場合、テスト項目を書いた人が、テストデータを作んないと、そのテスト項目が、どーいう意味で書かれたか、正しく伝わらないよね。

 でも、「テストデータを作っていただかないと、テスト項目の意味が正しく伝わらないと思います」とは、口が裂けても、いえないでしょ。

 だってそれって、「おまえのテスト項目は、テストデータ見ないと意味わかんねーよ」っていう意味に受け取られかねないもん。
 だから、効率にかこつけて、言っている。
 本当は、仕様書、テスト項目書の書き手の意図を明確化するため。

 ただし、それを、みようみまねでやっている会社、あとは、言われたことを真に受けているSEさんが、効率のために、テスト項目作成者がテストデータの元をExcelシートに入れていると思っている。

 つまり、前述の「ソフトウェアテストが開発のコストを下げる」で書いてある、設計と同時にテスト項目を作成したりするのが、昔は、ふつうだった(教科書には、そう書いてあった)。




 それと、「テストをしっかりやると上流が改善され、結局は開発全体のコストが減り、工数が少なくなる」というのは、違和感があるように聞こえると思う。

 ここでいう「テスト」が、下流のテストの意味であれば、下流のテストをやった時点で、上流が改善されるようなプロジェクトは、そのプロジェクト、すでに、上流の時点で破綻している。
 
 ふつう、下流工程で、とくに、テストまでいって、分かるようなら、上流の段階のレビューで防いでいれば、もっと、開発工程のコストは減る。
 つまり、「下流工程のテストをやることはあたりまえだけど、上流工程のレビューをしっかりやったほうが、開発コストがさがり、下流のテスト時間も短縮される」と考えるのが普通(これは、いまでも、どこの教科書にも、書いてあるでしょ)。

 だから、「下流工程のテストをしっかりやると、上流が改善される」という意味にとると、それなら、「上流からしっかりやれよ!そうやって、言ってるだろ!」っていう意味にとられる。

 もし、ここでいうテストが上流工程のレビュー(これをテストと考える)のことをさして言っているとすると、「レビューをしっかりやると、上流は改善される」というのは、あたりまえのことを言ってるだけで、上司としては、「それは、おれがいつも言ってるし、教科書にもかいてあることで、具体的にどういうレビュー方針をたてるの?」と、聞かれると思う。




 さらに、「要求仕様書を書いている段階から腕のいいテスト技術者をはりつけて仕様書のレビューをしたり」というのは、「ごめん、その根拠を論理的に説明してくれる?」って、言われるてしまうと思う。

 なぜなら、要求仕様書工程のレビューと、下流のプログラムの工程のテストのやり方が同じなら、論拠は明確なんだけど、これ、違いますよね。。。

 要求仕様書の段階は、ものが、できていない。この時点での矛盾点のチェックをしらべるには、   データの流れの一貫性
   日本語の揺れによる、機能のごまかし
   インターフェースと範囲わけしているものの、不整合
   要素技術の実現可能性
 なんかを調べる。

 これは、「要件プロセス完全修得法」 スザンヌ・ロバートソン+ ジェームズ・ロバートソン/著 苅部英司/訳で、「品質検問所」と言われているものと、同じだと思う。

 それに対して、下流工程の場合は、
    仕様書に書いてあることのチェック
 なんかが中心になる。この時点で、「要素技術の実現可能性」をチェックしている、お馬鹿なプロジェクトはない(よねえ。。。(^^;)。
 その他についても、そういうチェックは、するんだけど、下流工程と上流工程では、ウェイトがまったく違う。

 そこで、最上流・上流工程のレビューチェックの人と、中・下流工程のテストエンジニアを分けたいと考える(そのほうが、養成が楽だから)のが普通。

 もちろん、この考えに反論があるのは、百も承知。なので、反論を上司としては聞きたい。
 なので、理論的に、論拠(反論)を示して欲しいわけで、たんに、「こんなん聞いて来ました!」と、受け売りをいわれてもねえ。。。ということになると思う。




 なーんていう感じで、上司に報告する場合は、
(1)まず、上司の時代(第三次オン)のことをしらべて(注2)
(2)その頭のひとに、こーいうことをいったら、どーいう反応をされるか想像して
(3)それでOKそうだったら、言ったほうが安全!

かとおもわれます。

 よけいなおせわ&いちゃもんでした。




注:第三次オン
 1980年代後半に、銀行向けに行われた、オンラインシステム開発。
 24時間365日運用可能な、オンラインシステム構築ということで、開発された。
 
このサイトの「【企業研究】 コンピュータ業界」によると

第三次オンは都市銀行や大手地方銀行が中心となった大がかりなシステム開発で、数百億円から1千億円を超える規模のシステム開発であった。それまで、銀行や証券会社では、ユニバックや日本アイ・ビー・エム(日本IBM)といった外資系のコンピュータメーカーの製品が中心となって利用されてきた。しかし、この第三次オンが始まる時に、日本のコンピュータメーカーが積極的にこの分野にも乗り込んできたのである。
 日本IBM、富士通、日立製作所の三社がそれぞれシェアを分け合う形で決着がついたのだが、
(以下関係ないので省略)


注2:上司の時代(第三次オン)のことをしらべて(注2)
 げ、検索しても、そんなに載っていないジャン!
 ウィリアムのいたずらの独断と偏見で言うと、この時代の後から、学会の見ている世界と、企業のみている世界では、違いが出てきた。

 この後、オープン化により、開発方法論が変わった。

 その後さらに断層がおこり、
   企業は、この開発方法論を継承し、さらにオブジェクト指向の流れを取り込んでいった
     →その流れが、Excelシートとその自動化に結集される
   学会は、オブジェクト指向のほうに、突き進んだ。
 若手は、この学会の流れを全面的に受け入れ、Excelシートを嫌っていった。

 つー流れは、だれも、説明してないね。。。

 うーん、じゃあ、ウィリアムのいたずらが説明しようか。。。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする