Information Technology Tips

MySQLのSQL_CALC_FOUND_ROWSを使用する際の無駄なメモリ消費に注意 ページング機能の実装などのために、ヒットした全件数を取得する必要のある場合があるかと思います。 その場合、下記のようにSQL_CALC_FOUND_ROWSを使うと、検索結果に加えて、そのクエリの全ヒット件数が取得できます。 SELECT SQL_CALC_FOUND_ROWS table.column1, table.column2 ...(途中省略)... FROM table WHERE (条件) しかし、SQL_CALC_FOUND_ROWSを使うと、「絞り込んだ結果にヒットする全べての行の結果のセットを作成する」という大きな欠点があります。 これは、LIMIT, OFFSETを指定していても実行されてしまうので、 SELECTで指定するカラム数やデータ量が多い SELECTの結果返ってくる行数が多い 場合、無駄に領域(≒メモリ)を消費してしまうので注意が必要です。 例えば、100万行検索対象としてヒットするクエリの場合、仮にLIMIT 20と指定して最初の20行を取得するようにクエリを書いても、その100万行分の結果セットが作成されてしまうということになります。 対応策 根本的な対応策としては、SQL_CALC_FOUND_ROWSを使わない(結果行数の取得はCOUNTを用いた別クエリで取得する、結果行数をあらかじめサマリーテーブルに保持しておく)ことですが、 SQL_CALC_FOUND_ROWSをどうしても使う必要がある場合は、 SELECT SQL_CALC_FOUND_ROWS primary_id のように最低限のカラムを指定して結果行セットを取得 (LIMIT OFFSET指定前提) 取得したprimary_idを使って必要なデータを取得 して、SQL_CALC_FOUND_ROWSで使用する領域をできるだけ減らすことで、対応するしかないと思います。 世の中ではLIMIT, OFFSETは使わない方がよいとよく書かれていますが、 SQL_CALC_FOUND_ROWSは、書いてしまえばどんなときも検索にヒットする全結果行セットを作成するので、同じくらい使用する際には注意が必要です。

SELECTの結果をUNIONして ORDER BY する際には下記の点に注意する必要があります。 無駄なメモリ消費 ソートにINDEXが利かない (≒CPU負荷増大) 対応策 可能であればPush-down Condition (各サブクエリ内でORDER BY, LIMIT, OFFSETを適用してからUNION, ORDER BYを実行する)を利用することで、 パフォーマンスを改善できる場合があります。 下記に例を示します。 もともとのクエリ SELECT tmp.* FROM ( SELECT tableA.column1, tableA.column2 FROM tableA WHERE (条件) UNION ALL SELECT tableB.column1, tableB.column2 FROM tableB WHERE (条件) ) AS tmp ORDER BY tmp.column1, tmp.column2 LIMIT 100, 20 Push-down Conditionを用いて書き直したクエリ SELECT tmp.* FROM ( SELECT tableA.column1, tableA.column2 FROM tableA WHERE (条件) ORDER BY tableA.column1, tableA.column2 LIMIT 30 # ただしこのPush-down Conditionの手法も下記の場合は、効果が半減しますので注意が必要です。 OFFSETの値が大きい場合は、結局全結果セットUNIONと変わらない サブクエリ内のソートで、INDEXが効かない場合

今回は、筆者が気をつけている、MySQLのクエリチューニングの基本的な考え方について、紹介しようと思います。 基本的な指針としては、下記を守ることが重要です。 MySQLがクエリの実行で使用する領域(≒メモリ使用量)を減らす。 クエリ対象の行を減らす (INDEX, サマリーテーブルを駆使)。 上記の基本的な指針に基づいて、クエリを組み立てる際は以下の点を考慮するとよいと思います。 SELECTで指定する行は少なくする。 JOINするテーブルの数は減らす。 TEXTや大きいサイズのVARACHARでのORDER BYは極力避ける。SUBSTRなどを使ってカラムの一部データのみを使うことも考慮。 EXPLAINを実行した際に Extra: Using where; Using temporary; Using filesort と表示される場合は要チェック。 確認部分: 巨大なTemporaryテーブルが作成されないように注意。 対策: 「ソート部分でINDEXを使えないか」「サマリーテーブルを使って余計なJOINを減らしソート対象の行数を減らせないか」を検討。 INDEXを効かせる。 テーブル設計段階でどのカラムにINDEXを張るかをしっかり検討 (当たり前ですが。) 特にソートの必要がある場合は、できるだけINDEXやPRIMARY KEYを利用できるようにクエリやテーブルを設計。 基本MySQLのクエリオプティマイザに従うべきですが、あえて特定のINDEXを効かせる/効かせない場合は FORCE INDEX STRAIGHT_JOIN の利用も検討。ただし、クエリの実行プランはデータによっても変わるので、基本、FORCE INDEXやSTRAIGHT_JOINは使うべきではないと筆者は考えています。 想定される状況が限定的 解決しようとしているクエリの問題が明確 性能改善度合いが大きい ときのみ、FORCE INDEXやSTRAIGHT_JOINは使用すべきかと思います。また強制したクエリの実行プランが最悪の実行プランになった場合も想定することをお勧めします。 複雑なネストクエリは避ける。 確認部分: Temporaryテーブル(INDEXが効かない！)が作成される可能性が高い上、メモリも大量に...

下記の順序で環境を更新していったときに、問題が起こったのでメモしておきます。 Spring 3 + Java 7: もともとの環境。 Spring 3 + Java 8 (Java 8のラムダ機能などのJava 8からの新機能は未使用): 問題なく動作。 Spring 3 + Java 8 (Java 8のラムダ機能などのJava 8からの新機能を使用): 起動時に下記のExceptionが発生 org.springframework.beans.factory.BeanDefinitionStoreException: Failed to read candidate component class: URL ...(途中省略)... java.lang.ArrayIndexOutOfBoundsException: xxx Googleで調べたところJava 8から導入された新機能を使う場合は、Spring 4に更新しないといけないようです。 Mavenとかは、使っていなかったので、Spring Frameworkから提供されているspring-xxx系のjarすべてをバージョン3.X系からバージョン4.X系のものに手動で置き換えました。 (Spring Frameworkはバージョン5.X系ももう出ているのですね。既に置いていかれているorz...) 無事にアプリケーションが起動するようになりました！ ただ普通は、こんな乱暴にjarを入れ替えることは難しいので、アップデートはもっと慎重にやるべきでしょうね。

Google App Engine(GAE)から外部のネットワークへ接続する際の注意 Google App Engine(GAE)の開発環境の移行の際にJava 7からJava 8へ移行しました。 その際、GAEから、java.net.URL.openConnectionを使って普通に外部ネットワークのAPIを呼び出そうとすると下記のエラーが発生するようになってしまいました。 java.net.UnknownHostException: ホスト名 いろいろ調べていくと、下記のページにたどり着きました。 https://cloud.google.com/appengine/docs/standard/java/issue-requests 上記の表を間単に日本語訳すると URLのフェッチ方法 Java 7 Java 8 UrlFetch API Calls com.google.appengine.urlfetch.*以下のクラスを使う。無料で使用できる部分あり。 com.google.appengine.urlfetch.*以下のクラスを使う。無料で使用できる部分あり。 Javaネイティブのjava.net.URL.openConnectionなどを使う方法 無料ユーザも制限なく利用可能。 無料ユーザは、利用不可。 java.net.UnknownHostException、java.net.SocketTimeoutException、java.io.IOException とかが投げられる。 まとめると、 GAEで外部ネットワークへアクセスする方法には「GAEが提供するUrlFetch API Calls」「Javaネイティブのjava.net.URL.openConnection」の2つ方法がある。 Java 7では、「GAEが提供するUrlFetch API Calls」「Javaネイティブのjava.net.URL.openConnection」は無料でどちらの方法も利用可能。 Java 8で無料で利用できるのは「GAEが提供するUrlFetch API Calls」のみ。 Java 8で「Javaネイティブのjava.net.URL.openConnectionの方法」は課金ユーザーのみ利...

Google Plugins for EclipseからCloud Tools for Eclipseの移行 長らくEclipse Luna (4.4) + Google Plugin for Eclipseで開発を続けてきたのですが、Google App Engineの開発ページを覗いたら下記のようなメッセージが出ていてびっくり。 The Google Plugin for Eclipse is deprecated and will be removed in January 2018. Migrate to Cloud Tools for Eclipse and/or the GWT Eclipse Plugin as soon as possible to avoid disruption. Google Plugin for Eclipseは、2018年の1月でサポート打ち切りで、Cloud Tools for Eclipseに移行しなさいとのこと。 せっかくなので最新のeclipseを使って下記の設定で開発環境を再構築することにしました。 移行方法 最新のJDK 8 を http://www.oracle.com/technetwork/java/javase/downloads/index.html からダウンロードしてインストール。JDKをダウンロード Java 9 も試そうかとも思ったのですが、2017年9月現在Google App Engine側はまだJava 8までしかサポートしていないので、 Eclipseを  http://www.eclipse.org/downloads/eclipse-packages/  からダウンロード。私は、Eclipse IDE for Java Developersをダウンロードしました。 EclipseでGoogle App Engineの開発を行うための設定を https://cloud.google.com/eclipse/docs/quickstart  を読んで実施。 Google Cloud SDKをダウンロード Google Cloud Tools for Eclipse をEclipse Marketplace.を通してインス...

ジェラルド・M・ワインバーグは、自身のコンピューター業界を中心としたコンサルタント業の経験をもとに、人間やシステムの性質を本質的に捉えた数多くの書籍を発表しています。 今回紹介するのは、その中の「 プログラミングの心理学 25周年記念版 」になります。 25周年は、英語ではSilver anniversaryと表現されるようで、原題は「 The Psychology of Computer Programming: Silver Anniversary Edition 」となっています。 本書題名中の25周年というのは、原著の「The Psychology of Computer Programming」の初版が発行された1971年から25年後、つまり1998年に発行された英語版のことをさして、25周年といっています。この英語版の「 The Psychology of Computer Programming: Silver Anniversary Edition 」は、一度2005年に邦訳されて2005年に「 プログラミングの心理学―または、ハイテクノロジーの人間学 25周年記念版 」として刊行されています。今回紹介するのは、2005年に刊行された邦訳版の装丁を変えて2011年に再発刊されたものになります。ですので、おおもとの原著からは、40年経っていることになります。 本書では、1971年当時の初版の構成をそのままに、そのあとに25年後のワインバーグの振り返りが追記されるという形式をとっています。 この書評を書いている時点で、40年以上も前 (25周年を記念して加筆された部分は20年前)の内容で役に立つのと思う方も多いと思いますが、それがどうして、世の中あまり変わっていないのか、今でも十分に通用する示唆に富んだエピソードが多く紹介されています。 とはいえ12章「プログラミング言語の設計原則」で出てくる言語の話題はCOBOLとかFORTRANなので、「その言語なに？おいしいの？」「古臭い話だ！」と思う人が多いと思います。それでもよく掘り下げて読んでみると、普遍的な話題を扱っていることに気づかされると思います。これは、本書が「心理学」という言葉を使っているとおり、いつまでたっても変わらない、人間の根本的な性質を軸に書かれているからだと思い...

今回紹介するのは、「 世界一わかりやすいプロジェクトマネジメント 第4版 」です。 本書は「IDIOT'S GUIDE」シリーズの中の一冊になります。 英語の最新版は2014年刊行の第6版「 Project Management, Sixth Edition (Idiot's Guides)  」のようです。   本書では、プロジェクトマネジメントにかかわる基礎的な手法や用語が細かく解説されています。たとえば、 PDCAサイクル ガント・チャート (gantt chart) クリティカル・パス (critical path) WBS (Work Breakdown Structure) 振り返り スコープ・クリープ (scope creep) などです。本書は邦訳された書籍なので、日本語のプロジェクトマネジメント用語が英語ではどういうものになるのかも参考になると思います。 個人的には解説の途中途中で、数行さしこまれている「ときは金なり」「現場の声」「ご用心」「賢者の言葉」の項が読んでいて、面白かったです。 本書は、教科書的な書き方で書かれているので、面白みはないですが、プロジェクトマネジメントで発生する作業について網羅的に書かれているので、プロジェクトマネジメントに初めて取り組む人にとっては、よいスタート地点になると思います。より実践的なものを求める方は、「 アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 」の方がお勧めです。

今日紹介する書籍は、「 チームが機能するとはどういうことか―「学習力」と「実行力」を高める実践アプローチ 」です。 本書はタイトルどおり、チーミングでも特に「学習」という部分に特に重点を置いて書かれています。 原著は「 Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy 」になります。直訳すると「チーミング: 知識経済の中で、いかにして組織は学習し、イノベーティブになり、競争するか」にでもなるでしょうか。 この書籍については直訳より、邦訳版の題名の方が断然よいと思います。私が本書の内容を読んだ限りでも、邦訳版の題名は、本書の内容をよく表していると思います。 予断ですが、Innovationの訳は日本語では、カタカナ英語のイノベーションが一般的になっているとは思いますが、何かもっとピッタリ来る日本語はないのでしょうか。 本書はリーダーがトップダウンの決定を下すのではなく、チームメンバーそれぞれが自身の専門性や得意分野を生かし、意見の対立を乗り越えて、チーム全体で学習しながらチーム全体のパフォーマンスを上げるためには、どうすればよいかについて実例を交えながら詳細に述べられています。 こういったチーミングやマネジメントの話は、掘り下げていくと、人間の内面に深く根ざした部分にたどり着き心理学の研究結果が大いに役に立つものですが、本書もその例に漏れず、心理学分野の研究結果も交えなながら、効果的なチーミング手法について解説がなされています。例えば、人間は今まで自分が経験してきたものによって、現在の状況の認識が左右されているという観点(=フレーミング)から、革新的なプロジェクトを成功させるためには、どのような「フレーミング」が適切かを解き明かし、またリーダーはどのようにしてチームに適切なフレームを導入することができるかについて解説しています。 多くの書籍で「失敗」から学ぶことの重要性について語られていますが、本書では「失敗」を罰せられない環境づくりがなければ、「失敗」から学ぶことは難しいと指摘しています。本書では、失敗を「防ぐことのできる失敗」「複雑な失敗」「知的な失敗」に分類し、「防ぐことのできる失敗」は根本原因の究明を行い、「複雑な...

今日紹介させていただくのは、リチャード・P・ルメルトの「 良い戦略、悪い戦略 」です。 私は本書を読んで、リチャード・P・ルメルトの他の書籍を読んでみたいと思ったのですが、どうも2017年現在ではこの一冊ぐらいしか一般向けの書籍はないようです。残念。 定番の原著の紹介ですが、原著の題名は「 Good Strategy / Bad Strategy: The Difference and Why It Matters 」です。この書籍については邦訳版の題名は、ほぼ直訳になっています。 副題もつけて訳せば「よい戦略、悪い戦略: その違いとなぜその違いが大事なのか」になるでしょうか。 私は、著者の意見に共感する部分が多く、時間を置いては読み直して、読み直すたびに著者の「よい戦略」の立て方を頭の中に入れなおし、「悪い戦略」に自分が陥っていないか確認しています。本書では、まず「よい戦略」の実例を挙げ、その後「悪い戦略」を徹底的に(!)こき下ろしてその特徴を解き明かし、それ以降は「閾値効果」「テコ入れ効果」「おもしろみのある競争優位」など数多のキーワードを使って筆者独自の視点で「よい戦略」の特徴を丁寧に説明しています。 本書は共感する部分が多く、全部紹介したくなってしまうのですが、「よい戦略」については、是非本書を読んでもらうとして、特に私が強く共感した戦略とリソースの部分を紹介します。筆者は戦略とリソースの関係をこう述べています。 後世に賞賛され研究されるような優れた戦略は、乏しいリソースから始まっている。 ... その希少なリソースを巧みにコーディネートするところに戦略の妙味がある。 ... あまりに有利な地位を占め、さしたる努力もなしに利益があがるようになると、ぬくぬくとぬるま湯につかって楽をしたくなるのが人情である。 成功は怠惰とうぬぼれを招き、ひいては衰退や低迷につながる。 (184～185ページから抜粋) 私もかなり限られたリソース環境でプロジェクトを運営したのですが、本書で述べられている通り、その方が「本当に必要なものだけを実施しよう」「いかにして自らの強みを生かそうか」と必死に考えるようになり、結果的によい戦略かどうかは分かりませんが、非常に意味のあるとがった戦略を立てることができたと思っています。 このリソース...

今日紹介する本は「 アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法― 」です。 本書は、著者スコット・バークン(Scott Berkun)が、マイクロソフトに長年プロジェクトマネージャーとして勤務し経験してきたことを、一般化してまとめたものになります。 著者の実体験をふんだんに取り入れて書かれていますので、実感がこもっているところがよいろ思います。 クリティカル分析の仕方やガントチャートの組み方といったプロジェクトマネジメントの技術的手法そのものではなく、プロジェクトマネージャーの心構え、コミュニケーションのとり方、よいアイデアの生み出し方といった、より実践的なスキルについて書かれた本になります。 原著の題名は日本語のカタカナ英訳と同一で「 The Art Of Project Management (Theory in Practice (O'Reilly)) 」です。邦訳の題名には著者の経歴を踏まえて「Microsoft」を入れたのだと思います。  原著の方は新版が発行されていました。ぜひ機会があれば読んでみたいと思います。 「 Making Things Happen: Mastering Project Management (Theory in Practice (O'Reilly)) 」   本書は、優先順位付けの大切さ、ものごとを成し遂げるためには「ノー」といえるようにならなければならない、社内政治から逃げてはいけない、など、私に初めてプロジェクトマネジメントとはどういうものかを教えてくれた思い出深い書籍です。 特に当時の私は社内政治という言葉を毛嫌いしていました。本書の著者の言葉をかりていうならば、 政治力(名詞): 邪悪で、弱虫で、自己中心的な人々が利用しようとするもの (399ページ) と認識していました。この章で著者(Berkun)の上司がある行動をとったことにより、著者は「政治」に対する認識を大きく改めます(上司がどんな行動をとったかは是非、本書を読んでみてください)。私は、この部分を読んで「政治」に対する自身の認識の未熟さと傲慢さを痛感し、社内政治もしなければ、物事は成し遂げられないと強く思うようになりました。 著者は、本書で様々な視点から、どのよう...

今回、紹介する本は「 ハーバード流 ボス養成講座 優れたリーダーの3要素 」です。 私は正直「ハーバード流○○」「マッキンゼー流××」「Google流△△」などのようにいわゆる、一流と呼ばれる組織の名前を追加して、「ハロー効果(ある対象を評価をする時に、それが持つ顕著な特徴に引きずられて、他の特徴についての評価が歪められる現象のこと[Wikipediaより引用])」により買わせようとするマーケティング手法に対しては苦々しく思っています。本書もマーケティング戦略のためか、邦訳版の題名と原著の題名には大分乖離があります。原著の題名はシンプルに「Being the Boss: The 3 Imperatives for Becoming a Great Leader」、直訳すると「ボス(上司)になる : 偉大なリーダーになるための3つの必須事項」になるかと思います。 題名で売りたいだけの本で中身は薄っぺらいのかなと思い、本書を購入する気は余りなかったのですが、他の方の書評を見て購入に踏み切りました。内容は非常に実践的で濃いものですので、お勧めです！逆に題名に「ハーバード流」とか安っぽくなるのでつけない方がよい気がします。 翻訳そのものに関しては、ビジネス書の翻訳でよく見かける村井章子さんの訳だけあって、非常に読みやすいです。本書で最も読みづらかったのは、各章の導入部分で物語風に書かれている部分の登場人物の名前です。私は英米人の名前には馴染みが薄く、誰が何の役職なのかすぐに理解できなくなってしまいました。例えばブレンダ・ボールドウィン、レイ・サンチェス、ジャック・キャビットなどが登場します。日本人向けであれば、鈴木、山田、田中とかに置き換えて読むと理解が早まるのではないかと思いました。 さて肝心の内容です。本書は会社の中核を担う中間層のリーダーたち向けの本になります。彼らに求められる3つの要素(3 imperatives)として本書は 自分をマネジメントする 人脈をマネジメントする チームをマネジメントする を挙げています。単に並べただけですと抽象的ですが、各要素ごとに分量を割いて深く掘り下げて書かれています。 「2. 人脈をマネジメントする」の部分では「上司」「組織」「影響力」、「3. チームをマネジメントする」の部分では「将来像」...

今日紹介する書籍は、「 なぜ、わかっていても実行できないのか 知識を行動に変えるマネジメント 」です。   こちらの書籍は、2000年に出版された「The Knowing-Doing Gap: How Smart Companies Turn Knowledge into Action」の邦訳になります。   「The Knowing-Doing Gap: How Smart Companies Turn Knowledge into Action」の邦訳は既に、下記の2回刊行されています。 「 変われる会社、変われない会社―知識と行動が矛盾する経営 」2000年 「 実行力不全 」2005年 私は、「なぜ、わかっていても実行できないのか 知識を行動に変えるマネジメント」を購入した後、別の本だと勘違いして「実行力不全」を取り寄せてまで買ってしまいました。どこかで読んだことがある内容だなぁと思いながら読んでいて、同じ内容の本だと気がつきました。 「なぜ、わかっていても実行できないのか 知識を行動に変えるマネジメント」の最後のページにも、過去に刊行された本を改題、修正したものだと書いてありました。 目次の見出しなど、細かいところに翻訳の差異がありますが、内容はほぼ変わりませんので、上記紹介した3冊のいずれかを購入すれば問題ないかと思います。 邦訳版は3回刊行されいぇいますが、毎回書名がずいぶん違います。原著の題名「The Knowing-Doing Gap: How Smart Companies Turn Knowledge into Action」は、私の拙い英語力で直球に訳すと 「知っていることと実行することの壁: どうやってかしこい会社は知識を行動に変えるか」 みたいな感じでしょうか。  さて、内容ですが、このあたりはそれなりの規模の組織に所属したことのある人であれば、「あるある！」と思うことが多い内容なのではないかと思います。 意思決定ばかりで行動はおあずけ プレゼンテーションの準備に時間もエネルギーも奪われる 実行すべきことの文書づくりに熱中する 計画しただけで行動した気になる 社訓を掲げて行動のかわりにする うーん。耳の痛い言葉が並んでいます。 特に印象に残ったと...

自動テストのメリット 自動テストは「繰り返し」「誰でも」「手軽に」アプリケーションをテストできます。 この特徴によって、実際の開発プロセスでは、下記のメリットがあります。 1. 自分の予想していなかった部分が壊れていること(Regression)を検知できる 2. ケアレスミスを防げる 3. 他のエンジニアにも実装を頼みやすい システムに精通していないエンジニアに実装を頼んでも、適切な自動テストがあれば、ある程度の品質は保証できます。テストが失敗すれば、少なくとも使用からずれているといった問題は検知できます。さらに頼んだエンジニアのシステム設計理解も深まるという副次的なメリットも生まれます。自動テストが仕様書の代わりになるときもあります。 4. 自動テストが常に実行されているので、テスト対象のコードが動くという自信が持てる 5. コードの改善(リファクタリング)に取り組みやすくなる もちろん安全度100%ではないですが、なかったらとても安全に利ファクタリングはできません。特に入力と出力が明確でテストパターンが網羅されている場合、リファクタリングは非常に進めやすくなります。 自動テストのデメリット 自動テストは、このように品質のよいソフトウェアを開発する上で、非常に強力なツールです。しかし、大きな弱点も抱えています。筆者の経験をもとに列挙していきます。 1. テストコードの追加にコストがかかる テストコードの追加に際しても、テストデータの準備、設計、コーディングなどが必要になります。 2. 自動テストを構築するのにも技術力がいる テストコードを書くのも本番コードと同等(あるいはそれ以上)の技術力、設計力が要求されます。誰でも簡単にテストを追加可能な設計ができる、高速・安定したテストを組むことができるエンジニアが必要です。 3. テストコードの追加の優先度が下がりがちになる テストコードがなくてもアプリケーションは動いてしまうので、どうしても後回しになりがちです。どうしても本番のコード(テスト対象コード)の品質やバグFixが優先されてしまい、テストコード部分からカットされがちです。 4. チームでテストコードを書く文化がない 本番コードは、みんな頑張って書くのですが、テストコードはあまり書きたがらな...

はじめに 今日は、自動テストが威力を発揮する、ビジネス環境について考察したいと思います。 今までの筆者の経験から、筆者が重要だと思う「自動テストが威力を発揮するビジネス環境因子」を3つあげます。 コードベースに触るチームメンバーの人数が多い メンバーの入れ替わりが激しい コード変更を短期的に繰り返す 逆に言うと上記の3つに当てはまらない環境の場合、自動テストの導入の効果は薄いです。 つまり コードベースに触るチームメンバーの人数が少ない メンバーがほとんど入れ替われない 一度リリースしたら、コード変更はバグがあったときのみ (一回発注・納品型スタイル) の場合、自動テスト導入しても、効果は薄いと思われます。 以下、重要だと思う因子3つの根拠を記します。 3つの因子の根拠 1. コードベースに触るチームメンバーの人数が多い 当たり前ですが、関わるメンバーが多ければ多いほど。誰がどこを直したかをメンバー間で共有することは難しくなり、コードの変更管理コストも上昇していきます。Aという変更と別メンバーのBという変更が合わさったことによって、システムに矛盾した振る舞いを引き起こさせる可能性もあります。 そういった状況でも、自動テストがあれば、少なくとも現状のロジックが破壊された場合には検知してくれるので、メンバーが多くても安心して開発を進めることができます。 もちろん、対象のコードが自動テストでカバーされている + 正しいビジネスロジックのテストで網羅されているということが前提条件になります。 2. メンバーの入れ替わりが激しい メンバーの入れ替わりが激しい場合、各メンバーが保有している知識が断片的で、システム全体の知識を持っている人が少ない、あるいは全くいないということが考えられます。またメンバーの入れ替わり画激しいため、知識は容易に失われてしまう可能性も高いです。 自動テストがあれば、自分の変更が、思いがけないところでロジックを破壊していても検知できますので、安心です。 ただし、その入れ替わっていくメンバーには、そのメンバーの責任でテストを追加してもらうことが必須になります。あまり移動しないコアメンバーがいるのであれば、そのコアメンバーがテストコードを書くほうが望ましいです。コア...

最近BDD (Behavior-driven Development) についてエンジニア仲間で話題になったので、記事を書こうと思い立ちました。 結論から言うと、筆者は、BDDには懐疑的な立場です。 BDDとは(あくまで筆者の理解) BDD (Behavior-driven Development)は、 ビジネス側が書いたシナリオ(誰が、どんなとき、どの条件で、どうしする)や仕様をもとに、コンピュータで実行可能なテストを自動生成し、システム側がそのテストを通るようにシステム開発をしていく方法です。ビジネス側がBehaviorを書く際の言語は、ビジネス側でもできるだけ理解できる自然言語風の、BDD専用言語です。 BDDのメリットは、 ビジネス側の仕様記述から、システムテストを作成できるので、ビジネス側の望んでいるシステムを素早く正確につくれる ビジネス側の仕様変更がダイレクトにシステムテストに反映されるので、仕様変更にも強い ことかと思います(筆者の理解)。 筆者がBDDを支持しない理由 １番目の理由は、そもそもビジネス側の期待している振る舞い (Behavior) 自体が曖昧で、それを論理的に整合性のある仕様に落とし込むことが、システム開発で最も困難な場合が多いと感じるからです。 ビジネス側の期待している振る舞いが簡潔で、論理的であればあるほとプログラムとして記述しやすくなるはずなので、その場合は、システム側だけのTDD (Test Driven Development) 方式で開発を進められると思います。 BDDの記述方法も所詮は論理記述の一種なので、それが綺麗に書ける人はそもそも、エンジニアとしての才能があるので、普通に綺麗な仕様を書ける場合が多いのではないでしょうか。 ２番目の理由はBDDの記述言語です。 自然言語風にするのはいいのですが、自然言語に近づければ近づけるほど、論理の矛盾や文法チェックが必要になり意味解釈が面倒になると思います（自然言語処理が簡単であれば、自然言語処理という研究分野は存在しないはず）。 もちろんBDDの記述言語はプログラム言語を自然言語風にしたシナリオ記述言語なので、意味解釈の面で問題が出ることはないと思います。 しかしそうすると、BDDの記述言語には表現に制約があ...