黒柴的パンセ　#1

「考える」ということ　その１

このnoteでは、ブレーズ・パスカルの「パンセ」のように、黒柴が今までIT業界で生きてきた中で経験したこと、感じたこと、考えたことを残していければと思っている
そして、後進のエンジニアがIT業界を生きていく上で、多少なりとも参考にしてもらえたら嬉しい限りだ
来歴もだいぶ進んで、黒柴がどんなことをやってきた人間かを多少なりとも説明できたと思うので、少しずつパンセ（考え）を残していきたい

「パンセ（考える）」という言葉について、少し定義していきたい
実のところ、この「言葉を定義する」という作業が、黒柴は大好きだ
人は、会話するときに「言葉」を用いるが、その言葉に対する定義・認識がずれていると、当然ながら話はかみ合わない
また、それぞれが話している「言葉」の定義がずれていることを認識しないまま、お互いの定義を元に作業や契約を進めてしまうと、後で悲劇が訪れる
この「言葉を定義する」ということの重要性に気が付いたのは、次のような事例からだった

それは自社にとっては珍しく、エンドユーザから直接受注した案件だった
プロジェクトは、要件定義工程からスタートした
しかし、もともとSIer主導の基本設計に作業者として参画し、詳細設計以降の工程を請け負いとするような開発を行っている自社には、正直なところ要件定義は荷が重かった
しかも、営業担当の役員は何を考えていたのか、要件定義からリリースまでを一括契約としていたため、要件定義工程の遅れは後工程のスケジュールを圧迫していった

なんとか要件定義が終わり、基本設計（外部設計）、詳細設計（内部設計）がそこそこ形になって、一部の機能ではコーディングにも着手できる状態になった
しかし、契約時のマスタスケジュールでは、すでにテスト工程が始まっている時期だった
当然、コーディングで手一杯の状態のため、テスト工程に着手できる見込みもなく、この先も遅れが増大していくことは明白だった

この時点で、新規に作業者を追加することもリスクが大きい（追加した作業者に仕様を理解させるために、時間的なコストがかかるため）と判断したのか、自社のPMは作業者不足を遅れの要因として、エンドユーザ側のPMに相談したようだ
そこで、エンドユーザ側のPMは、「動く部分からリリースしてくれれば、単体テスト以降のテストは、こちらで巻き取りますよ」という提案をしてきた

ここで問題となるのが「単体テスト」という言葉である
黒柴的パンセでは、ソフトウェアテスト関連の用語についてはJSTQB（ISTQB）に準拠するが、JSTQBには「単体テスト」という用語はない
近い用語は、「コンポーネントテスト」となっており、「個々のハードウェアまたはソフトウェアコンポーネントに焦点を当てたテストレベル」と定義されている
では、「ソフトウェアコンポーネント」とは何か？
「ソフトウェアコンポーネント」という言葉はないが、「コンポーネント」は「独立してテストできる、システムの最小構成単位」と定義されている
すなわち、「コンポーネントテスト」とは、「function」とか「method」とかのソースコードの最小の塊を対象としたテストになる
（「考える」ということ　その２へつづく）