Qcon Tokyo 2016 参加レポート

レポーター：右田 尚人 (2016/11/15執筆)

今どきのアーキテクチャ設計戦略

Qcon Tokyo 2016 セッションA-3今どきのアーキテクチャ設計戦略

• スピーカー：鈴木 雄介氏（グロースエクスパートナーズ株式会社）
• セッション資料：http://www.qcontokyo.com/data_2016/pdf/A-3_YusukeSuzuki.pdf

「裏のセッションを見たかった」の一言で会場は笑いに包まれました。話はアーキテクチャ設計の基礎からはじまり、今どきのアーキテクチャ設計へ。そこでは、現代のように変化の激しいビジネスの現場で起こる設計のジレンマの紹介がありました。

アーキテクチャ設計において要求を明確にするには、ふるまいを見ないといけません。ふるまいを見るためには、構造を用意する必要があります。しかし、要求があいまいでは構造を定義できません。このようなジレンマを回避するためには、どうしたらいいのでしょうか？
解決案として「予測型」「犠牲型」「拡張構造型」の３つのアーキテクチャ設計の戦略が紹介されました。それぞれのメリット・デメリットなど詳細はセッション資料に譲りますが、おすすめの戦略は、OSSなどの「他人がつくった拡張構造に頼る」ことでした。

現時点での拡張可能な構造の集大成であるマイクロサービスアーキテクチャの話では、マイクロサービスで全体再構築はうまくいかないため、明日からでも少しずつマイクロサービスアーキテクチャを導入していくべきだと主張していました。マイクロサービスアーキテクチャ以降は、時間の関係で軽い紹介でしたが、量・質ともに濃ゆい発表でした。

優れたアーキテクトになるために

鈴木さん自身が、自分のセッションそっちのけで裏のセッションを見たいと口にする、Qcon Tokyo 2016のレベルの高さを感じました。

発表を聞いて「他人がつくった拡張構造に頼る」ということを早速やってみたいと思ったのと同時に、他のアーキテクチャ設計戦略も試してメリット・デメリットを体感したいと感じています。

発表の途中で「この話、どこかで見たことあるぞ！」と思う箇所があり、発表が終わってから、読みかけの『Cloud First Architecture 設計ガイド（日経BP Next ICT選書）』（日経BP社、2016年9月）に書いてある内容だと気づきました。帰宅後、本の著者に鈴木さんのお名前が！早速続きを読みました。
QConで生の声を聞いたことで理解も深まり、設計への興味がさらに増しました。私のようなアーキテクチャ設計経験の浅いエンジニアには、得るものが多くおすすめの本です！

DevOps導入＆実践の落とし穴

最終セッションだったため、「最後までわざわざ残っていただいて……、どうしてこんなセッションを見にこられたのか不思議です」と自虐をはさみつつ、和やかな雰囲気で始まりました。

はじめは「なぜDevOpsが『腹落ちしない』のか」についての話でした。DevOpsと言うと、Dockerなどツールの話が先行することが多いそうですが、実際は違っていて、業務の仕組みから変えていく必要があります。しかし、特にベンダーの場合は、今までのしきたりのために変化が難しいのが現状です。そのため、DevOpsの効果が感じられないという状態に陥っています。

続いて、DevOps導入のアプローチの一つとして、ディシプリンドDevOpsが紹介されました。ディシプリンドDevOpsは、DevOps導入時に、DAD（Disciplined Agile Delivery）的アプローチを使うものです。DADは、エンタープライズ向けのアジャイル手法です。スクラムの型を開発チームだけでやることは比較的簡単ですが、会社全体を見ると、適切な問題解決方法なのか判断が難しい場合があります。そんなとき、自分たちのプロセスになにが必要か判断材料を与えてくれるのが、DADです。
DevOpsの導入でも、DADは意思決定フレームワークとして役に立ちます。フレームワークの詳しい内容は、セッション資料やDADの日本語版公式サイトが参考になります。DevOps導入のヒントになるはずです。

おまけの話として、プロセス改善の指針に、業界共通のリファレンスアーキテクチャIT4ITが役に立つかもしれないそうです。社内でプロセス改善を進めるには、どうしても効果説明が必要なので、その解決策になるかもしれません。

DevOps導入がなぜうまくいかないのか、そして、うまく導入するためのヒントが多く語られた発表でした。

若手アジャイリストとして

自分のチームでDevOpsを導入する上で困難に感じていたことが、他社でも同じような状況だとわかりました。問題を客観的に見ることができて、腑に落ちる部分が多かったです。

発表を聞いて、チームの状態に合わせて、アジャイルを導入することはすごく重要だと改めて感じました。現在、先輩社員中心のスクラム経験の浅いチームに所属しているため、これまでの慣れたやり方から移行するのは、かなりのエネルギーがいることだと痛感しています。DADは、チームになにが必要かを見極める、いい材料になると感じました。
ちょうどチームの改善効果を上層部にどう伝えたらいいか悩んでいたので、IT4ITは調べてみたいと感じました。

おわりに

Beer Bash中の1コマ、DDD車座会議

全セクション終了後には、Beer Bashとして「全トラック合同 情報交流パーティ ＆展 示 ＆ Askザ・スピーカー」が行われました。トラックごとに3つのグループに分かれ、深いディスカッションが行われて、最後まで大盛り上がりでした。去年は、このような取り組みはなかったそうで、今年はBeer Bashまで巧みに設計されていると感じました。

開発チームで常々感じていた悩みに対するヒントと、これから一人のエンジニアとして磨いていきたいスキルを発見できた有益な一日でした。時代の変化に合わせて進化していくQcon、そこに集まる最先端の有識者やエンジニアに、今後も注目していきたいです。

このレポートが、同じように悩んでいる人の参考になれば幸いです。

レポーター

右田 尚人

2015年4月、富士通株式会社にソフトウェアエンジニアとして入社。同年7月にインキュベーションセンター配属。
配属後、スクラムを基本とした開発スタイルで、社内WebサービスのモダナイズやDeep Learningを用いた自然言語処理のビジネス応用へ向けた研究開発に従事。現在は、若手ばかりのチームからベテラン先輩社員ばかりのチームに移り、スクラムマスターとして奮闘中。