シン・アジャイル コミュニティサイト

増田さんは現在、個人事務所で業務系のアプリケーションを開発・設計をされています。最近では『現場から学ぶモデル駆動の設計』というコミュニティで、月に一度くらいの勉強会もされているそうです。一緒に会社を立ち上げて活動していた時期もあり、市谷が『大先輩であり盟友』と公言する増田さんとの対談は、当時の思い出を交えつつ、日本の組織やアジャイルをめぐる過去・現在、そして未来へと広がります。

前編では、現在の増田さんの取り組みやお互いのまわりで起きた変化、またソフトウェア開発にとってのアジャイルとは何だったのかについて語ります。

増田さんと言えば

市谷聡啓(以下、市谷):はじめに”増田さんと言えば”という観点で、オンラインホワイトボードmiroへの書き込みをお願いします。芸歴の長い方なのでいろいろあると思いますが。

まずは”日本におけるDDD(ドメイン駆動設計)の第一人者”というのがありますよね。私と増田さんとの出会いは和智さん(和智 右桂 氏)のおかげなんです。和智さんとDevLOVEで活動していた時に、増田さんというすごい人がいると聞きました。ただ怖そうだねという話で…

増田 亨さん(以下、敬称略):(笑)そこが誤解を受けるところですよね。言い方がきついというか断定調に聞こえるみたいで。でも今は昔のようにスイッチが入らない。 最近は温厚で通っています。

市谷:つづいて皆さんが挙げている内容を見ると、”設計でTwitterのつぶやきが多い人”まさにその通りですね。”設計 DDD Javaの人”、”テストがあまり好きではない人”など。

増田:伝わってるなぁ(笑)品質保証はまずは設計が第一という考え方があるのは確かです。もちろんテスト不要論を言ってるつもりではないのだけど。こういうところが断定的に聞こえるところなのかな?
Javaもそうですよね。TwitterではJava推しで書いてるので、Javaだけやってると見えるのだろうけど、私自身はプログラミングでも何でも好きで、何でも触っています。Javaが一番いい言語だとも思っていません。DDDもそうかな?共感はしているのでその考え方や周りで生まれる設計の話は一生懸命学んで吸収しようということは続けていますが、DDDが唯一の設計という感覚ではないですね。

市谷:たしかに増田さんの外苑前の隠れ家に通ってたころ、そこにはたくさんの本があって、Rubyの本もちゃんと読んで研究されているので、いろいろなことを踏まえた上でお話されているなと思います。

増田:Rubyは全然マスターできなかったですけどね。言語としてRuby自体は書けるのですが。

市谷:miroに戻りまして、”オブジェクト指向エクササイズ推しの人”、これも懐かしいですね。

増田:これもクラス設計の基礎としては悪いことは書いてないと思いますが、書き方で誤解が多い内容なんですよね。批判されることもありますが、ちゃんと理解した上で言ってほしいと感じることはあります。

最近の増田さんの取り組み

市谷:まずは私も久しぶりにお話しするので、増田さんの最近の取り組みについてお話を聞かせてください。

増田:最近は市谷さんとギルドワークスをやっていたころの感覚からすると、二度と戻ることはないと思っていたような世界で活動しています。

市谷:ほぉ~。といいますと?

増田:100人体制の基幹業務システムの再構築でSIerさんとガッツリ組んで、旗振り役などをやっています。何年も前に相談を受けた、ドメイン駆動設計の案件が今も続いていて。プロトタイプや仮説検証のフェーズが終わり、実システムで某金融系の基幹システムをドメイン駆動設計で再構築するという活動をしています。

これは私が変わったというよりは周りが変わってきたという印象です。私自身のやり方を変えたとか、そちら寄りにアレンジしたというよりは、なにか困っていろいろやってみようとした時、ドメイン駆動設計とマイクロサービスという言葉がセットで出てくることが多くなりました。基幹業務システムの世界でこういう設計方法で作ってみようと本気で取り組む時代が来るとは思わなかったなという感じです。

市谷:増田さんの立ち位置はどんな場所なのですか?メンター?アーキテクト?

増田:アーキテクトというような全体の話ではなく、ドメイン層のビジネスロジックだけをマイクロサービスで切り出して、基本設計からコードレビューを含めて定期的、継続的にアドバイザーとして支援しています。エクセル仕様書は書いていたけどプログラミングまではやってこなかったようなメンバーたちに、直接Javaで仕様を記述するといったドメインモデル的アプローチへの方針転換を、経験してもらいながら進めていくといった感じです。

市谷:もともと増田さんはSI的な方面って好きでしたっけ?

増田:好き嫌いといった言い方がいいのかは分かりませんが(笑)
私は自分たちがプロダクトオーナー兼プログラマーという数人のベンチャー企業でソフトウエア開発を覚えてきたので、自分たちでアイディアを出して自分たちで作るというのがメインでした。日本オラクルの時に銀行向け社内システムを作る仕事にかかわった際、SI的なこともやるようになった感じです。

市谷:そういった領域に戻ろうと思ったきっかけは、何かあったのでしょうか?

増田:やっぱり困っているんですよね。従来の作り方だとスピードも出ないし変更も補修も大変なので、次世代ではそこを改善したいと本気で取り組まれています。実際にどう作るかも研究されていて、いろいろな方式の候補がある中で、ドメイン駆動設計的なものを取り入れるのが良いのでは?という結論が出て、私に声をかけていただいたのかなと思います。お相手に情報提供だけではなく一緒にやってほしいと言っていただけたので戻ってきたといったところです。

市谷:そうですか。いいですね。私の中の増田さんは、SIerと組んで活動されるイメージではなかったので、いろいろと変化があるんだなと思いました。

『芯アジャイル』を読んで思ったこと

市谷:さて、増田さんにも『芯アジャイル』を読んでいただきましが、お⁈と思ったことなどを教えてください。

増田:すごくビックリしたのは、市谷さんが日本の歴史ある大きな組織に立ち向かっているということです。それこそそちらの世界にはいかないのではなかったっけと?(笑)でも本を読ませてもらって、すごく市谷さんらしいな、チャレンジだなと思いました。

『正しいものを正しく作る』は市谷さんのこれまで培ってきた知見を上手く整理してまとめた集大成で、次はどこに行こうかを書いた本といった印象でした。『芯アジャイル』は次はここで戦うぞといった宣戦布告のように感じました。

市谷:うれしいですね。私も一緒に増田さんと会社をやっているころは、こういった伝統的な組織でなにかやるということを避けていたところはありました。考えてみれば私も全く逆のことをやっていますね。

増田:だよね?このスピード感の組織と市谷さんのリズムは合わないでしょといった感じ。そういうことでいうと、市谷さんのケースも私のケースも、世の中が変わってきたんだと思うんです。私たちがそちらに合わせられるようになったという感覚はしないんじゃないかな。

市谷:あぁ、これまたいいお話しですね。私も以前は、まわりが分からなくてもガンガンやってやる!といった感じのところもありました。それから変わっていますね。ただ、やはりその頃やっていたことが今の取り組みに活きている。だからこそ今出来ている部分もありますよね。環境が追いついてきた、必要性が合致してきたように感じます。

増田:そうですね。そういった取り組みに対するニーズが出きたことで層が厚くなり、出会いがあって機会も増えたといった感じです。

市谷:同感です。

ソフトウェア開発にとってアジャイルとは何だったのか?

市谷:お互いにそれぞれ変化がありつつここまできたわけですが、ここからは増田さんにとっての「アジャイル」とは?といったお話を伺いたいと思います。

増田:私自身アジャイルという言葉と直接的に結びついたのはXPなんです。XPのプラクティスや考え方のようなものを、ソフトウェア開発者としていいなと思いました。なぜいいなと思ったかというと、自分のやってきたやり方に近いものが言語化されているという印象だったからです。

1990年代からアメリカのベンチャー企業のエンジニアが作った小さな会社とジョイントで、slackのコミュニケーションツールのようなプロダクトを設計・企画しながら作っていたのですが、そこで取り組んでいた世界が正にアジャイルそのものでした。ですから私にとってアジャイルとはXPで言語化されたソフトウェアの作り方といった感じです。

市谷:前回の平鍋さんとの対談の中でも、以前平鍋さんが『XPは俺の言葉や!』とお話しされていたことが話題に上がったのですが、それと近しいなと感じました。そういったやり方がご自身の取り組みに通じるというか、シンパシーがあったのかもしれませんね。

それから増田さんはよくケントベック実装パターンについて研究されてたと思うのですが、そちらはいかがですか?

増田:ケントベックの実装パターンの基になったスモールトークの実装パターンというものがあって、その影響はとても大きかったですね。ソフトウェア開発にとって『アジャイル』とは何かという観点で言うと、私自身が追及しているのは費用対効果なんです

エクセルドキュメントをたくさん作るのが費用対効果高いかと言えばNOだし、人力でテストケースを山ほど作って、実行して結果をスクリーンショットに取ることに比べたら、自動テストにして人手を介さずにテスト設計の代わりにテストコードを設計して自動でできるようにする方が、費用対効果はめちゃくちゃ上がりますよね。

ソフトウェア開発の費用対効果を1つ1つ丁寧に解きほぐせば、結果的にはアジャイルのプラクティスになるのではないかと思っています。例えばソフトウェアの作り方も、分業が合理的な制約条件なこともあるかもしれないですが、今は分業するより幅広いタスクをこなせるチームを作って担当したほうが、スピードも品質も上がり費用対効果が高い。

アジャイルというやり方には経済合理性があると思っています。アジャイルという言葉が一人歩きしてしまったから思想的な話のようになっていますが、私はむしろこの方がプログラムって作りやすくない?そんな感じで考えています。

市谷:なるほどいいですね。経済合理性が高いという表現はとても増田さんらしいなと思います。割に合うやり方とはこういうことだよねという感じですね。

増田:無駄なことや何をやっているのか意味が分からないようなことは、やりたくないですよね。

市谷:まあ、そうですね。そうなんですけど、でもやらなきゃいけないという…

増田:なぜやらなければいけないのか誰も分かってないけれど、それでもやらなければいけないことがまだ今でも多いですよね。

市谷:そうですね。私も昔はソフトウェア開発の標準というものがそうさせるのだと思っていたのですが、実際には標準を逐次読んでその通りに動いている人がいるかというと疑問ですよね。でもこういうときはこうするんだとか、こういうことしちゃいけないと決められている、といった認識はとても作用している。ルールや標準のようなものが、人の間の認識として根差してしまい常識になっているのだろうと感じます。

だから標準を変えたら組織が一気に変わるかというと、そういうわけではないということを目の当たりにしています。人にこびりついた認識や常識をどうにかしていくという話になると、大変だなという印象はあります。

増田:そこの世界に入っていってるんですね。

市谷:そうなんです。何と戦っているのか分からなくなることもありますね(笑)

後編へ続きます。

シン・アジャイルコミュニティについて

イベント開催情報など詳細はこちらをご覧ください。

書籍「芯アジャイル」特設ページはこちら