仕事を早く終える小手先芸

元々Qiitaに投稿していたものです。 関連書籍としてプロダクティブ・プログラマ。

プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)

このブログに最近書いたのだと 量に量で対抗しない方法を身につける がちょっと絡む感じ。

以下は 2016-12-12 に書いたのそのままです。

---

システムエンジニア Advent Calendar 2016の12日目です。ふつうのプログラマとして書かせていただきます。

当初はSIな現場のドロドロした何かしらを書こうと思っていたのですが、 ネタが被ったので 現場で使える小手先芸のお話をしようと思います。単純作業に対する個人技の話です。

なぜ小手先芸なのか

SIの現場では膨大な単純作業が待ち構えていることも少なくありません。 それらは手作業で心を込めて行うこともできます。 ですが、手作業にはミスもありますし、単純作業に時間を割いていると、あっという間に納期は来てしまいます。単純作業は効率良く済ませて、早く帰るようにしましょう。

さて、なぜ小手先芸なのかですが、技術を身につけるには時間と覚悟が必要です。覚悟はともかく時間は誰も与えちゃくれません。時間を作るためにも、軽く始められる小手先芸が便利なのです。 時間の余裕ができると、次の仕込みができます。次の仕込みができると、より余裕を作れるようになります。この好循環の第一歩として、単純作業を効率化するのに意識を向けるのも良いんじゃ無いかなと。

小道具の紹介

Excel

何かとネタにされたり、悪いイメージと共に語られたりするExcelの登場です。ここではExcel方眼紙などの話はしません。

Excelを多少使えると格段に仕事は非常に早くなります。と言っても、高度で複雑なExcel関数やVBAマクロを活用すると言った話ではありません。あくまで使える多少レベル使えれば十分です。

例えばオートフィル。SIerの現場で稀によく見る連番付き名称ですが、名前の元ネタを作るのにはもってこいです。単純な連番だけでなく、繰り返しの数列（1,2,3,1,2,3...）を作るのにも便利です。 同じ文字列で埋めるには範囲選択してから1つのセルで文字を入力し、Ctrl+Enterで一発です。入力後なら普通にコピペでも構いません。 セル同士を文字列結合して、1つの文字列を作れるようになれば、例えば「コピペしてからルールに従って書き換える」と言った作業は逆転します。つまり「ルールに従ったデータから文字列を生成する」となります。

Excelは関数を一つ知れば一つできることが増えます。 「知っておくべきn個の関数」などを見るのも良いかも知れませんが、何か機会があるたびに一つずつ道具箱に追加する道もあります。 今日やった単純な繰り返し作業は、もしかしたらExcelの出番だったかもしれません。

テキストエディタ

正規表現

正規表現が使えるテキストエディタはそう珍しいものではありませんが、エディタによって多少使い勝手は違います。ここでエディタの宗教戦争をする気はありませんが、ご自身の使用しているエディタの正規表現の使い勝手は確認しておくと良いでしょう。 私は普段のエディタはvimですが、正規表現を使う時は別のエディタを使用することもあります。単にvim力が低いと言われればそれまでなのですが、小手先芸なので良いのです。

正規表現も多少使えれば十分です。膨大なテキストから文字列を抜粋、加工するのが目的です。 例えば「郵便番号にマッチする正規表現を書いてください」に対して、¥d¥d¥d-¥d¥d¥d¥dが思い浮かび、ハイフンの前後を入れ替えられるならば何とかなると思います。量指定子は+と*が使えればまずは大丈夫。 この程度を調べながらでしか書けないのだと厳しいですが、それ以上は調べながら書ければ良いです。使ってるうちに調べずに書けるようになるので、まずは簡単なものを書けるようにして場数を踏みましょう。

正規表現の活用例はいくらでもあります。テキストなら何でも対象になります。微妙な例を挙げるならば、「コーディング規約通りのコメントが記述されているか」などをチェックし、場合によっては一律対応する……と言った作業が、一括置換で済むようになります。 「そんなこと手作業でやるわけないじゃん」と思うかもしれませんが、もしかしたら同じようなことを力技でやっているかもしれません。私はたまにあります。気づいた時の悔しさと言ったら、無い。

矩形選択

案外使ってる人が少ないのだけれど、多分想像以上に便利だから使えるようになっておきましょう。

コマンドプロンプト

私の経験では、Windowsを使用する現場が非常に多いです。 近年のWindowsにはPowerShellだったり、最近ではBashがどうこうって話も聞きはしますが、古来からずっと使えるのはコマンドプロンプトです。

コマンドプロンプトおよびバッチスクリプトは、お世辞にも使いやすいとは言えません。 しかしながら、ファイルの作成や移動、簡単な書き出しと言ったシンプルな作業をするには十分です。 ちょっとしたスクリプトが書けるようになっていると、格段に幅は広がります。

組み合わせ

Excelとコマンドプロンプト

複数のファイルの名前を変更する必要がある場合。 変更前後をExcelのセルA1とB1に記述し、C1に="move "&A1&" "&B1と書きます。これを必要なだけ（数百から数千のようなこともある）オートフィルで並べて、あとはC列をコマンドプロンプトにコピペすれば完了です。

同じような感じで、マルチモジュールプロジェクトに仕損なったMavenプロジェクトのビルドコマンドを作成した記憶もあります。プロジェクト構成を直すべきだったとも思いますが、諸々の事情でできなかったので、小手先で切り抜けることにしました。

正規表現とExcel

アプリケーションのログを適当に解析してExcelに貼り付けることも多いです。 あとは適当な設定ファイルの一覧化とか。XMLを表形式にするのに、面倒な時はタグ名と値をタブ区切りにして、そのままExcelにコピペするようなこともあります。何かしら適切なツールもあるでしょうが、この手の調査をする時は自分の端末じゃ無い時も多いので。そういう時でもすぐ使えるのは便利です。

とりあえずExcel

Excelは何かと組み合わせると大化けします。単純作業系では本当に強い。

まとめ

暗黙知的なのを形式にしようと試みてみました。 例はまだまだ挙げられるのですが、無限の組み合わせを書いてもキリはありません。また、私自身毎回違う方法でやっていて、鉄板的なものは無いと気づきました。我ながらどうよと思いました。 ここで挙げた道具はどれも磨けば一級の道具としても通じるものです。一方で、多くの場所で手軽に使えるものですし、特にイニシャルコストの低いものたちです。

小手先芸に「完璧な成果」を求めてはいけません。完璧を求め始めるとと、賄えない範囲が気になり、分析麻痺に陥ります。考えなしに体当たりするのもどうかと思いますが、8割くらいいけると思ったらやってしまって、残りの2割は他の道具や手作業で何とかするくらいの気持ちでやるのが良いと思うのです。

蛇足

これと似たようなことを書いた本もあります。もう少し抽象的でエモい感じかな。興味があればどうぞ。 開発現場に伝えたい10のこと

Javaのいまを知る「みんなのJava」を読みました #minjava

本日 2020-03-13 発売です！

みんなのJava OpenJDKから始まる大変革期!

著者の一人である @jyukutyo さんから献本いただきました。ありがとうございます。

読むなら今、と言う本。賞味期限は半年くらいかな。 過ぎてもJava史のチェックポイントには使えると思いますが、「大変革期」の今だからこそ自身の技術的審美眼を鍛えるのに役立てられるんじゃないかな、と思いました。

Javaのいまを知る一冊

2020年3月（実際書いているのはもう少し前になるんでしょうが）の「いま」にフォーカスした本だと感じました。 「大変革期」と題されている通り激動していますが、著者の方々それぞれが現状を真摯に見据え自身の見通しを書かれています。この方々だから書けたものだなと。

Mustang（暴れ馬）とつけられたJava SE 6なんて可愛いJava9以降ですが、リリースサイクルは掲げられた通り半年が実現され、LTSであるJava11もリリース。バイナリの配布は様々なところが名乗りを上げつつもそれなりに形が見えてきた今日この頃に出された本書は、Javaの今後を追う上でも一つのチェックポイントにできると思いました。 書かれていることの個々の情報は少し手を伸ばせば得られるものであり、著者の方々自身が記事やセッションで語られていたものも結構あります。それらが一冊にまとめられていることに価値があります。 私も大いに復習させて貰いました。見落としてた知らなかったことも結構ありました……ありがたい。

本書は「今すぐ現場で使える最新技術」が書かれたものではありません。 もちろん使えるものも書かれてはいますが、それよりも「Javaのいま」の状況にフォーカスしています。 経緯や選択肢、今後の見通しを読み、自身の判断に役立てる、そんな位置づけになるのではないでしょうか。 そんなわけで表紙に書かれている「現場で役立つ必須の知識、満載」ですが、これは若干疑問。役立てられる現場とかポジションは限定的じゃないかなと。

あ、この一冊を把握していれば現場で「Javaの最新情報に詳しい人」なブランディングができるかもしれません。 そう言う強みを持ちたい人は試してみてもいいんじゃないでしょうか。 一回そう言うイメージがつくと技術的な相談が舞い込んでくるようになったりするかもしれませんし。知らんけど。

どうでもいいけれど、本書を読みながら「このあたり執筆中のセッションがあれなのかなー」とか想像するのは楽しかったです。見出しとかまんまなので。

誰向きの本なの？

以下のような方に向いていると思います。

• Javaの激動に振り回されず手綱を握りたい
• Javaの採用を決定する権限があり、状況から技術的な判断を下す責務を負っている

以下のような方には不要です。

• これまでのJavaの各バージョンでの変化は知らないし特に興味がない
• すぐに現場のコーディングで使える知識が欲しい

使用しているバージョンに応じた安定した知識を身に付けるのが良いと思います。同日発売のこの辺りが良いのではないでしょうか。読んでいませんが、訳者が柴田さんなので安心して買えるかなと。

新世代Javaプログラミングガイド［Java SE 10/11/12/13と言語拡張プロジェクト］ impress top gearシリーズ

ドメイン駆動設計に関する何か

2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。

何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。

DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。

これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメインの話をすると、それは「DDDの話」ではなく「そのドメインの話」になります。ジレンマ。

仮にドメイン駆動設計を突き詰められ、特定ドメインの「正解」なドメインモデルが作成できたなら、きっと出来上がるのはDSLです。 DSL、ドメイン特化言語と言うとどうしても何かしらのコードをイメージしてしまうでしょうが、GUIでの設定やモデリングツールもDSLと見なすことができます。 DSLを使用してドメインを記述する物の実例があります。パッケージ製品と呼ばれるものになります。 幸いなことに、様々な業務のパッケージ製品や、サービスが存在します。

と言うことで ドメインモデリングの力を着ける高速道路は、既存のパッケージ製品やサービスがドメインをどう捉えているかを学ぶことです。 参照して自分なりにでも写経すれば、いかに現実の複雑なドメインをモデリングしているかがわかってきます。数を見ればパターンも見出せるでしょう。量は質に転嫁する。かも知れない。

1冊の本を読んで「あらゆるドメインの明確なドメインモデルが描けるようになる」なんてことはないと思います。あったら教えてください。

話はいきなり変わりますが、DDDと非DDD（レイヤードアーキテクチャ）のモデルを描いてみました。上がDDDで下が非DDDです。

以下、図の中のモデルを指す時は「DomainModel」など図中と同じ英字の記述を使用し、「ドメインモデル」などの表現は図に閉じないものを指すことにします。

矢印は依存線です。依存先が変わったら依存しているものが影響を受けます。

アイコンはネクタイがドメインエキスパートで、ディスプレイが開発者です。 DomainModelは「ドメインに対する認識」くらいに捉えてください。使用する道具はなんでも構いません。 私の使う「モデル」に違和感があれば モデリングのきほん を参照してください。 モデルそのものは表現手段の制約を受けず、文書だろうと図だろうと口頭だろうと、モデルはモデルです。 違和感が拭えない方はDomainModelを「ドメインモデル（脳内）」くらいに読み替えてくれるのがいいと思います。

DomainLogicはApplication内のDomainModelの表現です。これを「ドメインモデル」と呼ぶのが一般的かもしれませんが、私のモデルの認識は前述の通りなのでこの場は許してください。 主にコードで書く部分なのでDomainLogicと呼称していますが、実態はコードの字面だけでなくパッケージ構成やコメントなど、使える物は何でも使ってDomainModelを表現する概念です。 この辺りは「コードをどまんなかに」の「説明できるコード」に該当します。コードの表現力は高くもないですが、そこまで低くもないのです。

ドメインエキスパートしかDomainに直接は関わりません。 開発者はDomainを知りたいですが、Domainには直接触れないのでDomainModelを通じて理解することになります。絵の黄色部分です。 開発者はDomainそのものには触れず、ドメインエキスパート（人に限らず、例えば書籍もドメインエキスパートです）と共にDomainModelを構築します。 仮に自社サービスなどでドメインに直接触れる場合、ドメインエキスパートのロールを演じることになるでしょう。この場合はドメインエキスパートと開発者は同一人物になりますね。

DDDだろうとなかろうとドメインエキスパートと会話してDomainModelを構築する必要は必ずあります。

https://twitter.com/irof/status/1236635125460299776

どのような開発スタイルであろうとも、開発対象（ドメイン）は必ずあります。ある、はず。私が思いつかないだけかも知れないけれど、あるってことにして進めます。

Presentationは使い勝手の影響を受けます。 Infrastructureは使用している実装技術やミドルウェア（ここではBackendService）の影響を受けます。 これらを一緒くたにすることは少ないと思いますので、どちらも分けています。

レイヤードアーキテクチャ（図の下側）が厳しくなるのは、各レイヤーにドメインの知識が散るだけでなく、それぞれが他にも依存するので解決すべき問題が入り混じるからです。 PresentationもInfrastructureもそれだけで複雑性を抱え込みます。そこにドメインの複雑性も持ち込んだ結果が、よくあるFatControllerなどが抱える負債です。 このスタイルだとDomainModelはシステムに依存しない形で構築されることになります。いわゆる上流工程と呼ばれるところで、Applicationと関係なく、書面やホワイトボードで出来上がることでしょう。

「ソフトウェアアーキテクトが知るべき97のこと」の「本質的な複雑さは単純に、 付随的な複雑さは取り除け」に次のようなくだりがあります。

もともとは、数千機もの航空機をコントロールするという本質的に複雑な問題に対処するために作られたものですが、このソリューション自体が複雑になっています。

ソフトウェアアーキテクトが知るべき97のこと

散らばったDomainLogicは、ソリューションと密結合してしまうでしょう。これにより「システム都合でドメインの変化に追随できない」と言うことが起こります。私もいくつか見たことがありますし、作り込んでしまったこともあります。開発者として「そう言うもの」とは言いたくありません。現実は厳しいけれど、諦めたくない領域です。 私の認識するDDD（図の上側）では、DomainLogicを他のレイヤから独立させます。 これによりDomainLogicはDomainModelにのみ依存する形となり、前者の複雑性の絡み合いによる乗算から逃れられます。 DomainModelの知識を引き込む際にPresentationやInfrastructureの複雑性に振り回されずに済むようになるため、DomainModelとの齟齬が抑えられます。ゼロになるとは言わない。

DDDを冠する話題でApplicationの中の話しかされていないことにもどかしさを覚えますが、それなりに理由もはっきりしています。

• ドメインそのものの話はしづらい。特定ドメインに特化した話はDDDの話ではなくなってしまいます。
• ドメインの噛み砕きであれば、要件定義手法などになります。私はRDRA推しですが、手法は山ほどあります。
• エリック・エヴァンスのドメイン駆動設計に「実践的モデラー」があり、よく知られる書籍も実装技術の話に終始しているように見える。

ドメインで設計を駆動する（絵の黄色部分）あたりの話があまりされないのは当然と言えば当然。残念。

特にDDDの書籍、例えば先日発売された「ドメイン駆動設計入門」などがコードの話に多く割くのは、DDD以前に「そうは言ってもコードにドメインを持ち込むのは夢物語だ」と、これまで付随的複雑性の混濁したコードに慣らされたり、現実の重圧に押し潰されそうになっていたりと言った方に、現実感を持たせる必要があるからなのかなと思っています。

ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本

（ドメイン駆動設計の入門と言うよりは、「C#による"エリック・エヴァンスのドメイン駆動設計"入門」のように感じました。）

エリック・エヴァンスのドメイン駆動設計

増田さんがリポジトリ名をisolating the domain（ドメインを独立させる）としているのは、おそらくサンプルリポジトリで語れるのはドメインを独立させる方法だけであり、DDDのサンプルではないからだと思います。確認していませんが（←）。 なお、DDDの片鱗はコミットログにあります。対象ドメイン、ここでは勤怠管理のドメインエキスパートとして、実際に勤怠管理を行っている人へのインタビューや社労士向けの書籍、労働基準法などを参照しながらの現実との試行錯誤、付随的な複雑さの排除を繰り返しており、きっとどこかに埋もれています。コミットログだけで完結させるようなルールは敷いていないので、片鱗とだけ。読み取れるかどうかは知りません。

ドメイン駆動設計の修得に向けて

ドメイン駆動設計だけを勉強してもドメイン駆動設計はできるようになりません。

ドメインを動力として力を伝えるためには、対象ドメインへの関心を持たねばなりません。ドメイン駆動設計をやりたい（と言う表現もなんだかな、ですが）なら、一つ質問があります。「貴方が現在扱っているドメインをドメインの言葉で説明してください」……ラバーダッキングで構いません。これができないのであれば、まずドメインを知ろうと思うところからです。ドメインモデルの構築（図の上下共通する黄色部分）は「ドメイン駆動設計」かどうかに依存しません。

ドメインの知識が不要な開発もあります。例えば要件定義／設計／開発／テスト／運用のように工程分断されている場合、他の知識は無くてもなんとかなる、と言うか、ノイズですらあり得ます。工程を分けることで扱う問題の性質を変え最適化を行っているので当然です。近年は諸悪の根源のように語られる工程分割ですが、妥当な文脈もあります。プロセス自体に善悪はありません。あるのは合う合わないだけです。

もし自身がドメインを全く知らないし、知ることに興味がなく、知っても価値がない（知ることで収入が増えない）のであれば、ドメイン駆動設計を目指すのは時間の無駄だと思います。仮に形はできるようになっても、ドメインの動力を受ける最初の部分がない状態になりますので。

この前提を満たした上で、ドメインと設計を連動させる仕組みが必要です。ここを繋ぐのがドメインモデルとドメインロジックの関連です。エリック・エヴァンスのドメイン駆動設計の実践的モデラーから引用します。

コードを作成する人々がモデルに責任を感じていない場合や、アプリケーションのためにモデルを機能させる方法を理解していない場合、そのモデルはソフトウェアと無関係になってしまう。コードを変更するとモデルも変わることを、開発者が認識していない場合は、開発者によるリファクタリングによって、モデルは力を増すことなく、むしろ力を失うことになる。

コードの変更理由がドメインモデルでなければ、コードのモデルとドメインのモデルは解離していきます。ここをのギャップを可能な限りなくす（完全になくせるとは言わない）ことにより、図で示しているDomainModelとDomainLogicの連動が現実味を帯びてきます。

ドメインに駆動されたドメインモデルと設計を連動させることにより、ドメインへの理解が深まったりドメインが変化することによるドメインモデルの変更に追随するようになります。駆動する、力のあるモデルがでてきます。

実践的モデラーで思い出したのが、組織パターンの「アーキテクトも実装する」です。アーキテクチャの抽象と実装の解離に対応するパターン。実践的モデラーで語られてるものと似ているなと。分たれてしまったものを再び結びつけるのに同じ人の脳に詰め込んでしまうのは、一つのパターンなんでしょう。

組織パターン (Object Oriented SELECTION)

ドメイン駆動設計で語られる実装技術は、Applicationの部分に過ぎません。DomainLogicをどのように作るとDomainModelとの解離を避けられるか、そのいくつかの方法が示されています。どうしてもパターンカタログは「それで全てである」かのような誤解を与えてしまいますが、例えば「リファクタリング」にも掲載しているものは一手法であり今後も発見されることを期待していると書かれています。ドメイン駆動設計の実装パターンは無数にありますが、いずれも実装制約によりモデルが力を失うことを避けるための手法に過ぎません。一昔前のGOFのデザインパターンブームの頃にあった「このパターンだからヨシ！」を繰り返してはいけません。

と言うことで、ドメイン駆動設計文脈で語られる実装技術は、前段このドメインと設計を連動させる際の受け皿の一実装です。上の図の右下のところ。「ドメイン駆動設計のコアドメイン」ではありません。無ければ片手落ちの理想論に終わってしまうので重要ではあるのですが、いずれもドメイン駆動設計でなくても使える技術、使われてきた技術であって、それが適合するから採用されているだけと言うことは理解しておかないと、実装技術の引力に負けて「これをするのがドメイン駆動設計だ」と実装技術部分だけで完全に理解したと思ってしまったり、「ドメイン駆動設計だからこう実装しなければならない」と余計な制約を抱え込んだりして、モデルが力を失います。これは笑い事ではなく、実際起きている現実です。

ドメイン知識を得る方法はドメインに強く依存します。ドメインエキスパートへのインタビューで得られるかもしれませんが、ドメインエキスパートなんてそうそう存在しません。その時は自身がドメインエキスパートになるくらいの気持ちは必要です。なお、業務システム限定で使える普遍的なとっかかりは、金と法律です。あくまでとっかかりなのでブレイクスルーは何度か起きますが。