こまぶろ

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

コードの改善に使うEclipseショートカットキー（Windows/Mac）

Java プログラミング

Eclipseには、様々な編集機能や、自動リファクタリングの機能が搭載されている。Eclipseのショートカットキーを幅広く紹介する記事は、すでに優れたものが存在しているので、よく使うものだけをメモ。

qiita.com

Eclipseによるコードの改善

以下のライブコーディングでは、Eclipseの機能の力によってものすごい速さでコードが書き換えられていく様が見られる。手元が見えないのが非常に残念なのだが、ショートカットをかなり駆使していることは間違いないだろう。Java 8（ラムダ、Optionalなど）の使い方の紹介としても優れた動画だと思うのでおすすめ。

よく使うショートカットキー

以下、普段使うことの多いショートカットキーをつらつらと紹介。下記ツイートのような次第で、WindowsとMacの両方でのマッピングを併記する。なお、Win/Mac対照についても網羅的なものが既に存在しているので紹介しておく。

hutyao.hatenablog.com

名前変更

Windows Mac
alt + shift + R command(⌘) + option(⌥) + R

変数やクラス、メソッドなどの名前を参照元も含めて一括で変更できる。参照の数が少ないと手で書き換えることもあるが、油断をすると書き換え漏れが発生することもあるので基本的にこれを利用している。ファイル名と同名のクラスに対して実行した場合には、ファイル名にも変更が反映されるのが便利。

メソッドの抽出

Windows Mac
alt + shift + M command(⌘) + option(⌥) + M

選択した範囲を別のメソッドとして切り出す。リファクタリングの最初の一歩ともいえるかもしれない。

移動

Windows Mac
alt + shift + V command(⌘) + option(⌥) + V

メソッドを別のクラスに移動したり、ファイルを別のパッケージに移動したりするのに使う。前出の「メソッドの抽出」と組み合わせて、コントローラに書かれた処理をモデルのメソッドに書き換えるときなどに使う。

ローカル変数の抽出

Windows Mac
alt + shift + L command(⌘) + option(⌥) + L

選択した式（戻り値の型がvoidでないメソッドの呼び出しなど）の評価値を、推論された型の変数に代入するコードが自動生成される。同じ式の箇所は一斉に新しく作成されたローカル変数で書き換えられるのがポイント。別の使い方として、代入式の右辺を先に書いてから実行することで、ローカル変数の型の記述をサボるのにも使える。

インライン化

Windows Mac
alt + shift + I command(⌘) + option(⌥) + I

選択した変数を、インライン化する。「ローカル変数の抽出」の逆。

メソッドシグネチャの変更

Windows Mac
alt + shift + C command(⌘) + option(⌥) + C

ダイアログ画面を使って、アクセス修飾子、戻り値の型、メソッド名、引数の型と名前、throws句などをまとめて変更できる。

矩形選択

Windows Mac
alt + shift + A command(⌘) + option(⌥) + A

リファクタリングに特化した機能ではないが、メソッドの位置を移動してからthis.をまとめて[パラメータ].に書き換えるときなどに使うことがある。

次の注釈へ

Windows Mac
ctrl + . command(⌘) + .

次のエラーや警告の箇所にカーソルをジャンプさせることができる。リファクタリングに特化したものではないが、非常によく使う。スクロールバーで赤い/黄色い位置に移動するのは結構面倒なもの。

クイックフィックスを適用

Windows Mac
ctrl + 1 command(⌘) + 1

「次の注釈へ」とセット。修正候補から選択するだけで自動的に様々な修正を実施してくれる。

JUnitテストの実行

Windows Mac
alt + shift + X → T command (⌘) + option(⌥) + X → T

以上のようなショートカットを駆使し、スピーディにコードを改変していくためには、壊していないことを確認することがやはり必要。やや手間がかかるショートカットなので別のキーを割り当ててもいいかもしれない。

おわりに

本来、IDEの機能は「手動でやっていたことを自動でできるようにする」ものだと思うが、経験の浅い身にとっては、「なるほどこういう改善の仕方があるのか」というのを学ぶいい教材でもある。まだ使えていないIDEの機能を探すことを通じて、コード改善の手法をもっと身につけていきたい。

技術者のアウトプットにおける「エモさ」とは何か

雑記

ゲストで出演させてもらった「#成し遂げたいam」のep.8が公開された。前後編に分けて収録したうちの後編である。なお、前編が公開されたときに記事を一本書いているので、ポッドキャスト収録ということについてはそちらもご覧いただきたい。

anchor.fm

ky-yk-d.hatenablog.com

後半では、「言葉にこだわる」ということについて喋らせてもらった。意味が曖昧であることが問題になる例として「技術力」を、曖昧さに加えて価値判断が込められていることが問題になる例として「レガシー」をそれぞれ挙げ、適切な言語表現を利用することが思考・コミュニケーションの両面において重要なのではないか、ということを話した。

ep.8の後半*1では、技術者のアウトプット*2について「エモい」という表現が使われるケースについて話している。今回も公開を前にして聴き直させてもらったのだが、「エモ」については言葉足らずな部分があったと思われたので、補足としてこの記事を書くことにした。以下、放送の中で「エモい」という言葉に与えている3種類の意味について記述する。

コンピュータ領域の知見の欠如としての「エモさ」

会話の最初の方では、「技術的な」の対義語として、「技術的でない」という欠如した状態について、「エモい」という表現が使われている（ように思われる）ケースの話をしている。

ここでは、「技術的」とは何かということ自体が問題になるのだが、プロジェクトマネジメントに関わる事柄などは一旦除外して、「コンピュータの動作に関わる事柄」、つまりハードウェアあるいはソフトウェアに関する知識が含まれていることを「技術的」と表現しているものとして理解してもらえばいい。

「エモい」をこのような意味で捉えることは、語の字面から離れているので、あまり好ましくないと思う。同じような文脈で、「ポエム」という言葉が使われることもあるが、これも詩という文学ジャンルに対する理解および敬意を欠いたものであり、適切ではない。

では、「エモい」の語用から離れて、このような意味での「エモい」アウトプットは、どのような意義を持つ、あるいは持たないのであろうか。まず、読み手にとっては、もし技術的な内容を求めているのであれば、読まなければいいのであり、特定の読み手にとって無益であることこそあれ有害であることはないと思われる。

ただし、Qiitaやはてなブックマークの「テクノロジー」カテゴリのランキングが非技術的な内容のもので埋められてしまうとすれば、それは本来の情報収拾を妨げる害をもたらす。この点については、書き手の側に一定の配慮が求められる場面があることも否定しない*3。最終的にはサービスの運営主体による判断次第ではあるが、Qiitaでは、

プログラミング以外の内容は投稿しない

と、コミュニティガイドラインに明記されており、ガイドラインやそれを踏まえた利用者同士の議論を参照しつつ、書き手が自主的に判断することが求められている。

一方、書き手にとってはそれぞれの記事をどのような目的で書くのかはあまりに人それぞれであるため、一概には言えない。もし、アウトプットが転職に向けたプログラミングスキルのアピールが目的であれば、「非技術的」なものはあまり有効ではないであろう。対して、このブログがそうであるように、目的が考えの整理であれば、「非技術的」なものもまた有意義でありうる。いずれにせよ、目的に応じて合理的な手段が取れているかという判断を各自がするほかない。

読み手の感情を動かすものとしての「エモさ」

2番目の意味として、読み手の感情を動かすものとして「エモい」という言葉を用いた。これは、『カイゼン・ジャーニー』について以下のように述べている場面での用法だ。

いい意味で「エモい」本であると同時に、それだけでは終わらない何かを持っている

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

Amazon

ここでの「エモい」は、「コンピュータの動作に関わる事柄の欠如」ではなく、「感情を動かす要素の具備」を表現している。この意味が、音楽の文脈で使われていた本来の意味にも、emotionalという英語の原義にも忠実であり、適切であると思われる。なお、第一の意味での「エモい」と第二の意味での「エモい」は必ずしも一致しない。一冊の本の中に、コンピュータの動作に関わる知識と、読み手の感情を揺さぶる内容がともに含まれているということはありうる。

この種の「エモい」アウトプットが読み手に対して持つ意義については、放送の中で述べたとおりだ。ソフトウェア開発は簡単でないし、ビジネスとしてのシビアな側面も有している。また、組織の中で仕事として行われる限り、そこでの人間関係によってストレスが生じることもある。そのような苦しさを伴うソフトウェア開発という営みにエネルギーを持って向き合っていくために、この種の「エモさ」が助けになることはあるだろう。書き手にとっても、自分のアウトプットに対して寄せられる共感は糧になるものだ。

一方で、放送の中で少し言及したように、「頑張れる気はしたのに現実を変える術は得られなかった」ということになると、主観的な苦しさが紛れるだけで、開発の現場は前進しない。むしろ主観的な苦しさを紛らわすことによって実際の問題の解決が遅れるようなケースもあるのではないか。Show Notes にも記載してもらった以下のツイートはこのような考えを提示したものだった。

「現実と格闘するための武器となる知恵」は、必ずしも「コンピュータの動作に関わる」という意味での技術である必要はない。ソフトウェア開発の苦しさを生み出す現象が、コミュニケーションや見える化、タスク管理などによっても解決されうるというのは事実だろう。ただし、そのような「非技術的」アプローチが問題を解決する最良の手段であるとは限らないということは肝に銘じておかなければならない。伊藤直也さんの大好きな言葉を引用しておく*4。

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

Amazon

感情に訴えて説得することとしての「エモさ」

放送の中で用いている「エモい」の第三の意味は、「説得力を読み手の感情に訴えることによって得ようとする」ということであり、僕が独自に定義したものだ。このような「エモい」の定義は、僕の課題意識に密接に関わっている。

僕のブログを読んで、揶揄する意図を込めずに「エモい」という感想をくれる人がいる。一方で、「エモい記事ばかり書いていてはいけないよ」と諭してくれる人がいる。恐らく前者の「エモい」はこの記事における第二の意義に近く、後者の「エモい」は第一の意義で用いられているのだと理解している。いずれも、ありがたいフィードバックだ。

先に述べたように、技術者としてのアウトプットで「非技術的」なものがどれだけ有意義なのか、あるいはその執筆に費やした時間で「技術的」なものに取り組んだ方が有意義なのではないかという疑念は常にある。上記の「エモい記事ばかり……」という問題提起には確固たる態度決定をいまだに行えていないのだが、現状の自分の姿勢は、「非技術的なアウトプットにも書き手である自分にとっての意義がある」というものだ。でなければこんな記事は書かないし、ポッドキャストにも出ない。

第一の意味での「エモい」記事を書くことに対して、自分は抵抗はない*5。また、第二の意義での「エモい」記事については、あえて書こうというつもりはないが、読み手が「エモい」と感じるのであればそれは止めない。そう受け取られることにも抵抗はない。いずれの意味においても、「エモい」という言葉はあまり大きな意味を自分に持たない。

もちろん、「エモい」という言葉を使わない、無視するということもできる。しかしながら、「エモい」という言葉があまり意味を明確化されずに、しばしば揶揄のために用いられていることに対するささやかな抵抗を試みたい。この言葉を、単なる揶揄ではなく、何かしらの問題を適切に言い当てるものとして定義し直したいという欲望を持った。

そういう訳で考え付いたのが、「説得力を読み手の感情に訴えることによって得ようとする」という「エモさ」の定式化だった。この意味の否定的な評価は、自身の過去の記事について自ら下しているものでもあったし、自分以外の記事や各種の発言についても感じる部分があったものだ。「エモい」という言葉で言い表すことで、取り組むべき問題としてより強く意識できるのではないかと考えた。

この定義は、まだ練る余地のあるものだろう。感情に訴える説得とは何なのか。そもそも感情に訴えない説得というのがありうるのか。いまいち明確でない。「伝われ」という思いを持っているのも正直なところであり、「エモい」の定義自体がまだ「エモい」ものになっている。しかし、「そこに何かしら問題がありそうである」ということを指摘するのには十分に意味のあるものなのではないだろうか。

おわりに

以上、放送の中で用いている「エモい」の3つの意味について、補足的な説明を試みた。第一の「非技術的」という意味は、その過度の広範さを理由として自分としては使いたくないものである。第二の「読み手の感情を動かす」という意味は、最も字面や語源に忠実であり、この意味で使うことは今後もあるだろう。第三の「説得力を読み手の感情に訴えることによって得ようとする」という意味は、自分自身で持っていた課題意識のために「エモい」という言葉を転用したものであり、放送でも述べたようにこの種の「エモさ」はブログから減らしていきたいと考えている。

「説得力を読み手の感情に訴えることによって得ようとする」ということを避けようとするとき、自らを戒めなければならないと思っていることがある。それは、科学的な手続きで得られた根拠をもっと重視すべきだということだ。言語や論理ということに愛着を持つ一方で、自分はあまり実証に対して関心を持っていないという自覚がある。科学的な根拠に裏付けられた主張のみに価値があるという立場は採らないが、科学的な根拠の必要な場面で印象論を述べてしまうようなことは避けなければならない。印象論はまさしく第三の意味での「エモい」ものに他ならないのだ。

*1:28分頃〜。

*2:以下では、記述の冗長さを避けるため、断りがない限りは、アウトプットの代表として、ブログの記事を前提とした場合の表現を用いる。つまり、アウトプットの出し手は「書き手」と、受け手は「読み手」と記述する。これは、あくまで便宜上のものであり、口頭発表やポッドキャストなど別の媒体でのアウトプットを言及の対象から除外することを意味しない。

*3:もっとも、はてなブックマークの場合は、アウトプットの媒体に依らずに勝手にカテゴライズ、ランキング掲載されるので難しい。

*4:伊藤直也「大事な問題にフォーカスする」（『エラスティックリーダーシップ』所収より。

*5:ただし、この意味で「エモい」という言葉を用いることには反対である。

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

設計 雑記

要約

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

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

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

Amazon

SOLID原則との出会い

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

  • Ｓ：単一責任の原則（Single Responsibility Principle）
  • Ｏ：オープン・クローズドの原則（Open/closed principle）
  • Ｌ：リスコフの置換原則（Liskov substitution principle）
  • Ｉ：インターフェイス分離の原則（Interface segregation principle）
  • Ｄ：依存性逆転の原則（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を導くものであるかも、まだよくわかっていない。この点については、改めて検討したいと思う。

参考）

http://labs.septeni.co.jp/entry/2017/02/21/164127labs.septeni.co.jp

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

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

Amazon

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

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

Amazon

*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頁。