エンタープライズから見たImmutable Infrastructure
Immutable InfrastructureとかDisposable ComponentsとかBlue-Green Deploymentが話題になってるみたいで。
Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編） － Publickey
Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（後編） － Publickey
詳しくは記事を。「不変のインフラ」つまり、一度動くようになったサーバーには手を触れず、なにか変更が発生したら新たなサーバーを別途構築し、丸ごと入れ替えることでシンプルな管理が可能になるというもの。「インフラ設定を自動化する」という流れとして見ると非常に面白い。
言いかえれば「アプリからインフラまでを一貫して構成管理する」ということになると思います。ソフトウェアの動的な状態を「サービス」という言葉で表現するなら、「サービスの構成管理」といっても良いでしょう。
とはいえ、エンタープライズの人間としてはモジュラリティの管理ができないと、Immutable Infrastructureにも限界があるなと思うわけです。
ある一つのサービスが構成管理されることは良いのですが、そのサービスを利用するサービスとの関係はどうするのですか？と。
単体のサービスを単体としてバージョンアップすることは、言ってしまえばそんなに難しくない。ただ、ソーシャル系はエンタープライズに比べてリリース頻度が多いので、毎回の作業が大変だから自動化するのはよくわかります。
（ちなみにエンタープライズのリリース頻度が少ないのは関係各部署との調整が多いからであって、いわゆる文化の問題ではありません。エンタープライズは安定していることが価値であり、それが社会基盤としての役目です。文化は現象であって原因ではないのです）
でもサービス同士の関係性が強い場合、単体のサービスの変更は周辺のサービスに影響を与えます。そうすると、そこだけ自動化されていてメリットは少ないのです。
じゃ、サービス間に関係性があるもの全部、たとえば企業システム全体を巨大な一つのサービスとすればいいじゃんと言っても、じゃ、取引先はいいんですかとか、言い始めればきりがありません。そもそも、他人様のものですし。
つまり、エンタープライズの場合は、単体をきちんと管理するというだけではなくて、単体同士の関係性や全体としての整合性という別の次元をきちんと管理する必要性がある。
そうなるとエンタープライズからみたときにImmutable Infrastructureに投資するメリットって何だろうなと思います。
いつも通りの話です。Immutable Infrastructureは有益な概念ですが銀の弾丸じゃない。
エンタープライズでは「システム全体におけるサービス間の変化の差異をどのように管理するか」というテーマを考えないといけません。モジュラリティ管理ですね。
Immutable Infrastructureのような概念の登場は本当にワクワクしますが、それをさらに応用して、よりスピード感のあるエンタープライズシステムを構築するにはどうしたらいいか、まだまだ考えるべきことは多いのです。
アーキテクトと要求もしくは技術について[追記あり]
2014年2月27日の要求開発アライアンス２月定例会で「アーキテクチャの発掘に見る要求変化の発見」、そして翌2014年2月28日にはEnterprise ☓ HTML5 Web Application Conference 2014で「JavaエンタープライズアーキテクチャにおけるHTML5」という講演をさせていただきました。
前半は（ここ数年間は同じですが）、ITサービスの提供において「利用価値、提供機能、構成／構造、プロセス」の４つの要素のバランスが重要であり、そのバランスを取る事がアーキテクチャ設計だという話です（そのバランスを保ちながらモノを作るのがマネジメントですね）。そして、後半はそれぞれのイベントの趣旨に従って変えています。
要求定義がきちんとできても、どんなにHTML5に詳しくても、あるいは、どんなにアジャイルがうまく回っても、それ"だけ"で良いITサービスを提供する事は出来ません。4つの要素が調和してこそ、はじめて良いサービスにつながるのです。特定の要素に縛られすぎずに視野を広げて、各要素を整合させることこそが重要でしょう。
ここ最近は、どちらかというとDevOpsやアトラシアンの話をすることが多かったので、改めてアーキテクト／アーキテクチャの話がきちんとできたので非常に楽しかったです。お誘いただいた皆様、ありがとうございました。
それぞれのイベントでの気づきをメモ程度に。
要求開発アライアンスでは質問をきっかけに懇親会で「いかに変化し続ける要求に対応すべきか」という話になりました。おそらく４つの要素だけでは難しくて、もっと高レベルな意味での「利害関係者間での目的の共有や信頼関係」というようなことが必要になるかと思います。
どんなに優れた人間でも予言者ではありません。未来は常に不確定です。よってプロジェクトを進めるなかでは様々な不測の事態が発生するわけですが、それには「対処し続ける」という事でしかゴールに近づけません。これは、決して1人では出来ないのです。顧客、仲間、その他大勢の人の協力なしに乗り切る事はできません。こうした、泥臭いというか、非常に人間臭いことがITサービスの提供には欠かせないものでしょう。
ただ、まぁ、これだけを取り出して「みんなの信頼が大事だ」と声高に叫んでも事態が改善されるわけではありません。地道な積み重ねをしながら、利害関係者が真摯に話し合っていくしかないのです。それぞれの現場で、それぞれの姿で少しでも良くしていこうとする努力が続けられたらなと思います。
一方でEnterprise ☓ HTML5 Web Application Conferenceでは散々UI/UXをdisりました。現状のUI/UX論というのは所詮インタラクティブなホームページをデザインする域を出ておらず、非常に感性にまかされており、エンジニアリングと呼べるような状況ではないと考えています。そもそも、IAにしても、あるいはRESTfulにしても「静的な情報」の取り扱いをメインにしており、エンタープライズで必要な業務アプリケーションをデザインするには不足感が強い。だからこそ、ユーザーテストを中心に据えるという原始的な手法に頼るしかないのです（これがダメということではありません）。
とはいえ、こういう限界点さえ分かっていれば過去の積み重ねを学ぶことは大事です。ウェブに接続される動的なアプリケーションというのは発展途上であり、まだまだ多くの可能性を持っています。今年はウェアラブルデバイスの数も増えますし、IoT（Internet of Things/もののインターネット）というバズワードも広がってきていますし、試すべき事がなくなることはしばらくはありません。こちらも現場での努力を続け、その結果を共有しながら前に進んでいければと思います。
というわけで、これからも引き続き宜しくお願いいたします。資料は以下で。
※2014/3/4追記 Youtubeで講演記録が見れます。
※2014/4/3追記 CodeIQ MAGAZINEさんで「エンタープライズの課題解決を考える「Enterprise x HTML5 Conference 2014」レポート（おやつ問題解説付き） #html5biz」として、講演録を書いていただきました。ほぼ書き起こし状態なのでご覧下さい。
ymsr君のこと
＃ymsr との最後の会話はJJUG CCCの後の打ち上げで「席の周りの女子がかわいい」という話だった。
出会いは10年ぐらいまえ、優秀で身体のでかいエンジニアだった。職場は机と机の間隔が狭くて、彼ともう一人のでかい男が背中合わせに座っていると隙間がなくなってしまい「通路がnullだ」とか意味不明なことで爆笑してた。
それから彼が本格的に一緒のチームになり、java-jaという悪ふざけの立ち上げに付き合い、赤毛やダンサーも入ってきて、とても不思議な空間だった。
残念ながら彼らの実力を活かしきる仕事が用意できず、どっかのカフェの喫煙室で赤毛と2人して転職するって言われたときは、ちょっと安心した。
その後は、あまりにツブヤキが多くてtwitterのフォローは止めたけど、彼はずっと横目に見ている存在だった。
訃報を聞いたとき、あいつらならやりかねんと関係者のSNSを見たけど、みんながザワザワしているを見て悪ふざけじゃないと確信した。あまりのあっけなさに声が出なかった。同世代の死は何度目かだけど、どいつもこいつもあっけない。ただ、いなくなる。なんなんだまったく。
山城君は、みんなと出会う事で自由になっていったように思う。元々、彼は正直で純粋で思いを持っていて、それをどんどん自由に出すようになった。java-ja自体、そこに参加する人たちが相互にノリあっていって自由になる場だった。何をしても何を言っても死ぬわけじゃないから楽しもうって。
でも、そんなやつが死ぬんだから世の中ってわからないですよね。
弔いの形はいろいろだけど、彼については「語り」が良さそうなので書いておきます。これで許して。さようなら。
SIにおけるアジャイルとかウォーターフォールとか
取材を受けないとブログを書けないのは問題ですが、@ITの「特集：DevOpsで変わる情シスの未来」というのの第5回で「DevOpsというバズワードに流されないために」という話をさせていただいたので紹介を。
特集：DevOpsで変わる情シスの未来（5）：DevOpsというバズワードに流されないために (1/4) - ＠IT
弊社も当然、最初は顧客企業の業務のことをよく知りませんから、会話を軸に業務を理解し、顧客企業との共通理解という土台を構築する作業から入ることになります。従って、そこではアジャイル開発は行いませんし、行うべきではないと考えています。ウォーターフォールで始めて、まずは満点ではなく合格ラインのシステムを作ることで共通理解の土台を固めます。その上でアジャイルに移行してスピーディに改修を進めるといったケースが多いです。
というあたりがポイントかと思います。
「顧客の求めることには永遠にたどり着けない」という現実と「手法としてのプロジェクトマネジメントには明確なゴールが必要」という現実があって、その落としどころとして「小さく繰り返しゴールを定める」というアジャイル開発方法論が生まれました。
これ自体は素晴らしいアイデアですが、一方で「アジャイルでは繰り返し可能な土台があるかというのが成否を分ける」という現実も生まれました。保守フェーズにおいてアジャイルが有効なのは、この土台がしっかりしているためだというのは言うまでもありません。
SIにおいては保守フェーズだけではなくて新規開発もありますから、どうしても土台がない状況がありえます。そういった場合には「共通の土台を作るまでは迷うことなく進める」というのが必要となります。その場合には60点とか80点を取れるようなところまでゴールを定めることが重要であり、そのうえではウォーターフォール的な進め方が効率的です。
繰り返し言っていますが、ウォーターフォールでもアジャイルでも、別に名前なんかどっちでも良くて、
アジャイルやDevOpsを「開発プロセスの話」とか「運用のツールの自動化の話」といったように解釈せず、企画、開発、運用、フィードバックという一連のサイクル加速へのビジネスニーズがある、という背景に目を向け、そのためにDevOpsやアジャイルという手法が大事だと考えることが大切です。手法ばかりを見て矮小化して捉えてしまうことなく、トレンドの裏側にある本質的なことは何かを見据えることで、これらの言葉をあらためて理解できるのではないでしょうか。
ということで、ひとつよろしく。
アジャイルがビジネス価値を作るわけじゃない - 改めて開発手法としてのアジャイル
"アジャイル"は単なる開発手法というだけでなく、その出自からして「ビジネス価値にコミットする」というような意味を含んでいるように思います。なので「アジャイルだけがビジネス価値を作ることができる」、その逆として「ウォーターフォールではビジネス価値を作れない」というような言い方が出てしまう場合があります。
もちろん「ビジネス価値を作ること」と「ソフトウェアを作ること」は無関係ではありませんが、それがすべてではありません。ビジネス価値にとって重要なのは「どういうソフトウェアを作るか」ということであって「どうソフトウェアを作るか」ではないからです。
というわけで、改めてアジャイルやウォーターフォールを純粋な開発手法として整理したいと思います。
from Choices by Caleb Roenigk
基本は計画、実行、調整
ソフトウェア開発に限らず、プロジェクトマネジメントの基本は「計画し、実行し、調整する」です。プロジェクトマネジメントには必ず計画があり、それを実行します。そして実行しながら計画とのズレを把握し、調整を行います。完璧に計画通りなら調整というプロセスは不要ですが、世の中そうはうまくいきません。だから、計画だけではなく、調整が重要なのです。
そして開発手法とは「計画、実行、調整をどのような考え方で行うのか」であり、特に重要なのは「いかに計画と実行のズレを発見し、どのように調整するか」ということです。この点に注目してウォーターフォールとアジャイルを比較してみます。
ウォーターフォールは「計画を正として調整」
ウォーターフォールは全体計画を重視し、それを正しいものとしてスケジュールやリソース配置が組み立てられます。よって、実行が開始されると、ズレは計画を基準にして把握され（進捗管理）、タイミングを計って調整（変更管理）していきます。
前提は「計画が正しい」ですが、計画変更をしてはいけないわけではありません。ただ、調整が少ないほど効率は良いのは確かです。調整が多発するような状況になると、基準がブレてしまうためズレの把握が困難になっていきます。いわゆる「進捗が信用できない」という状況です。
このようにウォーターフォールでは計画精度が低いと実行段階での調整が間に合わずプロジェクトが崩壊します。よく聞くのはビジネス要件の決定が曖昧、技術的な検証が曖昧というような場合でしょうか。
逆に、十分に計画精度が高いと効率的で最適化されたプロジェクトが実現できます。そのドメインに十分な知識がある、あるいは、パッケージ導入や法律に定められたような機能のように繰り返し実行してノウハウが蓄積されているなどが考えられます。
アジャイルは「再計画によって調整」
一方アジャイルでは「調整が不要なぐらい計画を小さくし、その次の再計画によって調整を行う」という考え方をします。
まず、計画が小さくなれば計画精度は高まります。1年後ではなく数週間先のことだけを検討するのです。次に、実行しはじめたら調整をせずに「期間の完了後に棚卸を行うことでズレを把握」し、「次の計画に反映することで調整」させます。
ポイントはタイムボックスと呼ばれる「計画の期限が来たら必ず棚卸をする」という点です。これによって強制的に調整を働かせることができます。
ウォーターフォールが適宜調整していくのに比べると、アジャイルの強制調整は乱暴な考え方にも思えますが、実際にプロジェクトで調整が多い場合には効果を発揮します。つまり、調整を定期的なプロセスとして織り込んだわけです。かつ、再計画というのは調整幅が非常に大きく、どんな状況にも柔軟に対応することができます。これはウォーターフォールが計画を変えない前提に立つのとは大きく異なります。
ただし、逆にいえばアジャイルでは全体計画と個別計画の整合性を検証することが困難です。そのため個別計画はうまく行っていても、全体として問題が生じてしまい、崩壊することがあります。
アジャイルで全体と個別のバランスを取るのは職人的です。エンジニアと顧客が十分にコミュニケーションを行い、つねに全体感を共有する必要があります。双方が十分に対象ドメインに詳しければ、もっとも効率的な問題解決方法でしょう。
なので、改善や保守あるいはサービス運営などの「既に全体的な基盤が安定しているが、問題が突発的に発生してしまう」ような状況においては比較的簡単に導入できますし、逆に新規の大型案件のように「安定した基盤もなくコミュニケーションパスが大きくなりすぎる」ような状況では不利になります。
局面に合わせた選択を
こうして考えてみると、多くのプロジェクトが完全にどちらかの状況にあるわけではありません。よく言われるように近年はビジネス環境の変化が激しいため、一見するとアジャイルが適するような状況が多いでしょうが、一方でアジャイルは全体整合性が取りにくいのも事実です。
ビジネス環境の変化は大きいからといって事前の綿密な計画が不要なわけではありません。計画できることは十分に計画して効率的に進め、不明瞭な部分は先行的にトライ＆エラーをしてフィードバックを得ればよいのです。残念ながら絶対的な銀の弾丸は存在せず、敵に応じて弾の詰め替えをするしかないのです（写真はレゴを前に悩む女の子）。
ビジネス価値を作るのは「姿勢」
ビジネス価値を作るのに大事なのは、それを実現しようとするプロジェクトチームの姿勢です。それが開発手法によって決定するわけではありません（もちろん、助けにはなります）。これは請負受託だろうが自社開発だろうが、まったく同じことです。
プロジェクトはアジャイルだから成功するわけでも、ウォーターフォールだから失敗するわけでもありません。「ビジネス価値があるシステムを作りたいからアジャイル」という短絡的な考えに陥り、色々な制約を無視してプロジェクトを進めても成功することはありません。
チームはビジネス価値に貢献するという姿勢を忘れず、そのうえで、局面や状況にあわせた開発手法を選択してください。
ITS/BTSは進捗管理に使えるのか - SIの現場で使えるチケット駆動開発
2013年8月24日にグロースエクスパートナーズ主催にて「SIの現場で使えるチケット駆動開発」というセミナーを実施させて頂きました。「チケット駆動開発」の共著者である阪井誠さん（@sakaba37）をお招きしたものです（togetter）。
僕は基調講演で「チケット駆動で加速する、顧客と協業するプロジェクトマネジメント」を話しました。主にプロジェクトマネジメント論の中でチケット駆動の適用箇所について話をしています。
僕はアジャイルでもウォーターフォールでもプロジェクトに合ったものを選べばいいと考えています。どちらの手法にもメリットがありデメリットがあります。ただ、どちらの手法にしてもチケット（駆動）は有用なツールです。SIの現場で言えばチケットはウォーターフォールの限界を埋めるのに有効なので、積極的に活用をしていただきたいです。
（以前、「アジャイルがダメだと思う7つの理由」なんてものを書いたので、僕がアジャイル嫌いだと思っている人もいそうですが、まったくそんなことはありません。自社案件でも活用しています。ただ、盲目的にアジャイルが良いわけではない、というメッセージです）
ITS/BTSは進捗管理に使えるのか
さて、個人的に面白かったのは「組織パターン」の訳者である和智さん（@digitalsoul0124）も交えてのパネルディスカッションです。一番盛り上がったのが「ITS/BTSは進捗管理に使えるのか」という話題でした。
僕個人としては「ウォーターフォールのように長期な計画を前提としている場合、進捗管理はWBS/ガントチャートでやるべき」であり、BTSを利用するのは危険だと考えています。
長期的な計画を立てる場合、タスクの総量だけではなく、タスクの前後関係を把握する必要があります。そうしないと「工数的にはOKだけど、日程的にNG」ということが把握できません。ガントチャートはタスク間の関係を時間的な視点を把握することができるのです。
また、予実管理も全体を見通して把握することができます。いわゆる稲妻線ですが、プロジェクト全体の視点から「ここは遅れていてもかまわない」というような判断ができるのは大きなメリットです。
一方で、アジャイルは計画そのものを小さく（数週間）するので、全体の状況が個別の積み上げで判定できます。チーム内でタスク間の前後関係も共有されているからこそ、ガントチャートのようなツールがなくてもうまくいくのです。
ITS/BTSへの期待と現実
ですが、ガントチャートには問題もあります。パネルの中で参加者からは「BTSで進捗管理をすると、個別タスクの報告をチケットを経由してやれるから便利だと思っていた」という声が出ました。ガントチャートはPMが管理しているので進捗報告を受け取るのが面倒なのです。このニーズは非常によくわかりますし、多くのPMが実は期待したいところだと思います。
でも、PMとして考えると「個別の状況は分かるけど、全体の状況が分からない」という事態になる可能性があり、こういった目的での安易なBTS利用は危険だと思います。残念ながらWBS/ガントチャートとBTSを併用するというのが現実的な判断でしょう。
なお、BTSにはガントチャートツールが付いていたりしますが、僕としてはビューアーであり、いわゆる進捗管理のマネジメントツールとしては不足感があると思います。ただ、活用できる場面もあるはずなので、JIRAでいえばリックソフトさんのWBSガントチャート for JIRAなどはチェックされるとよいでしょう。
阪井さんが「チケット駆動コミュニティでも、チケットに作業予定日をいれるのはアンチパターンだという人もいる」と言われていましたが、それほどチケットで日程面での進捗管理をするのは簡単ではないのです。
手段と目的を履き違えてはいけない
そもそも論ですが、WBS/ガントチャートはトップダウンで計画を落とし込んでいく手法であり、ITS/BTSはボトムアップで事象を積み上げていく手法です。PMはこれらの特性を理解したプロジェクトマネジメントに活用していく必要があります。
なので「BTS（Redmine/JIRA）はプロジェクト管理に使える」というような安易な発想はやめましょう。使えないことはないですが、使ったからといって上手くいくわけではありません。手段と目的を履き違えてはいけません。
ここら辺、阪井さんも「チケット駆動開発をプロジェクト管理の視点だけで考えてはいけない #gxptech - ソフトウェアさかば」というエントリをいただき、またチケット駆動開発のもう一人の共著者であるあきぴーさんもust視聴後に「チケット駆動開発がWF型開発と相性が悪い理由 - プログラマの思索」を書かれています。ぜひ、ご参照ください。
＜講演の動画は公開予定です。公開されたら、ここにリンクを掲載します＞
- 作者: 小川明彦,阪井誠
- 出版社/メーカー: 翔泳社
- 発売日: 2013/06/20
- メディア: Kindle版
- この商品を含むブログを見る
組織パターン (Object Oriented SELECTION)
- 作者: James O. Coplien,Neil B.Harrison,ジェームス・コプリエン,ニール・ハリソン,和智右桂
- 出版社/メーカー: 翔泳社
- 発売日: 2013/08/06
- メディア: 大型本
- この商品を含むブログ (3件) を見る
未決定を決定する - アーキテクトの考え方
「アーキテクチャ設計の難しさについて」というエントリをしましたが、続きとして「未決定を決定する」という話を。
決定していないことを決める
アーキテクチャは「作り方」を示すものなので作り始める前に決定している必要があります。つまり、アーキテクチャ設計はプロジェクトの最初に行います。ところが、皆さんもご存知の通りプロジェクト開始時点で全ての要件が出ることはありません。要件定義＞基本設計と進んで行き、さらには実装も後半になってからアーキテクチャ上で対応すべき問題が発覚することもあります（後工程で問題が発覚するというのはアジャイルでも同じことです）。
ですから、アーキテクチャ設計では「決定していないことを決める」必要があります。
どう決定していないかを決める
決定していないことの設計方法は「どう決定していないかを決める」ということです。
前回のエントリで「接続先のサーバが決まっていない」という例を出しましたが、これに対して「IPアドレスを設定ファイルに追い出す」というのは「IPが決まっていない」というように決めたことになります。
なので、プロトコルも決まっていないような状態でファイル交換をするのであれば「CSVファイルをtmpに出力して、送信は別プログラムにする」と決めれば良いでしょう。送信処理そのものが丸ごと決まっていない、と決めたのです。
さらにファイルのフォーマットも決まっていないなら...というように「どう未決定であるか」というのを、その時点で得られた情報によって判断していくのです。
もちろん、なるべく分かっていた方が効率的ですから、決めてもらう努力はします。それでも決まらない場合は「どう決まっていないかを決める」というのがアーキテクチャ設計の進め方です。
マネジメントに選択肢を残す
こうした「未決定を決定」が適切になされたアーキテクチャ設計はプロジェクトマネジメントに貢献します。プロジェクトを進める中で未確定な物事は「リスク」と呼ばれます。リスクへの対応策は
- 回避：問題の原因を排除する （その製品を使わない）
- 抑止：問題の発生を抑える手法を用意する （その製品の独自マニュアルを用意する）
- 軽減：問題発生後の影響を抑える （代替製品を用意しておく）
- 移転：問題対応を外部化する （専門会社に管理を委託する）
- 分散：問題発生してもフェイルオーバーできるようにする （別の製品でおなじことをしておく）
というような方法が知られていますが、適切なアーキテクチャはリスク対応に選択肢を残すことができます。
上述の例では接続先サーバとの通信手段が未確定でリスクであった場合、送信部分を分離したようなアーキテクチャにしておけば以下のような選択肢を残せます（他にもあると思いますが）。
- 回避：ファイルを置くだけにして相手サーバから取りに来てもらうようにする（送信しない）
- 抑止：接続先サーバの仮サーバを立てる（仮でも構築する）
- 軽減：別スケジュールで送信機能を作る（決まるまで待つ）
- 移転：データ送受信パッケージ製品を買う（コストは掛かるが接続方式は自由）
- 分散：物理媒体伝送ルートを確保する（別の受け渡し手段でやる）
接続サーバがどうなるか分からない状態でFTPで送信するモジュールをがっつり作ってしまうのは、後の選択肢を減らし、リスクを高める結果になります。もちろん、あえてそういう手段を取って強引に進めるのも技の1つです。
なんにせよ、PMとアーキテクトが協業し、プロジェクトマネジメント上のリスク対応力を高めるのが優れたアーキテクチャの特徴です。
問題を解決してはいけない
この未決定を決定する上で大事なのは「この部分は作らない」という勇気を持つことです。僕は「問題を解決していけない」という表現が好きですが、エンジニアという職種は課題が目の前に現れると、どうしてもそれを解決したくなってしまいます。そして、結果的には「あらゆる可能性に対応できる複雑な解決策」を作ってしまうのです。
上述の例では「サーバとの接続プロトコルすら決まっていないんだ」という話を聞くと「あらゆる通信手段に対応できるコンポーネントを開発する」みたいなことを考えてしまいがちです（僕もですが）。
こういうときに「じゃ、作らないで分離しておこう」という一歩退いた判断が出来るかどうかが大事です。問題を解決せずに先送りしてしまうんですね。
アーキテクチャ設計のポイントは可能な限りシンプルに保つことであり、代替手段のある状況に置くことです。もちろん、固有ドメインの本当に特殊な課題は先送りしても解決されないでしょうが、多くの問題は「未決定の決定」による先送りが良い結果を生むと思います。
まとめ
- アーキテクチャ設計を始める時点では全ての要件は出そろっていない
- だから、不確定な物事については「どう未決定であるか」を決定する必要がある
- これが正しく出来ているとプロジェクトマネジメント上のリスク対応力に貢献する
- 勇気を持って問題をすぐに解決しようとせず、未決定なまま先送りするのが大事
本エントリはプロジェクトの新規開発時点のことばかりですが「カットオーバーされたシステムに起きる変化に適応するアーキテクチャをいかに設計するか」みたいな話は次回に。
