具体的に何をやるのか

CDP道場は、大まかに以下の様なフォーマットで進行します。

チーム分け、お題解説についてはその2で解説しました。今日はアーキテクティングからお話したいと思います。

アーキテクティング

お題が出されたら、実際にそのシステムの構成をチーム内でディスカッションして、設計していきます。ここが一番ワクワクして面白いところです！

お題について質問があったら、顧客役の運営側に質問してみましょう。この質問は通常、回答とともに全チームで共有されます。

JAWS-UG沖縄で行われたワールドカフェの様子

アーキテクティングをする際にあたって、いくつか注意事項を。

あくまでも「設計」なので、アプリケーションの詳細の動きにまで余り突っ込まないようにしましょう。そこを掘り下げるのも楽しいのですが、何せ時間が足りません！
とは言え、絵空事のシステムでは困りますので、確実な実現可能性を持ったシステムを設計しましょう。
ここで設計のパターンとして「CDP(Cloud Design Pattern)」を活用すると、チーム間のコミュニケーションが円滑になるかもしれません。ただし、全員の共通言語とは行かないことにご配慮ください。それがチームってもんです。
AWS経験者のかたへ：AWS固有の機能・サービス（別名：飛び道具とも言います）を活用する場合、それを知らない人に「これはこんな機能で、こんなに便利なんです！」「取り敢えずここ参照（サービス紹介ページやBlack Belt Techなどの資料）ね」と、積極的に情報共有をしましょう。
AWS初心者のかたへ：AWS各サービスの固有の機能を利用したな？という設計が出てきたら、近くにいるAWSに詳しい人に「これでこんなこと出来るの？」と積極的に聞いてみましょう

時間の無い中、チームで協力してお題に対して最適解を設計し、それだけでは飽きたらず追加提案なんかを盛り込み、提案資料に落としこむのは頭が知恵熱出るくらい熱い体験です。他のチームに負けない、良いシステムを設計しましょう！

アーキテクティングの時間が終了したら、設計したシステムを提案として各チーム発表します。プレゼン資料として発表するか、模造紙の設計図を前に解説するのか、そのチームやイベント時により異なるのですが、ともかく設計したシステムを顧客に向けてプレゼンする、というある意味一番重要なシーンです。

設計のキモを上手く表現するスキルが問われます！

他のチームの発表をよく聞いて、自分たちの考え方と比較するもよし、穴があったら突っ込みを入れる準備をするもよし、です。各チームの設計が意外とバラバラになる場合がありますので、各チームの設計思想を読み取り、不明なところは質問することは、非常にためになります。

最後に最も良かったと思われる提案を投票 or 主催側の独断と偏見で選び、終了となります。

選ばれたチームはおめでとうございます！なのですが、選ばれることが目的ではなくて、ここまで辿り着くまでに行った作業のすべてが自分の身について為になる、とても美味しいセッションなのです！