こまどブログ

技術のこととか仕事のこととか。

『Clean Architecture』における単一責任の原則とコンウェイの法則について

要約

『Clean Architecture』における「単一責任の原則(SRP)」の説明において、アンクル・ボブはコンウェイの法則に言及している。コンウェイの法則によって補強されていると思われるSRPの主張は、2014年のアンクル・ボブのブログ記事において既に現れている。「変更の理由」を「人間」であると同定することは、アンクル・ボブにおけるSRPを一段階踏み込んだ主張にしている。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

SOLID原則との出会い

ソフトウェア開発の世界には、「〇〇原則」や「〇〇法則」といったものが数多く存在している。その中でも、最も著名なものの1つが、SOLID原則であろう。SOLID原則とは、以下の5つの原則の頭文字をとったアクロニムである*1

  • S:単一責任の原則(Single Responsibility Principle)
  • O:オープン・クローズドの原則(Open/closed principle)
  • L:リスコフの置換原則(Liskov substitution principle)
  • I:インターフェイス分離の原則(Interface segregation principle)
  • D:依存性逆転の原則(Dependency inversion principle)

SOLID原則は、「アンクル・ボブ(ボブおじさん)」として知られるRobert C. Martinが紹介しているものだ。『Clean Architecture』によれば、2004年にMichael Feathers*2から「SOLID」と読めるという指摘を受けたのがSOLID原則の誕生の瞬間であったらしく*3、日本においてもよく知られた原則であると言えるだろう。

ある程度のキャリアを積んでいる開発者の方々にとっては、SOLID原則は決して目新しいものではないようだ。しかし、この業界に入ってようやく2年が経とうとしている自分にとっては、アンクル・ボブの最新刊であり、昨年7月に邦訳が公刊された『Clean Architecture』が、SOLID原則との事実上の最初の出会いを提供するものとなった*4

単一責任の原則とコンウェイの法則

『Clean Architecture』を読んでから、SOLID原則についての議論がTwitter上でなされているのを見る機会が度々ある。その中で、気になっていたことが1つあった。それは、単一責任の原則(SRP)について、そうした議論の中では語られないが、『Clean Architecture』では言及されているキーワードの存在である。

そのキーワードとは、コンウェイの法則」である。コンウェイの法則とは、メルヴィン・コンウェイ"How Do Committees Invent?"における以下の主張のことである。

システムを設計する組織は、組織のコミュニケーション構造をコピーした構造の設計を生み出す。*5

最近の記事や発表ではマイクロサービスアーキテクチャとの関わりで語られることの多いコンウェイの法則であるが、『Clean Architecture』において、SRPは以下のように、コンウェイの法則との強い結びつきがあるものとされている。

コンウェイの法則から導かれる当然の帰結。個々のモジュールを変更する理由がたったひとつだけになるように、ソフトウェアシステムの構造がそれを使う組織の社会的構造に大きな影響を受けるようにする。*6

コンウェイの法則を持ち出してSRPを説明するというのは、アンクル・ボブの旧著である『アジャイルソフトウェア開発の奥義』*7や『Clean Code』*8には見られなかったものである。これらかつての著作においては、SRPは「変更の理由」に関わる原則として説明されている。アンクル・ボブ自身、『Clean Architecture』において、「かつて……以下のように語られてきた」と前置きをしつつ、「モジュールを変更する理由はたったひとつであるべきである」*9と述べている。

『Clean Architecture』においても、「変更の理由」はSRPの中心的概念である。その点では、アンクル・ボブは一貫している。しかしながら、コンウェイの法則を持ち出している点は、上に掲げた3冊の単著のうち最新作である『Clean Architecture』にのみ見られる特徴である。本稿においては、『Clean Architecture』においてコンウェイの法則が持ち出されるに至った経緯を考えてみたい。

「変更の理由」とは人間である

アンクル・ボブによるSRPの説明にコンウェイの法則が持ち出されたのは、簡単に調べてみた限りでは『Clean Architecture』が初めてであるように思われる。ただし、「変更の理由」が人間であるということ、したがってこの原則が「人間に関するもの」であるということは、2014年に書かれたブログ記事において、アンクル・ボブが語っている。

この原則は人間に関するものだ。*10

この記事によれば、アンクル・ボブは70年代からの様々な論者による主張をまとめようとして、SRPを提唱するようになったという*11。その定式化が「変更の理由」によるものであったのだが、これが曖昧さを残すものだという思いがあったのだろう。前掲のブログ記事では、「変更する理由を何が定義するのだろうか」と問いかけたあと、『Clean Architecture』でも用いられている例を持ち出しつつ、以下のように述べている。

あなたがこの原則について考えを巡らせるときには、変更の理由は人間であることを思い出してほしい。変更を要求するのは人間なのだ。*12

『Clean Architecture』において、アンクル・ボブは、SRPが「どのモジュールもたったひとつのことだけを行うべき」とする原則だと誤解されがちである理由として、「名前があまりよくなかった」*13と述懐している。そうであるからこそ、「変更の理由=責務」という等置を『アジャイルソフトウェア開発の奥義』において明示する必要があったのだろう。責任、責務という単語は、不遇であったとも言える。しかし、責任(responsibility)という単語が、2014年のブログ記事において復権することになる。

プログラムの設計は誰に対して責任を負わねばならないのか?*14

単に「変更の理由」というよりも、変更の理由とは即ち人間であると述べる方が、より主張のポイントは明確である。この議論の発展を導いているのは、上の問いに他ならない。誤解を招く原因でしかなかった言葉は、2014年のブログ記事においては「人に対して責任を負う(responsible to)」という表現を用いることで、原則の意味をより特定的にする方向に利用されているのだ。その結果は、『Clean Architecture』において「アクター」という用語とともに定式化される。

モジュールはたったひとつのアクターに対して責務を負うべきである。*15

上記の主張は、『アジャイルソフトウェア開発の奥義』や『Clean Code』における主張よりも論理的に一歩踏み込んでいる。その進んだ部分は、ソフトウェアの外部に存在する人間を視野に入れた点にある。『Clean Architecture』においてコンウェイの法則ーーこれは組織とソフトウェアの相関を語る法則であるーーが持ち出されるようになったのも、この踏み込みを支えるものとして位置づけることができるだろう。

むすびに代えて:残された問い

以上、『Clean Architecture』における単一責任の原則(SRP)の説明におけるコンウェイの法則の引用について、それが生じた背景を2014年のブログ記事に依拠して検討した。

この記事が提起したいのは、「変更の理由とは即ち人間(アクター)である」という踏み込みを行うことで、『Clean Architecture』版(「アクター」バージョン)のSRPはより焦点を絞った原則となっているということである。「変更の理由」バージョンのSRP理解は正しくない、と主張するつもりもないし、「アクター」バージョンのSRPの方が有意義だと主張するつもりもない。ただ少なくとも、原則の焦点を絞ることによって、単に「変更の理由」と言っていたときには見えなかったものが見えてくる可能性はあるだろう。

なお、前節の末尾で結論じみたことを書いてしまったが、この記事での検討はコンウェイの法則を持ち出した意義までには踏み込んでおらず、したがって上記の結論はあくまで仮説に過ぎない。コンウェイの法則が果たしてアンクル・ボブの言うように「当然の帰結」としてSRPを導くものであるかも、まだよくわかっていない。この点については、改めて検討したいと思う。

参考)

labs.septeni.co.jp

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

*1:訳語は『Clean Architecture』に従った。

*2:『レガシーコード改善ガイド』の著者として知られる。

*3:アンクル・ボブがこの5つをまとめて紹介していたのは2000年頃まで遡れるようだ。

*4:名称だけは7月以前から知っていたように思うが、定かではない。

*5:ここに掲げた訳文は、『Clean Architecture』におけるものである。『Clean Architecture』159頁。コンウェイ自身による「コンウェイの法則」についての説明はConway's Lawを参照。

*6:78頁。

*7:原書は2002年出版。

*8:原書は2008年出版。

*9:81頁。

*10:"This principle is about people.":前掲記事より。

*11:前掲のブログ記事参照。

*12:"However, as you think about this principle, remember that the reasons for change are people. It is people who request changes.":前掲記事より。

*13:『Clean Architecture』81頁。

*14:"who must the design of the program respond to?":前掲記事より。

*15:『Clean Architecture』 82頁。

ポッドキャスト出演の収穫: #成し遂げたいam ep.7 に出演した

先日、ポッドキャスト「#成し遂げたいam」の収録にゲストとして参加してきた。そして、収録した前・後編のうち、前編がすでに公開されている。

anchor.fm

内容については、上のツイートのようなことを話している。この記事では、

を書く。リンク集が話の内容に沿ったものであるのに対して、それ以下の文章はメタ的なものになっている。ぜひ、本編と併せて読んでいただき、できればフィードバックをお寄せいただきたい。

補足リンク集

本編のShow Notesには載せられなかったリンクを掲載する。

ブログを書くことになったきっかけ

このブログの最初の記事。

ky-yk-d.hatenablog.com

write-blog-every-week

Slackグループを立ち上げたkojirock(@kojirock5260)さんの記事。

kojirooooocks.hatenablog.com

昨年末に立ち上げられ、無事完走したAdvent Calendar。

adventar.org

カカカカックさん関連

ブログ書かなきゃと思わされたカカカカックさんの一枚のスライド。ここから始まった。

「ブログ欲」の話がされているポッドキャスト(fukabori.fm)。エラーでつまずいたときにブログを書くことの意義についてもこちらのエピソードで語られている。

fukabori.fm

『自省録』関連

『自省録』(岩波文庫)。

自省録 (岩波文庫)

自省録 (岩波文庫)

『自省録』を引用しているブログ記事。

ky-yk-d.hatenablog.com

アジャイルに対する欲望

アジャイルに強い思いを持ちすぎていた頃の記事。良くも悪くも我ながらエモい。

ky-yk-d.hatenablog.com

宣伝:DevLOVE

3月に開催する2つのイベント。

devlove.doorkeeper.jp

devlove.doorkeeper.jp

なぜポッドキャストに出ることになったのか

なぜポッドキャストに出ることになったか。きっかけは、今回出演させていただいた「#成し遂げたいam」の過去の回を聴いて思ったことを書いた以下のツイートだ。当然、こういうことをツイートすれば、パーソナリティの一人であり、他にも多くのポッドキャストを配信されている「ポッドキャスト生やすおじさんお兄さん」ことKANE(@higuyume)さんから声が掛かることは予想できた。果たして、出演の依頼をいただくことになり、今に至る。

事前に「自分を知ってもらうメモ」を書いた

僕は、技術やその他の何らかの領域において、特段人に話すべき知見を持ち合わせているわけではない。このブログにしても、自分の有している知識を誰かに伝えるというよりは、書こうとすることによって考えるということに重きを置いている。したがって、ポッドキャストに出るといっても、たとえば和田卓人(@t_wada)さんのように、確固たる実績に基づいて知見を語るというわけにはいかないし、TDDやペアプロといった「持ちネタ」があるわけでもない。パーソナリティのKANEさんとなべくら(@nabe__kurage)さんにしても、それほどお互いをよく知っている間柄でもないから*1、僕が何を喋るのか、喋ることができるのか、というのは未知数だったはずだ。

そこで、事前に頼まれてもいないのに僕について知ってもらうためのメモを作成して、お二人に目を通していただくことにした*2。そのメモには「話せないけどお二人に参考にしてほしいこと」も載せていたので、公開することはしないけれども、これを作成したのは有意義だった。

メモには主に、下記の事柄を書いた。

  • 自分の来歴
  • 最近考えていること、悩んでいること
  • ポッドキャストで話せそうな話題

1点目の、自分の来歴については、主に就職をしてから、どの時期にどういう人・物事との出会いがあって、自分がどう考え、行動してきたのか、を書いた。書くにあたっては、ConnpassやDoorkeeperのイベント参加履歴、読書履歴、Twitterやブログの過去ログ、カレンダーの過去の予定、毎日つけている日記など、様々な情報ソースに目を通した。その過程で、忘れかけていた初心や、消化不良のままになっている書籍などを思い出すことができた。また、2年弱という期間をふりかえることによって、自分の思考や行動を貫いているものや、逆に一貫していないもの、それと過去の自分からの差分などが見えてきた。

2点目の、最近考えていること、悩んでいることについては、普段からノートやTwitterに書き出しているから、新しいものが生まれたわけではないけれども、人に伝えることを意図してまとめてみると、いくつかの主題が見えてきた。色々なことを考えているようで、実は少ない数の中心的なテーマに発しているということがわかったので、掘り下げるべき方向性を考えるのに役立った。

3点目の、ポッドキャストで話せそうな話題を書いてみたところ、冒頭の言葉を覆すようではあるが、「意外と人に話せることがあるんじゃないか」という感想を持った。話せそうな事柄は、必ずしも自分のオリジナルの内容ではなく、書籍やインターネットの記事、Twitterポッドキャストなどの様々な媒体から入手した他人の知識や意見が多くを占めているのだけれども、それでも自分なりの情報の集め方、消化の仕方をしたものを表現するということは意味のないことではないと思うようになった。

以上のいずれも、普段は自分のその時々の関心に導かれて断片的に想起・表現している事柄を、まとめて人に対して表現しようとすることによって得られた効果だ。特に、今回のメモはパーソナリティのお二人に対してのみ見せるためのものであり、ブログなどでは公開することを躊躇う事柄も排除していないのが有効だった。これが、不特定多数に公開する媒体や、あるいは人事・採用上の評価を受ける可能性のある媒体であったとすれば、また違った結果になっただろう。

自分のポッドキャストでの喋りを聴く

公開前に、事前確認ということで、全編を通しで聴き直させてもらった。プレゼンテーションの練習をするときに、自分の喋りを録音して聴いてみたことはあった。しかし、ポッドキャストのように、事前のスクリプトなしの、人との対話を録音したものを聴くというのは初めてだった。

まず、一番懸念していたスピードについては、速すぎるということがなくて安心した。僕は普段、話すスピードが速いという自覚があるので、今回はかなり意識をしてスピードを抑えていた。意識しても速くなってしまうものなので、うまくいったのはよかった*3

話の内容についても、思っていたよりはしっかり喋ることができていたと思う。欲望についての考えは、抽象的にすぎるところがあり、リスナーの方を置いてけぼりにしているのではないかという懸念もあるが、話として聴きづらいということはそこまでないのではないかと自分では評価している。

一方で、気づくことがあった。それは、以下に記すようにネガティブな形で現れているのだが、ポッドキャストという媒体で自分の語りを聴くことによって見えてきたものであり、大きな収穫でもある。特に気になった以下の2点について言及しておきたい。

  • パーソナリティの質問に答えていない/応答していない
  • 話している中で主張が一貫していない

1点目は、ポッドキャストという媒体ゆえの難しさと、自分自身の元来持っている悪い癖とが現れたものだと思う。今回、話せることがあるかが不安だったため、上に書いたように事前にかなり話す内容を考えておいた。これは、良い面もあったと思うけれど、「時間内に話さなきゃ」「放送事故っぽくなったらいやだ」と、あらかじめ考えてきたことを喋る方向に傾いてしまったと思う。

特に、なべくらさんからは自分の意見に対して反対意見、少なくとも違和感を表明されていたのに、正面から対話をするという方向にいけなかったのは、とても勿体なかったと思う。これは、「あらかじめ持っている意見に疑問を呈されるとその場では防衛的になってしまう」という自分の弱いところが出た結果でもあり、反省が大きい。

2点目は、逆に話していることに一貫性がなくなっていたという点だ。具体的には本編を聴いて探していただければと思うが、語りの中で、矛盾した2つの主張をしている場面や、同じ言葉を別の意味で使うことで話をすり替える場面があったように自分では感じている。これは、「その場しのぎ」で答えてしまったがゆえだと思われ、自分の普段の思考の盲点があぶり出されるものであったように思う。

ブログや発表原稿の場合には、ある程度筋を作ってから書くので、ある部分と別の部分とで矛盾した内容を書き、しかもそれに自ら気づくようなことはあまりない。ポッドキャストは、自分の思考の流れに他者の意見や問いかけが挿し込まれるので、上に書いたようなその場しのぎの発言が出やすい状態になる。今回は聴き直したから気づくことができたが、普段の会話でも恐らくその種の発言をしているのだろう。これに気づくことができた(あるいは、向き合わざるを得なくなった)のはポッドキャスト出演の貴重な収穫だと思う。

終わりに

収録当日はとても楽しく、終わってからの反省の多いポッドキャスト出演だった。当初の「ポッドキャストに出演しても喋ることがないんじゃないか、リスナーのためになるのだろうか」というのは烏滸がましい悩みであり、むしろ自分にとって大きな気づきのある体験になった。このような機会を設けてくださったKANEさんとなべくらさんに感謝したい。反省を今後に生かすこととともに、本編でも言及があった「欲望との折り合いのつけ方」の記事を書くこととで報いたい。

なお、後半では、何度かTwitterでは言及している「言葉」についての思いを話させてもらっている。2本どり2本目ということもあり、緊張もほぐれてきて、個人的にはかなり手応えを感じている。まだ編集作業中で、僕の方にも音源が回ってきていないので、聴き直したら大いに反省することになるかもしれないが、公開されたらぜひ聴いてみていただきたいと思う。

*1:なべくらさんに至っては収録日が初対面だった。

*2:これは最終的に、なべくらさんが用意してくださった収録用のメモに統合された。

*3:ポッドキャストの中で言及したカカカカックさんからも「1.2倍速で聞くぐらいがちょうど良かった」というコメントをいただいた。

ソフトウェア開発者がテスト技術の資格「JSTQB」のテキストを読んで感じたこと

テスト技術についての資格である「JSTQB認定テスト技術者資格」のテキストを読んだ。読もうと思った理由は後述するが、ソフトウェア開発についての考えに別の光を当ててくれるいい体験になった。

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェアテスト教科書 JSTQB Foundation 第3版

  • 作者: 大西建児,勝亦匡秀,佐々木方規,鈴木三紀夫,中野直樹,町田欣史,湯本剛,吉澤智美
  • 出版社/メーカー: 翔泳社
  • 発売日: 2011/11/12
  • メディア: 単行本(ソフトカバー)
  • 購入: 5人 クリック: 85回
  • この商品を含むブログ (12件) を見る

なぜテストを学ぼうと思ったのか

僕は開発者、プログラマという自己認識をしており、現在の業務の中心はソースコードを書くことだ。また、普段勉強している事柄も、コードの書き方やプログラミング言語についてのものが中心になっている。

しかしながら、今回、テストの勉強をざっとでいいのでしておくべきだと思い立ち、冒頭に掲げた書籍を手に取った。その理由は以下の通りである。

  • 現職にはテスト専門の部隊がおらず、開発チームがテストまで行うため、テストの技法を知る必要がある。
  • プロジェクトを通じてどのように品質を高めていくを織り込んだ計画を作成する必要があり、テスト計画の考え方を知りたい。
  • テスト経験のないメンバーが漏れの多いテスト項目書を作成していたため、共通の理解の基盤が必要と考えた。

上記は、現在のプロジェクトというコンテキストに依存する理由であるが、一般論としても、ソフトウェア開発者として、品質に関わる重要な営みであるテストを学ぶ意味はあると思う。どれだけスピーディに開発をしても、品質が悪くテストで差し戻されるようであれば、結局リードタイムは長くなってしまう。製造業的な言い方をすれば、「歩どまりの悪い」開発となってしまう。

SHIROBAKO』で井口さんが、「リテイクが見えればいい原画が見える、悪い原画もわかる。」と言っているのと同じで、テストにおいてどのような観点でソフトウェアが見られるかを知っておくことは開発者にとって意味のあることだろう。そのような言説にもちょうど先日接する機会があり、いいタイミングだと思って学ぶことにした。

以下、本を一冊読んで感じたことを述べていく。

制約の中でテストをするということ

この書籍の冒頭の方で、「テストの7原則」というものが挙げられている*1

  • 原則1:テストは「欠陥がある」ことしか示せない
  • 原則2:全数テストは不可能
  • 原則3:初期テスト
  • 原則4:欠陥の偏在
  • 原則5:殺虫剤のパラドックス
  • 原則6:テストは条件次第
  • 原則7:「バグゼロ」の落とし穴

このうち、ハッとさせられたのは、原則2の「全数テストは不可能」である。これは、「ソフトウェアに入力する可能性のある、すべてのパターンをテストする」*2ことが不可能であると主張するものであり、当たり前といえば当たり前の、何ら衝撃を受けるようなものではない。

僕がこの原則に強い印象を受けたのは、この原則に端を発して、書籍全体を貫いているテストというものへの考え方が、自分のテストに対するイメージとは異なるものだったからだ。僕のテストに対するイメージは、バグを無くすためにしらみつぶしで実施するものというものだった。もちろん、全数テストを行うものだ、というまでの極端なイメージではなかったが、決められた件数を実施するまでひたすらやる退屈なものというイメージがあった。

しかしながら、この書籍では、時間やコストの観点から、どのようにテストを効率的に設計・実施するかという観点から書かれている記述が非常に多かった。どのようなテストを実施するのかについても、テストの目的、対象となるソフトウェアの種類に応じて合理的なものを選択するという姿勢が一貫している。「全数テストは不可能」という原則には、テストがそもそも限られた資源の中で実施されるものであり、「制約の中でどのようにテストを行うか」こそがテスト技術の本質なのだということが表現されているように感じた。現実を見据えることなくしてテストを考えることはできないのだ。

「品質」の多様性とOOP

テストは品質と深い関係を有している。僕も、品質という言葉を普段口にすることもあるが、実際のところ「品質」が何を指しているのかは深く考えたことがなかった。「バグがある」や「パフォーマンスが悪い」というのが品質の悪い例であることはわかるから、コードを書く際も左の2点については考えることは多いが、この書籍を読むことで、考慮すべき品質が思っていた以上に多様であることがわかった。

それを教えてくれるのは、書籍中で紹介されているISO/IEC 9126の品質モデルである。これは、非機能テストを実施する際に参照することのできるモデルとして紹介されているものであり、以下のように整理されている*3

品質特性 品質副特性
機能性 合目的性・正確性・相互運用性・セキュリティ・適合性
信頼性 成熟性・障害許容性・回復性・適合性
使用性 理解性・習得性・運用性・魅力性・適合性
効率性 時間効率性・資源効率性・適合性
保守性 解析性・変更性・安定性・試験性・適合性
移植性 環境適応性・設置性・共存性・置換性・適合性

これを見たときに、「自分は今まで品質というものの一部しか見られていなかった」という思いを持つとともに、ここしばらく興味を持って勉強している事柄の意義を再確認できた気がした。「興味を持って勉強している事柄」というのは、オブジェクト指向のことである。

オブジェクト指向は、拡張性や保守性を持ったソフトウェアを開発するための技術、考え方だと思っている。オブジェクト指向と品質の関係については、オブジェクト指向の泰斗であるバートランド・メイヤーの言葉を引いておきたい。鈍器大著『オブジェクト指向入門』の第1章は「ソフトウェアの品質」であり、以下のような端的な言明で説き起こされている。

工学の目的は品質である。したがって、ソフトウェア工学は、品質の高いソフトウェアの生産を意味する。本書ではソフトウェア製品の品質を飛躍的に高める可能性を持った一連の技法を紹介する。*4

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

メイヤーは、ソフトウェアの品質の「外的品質要因」と「内的品質要因」のうち、オブジェクト指向の技法が内的品質要因を実現するとした上で、あくまで後者は前者の達成のための手段であると述べる。これは忘れてはならない事柄だと思う。拡張性や保守性というのは、後々の開発者にとって問題になるものであり、直接的に顧客に価値をもたらすものではない。それ自体が価値なのではないという意味では、アジャイルもこれに似ており、ややもするとソフトウェア開発者の自己満足の対象となりかねないという危惧を持っている。

上の表に保守性や移植性というものが挙がっていることを、自己満足の免罪符に使うつもりはない。品質特性に含まれているということは、いつでもこれらが重要であるということを意味しない。どのような品質特性を重んじるべきかは、対象となるソフトウェアの性格によって異なるからだ。自分にとって「品質モデル」が啓発的だったのは、普段自分が「開発者」として興味を持っている事柄と、(今までは「開発」ではない営みとして見がちであった)テストで扱われている事柄が地続きであることを確認できたからである。

後工程を考えて開発するということ

当たり前のことではあるが、テストをする際には、要件がわかっていることが重要である。要件を窺い知るための資料は、書籍では「テストベース」という言葉で指示されている。外部のソフトウェアテスト会社にテストを依頼したところ、「仕様がないからテストできません、うちは設計する会社じゃないんですよ」と言われたという笑い話を耳にしたことがあるが、有効なテストを実施するためにはこのテストベースの充実が不可欠である。

テストベースの分析はテスト設計のための重要な作業であるわけだが、書籍では、実際のプロジェクトにおいてはこのテストベースが十分に揃っていない場合が多いから、収集と分析にかかるオーバーヘッドを考慮に入れて計画せよ、と指摘されている*5。ドキュメントが揃っていないと、テストにおいても遅延を引き起こすことになるというわけだ。

これは、現在のプロジェクトにおいても実体験していることであるが、仕様が開発者の頭の中だけにあるような状態では、テスト実施は覚束ない。「テストで見つかればいいや」と考えずに、品質を意識してコードを書くのは当然なされるべきことであるが、「どのような資料があればテストしやすいだろうか」と考えて適切な資料を残すということも重要なのである。後工程のことを考えて開発をするというのは、コードを書くことだけではないのだ。

おわりに:開発者がテストを学ぶということ

以前のブログ記事で、『エクストリームプログラミング』の一節を紹介した。以下に再び引用する。

ky-yk-d.hatenablog.com

品質部門を別に設置すれば、エンジニアリングにおける品質の重要性が、マーケティングや営業における品質と同等だというメッセージを送ることになる。エンジニアリングで品質に責任を持つ人がいなくなる。すべては他の誰かの責任だ。開発組織のなかにQA部門を設置したとしても、エンジニアリングと品質保証が別々の並行した活動であるというメッセージを送ることになる。品質とエンジニアリングを組織的に分離すれば、品質部門の仕事は建設的なものではなく、懲罰的なものとなってしまう。*6

現在属している会社にも、独立した「品質部門」が存在しており、プロダクトの品質を改善するためのマニュアルやドキュメントのフォーマットを「開発部門」に提供したり、レビューに入ったりしている。自分も「開発部門」の一角に属する身であるわけだが、他の「開発部門」の諸先輩に話を聞いてみると、「品質部門」の取り組みに対して懐疑的な声も聞こえてくる。だからこそ、『エクストリームプログラミング』の上の記述を読んだときは笑ってしまった。

今回、JSTQBのテキストを読んでみて、テストという営みがソフトウェア開発プロジェクトの「テスト工程」以外の部分にも深く関わっているものだということを確認することができた。上では書かなかったが、開発者とのコミュニケーションの重要性や、プロセス全体においてテストチームがボトルネックとならないようにする配慮、テストに関わるリスクに対する考え方など、テストという分野が視野に収めるべき事柄は非常に広い。これは、専門職としてのテスト技術者の重要性を語るものであると同時に、「視野に収められる側」である開発者もまたテストを学ばねばならないということも意味しているのだろう。

エクストリームプログラミング

エクストリームプログラミング

*1:27頁以下。

*2:28頁。

*3:108頁。

*4:バートランド・メイヤー『オブジェクト指向入門 第2版 原則・コンセプト』2頁。

*5:40頁。

*6:ケント・ベックエクストリームプログラミング』128頁。