アーキテクチャ設計の意味を問う - クリストファー・アレグザンダーの思考の軌跡 - arclamp
建築家クリストファー・アレグザンダーが「パターン」という概念を広め、それがウォード・カニンガムとケント・ベックによってソフトウェア開発のデザイン・パターンに応用されたことをご存じの方も多いでしょう。 （ご存じでない方には、江渡さんの「パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)」をお勧めします） 「クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う」は、そのアレグザンダーがパターン・ランゲージに至った経緯、そしてパターン・ランゲージの限界を超えていった流れを追うことができる本です。 この本を読むと、アレグザンダーは一貫して”数学的”であり、客観的に証明可能な構造を求め続けたからこそ、近年では”神”の視座へと導かれていったのだと分かります。 パターン・ランゲージと設計プロセス アレグザンダーはパターン・ランゲージによって、
エンタープライズから見たImmutable Infrastructure - arclamp
Immutable InfrastructureとかDisposable ComponentsとかBlue-Green Deploymentが話題になってるみたいで。 Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編） － Publickey Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（後編） － Publickey 詳しくは記事を。「不変のインフラ」つまり、一度動くようになったサーバーには手を触れず、なにか変更が発生したら新たなサーバーを別途構築し、丸ごと入れ替えることでシンプルな管理が可能になるというもの。「インフラ設定を自動化する」という流れとして見ると非常に面白い。 言いかえれば「アプリからインフラまでを一貫して構成管理する」ということになると思います。ソ
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
アジャイルって組織論ですよね（DevLOVE2012ご報告） - arclamp
2012年12月15－16日に開催されたDevLOVE2012で「どうしたら良いシステムが作れるのか」というタイトルで講演をさせていただきました。 Devlove2012 どうしたら良いシステムが作れるのか from yusuke suzuki アーキテクチャとマネジメントについての講演は2年ぐらい前からしていますが、そこで考えてきたことをギュっとまとめたので相当密度の高い内容になっています。予想通り時間も足りず、ちょっと最後が駆け足で申し訳なかったです。前半部分とかを丁寧に見たい方は過去記事を漁ってもらうとよいかも。 この資料を作るにあたって1960年代からのIT技術とマネジメント手法の歴史を見直していたのですが、組織論や科学（認知学/複雑系など）の流れとの絡み合いは非常に面白かったです。 その中で「アジャイルって組織論なんだな」と当たり前の事実に（いまさら）気づけけました。スクラムのJ
歴史から考えるアーキテクチャとマネジメント - arclamp
ソフトウェアアーキテクチャとプロジェクトマネジメントは相互に絡み合う要素です。この関係性を歴史の流れから考えていくと面白い推測が成り立ちます。 アーキテクチャの歴史 「アーキテクチャとは」というのに定まった定義はありませんが、大枠では「システムの目的や環境を前提とし、様々な利害関係者の関心事を整合させた、システムの構成や構造」のことです。 これはもちろん「あるべき姿」です。完成されたシステムには必ず構成や構造がありますが、それが「システムの目的や環境、あるいは様々な利害関係者の関心事」と完全に合致しているとは限りません。 （ソフトウェア）アーキテクチャという言葉、あるいは（ソフトウェア）アーキテクトという用語は2000年前後から一般的になってきました。逆にいえば当時は「システムの構造や構成」と「システムの目的や環境、あるいは様々な利害関係者の関心事」の不一致があったということでしょう。 で
「ソフトウェア開発プロジェクトをとりまく６つの誤解」は真実でもある - arclamp
「ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと」に釣られてみます。 6つの誤解は次の通り。 既にあるソフトウェアを流用した方が速く作れる ソフトウェアはハードと違って後から容易に直せる 誰が作っても中身は同じ品質になる 共通部品から先に作ることが出来る 人を増やせば一度に沢山の機能が作れる 正確な見積もりを出すことが出来る 記事の前提は"お客さんはITにそれなりに詳しい（けどプログラミングはしたことがない）情報システム部門の人"ということだと思います。 この6つは誤解しやすいし、僕もお客さんと会話する内容です。でもね、お客さんがそう感じていることも事実です。なるべく安く早く、そして変更に強いシステムを作りたいと願うことは当然のことです（もちろん予算どおりに）。 ソフトウェア開発に職人的（あるいは芸術的）要素があることは間違いありませんが、それ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
