少しだけ論理的に本を読んでみよう

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

技術書を読むという習慣はみなさん持っていると思います。
技術書を消化しようと思った時、みなさんはどのようにされているでしょうか?
写経をしたり、議論をしたり色々な方法があるかと思います。

今回はもう一つの選択肢として、「少し論理的に読んでみる」という方法を紹介したいと思います。

と言っても、それほど難しいわけではなく、

① 主題はなにか?(何について書かれているか?)
② 問題はなにか?(何が問われているのか?)
③ 主張はなにか?(どう答えるのか?)
④ 根拠はなにか?
について考えながら読むだけです。

たとえば、ドメイン駆動設計本のコアドメインなら、

主題(何について)
巨大なシステムのドメインについて。

問題(何が問われ)
巨大なシステムは複雑なので、ビジネス資産がどこだかわからない。ドメインの全体像が見えづらい。設計が理解しにくいときに起きる問題と同じことがおきる。その解決策。

主張(どう答えるのか)
モデルの重要なコアを洗練する。

根拠
設計はすべての部分が等しく改良されるわけではないから、その中でもコアを洗練することによって、最も価値のある特化した概念を浮き彫りにする。

と考えることで要約もできて、理解も進みやすくなり、議論の元にすることもできるのではと思います。

また、ソフトウェアの設計というのが、ビジネスモデルの要約だと考えるならばこのような練習が設計のスキルアップに役に立つのではないかと、個人的に思っています。

そして、もっと論理的な考え方を身につけたいと思う方にお勧めの本が「新版 論理トレーニング(野矢茂樹 著)」です。

この本の例題を引用してみます。

タコは8本足である。
ジョロウグモはタコではない。
だから、ジョロウグモは8本足ではない。

どうでしょうか。何か違うのがすぐわかりますよね。

では、これはどうでしょうか?

思考は閃きを必要とする。
頭のよい人は閃きを得る力に恵まれている。
つまり、頭のよい人は思考力もある。

ぱっと読むと正しそうに見えませんか?
どこがおかしいか、ぜひ考えてみてください。

上記の例は「新版 論理トレーニング」の中の例題ですが、実際のWebや新聞の記事なんかでも論理的におかしいと気づくことがあります。

考えながら本を読むのは大変疲れますが、技術書のみならず、いろいろなジャンルの本やWEBの記事を読む際などにもきっと役に立つと思います。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

禅とソフトウェア設計技術

心の落ち着きは、技術的作業にとって決して表面的なものではない。これこそが重要なものである。心の落ち着きを生み出すものは、優れた仕事であり、それを破壊するものは悪い仕事である。仕様書、計量器機、品質管理、最終点検などはすべて、作業責任者に心の落ち着きを与えるための手段である。ここでは心の落ち着き以外に重要なものは何ひとつない。なぜかといえば、心の落ち着きこそが例の <<クオリティ>> を知覚するための前提条件だからである。

(※ 禅とオートバイ修理技術より(単行本 下巻164ページ) )

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

ソフトウェアにとって、心の落ち着きをもたらしてくれるもの、つまりは優れた仕事、 <<クオリティ>>を知覚できるものは何でしょうか?

Excelの設計書?
トランザクションスクリプトなソースコード?

これらを注意深く、完璧に仕上げたとして心に落ち着きを与えられるでしょうか?

変わり続ける仕様・業務の知識・ビジネス、100%なくすことができないバグが存在する前提がある以上、ソースとドキュメントとの乖離があるのではないかという不安と、ソースコードを変更するたびに他にも影響があるのではないかという不安は消えないのではないのでしょうか?

であれば、ソースコードに変更を加えることが容易になる設計手法こそが心に落ち着きを与えうる設計であると言えると思うのです。

私たちは、ドメイン駆動設計にその活路を見出し取り組んでいます。

それにしても、「心の落ち着き」と「<<クオリティ>>」を結びつけるということに意外であると思う一方、ソフトウェアに携わってきた経験上、妙な納得感がありました。
設計手法以外にも深夜・休日まで仕事をしてしまう、少ないコミュニケーション、要件定義・設計・開発など工程でチームが分かれる・・・などなど心を乱す要因はいろいろありそうですね。

最後に、心の落ち着きを生み出すために美味しい一杯のコーヒーを飲みましょう。。。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

Robot Frameworkで自動受け入れテスト

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

Robot Frameworkの紹介

Robot Frameworkは受け入れテスト、受け入れテスト駆動開発のための、python製の自動テストフレームワークです。

海外では利用されているようですが、日本ではなじみの薄いツールのようなので紹介したいと思います。

特徴は、キーワード駆動です。
「キーワード」と「キーワードの実際の動作」を定義し、テストケースでそのキーワードを組み合わせてテストを実行させます。

また、予めキーワードが実装されたライブラリを使用することができます。
例えば、Selenium2 Web Driverのラッパーである、Selenium2Libraryを使用することでRobot FrameworkでSelenium2 Web Driverを使用できます。

OperatingSystemLibraryを使用するとOSやファイルの操作ができますし、DatabaseLibraryを使用するとデータベースの操作ができます。

他にも、AndroidやiOSのテストツールAppiumのラッパーであるAppiumLibraryや、SSHが利用できるSSHLibrayなど多様なライブラリがあります。詳しくは、ドキュメントを御覧ください。

Robot Frameworkの例

早速、Robot FrameworkとSelenium2Libraryを使用した例をみてみましょう。
インストールはpythonがインストールされていれば、

pip install robotframework-selenium2library

でインストール完了です。

以下はテストファイルです。

*** Settings ***
Documentation  RobotFramework,Selenium2Libraryテスト
Library  Selenium2Library

*** Variables ***
${browser}  firefox
${login_url}  https://◯◯.com/login

*** Test Cases ***

ログイン画面を開く
  ログイン画面を開く

ログインできない
  ユーザーを入力する  user
  パスワードを入力する  no-password
  ログインボタンを押す
  ログインエラーが出力される

ログインできる
  ユーザーを入力する  user
  パスワードを入力する  password
  ログインボタンを押す
  ログイン成功の画面が表示される

[Teardown] Close Browser

*** Keywords ***

ログイン画面を開く
  Open Browser  ${login_url}  ${browser}
  Title Should Be  トップ

ユーザーを入力する  [Arguments]  ${user}
  Input Text  username  ${user}

パスワードを入力する  Arguments]  ${password}
  Input Text  password  ${password}

ログインボタンを押す
  Click Button  login

ログインエラーが出力される
  Wait Until Page Contains  ログイン
  Page Should Contain  ログインIDまたはパスワードに誤りがあります。

ログイン成功の画面が表示される
  Wait Until Page Contains  ログイン成功
  Page Should Contain  ログイン成功

これは普通のテキストファイルです。拡張子も何でも大丈夫です。
上のようなファイルを用意して、

pybot ファイルのパス

で実行できます。ファイルのパスではなく、フォルダを指定するとフォルダ内のテストを全て実行します。

*** Settings ***は使用するライブラリを定義したり、テスト結果(HTMLファイルで出力されます)に表示するドキュメントを定義したりします。

*** Variables ***でテストケースやキーワードで使用できる変数を定義できます。

*** Test Cases ***でテストケースを定義します。タブ分開けて(または空白を2文字以上開けて)定義したテストケースが実行されるキーワードになります。

*** Keywords ***でテストケースで記述したキーワードの定義とその実装を記述します。「Input Text」や「Click Button」などはSelenium2Libraryで定義されているキーワードです。Selenium2Libraryのキーワードは、Selenium2Libraryのキーワード一覧ドキュメントを御覧ください。他のライブラリを使う際もそれぞれ同様のドキュメントが用意されています。
また、キーワードは引数が取れます。キーワードと引数はタブ分開けて(または空白を2文字以上開けて)定義します。

他、注目すべき点を挙げておきます。

  • 日本語が使えます。ファイル名も日本語でOKです。
  • Selenium2Library はfirefox driverを標準で備えています。ただ、Chromeで動かしたい場合は別途ChromeDriverが必要です。
  • 上記は1つのファイルで全部記述していますが、ファイルは分けることが可能です。その場合、*** Settings *** にて参照するファイルを「Resource ファイルのpath」と記述することで読み込むことが可能です。
    Library定義や変数定義用のファイル、各画面ごとのテストケース用ファイル、各画面ごとのキーワード定義ファイル等ファイルを分割するとよいでしょう。

Robot Frameworkのここが便利

  • python製ですが、インストール以外でpython を意識するところはありません。
  • 文法がない。キーワードから必要なものを引用するだけなので学習コストが低いです。
  • ファイル名もテストケースも日本語で自由に書けるのでエンドユーザー向けにも使えるのではないでしょうか。

いかがでしょうか。とにかく、簡単にWebの自動テストが書けてしまうツールですので、ぜひ、試してみてください。

また、長い文字列のテストデータを簡単に作成する方法や、ローカル・ステージング等環境別に実行する方法、JenkinsやCircleCIなどCIツールで実行する方法などのTIPSをまた機会がありましたら紹介したいと思います。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

リモートワークなのに時間がないってどういうこと?

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

ギルドワークスさんの特徴の一つに「リモートワークが可能」というのがあり、私自身もリモートワークで普段お世話になっています。作業場所は主に自宅です。

自宅で仕事していると言うと大抵、「誘惑が多くて大変じゃない?」と聞かれますが、あまりテレビ見る習慣もなく、ゲームもしないし、漫画もあまり持っていないので誘惑に負けてというのは幸いあまりありません。

むしろ、大変なのは「時間がない」ということでしょうか?
なんていうと、「通勤もないし時間なんてたっぷりあるでしょ!」と突っ込まれそうですが、実はリモートワーク特有(?)の「時間がない」問題というのがあるのです。

今回はこの問題について、『いつも「時間がない」あなたに:欠乏の行動経済学』という本を引用しつつ紹介したいと思います。

トンネリング

どこで仕事をしても当然、仕事量は変わりません。
むしろ、通勤がない分その時間まで仕事にまわせてしまうという状況も作れてしまいます。
仕事に遅れが生じれば当然、空いた時間も使って集中して取り組む必要があります。

このような時間がない状態のとき、「トンネリング」という現象が起きると上記の本では解説されています。

「トンネリング」とは時間がないなか一つのことに集中しすぎて、他のことが見えなくなる現象のことです。
会社は仕事のみをする場なのでトンネリングが起こっても問題になりにくいですが、家でトンネリングが起きると生活に多大な影響が起きます。

家で仕事をする場合と会社と仕事をする場合の一番の違いは、「生活と仕事が隣りあわせ」なことです。

そんななかトンネリングが起きると、家事をしなくなる、食事をしなくなる、深夜まで仕事してる、家族の話を聞かなくなる、部屋に引きこもる、運動しなくなる、ものを片付けなくなる・・・などなど大変な状況になります。一日家にいるのにこんな状況なかなか厳しいと思いませんか?

ジャグリング

問題はもう一つ。

トンネリングが続くと、先送りにした仕事以外のことは積み重なったり、その場しのぎで緊急に片つけた問題が、別の新しい問題を産んだりしてさらに時間がない状態になるのです。

例を挙げると、仕事に集中してお風呂を沸かすのを忘れてしまい、深夜になってトンネルから抜け出したときにやっと気付きお風呂を沸かす。そのあとお風呂に入って寝る頃にはすでにド深夜。
結果、次の日は寝不足で、パフォーマンスも落ち、失敗続きでさらに時間がなくなっていく・・・
という具合です。

緊急の課題を次から次へとなんとかやりくりしていく様子からこのことを本書ではジャグリングと読んでいます。

解決するには

本書ではこれらの問題を解決すべくいろいろな提案をしてくれています。
今回はこのなかから2つほど紹介しましょう。

トンネルの中に入れる
健康のためにジョギングの習慣を取り入れたいけど、トンネリングが続くと他のことに押しのけられ、やらなくなる。
そこでマラソン大会に申し込む。締め切りができたことで走る必要性が生まれるのでトンネルの中に入ることになり、やらざるを得なくなる。

「何もしない」という予定を入れる
時間が欠乏すると突然割り込んできた課題に対応できない。そしてさらにトンネリングにはまっていく。。。ということを防ぐため予め「何もしない」という予定をいれておく。

などなど、他にもこの本にはリモートワークのための本ではない(行動経済学という学問の本です)のですが、役に立つ情報が多く紹介されています。

リモートワークをされているみなさんにおすすめの一冊です。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

エンティティの識別子をラップしたクラスを用意するとよい理由

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

今回は、ドメイン駆動設計における、エンティティの識別子の実装面について考えてみたいと思います。(あまり本質的な話題でなくてすみません。。。)

エンティティの識別子、どう実装していますか?

私の場合、以下の図のようにエンティティが直接LongやStringなどプリミティブの型で持ってもよいと思っていました。エンティティの識別にしか使われないのでエンティティが直接持っていた方が使いやすいと思っていたのです。

VoyageClass

ドメイン駆動設計本の例はどうでしょう・・・。

ドメイン駆動設計ではプリミティブの型を使用している例も載っていますが、書籍内のサンプルを実装したDDDSampleではVoyageNumberやTrackingIdなど識別子をラップしたクラスを使ってます。

VoyageAndVoyageNumberClass

実践ドメイン駆動設計本では日付時刻を含んでいるような識別子を例にあげてこのような複雑な識別子はラップしたクラスを使うべきとあります。

要は識別子の複雑さや使われ方によるのかなと思います。

という曖昧な結論では記事になりませんので、識別子用のクラスを持つことで効果がでるケースを紹介したいと思います。

例は、よくある求人サイトの想定で、求職者が求人に応募するようなモデルです。

まずは、求人パッケージ(モジュール)。
求人

そして、求職者パッケージ(モジュール)。
求職者は求人に応募しますので、応募クラスは求人IDクラスを持っています。
求職者

・・・と、クラス図だけではなんてことないのですが、パッケージ図を見るとこうなります。
求人サイト

これが求人や求職者の識別子がプリミティブな型の場合は以下の通り依存関係を持つことはありません。

求職者2

求人サイト2

実装上はこれでも問題ないのですが、ドメインの知識をソースコードに反映するということを考えると、パッケージ間の依存関係がきちんと表現できるとよりわかりやすい設計になると思います。

エンティティの識別子はそのエンティティの同一性を保証してあげるだけの役割ですので、わざわざラップして使う必要がないと思いがちです。
しかし、ラップして使うことで、プリミティブな型をそのまま使うことに比べてモデルをより豊かに表現することができ、ドメインの知識をより深く理解する手掛かりとすることができます。

ぜひ試してみてください。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

※ アイキャッチ画像(Original Update by paurian https://www.flickr.com/photos/paurian/3707187124)

実装パターン本やXP本に登場する「価値」とはなんだろう?

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

どちらもKent Beckの著書である、XP本実装パターン本に登場する価値と原則。

その内容については触れられる機会が多いと思いますが、
価値・原則とはそもそも何なのか?という点を考えたいと思います。

特に今回は「価値」に絞って考えてみます。

実装パターン本による「価値」の解説

当初、この記事を書くにあたって、「実装パターン」の価値についてのみ考えるつもりでした。
しかし、「実装パターン」で語られている価値についての説明は、

  • 普遍的で包括的な主題。
  • プログラミング時におけるあらゆる決定を左右する。
  • 価値は(パターンという行動を起こす際の)動機を提供する

ぐらいにしか、解説されておらず、なんとなくわかるのですが、なんとなく曖昧な説明に思えました。

そこで、同じく価値・原則・プラクティス(実装パターン本もパターンのことをプラクティスと言っている箇所があります。)形式で書かれているXP本の方も調べてみました。

XP本における「価値」の解説

XP本にて、価値について説明している箇所を抜き出してみます。

  • (園芸の例えより、剪定のプラクティスを理解するだけでなく、木全体・庭全体を捉える方法を指して)このレベルの知識と理解を価値と呼ぼう。
  • 価値とは、ある状況における好き嫌いの根源にあるものだ。
  • 価値とは、目にするものや考えていることなどを判断するための大きな基準である。
  • 価値は、プラクティスに目的をもたらしてくれる。

実装パターン本よりわかりやすい説明です。さらに、

価値がなければ、プラクティスはすぐに機械的な作業になってしまう

この箇所で理解できました。

実装パターンもXPも多くのプラクティス(パターン)が載っていますが、それらをただ実施するだけでは意味がありません。

例えば、ペアプログラミングを上司を満足させるためだったり、やってみたいからという理由で行っても意味がないということです。

また、コミニュケーションに不満があったり、チームのメンバー間がお互いに無関心といった問題を抱えていたらペアプログラミングというプラクティスが有効かもしれません。(「コミュニケーション」と「リスペクト」はそれぞれXPの価値の一つ)

最後に、実装パターンの価値やXPの価値は「実装パターン」を、または「XP」を方向付けるための価値であって、自分自身や、チーム、会社、またはビジネスのための価値とは必ずしもイコールではないという点に触れておきたいと思います。

これらはXPの原動力となる価値である。組織、チーム、あなた自身が、その他の価値を選択しても構わない。・・・チームがそれらの価値を共有すれば、XPの価値がプラクティスを作り出すのとは違ったやり方で、自分たちのプラクティスを作り出すことができるだろう。

とXP本の価値の章の最後にありました。

逆に言えば、XPや実装パターンの価値とチームの持つ価値が一致していれば、XP本や実装パターンの各プラクティスはチームに大きな力をもたらしてくれるということではないかと思います。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

「よいコード」を書くためのはじめの2歩

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています
木目沢(@pilgrim_reds)と申します。

このような場で記事を書かせていただけることになりまして大変緊張しております。

今回は、Kent Beckが書いた「実装パターン」という本を紹介したいと思います。

出版社の都合で絶版になってしまっているのですが、素晴らしい本ですので、もし手に取る機会がありましたらぜひ読んでみてください。

この本のテーマは、「よいコードを書く方法」です。
190ページという薄い本ながら、「よいコードを書く」ためのパターンが100個近く掲載されています。

なにより素晴らしいのは、パターンを紹介するだけでなく、

  • そもそもよいコードとは何か?
  • なぜよいコードを書く必要があるのか?
  • パターンとは何か?
  • どのようにパターンを選択し、適用すればよいのか?

という本のテーマの「前提」となる部分がきちんと説明されていることです。(まえがき、1章〜4章)

全てをこの場では紹介しきれませんので、今回はこのなかから、「よいコードを書くためのはじめの2歩」を紹介します。これは、Kent Beck自身が歩んだ最初のステップということで「1章 はじめに」で紹介されています。

1歩目・・・プログラミングを行うと同時に意識的になること。

Kent Beckがこの本を執筆しはじめたころの話だそうですが、当時、すでに、何年もプログラミングの経験があり、プログラミング上の決定はスムーズにすばやく行われているのに、なぜメソッド名をその名前にしたのか、そのオブジェクトにそのロジックを含ませるべきだと確信した理由は何なのかを説明できなかったことに気がついたそうです。

そこで、よいコードを書くための第一歩は「自分で何を考えているかを意識できるぐらいに思考速度を落とす」こと、直感でコードを書く「振り」をやめることを挙げています。

2歩目・・・他人の重要性を認識すること。

プログラミングというのは、1人の人間と1台のマシンとの孤独なコミュニケーションであることは、ほとんどありません。
また、他人を気に掛けるということは、意識的な決定であって、練習しないと身につかないものです。

同じくKent Beckが書いた「XPエクストリーム・プログラミング入門 — 変化を受け入れる 第2版」の原書出版が2004年。「実装パターン」原書出版が2007年ですから、当時、すでに達人の域に入っていたといってもいいでしょう。
つまり、新人でも中級者・上級者であっても気がつかなければ最初の一歩も踏み出せないということです。

ここまで、こんなことを言っておいてなんですが、私自身、はじめの2歩を忘れてコードを書いていることが未だに多いです。
まだまだ、練習が足りませんね。

誤解していただきたくないのは、「常にゆっくり」コードを書けといっているわけではありません。いわばトレーニングの一環といったところです。
最終的にはよいコードを書くことを「習慣化」するというのが、そもそもの本書の目的であります。

最後にこの「実装パターン」ですが、ギルドワークスの増田さんが、ドメイン駆動設計を実践する中で、何度も読み返して参考になさっている文献のなかの一冊に挙げられています。

ドメイン駆動設計を実践されている方にもぜひ手に取っていただきたい一冊です。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください