JJUGのエキスパートが語るエンタープライズ・アーキテクチャの過去、現在、未来──SOAP・RESTからIoT・ウェアラブルまで
JJUGのエキスパートが語るエンタープライズ・アーキテクチャの過去、現在、未来──SOAP・RESTからIoT・ウェアラブルまで 吉川 徹 特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、エンタープライズ・アーキテクチャについて取り上げます。 HTML5・モバイル・IoT・ウェアラブルなどビジネス環境が激変する中、エンタープライズ・アーキテクチャはどういう課題を抱えていて、どうあるべきなのか。今回は、JJUG (日本Javaユーザーグループ）でご活躍中のお二人に話を伺うことにしました。 アーキテクチャを主軸に第一線で活躍しているグロースエクスパートナーズ株式会社 執行役員の鈴木雄介さんと、「流しのアーキテクト」を自称する株式会社アーキテクタス 代表取締役の細川努さんを交えて、エンタープライ
WBS は、作業分解構造ではないのよ。 - haradakiro's blog
ちょっと大人数で行うプロジェクトに参加したことがある人なら、WBS (ワークブレークダウンストラクチャー) を目にしたことがあるだろう。 日本語だと作業分解構成と説明されることが多い。Work(作業) Breakdown(分解) Structure(構造) というわけだ。日本語の説明では、そういう説明が主流のようだ。 でも、WBS の Work は実は作業ではない。 WBS を定義した標準の最新版MIL-STD-881Cを見てみると、"A product-oriented family tree composed of hardware, software, services, data, and facilities." 「WBS の定義は、ハードウェア、ソフトウェア、サービス、データ、設備などからなる成果物指向の分解ツリーである。」 ここでいう Work は、成果物のことだ。Workb
アジャイルの人たちは自分の優秀さに気づいていない - 設計者の発言
アジャイル手法を実践できるプロジェクトは恵まれている。それは、「理解ある管理者」がアジャイル手法を了承してくれたからではない。管理者がそう判断できるほどに参加メンバーが優秀だからだ。 アジャイルの特徴のひとつが「少数精鋭」である。いっぽう、アジャイルの対立手法として理解されているウォーターフォール型手法では「人海戦術」で進められる点が対照的だ。じつは「少数精鋭」というのはアジャイルの特徴であるだけでなく、あまり触れられたくない弱点でもある。なにしろ「精鋭」しか関われない。 しかしアジャイル手法の推進者は、自分が優秀であることをそれほど意識していない。それどころか彼らは「いえいえ精鋭である必要はありません。じっさい私はアジャイルが大好きですが、凡庸な技術者ですよ」と自嘲的に語るだろう。そしてそれは本心でもあるだろう。なぜなら、彼らは「超」がつくほど優秀な技術者たちがいることをアジャイルコミュ
システム設計日記
テスト駆動開発 和田卓人(t-wada)さんによる『テスト駆動開発』の新訳版が出版されました。 オブジェクト指向でソフトウェアを開発するのであれば、この本とマーチンファウラーの『リファクタリング』は必読書だと思います。この古典ともいえる『テスト駆動開発』が和田さんの手によって新訳版として復刊されたことは、ほんとうにすばらしいことです。 この本が出版された経緯と、和田さんはじめ関係者の方々のご努力については、和田さんの、このブログをぜひ読んでいただければと思います。 新訳版『テスト駆動開発』が出ます 新訳本は、単に原著が日本語で読めるようになっただけではありません。和田さんの手によって、原著にはない新たな価値が付け加えらました。 一つは、サンプルコードの工夫です。 できるだけ省略はしない変更箇所を目立つようにした各章末にその時点での全コードを記載する これらの工夫により、本に書かれた内容が、
スタンプ属性や更新履歴テーブルの無駄っぽさ - 設計者の発言
データベース設計の際に「スタンプ属性」を載せることが設計標準とされているプロジェクトは多い。典型的なところでは、 ・レコード追加日時 ・レコード追加ユーザＩＤ ・レコード追加プログラムＩＤ ・レコード最終更新日時 ・レコード最終更新ユーザＩＤ ・レコード最終更新プログラムＩＤ といった項目をテーブル毎に載せ、更新系の処理が起こるたびにアプリに更新させる。捺印するように設定されるので「スタンプ属性」と呼ばれる。私も何も疑問を持たずに昔から従っていたものだ。 スタンプ属性の意義として、何か異状が生じた場合にそれらの値を調べることによって原因を特定しやすくなる、と説明される。しかし私のこれまでの開発経験の中で、そのように役に立った記憶が一度もない。 今やスタンプ属性は、「要らないもの」ではないにせよ「とりあえず載せるもの」ではなくなっている。それは「必要であれば載せ、必要でないなら載せなくていい
キレイなコードでも仕様書の代わりにはならない - 設計者の発言
４ＧＬ（第四世代言語。既に死語）を使っていた頃に「ソースコードが仕様書だ」と言い張っていたことがある。テーブル操作コマンドと統合されているそのプログラミング言語を使えば、じっさい英語の文章のように明解にコーディングできた。しかしそんな強力な言語を前提にしても、今から考えれば「コードが仕様書だ」と主張したのは間違いだった。 理由は単純。仕様書として通用するほどキレイにコーディングが可能と謳われている言語を使ったとしても、コーディングがキレイになることが「保証」されているわけではないからだ。まあ当然のことで、文章の読みやすさが書き手によってまるで違うのと同様、コードの読みやすさはプログラマによってまるで違う（その日の気分や体調によっても違うかもしれない）。いかに標準化を徹底しようが、同じ動きをするのにいっぽうは読みやすくいっぽうはわけがわからないなんて事態は日常的に起こる。そして、システム開発
アジャイルと受託開発
先日、永和システムマネジメント社がアジャイルによる受託開発サービスを発表し、話題になっている。多くの人の関心を引いているのは、アジャイル開発手法を取り入れるということだけでなく、その価格の安さだ。一ヶ月あたりの料金は、もっとも安いものでは月々15万円から、もっとも高額なプランでも月々150万円からとなっている。果たしてそんなので儲かるの！？というのが多くの人がいだいている疑問であろう。自分なりに「アジャイルによる受託開発サービス」について分析してみたので語ってみようと思う。なお、本エントリは永和システムマネジメント社が公開されている資料と筆者の推測に基づくものであるので、より詳細で正確な内容は永和システムマネジメント社さんへ問い合せて頂くよう悪しからず了承いただきたい。 採算割れしないのか？筆者の見解では、たぶんしない。何故か？それは一旦開発が終わったらそうそう頻繁にシステムの仕様を変更し
新しい契約形態での受託開発サービス ｜ 永和システムマネジメント
近年、大変注目を集めているソフトウェア開発手法に「アジャイル」があります。 アジャイルはお客さまの組織やビジネスの変化に素早く対応することが可能な開発手法です。 しかし、ソフトウェア業界での受託型の請負契約は要件定義が完了してから開発見積り・契約するというやり方が当たり前となっており、お客様にアジャイルのメリットを実感頂くのが難しいという課題がありました。 これまでの受託開発における一括請負型の契約では納品時に費用を全額お支払いいただくというビジネスモデルをとってきました。 このサービスではこのビジネスモデルから脱却し、開発したシステムを初期費用0円で提供します。その後、お客さまにはサービス利用料という形で月々お支払いいただきます。 サービスがお客さまに価値を提供するのは納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的にです。 このことから、お客さまがサービスを利用してい
非機能要求
1 はじめに システム開発における要求分析モデルとして、ユースケースを中心に説明してきました。 ユースケースはユーザの目的をモデル化したモデル要素であり、システムがユーザに提供する機能を表現するという意味で機能要求のモデルといえます。第1回では、図1[営業社員のシステム・ユースケース]に示すユースケースを用いた要求モデルを作成しましたが、これは機能要求ということになります。 しかし、要求仕様は機能要求だけで構成されるわけではありません。実際のシステム開発では「ユーザの目的」とは別の観点でさまざまな要求を定める必要があります。このような機能外の要求のことを非機能要求と呼びます。 今回は、この非機能要求について説明します。 2 ISO/IEC 9126(JIS X 0129) 非機能要求を考える上では、システムの品質という切り口が重要です。 ISO/IEC 9126は、ソフトウェア開発における
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ビジネスアプリ開発者のための機能規模測定手法COSMIC法入門 | オブジェクトの広場
JFPUG COSMIC METHOD（COSMIC法）
NTTデータ公式サイト