[音楽]成功するアジャイル開発今回はアーキテクチャ設計について説明したいと思いますアジャイルなアーキテクチャ設計ですけれどもアジャイル開発においては早く作ってそしてユーザーに製品を届けてユーザーがその
機能使い始める校ユーザーがその機能の価値が家計の高いほどユーザーの業務も変更されますあるいは提供した機能がユーザーが求めているものと微妙に食い違った場合だとしてもまたユーザーが求めているものが何なのかというのをフィードバックで把握した後に
それを機能に安永させて修正していくということを行いますですので始めたら計画通りに立てばビルを出てるかのように弱いから作って上で立ち上げてそしてすべきが完成して終わりではないのでできる限り小さな単位無駄使えるものから作りましょうというえ基本的スタンスを
でアジャイル開発では求められますしそのような基本的な幸せ開発を存分になりとなるとアーキテクチャ設計をする際に変更がしやすい設計というのが大前提になります
そこで今回はこのようにして実は結構がてそれぞれにどのレイヤーで変更が加わった場合においてもポストというのは違うということを説明したいと思います
この場合上に行くほど変更コストが低く変更しやすいということですね下に行くほど変更コストが高い変更し菊井変更した場合の影響度が大きいといったこの積み上げたピラミットの位置づけになりますでこれらの考え方をチームあるいは組織全体が持っておくことは非常に重要です
といいますのもアジャイル開発だと全てが変更可能であるあるいはすべてが変更可能であるべきだと勘違いしてしまった場合いい例えば極端な例ですけれどもプログラミング言語を次のスプリントデー新しいこのプログラミング言語が何か良いと聞いたらしいぞ
ということで次のスプリントでこのプログラミング言語に変えてくれとかそういった議論になってしまってですねその辺ポーコストこれを全く考慮しないような選択肢が洗濯の仕方が発生したりしますですのでこの辺高コストが低いところは積極的に変えても大丈夫ですけれども
下に行けば行くほど慎重に変えないといけないあるいは変更がどれぐらい発生するのかをかなり長い目で見て予測しておかないといけないということが必要になってきますこれをこの層に分けたこの上3つがプロジェクトチームが設計を行うというのがだいたい多いパターンかと思います
下の二つがアーキテクトチームが設計するというのが多いと思います大規模開発になって複数チーム複数のプロジェクトチームでシステム全体を開発しているという場合だと複数のプロジェクトチームそれぞれがプロダクトチーム内でこれらを設計してそして横断的なアーキテクトチームがこのした2つを設計したり
意思決定したりということをするようなチーム携帯プロジェクト形態というのが多いと思いますそのそれぞれの騒動に対して判断基準ですね列強しましたで上の方はですね画面 ui に関しては認識性とか
アフォーダンスアフォーダンスというのはユーザーが動きを促すということですねボタンがあれば意思決定したいという場合ですね登録とか送信とかやりたい場合決定をしたい場合はこのボタンを見ると決定するんだなぁと認識できて決定するというう実際のアクションに移しやすい移そうと滑るその画面そのものがユーザーに訴えかけ
て村がしているそういったことをこのアフォーダンスという言葉が意味しますでその下の機能このあたりは業務に関わってくる部分ですね例えば銀行だったら入金出金送金こういったもの5昨日として考えた場合に汎用性があるのかどうか
でも入金出金台場お金が出たりそして取り出されたりしますけれどもこれらをデータとでこれらの機能は入金だけじゃなく出勤もそして送金も似たような処理があるんじゃないかそいう実際がその際したのデータ報道で部分でデータがどのようにもでばいいかということも考える必要が出てきますが
データ構造に関しては処理する速度であったり拡張性行ったりというところっこも判断の基準になっていきますこのプロダクトちんは考えるこのレイヤーの中の一番下なのがデータ構造になりますけれどもこのデータ構造は一度設計してそこにデータが入ってきて実際にユーザーが使い出したとなるとデータを
その後構造的に変更を加えたりするのはとても難しくなってきますなのでできる限りデータ構造は既存の構造そのものに手を入れて動かすんではなくて付け足し付け足しという形でもうまく全体としての整合性がとれるような設計というのをなるべく入り初期の段階で考えておく方が良いです
あらかじめ見ないにわたってどのようなデータが必要になるかということを見越して設計しておくというのはそれはそれで有益なんですけれどもただ例えば4スプリント5までのテーブル設計はありましょうぐらいならいいですけれども1年先までどんな機能が出るか分からないからとりあえずたくさん絡むいっぱい
用意しておきましょうテーブルも呼びテーブル一杯応じておきましょうみたいなことをやるのはやりすぎですなのでデータコードはあくまでももしこのテーブルに絡むが必要になるんだとしたら今ある既存の絡むとの整合性を潰さない整合性を崩さないような
付け方ができないかどうかそしてそれをテーブルを分けるなどした場合に既存のテーブルからのベータを外に出してしまうみたいなことをしなくてもテーブルそのものを新しくつけただけでも既存の今ユーザーが使っている前バージョンのデータとも整合性がとれるといったような行動設計を考えておくというのはこの領域ですね
そのしたあーケットシーンは考えるとレイヤーを開けてますフレームワークインフラの部分これは最近だとクラウドサービスを使って開発するというプロジェクトも多いと思いますaws を使ったり gcp を使ったり
アズーロ使ったりというクラウドサービスを使う場合もあるかと思いますし最近はさすがにまあ乗せそういった選択車減ったと思いますけれども例えば汎用機とかホットコンピューターとかってなった場合はそのメーカーの製品に6ロックインされてしまうその上に動いているシステムほかのシステムに河畔できない
別そのままの世界ができない職ができないみたいなことが起こった場合にこのベンダーロックインとのが発生しますただベンダーロックインを全くゼロにしましょうという意味ではなくてできる限りそのベンダーロックインが起こるシチュエーションを限定的にしておくということですね
そのインフラサービスあるいはえーっフレームワークというのを選択したのにはそれなりのメリットがあるはずですなのでそのフレームワークあればいいフラを選択したことによるメリットとこのロックインされてしまうことのリスクというのをあらかじめ考えておく必要がありますそして一番したらに来たのはプログラミング言語を上げてますけれどもなかなかある
製品のプログラミング言語を途中から急に大幅に変えるみたいなことはそんなにね起こりにくいとは思いますけれどもこれは多分あの多くの人はこのプログラミング言語スイッチすることのコストの高さというのは簡単に想像できると思いますこれはまずスキル面とか採用面でプログラミング言語というのを選択するというのが
このプログラミング言語領域てはかなり重要になってくると思います社内にそのスキルを持っている人がいるのかどうかそして採用するときにどれくらい採用しやすいのかしにくいのかそしてそのプログラミン件は持ってるエコシステムこれは豊富なのかどうかあるいはそのエコシステムに足りない部分足りない
エコシステムはどういうところがあるのかそしてそのプログラミング言語によって作られている製品というのはどういうものがあるのかこういったものをここで考慮しますこういったものがこれらのアーキテクチャを設計する上でのこの
レイヤーの並びなりますこれがわかっているとこの一番上の ui というのは変更コストが一番低いですから例えばデザインスプリットとかスプリントの初めにですねプロトタイピングという形でもうカップをつくって複数作った中からユーザーに使わせてそれを観察しながらどれが一番多くがあるのかどれが一番ユーザーにとって使い
やすいと判断されるのかというのを行いながら最終的に一つに絞るみたいなことができやすいのはこのui の変更ポストが低いからなんですねなのでこのいうへの変更構成は低ければそれ以下の機能とかデータ構造というのもこの有利を変更するあるいは ui をユーザーに
店で打って使わせている中であぶり出せるんですねなので ui の方を積極的にたくさん作ってはユーザーに使ってもらいみたいなことをしてがん実際ができるということですねしかし2のデータ構造とかになってくると
とりあえずテーブル作ってデータベースを作った中でユーザーの業務実際に使われるデータなんかを集めてみたらやっぱりこの設計者ってこっちの設計にしましょうみたいなことは簡単にはできないんですねなぜならもう去って指定しとってしまったデータがそこに蓄積されているのでそれらを全部防ぎもっかい
やるわけにはいかないんですよね構造を変えるとデータ自体も無意味なものになってしまったりあるいは消失してしまったりあるいは重複したりということが起こりえますなのでこのデータコードの部分は積極的に変更しましょういう設計ではなくて
はじめにある程度このような形と設計したものに対して整合性を維持しながらいかに追加していくか追加しやすい設計にしていくかといったことを考えられるような設計にあらかじめしておくことをおすすめしますあとしたはこのあフィットチームと
プロジェクトチームとの連携バランスですからこのプロジェクトチームを複数見た上でどのような選択肢が良いかという議論がいいと思いますではどこからは実際のプロジェクトチームの中でやる設計に関する考え方ですねここはまあ横軸をこれとりあえず行ったーースプリントの際車イテレーションのサイクルでちょっと
区切ってますけれどもぷらっとチームはプロジェクトオーナーがユーザーストーリーに対して正それぞれイーターストーリーはどういう価値をもたらすのかまあシステム全体としてというのもカチカチの対象としてプロダクトオーナーが
考えて計算する必要がありますけれどもそれらに勝ちという概念をユーザーストーリーに起こしてそのユーザーストーリーをもとにいい開発者実際ので火のば開発者たちがうどういう ui 石をどういう機能に仕様度茹でた行動にしよう
みたいな風にして設計を考えていくんですけれども考えるときの巫女須崎時間チックが少し違いますこのように ui 昨日データ行動を考えた場合データ構造に関してはかなり先まで見越して設計をする意識を持った方がいいですというのもデータ構造は簡単に一度稼働させてしまった後に
構造そのものをいじる変更を加えるというのはかなりコストは高いですなのである程度先まで見越した構造として考えておく必要がありますしあとこの先といってもですねこのスプリントの最後でどういう機能がリリースされてどういうデータが必要になるか
まで計画に織り込んで作るというのもそれもそれでまた現実的ではありませんどういう機能が柱タイに本当にここで意思決定されて出るのかというのは実際にこの近く前になってみないと分からないということが起こりえますしアジア具の基本スタンスは
未来のことはわからないというスタンスですから実際のデータ構造はこの辺までは先を見越して考えるんですけれども決してこの先までの設計を先にやってしまうという意味ではありませんあくまでもこの先どういうデータ高度になるのかというのはかなり幅がありますなのでそういったどのようなデータ設計を将来にしていかないといけないのかというの
がこの開始時はよくわからないけれども将来的にこういうデータ構造を求められたとしてもこう言う構造今のさあと子の構造をいじらなくてもいいといったような長い目で設計をしておくというのがこのデータ構造の領域になります機能に関しても
それぞれスプリットごとに出す機能だけを考えるのではなくてその先に出るであろう機能と今出す機能の関係性ですねつながりというのも計画のなか石鹸をする際に考えておくといいと思いますいうふうに関してはこれちょっとかなり短く書いてますけれどもあの1スプリントだけ考えればいいという
ことではありませんただ ui は本当にリリースした後ユーザーからのフィードバック一番を受けやすいので出してみないと分からないというのはが本当に多いですなので本当にさっきまでこんな ui にしますっていうラフスケッチをはじめのうち入念8割も会としてもその大半が使い物にならないとかよくありますなの
で設計する場合はもう直前に出すものこれらをたくさん作ってそして設計として終わらせてしまうといったことが可能になりますなのでそういう意味ではこのへ
時間軸がそれぞれ違いますのでなのでできる限り先を見越して設計をするというのであればデータ構造にフォーカスしてそしてこの遊園僕に関してはもうどんどん作って作ってこのタイピングを二枚ってってユーザーに触ってもらってビューを受けてすぐに修正版をしていくといったような
スピード感であればいいかなと思いますなぁで決してこの上のユーリとデータ構造というものを同じ変更の容易性だと思って取り扱うのは注意が必要ですなので消しと同じ変更の容易性ではないのでコストも同じではありませんので積極的に変更を加えられる可能性があるものと変更があるんであればもうある程度それ
をその変更がしやすいような設計にしておくことこれらのバランスを保った開発のサイクルの中での開発者同士の会話ができるチームの中にできればいいと思いますなので2等ダーはユーザーストーリーを書いて家中勝ちだけを計算してあとはもうユーザー最後見たりマーケティングをしたりということをやればいいんだとあなるより
もこのプロダクトオーナーもこの概念を理解した上でそしてユーザーストーリーそれぞれのつながりあるいは実際にどういうデータ構造で会派したこのチームは開発者は設計しようとすんだろうかということぐらいは踏み込んで議論しておいたほうがいいです
という意味でこのアーキテクチャ設計に関してはそれぞれのコストが違いますよということとそのコストが違う事をどんどんどのようにしてあらかじめ開発の中で取り決めてをしておくか共通の認識を持っておくかということに関して今日は説明しましたので
この上の変更コストが低いところがどんどん積極的に修正して変更して言ってそして変更こそ高い領域に関しては開始時からもかなり慎重に決めておいたほうがいいと思います