Fred George氏がGOTO Amsterdam 2015で，“Challenges in Implementing MicroServices”および“The Secret Assumption of Agile”と題した講演を行った。InfoQは氏にインタビューして，マイクロサービスをできる限り小さくする方法，マイクロサービス実装時の問題と対処方法，プログラムスタイルが問題となる理由，開発者がコードスキルを向上させるためにできること，などについて聞いた。
InfoQ: マイクロサービスはどの程度小さくなければならないのか，意見を聞かせてください。
George: サイズに関しては，いろいろな考え方がありますが，私自身は，ひとりのプログラマがひとつのマイクロサービスを設計，実装，公開，メンテナンス可能であるという，ベルリンのMicroXchgカンファレンスで発表された考え方を支持します。もう少し言うならば，オブジェクト指向プログラミングの原則を借りて，“可能な限り小さいが，意味のある動作を行うサービス”としたいですね。“意味のある動作”というのは，要求されてデータを投げるというだけではありません。むしろサービスには，結論を導き出して，その情報を要求に応じて公開することが必要です。
実際に私が書いているマイクロサービスは実行コードで100行未満，通常は20行未満ですが，それぞれ意味のある動作をします。
InfoQ: それほど小さくするには，何をすればよいのでしょう？
George: 私がサービスを開発する時には，いくつかのサインを見るようにしています。サービスについて考える時に，“および(and)”を使うようならば，多分それは分割が可能です。 例えばNeedパターンでは，ひとつのサービスがメッセージバス上で要求を送信して，別のサービスが可能なソリューションを収集します。これをひとつのマイクロサービスとして実装する必要はありません。２つの，別々の“ジョブ”なのですから。
もうひとつ，スレッドが必要だと感じたならば，それは間違いなく分離可能だと思います。
InfoQ: 企業がマイクロサービスを導入しようとする時，最も大きな課題は何だと思われますか？
George: マイクロサービスを採用する上で最大の障害は，既存のITプロセスにマイクロサービスを詰め込もうとする組織でしょう。ほとんどの企業のITシステムは大規模なサービス，場合によってはモノシリックなアプリケーションを中心に構成されています。このようなアーキテクチャが必要とするプロセスは，マイクロサービスにはうまく移植できないのです。
この障壁はビジネス側にも拡がっています。私は，“ソフトウェアはビジネス構造を反映する”というConwayの法則を信じていませんし，これまでに何度もそれを打ち破ってきました。ですが，そのような構造の組織がたくさん存在することも分かっています。プロジェクトに対する投資の多寡に組織構造が反映されるからです。
ですから，マイクロサービスの導入を有益なものにするためには，IT部門もビジネス側も再調整する必要があります。IT部門にはビジネスのKPIを中心とした管理が必要です。KPIを監視し，その改善のためにマイクロサービスを構築するのです。ビジネス側は要求を壁越しに投げるのを止めて，ITグループと密接に協力してKPI改善のアイデアを試す方法にシフトしなくてはなりません。
要するに，マイクロサービスそれ自体で企業は改善されないのです。デプロイメント(Ops)やビジネスの交流，ITスタッフ自身の組織も変わらなくてはなりません。
InfoQ: これらの課題にどう対処すればよいのでしょう，何かアドバイスはありますか？
George: まず最初に，企業が現在直面している課題に対して，マイクロサービスが現実的なソリューションであるかどうか，評価することが必要です。マイクロサービスはある特定のクラスの問題，特にレコメンデーションエンジンや許容リスクといった“ファジー”な問題には非常に適していますが，従来型の会計アプリケーションなどには，あまり導入するメリットがありません。
第２に，特にマイクロサービスの効果的な利用には大きな影響力がありますから，企業による過度の期待は見直さなければなりません。
最後に，マイクロサービスの導入は，具体的かつ重要な問題解決をパイロットとして行うべきです。このパイロットはプロセスや役割，承認といった，従来的な組織の要求に縛られないものでなくてはなりません。パイロットで学んだことがマイクロサービスの広範な適用のガイドになり，組織的な成功に必要な基本的変化のヒントになるはずです。
InfoQ: チームにおける開発者のプログラミングスタイルが問題になる理由について，詳しく説明してください。
George: ソフトウェアエンジニアリングに関するアジャイルプラクティスの多くは，90年代後半にKent Beck氏が書いたXPプロセスに端を発しています。Kentとその同僚はSmalltalkプログラマだったので，変更の容易な独特のプログラムスタイルを使っていました。すべての要件，およびそれに対応するアーキテクチャや設計を事前に用意しない，という新しいストーリを彼らが展開できたのは，そういった理由があったのです。最初のリファクタリングエディタがSmalltalkで開発されたというのは，偶然ではありません。
幸いにも，このSmalltalkプログラミングのスタイルは，JavaやC#，Visual Basic，Python，Rubyといった言語に，かなりの部分が受け継がれています。
ですから，このプログラミングスタイルを活用すれば，アジャイルの前提は簡単に満たすことができます。順序を意識せずにストーリを実行することが可能ですし，多くの事前設計を行う必要もありません。
事前設計が不可欠と考えているIT部門は，Smalltalkスタイルを使っていない，ということになります。実際に彼らは，そういったスタイルが存在することさえ，気付いていないように見えます。これについて私は，“アジャイルの秘密の前提(The Secret Assumption of Agile)”というプレゼンテーションで話しました。私が企業向けのコード開発に従事する場合には，開発を始める前にまず，チームにこれらのテクニックを練習させるようにしています！
InfoQ: プログラミングスタイルがアジャイルに適さなければ，どうなるのでしょう？
George: 新しい未開発なプログラミングプロジェクトは，とにかくスタートするものです。スタイルの違いは，後にならないと分かりません。チームが学校で学んだ(私が70年代初めに教えていた)技術を使えば，システムの変更はどんどん難しくなります。アーキテクチャと設計の欠点に非難が集中して，最終的には書き換えが必要になります。そして歴史は繰り返すのです。
ある大手コンサルティング会社によると，アジャイルによるソフトウェア開発改善率は最大13%ということですが，私自身は通常４倍，あるいはそれ以上の改善を得ています。その違いはスタイルにあると，私は思っています。
GOTO文を覚えていますか？70年代後半，GOTOの使用は多くのエラーの根源であり，放逐する必要があるとみなされました。ですが，私の書いていた全ステートメントの12%がGOTO文だったのです！それなしで，どうやってプログラムを書けばいいのでしょう？今日では，ほとんどの言語にはGOTO文がありませんし，Smalltalkスタイルのプログラミングならば，ELSE文を使うこともほとんどありません。標準的なコードを開いて，ELSE文を数えてみてください。それを排除するには，GOTOの時と同じように，スタイルを変える必要があるのです。
InfoQ: 好ましいコーディングスタイルの例をいくつか挙げて頂けますか？それらが好ましい理由は何でしょう？
George: クライアントとの機密保持上の理由があるので，関与したプロジェクトからは，あまり多くの例を紹介できません。アジャイルを始めた頃のプロジェクトのひとつである米国Nationwide Insuranceでのプロジェクトは，Forrester Researchによる，アジャイルの効果性に関するホワイトペーパーの対象になりました。その調査によると，アジャイルプラクティスを使用することで，私たちは最高位であるCMMレベル５のオフショア企業の1/6の労力で，製品を開発することができたのです。調査ではさらに，プロジェクトのROIについて，オフショアソリューションの4%以下に対して94%と推定しています。
アプリケーションは，レガシシステムの書き換えでした。リプレース前後の技術は同じで，いずれもJava, Oracle, Webのフロントエンドを使用していました。レガシシステムには72のJavaクラスがありましたが，書き換え後は1,400になりました。それ以降，新たに開発されるシステムは，それまで開発された他のソフトウェアよりも10倍高い品質を備えています。
InfoQ: 開発者が自身のコード記述スキルを向上するためには，どんなことができるのでしょう？
George: 医師のようにキャリアとしてプログラミングを追求するのであれば，学習に継続的な投資をする必要があります。それから，手順を勉強しただけの医師に手術されるのを嫌だと思うように，新しい言語や技術を学んだだけのプログラマのコードは望まないでしょう。スキルは実践して，そのスキルを習得している人の下で学ぶことで身に付くものなのです。
私自身は，効果的な学習手段としてペアプログラミングを好んで用いています。 技術をよく知っている人と一緒に作業することで，私の技術も向上できますし，パートナーもその見返りに， 私の持っているスキルのいくつかをピックアップします。その日の終わりには，いくらか腕を上げたプログラマが２人いる，という訳です。これを何ヶ月も続ければ，スキルは非常に高くなります。
仕事が退屈で，その技術もさらに退屈ならば，自分でミートアップやオープンソースプロジェクトを見つけて，そこで誰かと一緒に作業しましょう。あなたの最も大切な資産である，“あなた自身”への投資を怠ってはいけません！