Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。原文(投稿日:2013/04/16)へのリンクもしも今,アジャイルソフトウェア開発チームで仕事をしているのでしたら,お使いの環境を見回してみてください。物理的にせよ仮想的にせよ,ストーリボードやかんばんボードなどが用意されていて,未着手の作業や進行中の作業,完了した作業などが視覚的に表されていることでしょう。ソフトウェア開発プロセスの視覚化は,透過性を実現するための優れた方法です。現在の進行状況をハイレベルのスナップショットで表すことで,誰もが一目で確認できるからです。私たちの産業において,ソフトウェア開発プロセスの視覚化はここ数年間で長足の進歩を遂げました。実際に開発しているソフトウェアを視覚化する方法については,忘れられているのではないでしょうか。プロジェクトの完成ドキュメントのことを言っているのではありません。コミュニケーションをも含んだ話なのです。アジリティ(Agility)とは素早く行動することであり,それには良好なコミュニケーションが必要です。ところが驚いたことに,ソフトウェアの設計についての効率的なコミュニケーションに,多くのチームが苦労しているというのです。数年前を振り返ってみれば,構造化プロセスや形式的記述といったものが,ソフトウェア設計プロセスにおいても,完成した設計を伝える方法としても基準点になっていました。ソフトウェア開発業界はさまざまな面で進歩を遂げてきましたが,私たちはその過程で,これらかつてのアプローチが持っていた素晴らしい部分のいくつかを忘れてしまったように思います。今日ではアジャイルデリバリとリーンスタートアップが隆盛ですが,その中で自分たちの開発対象を説明するためのコミュニケーション能力を失ってしまったソフトウェアチームもあります。このような状態のチームが技術的なリーダシップや方向性,一貫性を欠いていたとしても,不思議なことではありません。全員が同じ目標に向かって確実に貢献できるようにするためには,何を開発しているのか,というビジョンを効果的に伝えられることが必要です。俊敏性と迅速性が必要ならば,それらと同じようにビジョンを効果的に伝えられることも必要なのです。私自身もUMLを使っていますが,どちらかというとソフトウェアの低レベル設計の面で重要な部分をスケッチするため,という控えめな使い方をしています。ソフトウェアシステムの上位レベルを説明する上で,UMLが便利だとは思いませんし,すでにUMLを放棄してしまったチームや単に知らないチームも多く,不便さを感じることが少なくないからです。このようなチームは大抵の場合,UMLの代わりに非公式なボックスやライン形式のスケッチを好んで使っています。それらの中には,口頭による説明がなければ意味をなさないようなものも多く,結果的にチームのパフォーマンスを下げることになります。この次,1つ以上の非公式スケッチを中心においたソフトウェア設計のプレゼンテーションを受ける機会があったならば,彼らはそのスケッチに沿って説明しているのか,あるいはプレゼンテーションの対象は彼らの頭の中に残ったままなのか,自問してみてください。(画像をクリックして拡大)UMLを捨てるのは構いませんが,アジリティを競い合う中で,多くのソフトウェア開発チームが視覚に訴えるコミュニケーション能力を失っています。NoUMLソフトウェアアーキテクチャスケッチ(上記)の例には,ソフトウェアのアーキテクチャを伝える代表的アプローチがたくさん挙げられていますが,そのどれもが次のような問題で苦労することになります。非公式なボックスとラインによるスケッチは分かりやすいかも知れませんが,ソフトウェア設計の伝達手段として用いるには多くの落とし穴もあります。私が採っているアプローチは,単純なダイアグラムを少数使用して,それぞれでストーリ全体の異なった部分を表現する,というものです。これを行うには,開発中のソフトウェアを考える簡単な方法について,同意しておくとが必要になります。各コンポーネントが1つないし複数のクラスで実装される。このような論理的構成ブロックの単純なヒエラルキで,私がこれまで関わってきたほとんどのソフトウェアシステムをモデル化することができるのです。OOの世界では,クラスがソフトウェアシステムの最小構成要素です。一般的に,複数の協調動作するクラスで構成され,粒度の粗いインターフェースの背後にすべて配置されます。開発中のシステムによってさまざまです。コンポーネントが実行されたり,あるいはデータが設定されたりする場所を表すものです。Webサーバ,アプリケーションサーバといったものから,リッチクライアントアプリケーション,データベース,あるいはファイルシステムといったものが考えられます。コンテナは通常,ソフトウェアシステムが動作している間は常に実行,あるいは有効であることが必要です。コンテナの観点からソフトウェアシステムを理解する上で重要なポイントは,コンテナ間通信にはすべて,Webサービス呼び出しやリモートメソッド呼び出し,メッセージなどのリモートインターフェースが必要である,ということです。システムは抽象化の最上位レベルであり,例えばエンドユーザに価値を提供する存在を表しています。非常に高いレベルの図です。システムを表すボックスを中心として,周辺にインターフェースを持つ他システムやユーザを表すボックスを配置します。システムの全体像を示すためにズームアウトした図ですから,詳細な部分はここでは重要ではありません。(アクタ,ロール,ペルソナなど)であり,ソフトウェアシステムなのです。要するにこの図は,非技術系の人たちに見てもらうためのものです。Webサーバ,アプリケーションサーバ,独立したアプリケーション,データベース,ファイルシステムなどのシステムを構成するさまざまな構成要素と,それらの関係性と相互作用を示した,ハイレベルな図です。コンテナ図は高いレベルでの技術的選択を示すもので,基本的には論理コンテナを表現しています。物理的なインスタンスや配信マップの表現は他の方法(インフラストラクチャ図やデプロイメント図)で行います。おもな論理コンポーネント/サービスとその相互関係を(コンテナ単位に)示す図です。付加情報を図に追加して,設計に現実性を与えることも可能です。詳細レベルを表すときのオプションです。場合に,高いレベルのUMLクラス図を少し書くようにしています。ソフトウェアシステムに部分的なクラス図が必要かどうかは,ソフトウェアの複雑さの他,チームの規模や経験度なども加えて判断します。私がUML図を描くときは,全体的なモデルというよりも,スケッチという感覚のことが多くあります。(画像をクリックして拡大)単一の図は混乱して雑然としたものになりやすいのですが,単純な図を複数描くようにすれば,ソフトウェアをさまざまな抽象レベルで簡単に表現することができます。これは非常に重要なポイントです。ソフトウェアに関する情報を必要としているのは,チーム内のソフトウェア開発者だけではないからです。その他ソフトウェア技術以外の専門家やテスタ,マネージャから,運用やサポートを担当する技術スタッフまで,利害関係者やユーザは広い範囲にわたっています。運用やサポートスタッフのようにソフトウェアシステムに関する技術情報を必要とする人々にとって,コンテナ図は特に有用なものですが,その内部の仕組みについては何も知る必要はありません。組織独自のアイデアこの単純なスケッチアプローチは,私がこれまで関係してきた多くのソフトウェアチームで有効だったものです。何らかの規範的な標準を作るというよりも,何らかの組織的なアイデアやガイドラインを提供するものです。ここでの目標は,新たに包括的なモデル記法を作り上げることではなく,どちらかと言えばソフトウェア設計を効果的かつ効率的に伝えるためにチームを支援する,ということにあります。ここで改めて注目したいのが,非公式なボックスやラインによるスケッチが,図の一貫性を犠牲にする一方で柔軟性を提供しているという点です。今は,UMLのような標準の使用に代えて,独自の記法を作りだそうとしているのですから。ここではカラーコーディングやラインのスタイル,形などを意識しながら,一貫性のある記法セットをチーム内で自然発展させる方法を推奨したいと思います。記法を説明するために,それぞれの図に簡単なキー/凡例を含めておくことも有効でしょう。高レベルの概念図だけを描かなければならない,という共通の誤解があるようです。それではソフトウェア開発者には意味がないと受け取られても致し方ないでしょう。ソフトウェアアーキテクチャが象牙の塔ではなく,コーディングやコーチング,コラボレーションを扱うべきものであるのと同じように,ソフトウェアアーキテクチャズもまた現実に即したものであるべきです。テクノロジの選択(あるいはオプション)を含めることは,一般的に正しい方向へのステップです。多数の概念的要素があたかも魔法のように,ソフトウェアシステムの隅々まで協調動作するというような,象牙の塔的なアーキテクチャ図になることを防止する上で有効です。Booch氏の名言を紹介しましょう。ここでの重要性は,変更コストで測られます。コンテキスト,コンテナ,コンポーネントといった図は,私がソフトウェアシステムの重要な構成要素と考えたものを表現します。したがってこのアプローチを作図に適用することは,チームの効率的,効果的なコミュニケーションの支援に加えて,事前設計の過剰あるいは不足に苦労しているソフトウェアチームを助けることにもなるのです。白紙の状態から始まった多数のソフトウェアシステムが,数週間や数ヶ月という期間ではなく,むしろ数時間や数日といったオーダで設計され,高レベルのコンポーネント図として書き下されています。ソフトウェア設計の説明が迅速かつ簡単にできるようになるので,それがうまく行けば,技術的リーダシップの導入や,技術的ビジョンをチーム全体で共有するという感覚の浸透を図る上でも有効です。スケッチを描くことは,すべてのソフトウェア技術者が備えるツールとなるべきです。ソリューションを視覚化して,それを素早く伝達するための素晴らしい方法であるだけでなく,協調(collaborative)設計や協調コード所有などへの道を開くのです。在住し,ソフトウェアアーキテクチャ,技術的リーダシップ,アジリティのバランスなどを専門にする独立コンサルタントとして働いています。氏は国際ソフトウェア開発カンファレンスで定期的に講演すると同時に,小さな新興企業から世界的優良企業に至るまで,欧州全域の組織内のソフトウェアチームを対象としてコンサルティング/トレーニングを提供しています。著者でもありますが,現在もコードを書いています。