アーキテクチャ設計のジレンマと拡張構造としてのマイクロサービスアーキテクチャ - arclamp
2016年10月24日のQCon Tokyo 2016にて「今どきのアーキテクチャ設計戦略」という講演をさせていただきました。 アーキテクチャ設計のジレンマ 伝統的に、アーキテクチャ設計というのは設計や実装に先立って事前的に行われる必要がある、とされています。設計や実装は定義されたアーキテクチャを参照しながら進めなくてはならないからです。なので、アーキテクチャ設計にあたっては「システムの振る舞いに対する要求」という「話」を理解して進めていくことになります。そのため、その要求が正確であればあるほど適切な構造を定義できることになります。これは当たり前のことですね。 一方で、現在的なシステム開発というのはアジャイルに代表される「フィードバックと改善によって段階的に機能を拡張する」という前提にあります。これも当たり前のことで「誰も事前に正しい要求を定義できるわけがない」から「動くソフトウェアを見て
エンタープライズにおけるマイクロサービスアーキテクチャについて - arclamp
エンタープライズ業界でもマイクロサービスアーキテクチャの議論が盛り上がりはじめてて、それは良いのですが、やはり本質的ではない技術論にばかり夢中になっている気がしています。 エンタープライズシステムの現状 モノリシックな巨大システムでは一部分の改修であっても、システム全体対する影響調査やリグレッションテストによる工数増加が発生し、共通機能をいじるとなれば関連機能も含めた改修が発生するなど、スピード感は落ちる一方です。 つまり、従来型のコンポーネント集約のような手法で巨大システムを作ると、開発効率が上がったとしても、保守における変化効率が極端に下げることが分かっているわけです。 一方で、旧来から部門別で構築されてきた中小規模システム達は、いつのまにやら複雑に連携しあっており、相互に影響を与える中では、個別システムの都合だけでリリーススケジュールを決めることが困難になってます。 特に場当たり的に
ウォーターフォールとアジャイルを考える - arclamp
初めて単独主催の勉強会をしました。ワークショップなので後半の1時間はディスカッションにしたのですが40人のわりには、それなりに面白い話ができた気がしています。資料とワークの結果、あとTogetterは以下から。 togetter.com 今回のプレゼンは純粋な「プロジェクトマネジメント論としてのウォーターフォールとアジャイルの違い」に絞った話をしたので、後半のワークが現実的な話になって面白かったです。話をしたのは以下のようなことです（資料の後半に細かいメモ書きがあります）。 そもそもウォータフォールは必要なのか？ とはいえ、ウォータフォールを採用しなくてはならない状況は？ なぜ、アジャイルを採用できないのか？ チームは重要だけど、どういうメンバーがいいのか？ アジャイルとはいえPM的な人が必要になることってあるよね？ アジャイルの立ち上げってどうするのがいいの？ 偶然、牛尾さんの 私は間違
エンタープライズにおけるDevOpsとマイクロサービス - JavaOne2015レポート - arclamp
バズワード過ぎてタイトルにするのも憚られるのですが、JavaOne2015でキーワードになったことは間違いないので...。 JavaOne2015でもDevOpsやマイクロサービスについてのセッションが多く見られました。昨年はマイクロサービスというとWebアプリケーションフレームワークからの理想論的な話が多かったですが、今年はわりと事例に基づいた話が多かったように思います。ただ事例は事例で抽象的な話にならざるを得ないわけで、目新しい話があったわけではないように思います。 あと「Java（JVM）を使っているよ」というだけのことで、直接的に「Javaでどうすべき」という話は少ないです。これもDevOpsやマイクロサービスが特定の技術の依存しているわけではないから当然のことかと思います。 事例そのものはよく知られたWebサービス系の事例が中心となっていますので、Netflix、Gilt、Twi
マイクロサービスアーキテクチャとは何か - arclamp
マイクロサービスアーキテクチャ（以下、MSA）という言葉を聞くようになりました。きっかけはファウラーのブログ「Microservices」（2014年3月）ですが、昨年10月のJavaOne SFでも多くの講演でMicroservicesという言葉を聞かれ、多くのエンジニアがすぐに共感していたことが分かりました。今後、日本でも広く知られる言葉になることでしょう。 一方でMSAは誤解を招きやすいバズワードとも言える気がします。というわけで、僕なりのMSAについての考えをまとめてみました。 MSAは「優れたウェブサービスを観察したところ同じようなアーキテクチャだったので、それをマイクロサービスアーキテクチャと名付けた」というものです。逆に言えば「大きなウェブサービスを作ろうと思ったときの定石」といえます。「各要素を疎結合に構成し、連携する」「それぞれの要素に適した技術を使う」といったアイデアは
ITサービス運営におけるアーキテクチャの役割 - arclamp
2014年11月15日に開催されたJJUG CCC 2014 Fallにて「Javaエンジニアのためのアーキテクト講座」と題して発表を行いました。資料は以下です。 「良いアプリケーションを作る」時代から「良いITサービス運営を実現する」時代になったことで、アーキテクトの役割はどうなったか、という内容を話しました。 今回は自分なりにITサービス運営というものをモデルを書いてみました。v0.1となっていますが、まだまだ見直せることはあると思っています。 元ネタはソフトウェア品質モデルです。ソフトウェア品質モデルでも「外部」「内部」といった静的な要素に加えて、「利用時」「プロセス」といった動的な要素も含めて、お互いに依存したり影響を与えたりするということが定義されていました。ITサービス運営ということを考えて、もう一歩、複雑な構成となっています。大きく分けて「ITサービスを構成する要素」と「IT
アジャイルが否定したものを見直そう - arclamp
2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。 元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。 さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。 アジャイルがさまたげたもの アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流で
「納品」をなくさなくてもうまくいく - arclamp
倉貫さんから直接献本をしていただいきましたので感想がてらに。 本書はいわゆる“アジャイル”を清く正しく実践している実績と、その仕組みを丁寧に解説した本です。しかも、開発体制は「事業会社の内製化」ではなく「外部のソフトウェア開発企業を継続的に利用する」というスタイルであることに大きな意味があります。 （ソフトウェア開発企業という名称ですが、もはや「ソフトウェアだけを開発している」わけではないので、本来は「ITサービスを開発している」企業というような名称が最適なのですが、ここでは一般的な名称として使います） これまでアジャイル開発方法論は「事業会社における保守運用フェーズの内製開発」に最適であるとされてきました。実際、多くのウェブ企業が社内にエンジニアを抱え、継続的な保守運用の中でイテレーティブに開発を行うスタイルを実践しています。 しかし、実際には世の中の大半の企業が“優秀なエンジニア”を雇
ベネッセ事件はITマネジメントの課題として語るべき（追記あり） - arclamp
思ってたより衝撃的だったのでブログを書きます。 顧客ＤＢ開発に関与＝知識悪用し防止措置解除—派遣ＳＥ、逮捕状請求へ・警視庁 - WSJ 外部業者から派遣されているシステムエンジニア（ＳＥ）の男が、情報が流出したデータベース（ＤＢ）のシステム開発に関与していたことが１７日、捜査関係者への取材で分かった。 警視庁は男が専門知識を悪用し、ＤＢの流出防止プログラムを解除して顧客情報を記憶媒体に複製したことを確認。 これが本当だとすると各所が大騒ぎにならないといけません。ただ、「すわ、セキュリティコンサルに依頼だ！」では、まったく解決になりません。むしろ、振り返って「自社のITマネジメントってどうなっている」を正しく理解した上で「で、これからどうしていく？」ということを考えないといけません。 この事件はセキュリティの問題ではなく、ITマネジメントの問題なのです。 まず「流出防止プログラムがあった」こ
企業経営とクラウド[追記あり] - arclamp
こういう抽象度の高い話もたまには。 近年、仮想化技術の発展と共にクラウドやXaaS（X as a Service）と呼ばれる概念が登場しました。"as a Service"というのは必要に応じてサービスされること、つまり、技術面ではスケーラビリティできることを意味し、ビジネス面では従量課金のように投資リソースの最適化ができるようになります。 このXaaSですが、大きく分けると以下のように類型化されます。 名称 提供レベル 利用イメージ IaaS(Infrastructure as a Service) インフラ 自分で作ったソフトウェアを置く PaaS(Platform as a Service) 特定ニーズに合わせたアプリケーション基盤 自分で作ったソフトウェアから利用する SaaS(Software as a Service) 具体的なアプリケーション 自分では設定やプラグイン開発だけ
![企業経営とクラウド[追記あり] - arclamp](https://cdn-ak-scissors.b.st-hatena.com/image/square/347a1277611c3e1ac48424341f12fdcb634e73e2/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fa%2Farclamp%2F20140523%2F20140523223114.png)
アーキテクチャ設計に品質特性を使おう - arclamp
アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報
アーキテクトと要求もしくは技術について[追記あり] - arclamp
2014年2月27日の要求開発アライアンス２月定例会で「アーキテクチャの発掘に見る要求変化の発見」、そして翌2014年2月28日にはEnterprise ☓ HTML5 Web Application Conference 2014で「JavaエンタープライズアーキテクチャにおけるHTML5」という講演をさせていただきました。 前半は（ここ数年間は同じですが）、ITサービスの提供において「利用価値、提供機能、構成／構造、プロセス」の４つの要素のバランスが重要であり、そのバランスを取る事がアーキテクチャ設計だという話です（そのバランスを保ちながらモノを作るのがマネジメントですね）。そして、後半はそれぞれのイベントの趣旨に従って変えています。 要求定義がきちんとできても、どんなにHTML5に詳しくても、あるいは、どんなにアジャイルがうまく回っても、それ"だけ"で良いITサービスを提供する事は出
![アーキテクトと要求もしくは技術について[追記あり] - arclamp](https://cdn-ak-scissors.b.st-hatena.com/image/square/6d8216e64106bac7e18f0344459bda51cb85fdba/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704346814673873149%2F12921228815719241700%2F1396502451)
SIにおけるアジャイルとかウォーターフォールとか - arclamp
取材を受けないとブログを書けないのは問題ですが、@ITの「特集：DevOpsで変わる情シスの未来」というのの第5回で「DevOpsというバズワードに流されないために」という話をさせていただいたので紹介を。 特集：DevOpsで変わる情シスの未来（5）：DevOpsというバズワードに流されないために (1/4) - ＠IT 弊社も当然、最初は顧客企業の業務のことをよく知りませんから、会話を軸に業務を理解し、顧客企業との共通理解という土台を構築する作業から入ることになります。従って、そこではアジャイル開発は行いませんし、行うべきではないと考えています。ウォーターフォールで始めて、まずは満点ではなく合格ラインのシステムを作ることで共通理解の土台を固めます。その上でアジャイルに移行してスピーディに改修を進めるといったケースが多いです。 というあたりがポイントかと思います。 「顧客の求めることには永
未決定を決定する - アーキテクトの考え方 - arclamp
「アーキテクチャ設計の難しさについて」というエントリをしましたが、続きとして「未決定を決定する」という話を。 決定していないことを決める アーキテクチャは「作り方」を示すものなので作り始める前に決定している必要があります。つまり、アーキテクチャ設計はプロジェクトの最初に行います。ところが、皆さんもご存知の通りプロジェクト開始時点で全ての要件が出ることはありません。要件定義＞基本設計と進んで行き、さらには実装も後半になってからアーキテクチャ上で対応すべき問題が発覚することもあります（後工程で問題が発覚するというのはアジャイルでも同じことです）。 ですから、アーキテクチャ設計では「決定していないことを決める」必要があります。 どう決定していないかを決める 決定していないことの設計方法は「どう決定していないかを決める」ということです。 前回のエントリで「接続先のサーバが決まっていない」という例を
「ITプロジェクトのリスク予防への実践的アプローチ」への違和感 - arclamp
IPAから2013/3/27に「ITプロジェクトのリスク予防への実践的アプローチ」が公開されました。読んでみて感じたことを簡単に（参照：ITプロジェクトのリスク予防への実践的アプローチを公開） リスクを発現させない この資料の目的は「リスクを発現させない」ということにフォーカスされています。 そのためにリスクの発生要因となる「リスク事象ドライバー」を整理し、そこで把握された要因について回避や軽減といった予防策を取るように推奨されています。リスク事象ドライバーは以下の通り。 システム化の目的が明確でない 現行機能の調査確認が不足している 現行システムとそのドキュメントが整合していない パッケージ選定に関する検討が十分でない 性能の検討が十分でない 可用性の検討が十分でない 運用要件の検討が十分でない 運用に向けての制約条件が明確でない 要件を獲得すべきステークホルダーが網羅されていない シス
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
技術的な結合度と設計的な結合度 - arclamp
ささっとBlogを書く訓練。 エンタープライズシステムではシステム間を疎結合に保つことが重要とされます。結合度が下がっていれば両者の依存関係は弱くなります。システムAとBがあったとして、Aが停止した場合に、それによってBが停止しない（縮退はするかも）、あるいはAの内部仕様に変更があった場合に、それによってBが仕様変更を強制されることがない、という示しています。 結合度が低ければシステムのライフサイクルをずらすことができるため、運用上も保守上も大きなメリットになります。 とはいえ、結合度が高いことでのメリットもあります。主にはコストの低下や性能の向上が見込めます。 マスタデータを共有したい場合、ファイルによるデータ交換は結合度を下げることができます。ですが、双方がファイルを入出力する仕組みを作る必要があり、かつ、連携遅延が出てしまいます。そうではなくて、直接データベースを共有するようにすれば
アーキテクトがプロジェクトマネジメントをしたら - arclamp
システム開発プロジェクトでは、技術要素が複雑化するなかで「何を作るか」というだけではなく「どう作るか」ということの難しさが高まっています。 「何を作るか」というのがユーザー要求やシステム機能であり、「どう作るか」というのは「静的な内部構成・内部構造」と「動的な開発プロセス」のことです。一般的には「静的な内部構成・内部構造」というのをアーキテクトが担当し、「動的な開発プロセス」をプロジェクトマネージャーが担当し、両者はWBS（タスクとスケジュール）を通じて会話をします。 「good manager does things right.（良いマネージャーは事を正しくする）」と言われるように、PMは予定（計画やスケジュール）に従って実行し、その実績を見ながら日程／リソース／タスクなどを調整をしていきます。 これに対してアーキテクトの仕事は事前的です。内部構造は事後的な変更コストが高いため、事前に
ITに社会は変えられるのか - arclamp
もう2012年も終わりですね。年の瀬に「社会は情報化の夢を見る---［新世紀版］ノイマンの夢・近代の欲望」が面白かったので久しぶりに感想文。 IT業界のトレンドを示すキーワード、いわゆるバズワードの入れ替わりは相変わらずの勢いです。今年はクラウド、ビッグデータ、ソーシャル、モバイルというところでしょうか。特にソーシャルは2011年のFacebook/Twitterブームが頂点と思いきや、LINEの登場で、まだまだ面白いことが起きる可能性が残っていることを示しました。2013年もソーシャルとモバイルの勢いはとどまることをしらないでしょう。 さて、一方で、こうしたバズワードの流行とともに語られるのが「"IT技術"が世の中を変える」という話。本当にそうなのでしょうか？本書は、そんな言説を一刀両断しています。なぜか。それは「技術が進歩したから社会が変化したのではなく、社会の変化によって技術の使い方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
