Something about Development Technology :-)

商用サービスが始まる前に Windows Azure を楽しもう！～ Cloud Bootstrap × Cloud Bootstrap ～

2009-11-09T07:19:00Z

さて、PDC09 の開催が近づくと同時にマイクロソフトの新しいプラットフォーム、Windows Azure の商用サービス開始も近づいてきました。

すでに Windows Azure の CTP に参加いただいている皆様であれば、CTP チームからのメールで（砂金のBlogも参照ください）ご存知かと思いますが、Windows Azure のサービスは、2009年12月末までを CTP (評価期間。無償で提供）とし、また 2010年1月に関しては、商用のサービスとして提供しながらも、課金については $0 でのサービス提供を行わせていただく予定になっています。

大事な話なので、もう一度。

Windows Azure　のCTP（評価期間）は 2009年12月末まで。
2010年1月からは商用サービスとして開始するけれど、1月の請求に関しては $0 で請求。

です。

そう、つまり Windows Azure を無償で使っていただくのは、今がチャンス！

ということで、皆様の Windows Azure アプリケーション開発を支援するため、２つのキャンペーンを実施中です。

１つ目：無償のハンズオンラボセミナー「Cloud Bootstrap セミナー＆ハンズオンラボ」

マイクロソフトが最近オープンした、新しいオフィス（大手町オフィス）にて実施する、ハンズオンラボです。

あらかじめ用意させていただいている開発環境（Windows 7 + Visual Studio 2008 + 必要な開発環境）を使って、２時間の演習で Windows Azure のアプリケーション開発から、実際の公開までを体験いただけます。

Windows Azure のCTPにおいては、トークンの発行（CTPのサービスを利用するためのチケットのようなもので、アプリケーションの公開を行う際に必要です（※））が必要で、通常は申し込みから何日かお待ちいただくことになるのですが、今回のハンズオンラボでは、参加者の皆様にその場でトークンを提供させていただき、その場でアプリケーションの公開を行っていただけます！

※ ちなみに、アプリケーションの開発、だけであれば（つまり、Azure のサーバーにアプリケーションを Upload して、インターネットで公開を行わないのであれば）、トークンの発行は不要で、開発環境を用意いただくだけで、即、Azure アプリケーション開発を実施いただけます。

２つ目：クラウドアプリ開発の腕を競おう！？「Cloud Bootstrap ～ Windows Azure 開発コンテスト＆タイムトライアル」

せっかく Windows Azure アプリケーションを開発するのであれば、開発の腕を競ってみたいですよね！？

２つ目に紹介する Cloud Bootstrap なキャンペーンでは、アプリケーションそのもののUXやユニークさを強化する開発コンテストと、Windows Azure アプリケーションをアップロードし、デプロイが完了するまでの時間を競うタイムトライアルを用意。

とくに前者に関しては、入賞したWindows Azure アプリケーションをマイクロソフトが積極的にプロモーションさせていただく予定ですので、ぜひ気合を入れて応募いただければ、と思います。

ということで、今回は２つの「Cloud Bootstrap」　キャンペーンを紹介させていただきました。

すでに告知を行わせていただいていますが、Windows Azure のサービスは、MSDN Subscription ユーザーの皆様にも新しいベネフィットとして追加される予定です（詳しくはこちらのページを参照ください）。

また、Windows Azure の商用サービス開始に伴い、今後は実案件においても Windows Azure を使用したプロジェクトも行われると思います。

ぜひこの２つの「Cloud Bootstrap」の機会を活用し、Windows Azure を利用したアプリケーション開発技術を取得ください！

では！　

VSS 大好き！なあなたにも～ Team Foundation Server ”簡易版”

2009-10-05T06:24:00Z

Team Foundation Server の開発チームの責任者 Brian Harry (※1) が下記のブログエントリでアナウンスしているとおり、現在次期バージョンの 2010 のリリースにおいて、”簡易版”の TFS のリリースが予定されています。

http://blogs.msdn.com/bharry/archive/2009/10/01/tfs-2010-for-sourcesafe-users.aspx

この”簡易版” のTFSを利用すると、主にソースコード管理と、バグトラッキング、そしてビルド機能を利用いただけます。

しかも、このTFSのインストール、クライアントOSへのインストールもOKです。(※2)

そして、インストールも楽です（もっともフルバージョンの TFS2010 でもインストールは結構楽になっていますが）。

重要なポイントを簡単に整理すると、

① 使える機能：コード管理、バグトラック、ビルド

② 使えない機能： SharePoint を使った共有サイト、レポーティング機能

③ インストールはクライアントOSでもOK。インストールはとても楽。(DBには SQL Express 使用)

④ 価格、リリースは未定。2010 の Beta 2 リリース時に初の評価リリース予定

といった感じです。

ライトな感じでTFSを自分のPCに入れて、コード管理と、自動ビルドを使いたい！、というニーズにぴったり、ではないでしょうか？

ということで、Brian のエントリのタイトルにもありますが、VSS ユーザーにぜひ使っていただきたいTFSでもあります。

まずは、Beta 2 での評価版リリースをお待ちください！

※1 ついでに、Brian Harry は VSS の開発者でもあります（後にMicrosoft に買収）。そして、現在でも Redmond ではなく、North Carolina のオフィスで開発をしています。そのため、TFSの主要な機能は、その開発時（コードネーム Burton。VSのバージョンでいうと2005)には、North Carolina の灯台の名前がつけられていました。

※2 接続数などクライアントOS毎に制限があります。詳しくは各OSのライセンス条項を確認ください。

Tech・Ed Bof 会場の盛り上がりを再現～ "Web Form" vs "MVC"

2009-09-04T08:17:00Z

先週はマイクロソフトにおける最大級のイベントの一つである Tech・Ed 2009 がひらかれていたのですが、その中で Bof として実施させていただきました「ASP.NET Web Form vs ASP.NET MVC」のセッションレポートが CodeZine でさっそく公開されています！

「ASP.NET Web Form」か「ASP.NET MVC」か？.NETによるWebアプリ開発の今を徹底討論

執筆者は、当日のBof で司会をされたナオキさんです。

当日も非常に盛り上がったBofセッションでしたが、改めて文章で読んでも参考になります。

Web Form と MVC は「Web アプリケーション開発のためのフレームワーク」という点では同じですが、その性格（設計思想）はまったく異なっています。どちらが良い技術であるか、ということではなく、その性格を理解したうえで、使いこなしていただくのがよいかと。

ということで、「ASP.NET MVC」まだ使ってない、という方は、ぜひ体験ください！

Enjoy Coding!

P.S.

ASP.NET MVC の取り掛として、@IT に Chica さんが翻訳された Scott Guthrie （マイクロソフト米国本社の副社長。ASP.NET / Silverlight / IIS 等の開発責任者）の「NerdDinner」チュートリアルがよい開始点になると思います。ぜひご参照ください。

http://www.atmarkit.co.jp/fdotnet/scottgublog/nerddinner/part01.html

絵で見て理解する ASP.NET シリーズ：Routing の仕組み

2009-07-31T09:15:45Z

さて、今回の「絵で見て理解する ASP.NET シリーズ」(※1)では、.NET Framework 3.5 SP1 で導入された Routing (System.Web.Routing)についてみていきたいと思います。

ASP.NET ではこの Routing を使用することにより、例えば

http://www.example.com/productlist.aspx?id=1214&category=toys&page=3

といったURLに対して、

http://www.example.com/toys/1214/3

といった別表記のURLにてアクセスすることが可能になります。

今回はこの Routing の仕組みを解説したいと思います。

まず最初に主要な登場人物と、物語風の処理のあらすじです。

登場人物：

Route 一家。Routing 情報を知っている Route オブジェクトがいっぱいいる一家。

MyHandler。リクエストに基づき Page(WebForm)を返す。Route 一家と仲が良い。

BuildManager。結構偉い人。MyHandler が返す Page は実は彼が作っている。

Page。MyHandler によって返されるオブジェクト。

物語風あらすじ：

ある日、とあるユーザーから ASP.NET 村に “http://www.example.com/toys/1214/3” への Request が入ります。

この Request を受け取った ASP.NET 村の村長は、村一の物知り一家 Route 家にこの Request を誰に任せるのかよいか訪ねます。

Route 家で Request を良く調べた結果、今回は MyHandler 君に処理を任せるのが一番だと判断し、それを伝えます。

村長は MyHanlder 君を呼び出し、Request の処理を依頼します。

MyHandler 君は Request をもとに BuildManager に Page の作成をお願いし、できあがった Page を村長に渡したのでした。

ということで、概略を理解いただいたうえで、実際の解説に入りたいと思います。

実際の処理概要：

最初に Routing を使用したい Web アプリケーションにおいて、Global.asax に、適切な Route 情報を登録しておきます。

RouteTable.Routes.Add(new Route

(

"{category}/{productID}/{page}",

new MyHandler("~/productlist.aspx")

)

);

このRoute 情報は複数登録を行うことができます。

Web アプリケーションに対して、ユーザー（Webアプリケーションの使用者）から Request が投げられると、Web アプリケーションは RouteTable（物語におけるRoute一家）の Route 情報を順番に確認し、Request にマッチする Route があれば、それに関連づいている Handler クラス（実際には IRouteHandler インターフェィスを実装した何らかのクラス）の GetHttpHandler メソッドを呼び出します。

Handler (IRouteHandler インターフェィスを実装した何らかのクラス) の GetHttpHandler メソッドでは Reqest に最適な Page オブジェクトを生成し、返します。

この Page の生成には、BuildManager の CreateInstanceFromVirtualPath メソッドを使用しています。

さて、GetHttpHandler メソッドの戻り値は、IHttpHandler インターフェィスを実装している必要がありますが、ここで生成される Page クラス（WebForm）は System.Web.UI.Pageを継承しており、この System.Web.UI.Page が IHttpHandler インターフェィスを実装しているので特に細工はいりません(※2)

BuildManager の CreateInstanceFromVirtualPath で Page オブジェクトを作成して、さっくり返してあげれば、あとは生成された Page オブジェクトが処理を継続します。

Request から必要な情報の取り出し：

以上で Routing の概略は終了ですが、実際には Request から必要な情報を取り出す処理(①)と、その情報を Pageに渡す処理(②)が必要です。

まず、①の情報の取り出しについてですが、この部分は Routing の基本的な仕組みとしてフレームワークで提供されています。

具体的には、Route 情報の登録の際に指定したパターン（赤字部分）

RouteTable.Routes.Add(new Route

(

"{category}/{productID}/{page}",

new MyHandler("~/productlist.aspx")

)

);

に基づいて、Routing のフレームワークが、RequestContext.RouteData にその情報を格納しています。

(パターンで指定された文字（たとえば “category” ）をキーに、実際の Request で与えられた文字列を値として保持します)

これを取り出すのは、以下のようにします。

public IHttpHandler GetHttpHandler(RequestContext requestContext)

{

string category = requestContext.RouteData.Values["category"] as string;

……

}

もしくは GetRequiredString メソッドでもOKです。

public IHttpHandler GetHttpHandler(RequestContext requestContext)

{

string category = requestContext.RouteData.GetRequiredString("category");

……

}

これで Request から必要な情報を取り出せました。

次に、②の「Pageに渡す処理」です。

これについては、BuildManager に作成させる Page クラスを拡張することで対応します。

具体的には、IHttpHandlerインターフェイスを継承した新しい Handler インターフェイスを作成し、その中に値を保持するためのプロパティを追加します。

以下のような感じです。

interface IMyHttpHandler : IHttpHandler

{

string Category { get; set; }

string ProductID { get; set; }

string Page { get; set; }

}

これにあわせて Page の宣言を変更しましょう。

public partial class ProductList : System.Web.UI.Page, IMyHttpHandler

最後に、BuildeManager による Page インスタンス作成時に、今回追加を行ったプロパティへの値の設定のためのコードを追加します。

public IHttpHandler GetHttpHandler(RequestContext requestContext)

{

var page = BuildManager.CreateInstanceFromVirtualPath

(VirtualPath, typeof(Page)) as IMyHttpHandler;

page.Category = requestContext.RouteData.Values["category"] as string;;

……

}

これで Request (VirtualPath) に含まれている情報を Page に渡すことができるようになりました。

以上で今回の絵で見て理解する ASP.NET シリーズ、「Routing の仕組み」を終了します。

ありがとうございました。

謝辞：

今回のエントリは Routing について調べていたところ、以下の２つの素晴らしい記事に接し、それに触発されて書いたものです。

小山さんと小野さんにお礼申し上げます <(_ _)>

IIS/Windows サーバー徹底解説：ASP.NET ルーティング (ASP.NET Routing)

http://keicode.com/dotnet/aspnet-routing.php

どっとねっとふぁんBlog：ASP.NET ルーティングを実装する

http://dotnetfan.org/blogs/dotnetfanblog/archive/2008/09/18/2809.aspx

今回のエントリでは ASP.NET Routing の実際の使用方法、あるいは web.cofig の設定については触れていませんが、それについてはぜひ上記の記事を参照ください。

※1

思わずネタで書いてしまいましたが、当然そんなシリーズはなく、今回限りのエントリです。しかも、おもったより「絵」の少ないエントリですいません。。。

※2

最初に公開したときに、「Page で IHttpHandler を実装しましょう。といってもクラス宣言で、IHttpHandler を継承すればOKです」といった記述をしていましたが、小野さんから、「Page 自体が IHttpHandler を継承している」ので、「両方を継承する必要はないんじゃ」とコメントいただき、そのとおりですので書き換えました。スイマセン。

Windows Mobile のアプリケーション開発コンテスト、"Race To Market" 始まる。

2009-07-30T04:51:00Z

最近、この界隈（どこ？ :-) ）でも盛り上がりつつある Windows Mobile ですが、アプリケーションの開発コンテスト、"Race To Market" が開始されました。

Race To Market は、Windows Mobile おけるアプリケーションのオンラインストア “Windows Marketplace” で行われるコンテストで、そこに登録されたアプリケーションのうち、ダウンロード数が多かったもの、あるいはもっとも売り上げが多かったものがこのコンテストの Winner になる、というものです。

コンテストでは、①北米（アメリカ/カナダ）、②東、および南アジア、③ヨーロッパ中東、④中南米、の４つの地域に分かれ、各地域から無料のアプリケーションはダウンロード数、有償のアプリケーションは売上、で上位５つのアプリケーション（トータル４０）が最終の評価に残り、そこから「Useful」および「Playful」の各部門で、２つのアプリが選ばれます。

そして、その商品はなんと Surface！

、、、、、なんですが、「Surface が売っていない国では、Surfaceと等価の現金」だとか。（Approximate で $20000なので、約200万円だと思うのですが、個人的には Surface ほしい！）

ということで、

「そろそろ Windows Mobile なアプリケーションでも開発してやるか！」

というい方は、ぜひこの機会に！

エントリーは今年の12月31日までですが、ダウンロード/購入の数を競うコンテストですので、早めの登録がお勧めです！

開発者向けポータルはこちら –> http://developer.windowsmobile.com/

Enjoy Developing!

Tech・Ed の季節がやってきました。今年は8月26日から！

2009-07-03T06:42:48Z

だんだん暑くなってきましたが、夏といえば Tech・Ed。

そう今年もやってきます、Tech・Ed。

今年も横浜で、夏の暑いテッキーな日々を過ごしましょう！

開催日は8月26日から、29日まで。7月17日までは、早期割引も受付中です！

Visual Studio 関係では、2010のセッションはもちろん、Webアプリケーションのテストや、エンタープライズ開発における Foundation Server 活用法など、いますぐ活用いただける技術セッションを用意しています。

ぜひご期待ください！

直感マインドマップ by アークウェイがリリース。

2009-07-03T06:32:00Z

Team System の導入支援や、メンタリングサービス等を提供いただいているアークウェイさんが開発されたソフト「直感マインドマップ」がリリースされています。

http://www.sourcenext.com/titles/use/105930/

以下はアークウェイさんのHPの情報。

http://www.archway.co.jp/Home/aiNote.aspx

マインドマップといえば Visio にも描画ツールがありますが、さくさくっと直感的に書きたいときはよいかもしれませんね。UX重要、ということで。

では！

Windows Live Writer からの投稿！

2009-05-20T11:27:24Z

さて、これまでの投稿は Community Server を利用しておこなっていたのですが、ちょっと気分をかえるために（？） Live Writer をインストールしてみました！

ということで、今回の投稿は Live Writer のテストです。

ためしに反射付で画像を張ってみたり、、、

文字フォントを変えてみたり。。。

ということで、次回以降は Live Writer も使いながらエントリを投稿したいと思います！

では！

Visual Studio 2010 英語版 Beta 1 を MSDN サブスクライバダウンロードで公開しました！

2009-05-20T09:30:00Z

表題のとおりですが、いよいよ次期 Visual Studio のリリースとなる Visual Stusio 2010 の Beta 1 が完成しました！

早速 MSDN サブスクリプション会員向けのダウンロード提供が始まっています。

http://msdn.microsoft.com/ja-jp/subscriptions/default.aspx

今回は、英語版、の提供です。

日本語版の開発も着々と進んでいますので、いま少しお待ちいただければ提供を開始できると思います。

なにはともあれ、是非ダウンロードいただき、評価いただければ！

それでは！

Agile Japan セッションメモ(2)：午後の部

2009-04-23T09:41:00Z

午後はいくつかのセッションがありますが、概ね事例のお話。

Agile とか XP とか Scrum とはいわないけれど、ユーザー企業と開発者の協働体制によってよりよいソフトウェアをリリースできています、というお話でした。最初の総括の部分でも書きましたが、不確実性が高い（要件リスクが高い）開発においては、アジャイル（というより、ユーザーを巻き込んだ開発ですね）重要、という感じです。

そして、成功のポイントとなるのは、やはりユーザー企業の態度、です。要件リスクが高い開発においては、意思決定を遅らせる必要があり、それにより投機リスクよろしく、利得の機会も最大化（最適化）できるというメリットもあるので、そのメリットを享受するために、損失の機会を許容できるか、また意思決定を遅らせた場合に、利得を最大化するための仕組みをいかに用意できるか、というあたりがポイントかと。「仕組み」に関して言うと、単純には開発フェーズでどれだけシステムのエンドユーザーを巻き込み、エンドユーザーにとって優先度の高い機能を実現するか、という点がポイントになるかと。

またその際に、内製化をすすめた良品計画の事例と、内製化せずに対応したリクルートがあるのですが、どちらからも重要なのは内製するかどうかではなく、「100%を求めることではなく、現場を信頼する態度」が重要と感じました。これは一種の「へっちゃらだい！戦略」ですね。その意味で、技術的な正確さを突き詰めるよりも、ユーザーの要求を突き詰めていける態度が、ユーザーと開発者の双方にとって今後重要になる、といえるのではないかと。

ということで、引き続きメモです。

（本間さんのセッションについてはメモできませんでしたが、これも面白いセッションでした。本間さんは、「自分のセッションは時間調整ですから」とおっしゃっていましたが、午後の事例セッションに入る前に本間さんのセッションがあったので、会場の和気藹々度が 50ポイントほど上昇して、後のセッションにつながりました）

スピードがすべてを駆逐する

良品計画のシステム内製化事例

l 良品計画

Ø 15,000アイテム/年

Ø 売り上げ 1454億円

Ø 国内店舗：直営200店、フランチャイズ150店

Ø そのほか、ファミリーマート、キヨスク、海外（100店舗）など。

Ø ネット販売 74億円

Ø 従業員 4300名。

l SPA業態。期間を担うMD(マーチャンダイジング)

l IT戦略

Ø ①「自社の競争力を高める」のか否か

Ø ② すべてに100%を求めない

Ø リスクヘッジではなく、リスクテイク

Ø 本質的な要件定義力を持つ

l システム構造

Ø 「早く柔軟に」開発・変更できる構造

² マスタ類はすべて内製化（管理系システム）

² 実行系システム（POS、物流、勘定システム）などは、仕様が明確になりやすいので外部委託。

² 管理系システムから、マスタデータを実行系システムに配信し、管理系システムは実行系システムから生データを収集する（1時間に1度程度）。

l 内製化の方法

Ø ユニケージ開発手法

² 自社で完結できるシンプルな開発方法

² ミドルウェア、DBシステムは使わない（難・高・灰）

Ø 技術面：コマンド言語だけでシステムを作成

Ø マネジメント面：利用部門は検証力が、開発部門には業務知識が必要

l スピードがすべてを駆逐する

Ø スピード開発の仕組み

² 最初から完璧を狙わず、7割のレベルで早く試作する

² 実際に使って手直しを行い完成度を高める

Ø 「週1回、3回コース」

² 週1回程度、利用部門へモックを提供し、フィードバックを得ながら設計を進めていく

Ø ドキュメントは必要最小限

² ①ユーザー部門のためであること、②ユーザー部門が見て・使えること、③会社組織・業務プロセスは常に変化する前提。

² １部上場企業であるが、監査会社にも上記を伝えており、コンプライアンス的にも問題はない。

l 成果と今後の課題

Ø 「業務改善」への意識

Ø コミュニケーションロスが減った

Ø システム開発部員の育成

Ø システムコストの削減（20億円à12億円。売上高比率 1.8% à 0.9%）

l ちょっとした機能改善を、継続的に

Ø 1日の天気予報 à 1週間に

Ø 今日の誕生花の表示

Ø 店舗から、1週間に500件くらいの改善提案。

l 内製化にしたシステムの稼働状況

Ø ハード60台

Ø 画面数160画面

Ø ステップ数 86600行

Ø システム規模は1/50、パフォーマンスは20倍アップ。

è ここから Universal Shell Programming Lab の當仲さん

l ユニケージ開発手法とは？

Ø パッケージに対して、ユニケージはスクラッチ開発の高効率化手法

Ø Unix Uniq Unify

Ø 「安く、早く、柔らかく」がキーワード

l Shellによるプログラミング

Ø Shell を拡張するためのDSLを内在

Ø 20行程度のCプログラミングで、新しいコマンド(keta, comma)などを用意

Ø Shell で、パイプを使いながら処理をおこなう

Ø 開発環境は vi と cp（コピー）

² 人の書いたコードを使用するときは、written by を自分の名前に書き換える。

² コピー奨励。どうせたいしたコードでないのだから、original の written by は不要。

l ユーザー一体型開発

Ø 業務とシステムは表裏一体

Ø システムは業務にある。

l 非分業のススメ

l ワンプログラム・ワンフロー

Ø 依存関係の排除

Ø 再利用はしない。オブジェクト指向と対極

l 作る側、売る側、使う側

Ø 以前は：（使う側、作る側）、売る側

Ø 最近は：使う側、（売る側、作る側）

Ø 「売る側」、による使う側と作る側の分断。これを解決しないと。

事例：ユーザー企業責任で25歳とをアジャイル開発

リクルート

l 内製化せずに、スケジュールを守って、システムを提供する。

Ø アジャイルでどのように実践したか

l システム部門の組織

Ø 各事業担当と、インフラ担当部門

l Webメディア・サービス

Ø 従来型：新たな情報誌カテゴリを世の中に提案。スタートダッシュ重要。

Ø Webでは：変化が激しく、実際に出してみるまでわからない

l 背景課題

Ø Webでは何が当たるかわからない

Ø そのため、要件を詰め込んでしまう。

Ø そのため、検討時間、開発時間が長期化

Ø そのため、リリースが長期化

Ø 大規模化するために、追加リリースも1年先、といった長期化が引き起こされる

Ø 追加リリースでも要件をどんどん詰め込んでしまう

Ø 負のスパイラル

l ~~開発方法論やアーキテクチャの変革によりスピードアップ~~

è サービス開発の「考え方」「やり方」を変える。

l 新しいやり方：SWAT手法(Speedy Willing Alliance Team)

Ø ①スモールスタート (vs 100%の完成度でリリース)

Ø ②ビジネスのコアに絞り込んで検討　（vs もれなく検討）

Ø ③期間と投資上限をあらかじめ設定 (vs やりたいことを積み上げて予算をとる)

Ø ④小規模チームへの権限委譲(vs ステークホルダーとの調整、確認)

Ø ⑤独自のシステム開発手法（vs ウォーターフォール）

l ビジネス・サービスのライフサイクルイメージと使い分け

Ø ①スタートUP：加速 ß SWAT はここで使う

Ø ②成長・拡大

Ø ③成熟

Ø ④衰退

l SWAT方法論自体も漸進進化

l SWATの特徴

Ø 従来型よりもスピードが速い：1500FPで要件定義からリリースまで約3ヶ月

Ø タイムボックス開発

² 仕様の確定はLateBindingな感じ

² Water Fall よりもリスク（投機リスク）が高いが、リスクを許容することで、投資リターンを最適化する。

Ø 1週間単位のスケジューリング、ユーザーを巻き込んだ開発

² ユーザー巻き込みによる後工程（検証、教育）コストを低減

² 仕様の伝達、決定を現場で実施し、オーバーヘッドを減らす。

² ユーザーとの毎週の要件確認会では、実装者が発表をおこなう。ダイレクトコミュニケーション。

² 要件確認会で10分以上議論し、結論が出来ない場合はエスカレーション。

² 事業側、開発側とも、“８０％ルール（仮決め）”、により意思決定をすばやくおこなう。

l 情報を100%もとめず、80%の情報が集まった時点で意思決定

l 80%の完成度で、次の手を判断する。

l ケース

Ø BAD作業中に難易度が高いことが判明 à なんとか実装してよ、の声でなんとか実装 à 次回からは作業見積もりを厳格に出さなければ à 保守的な見積もりと、見積もりの作業の増加

Ø GOOD　作業中に難易度が高いことが判明 à では別の方法でもいいので同じ目的を達成できるように検討しましょう。

l ケース

Ø BAD作業中に機能の絞込みが必要なことが判明 à機能一覧と見積もりを出してください。優先度つけます à 詳細な作業見積もりを作成

Ø GOOD　作業中に機能の絞込みが必要なことが判明 à 大くくりで優先度を指定します。また期日リリースに間に合わせるために落としたほうが良いおすすめの機能提案があれば教えてください。

² SWATでは、要件確認会で、つねに現場メンバーによって作業のスコープ変更に関する判断をおこなうことが求められる。

l SWAT：

Ø 開発をおこないながら、徐々に仕様を決定して行き、「決まったことの量」を増やすことで、先の状況の予測精度を高める。（対極が「決まったことの量」が増えていかないバーンアウトなプロジェクト）

Ø バーンアウトしないために

² ダンドリ重要

² 80%ルール重要

² 人の意識を変えていくこと重要

Ø いずれにせよ「ユーザー企業」の責任、態度が重要。

事例：スピードがすべてを駆逐する Part 2

良品計画、USP

l Q＆A

Ø なぜShell?

² プログラミング言語は難しすぎる。メンバー全員が使用できるのはShell。

² ライブラリ蓄積で、Shell であれば、多くの人が便利に開発できる

Ø 画面は？

² CGIで、Shell で実行した結果をHTMLにしている

Ø 昔は？

² 開発を開始した93年当初はMotif を画面に使っていた

Ø データのやり取りは？

² 基幹DBやPOSデータから、データを取り込み、テキストファイルにしたり、そのままShellでパイプで処理する、という感じ

Ø 良品計画：内製化を進めたのは？

² システム化で時間がかかると、「熱いうちに鉄がうてない」。内製化でタイムリーに。Shellを使うことで、自由度を確保。

² UPSさんとの取引に関しては、担当者が納得して責任を取れるのであればOK、と上司から許可をもらえた。最初は Shellでやる、ということに怖さもあった。

Ø 松田設計って？

² 大阪の松田さん。薬局のボランタリーチェーン(3000点くらいの規模)のオーナー

² 「スピードが速いという価値」と、「情報の価値」は別。商売人は自分の手で、自分が必要とする情報を入手できるようにならなければいけない。

² 上記の思想の元、COBOLとかでなく、バッチで処理をする、データは捨てない（ディスクが増えてもOK）、といった実践。

² 中小企業向けのIT塾を開催。

Ø 内製化と、アウトソーシング

² 重要なのは、何を内製して、何をアウトソースするか、の切り分けをしっかりしておくこと。

² 内製のチームは、業務とシステムの連携、システムの継続的な改善を提供しなければいけない（ルーチンワークで担当していると、業務もシステムもわかっていない人間になってしまう）

Ø ユニケージ手法の展開について

² 拡げるための、教育用の資料などを整備中

² 実績を重ねていく必要。

チームビルディング

永和システム岡島さん

l 「カマスの実験」

Ø カマスは獰猛な魚

Ø えさの前に、ガラスの壁を作っておくと、最初は壁に突っ込む。そのうち学習し、えさを追わなくなる。

Ø ガラスの壁を取り除いても、えさに飛び掛らなくなる。

Ø やる気重要。「ガラスの壁」のメタファ。

l 「開発チーム」と「マネージャ」の緊張関係

Ø 透明の壁をかんじますね、、、、

l アジャイル開発チームに対する誤解

Ø 個人で好き勝手

Ø 組織の成功を軽視している

Ø コードを書くことがすべて

l 開発チームの成功モデル（3つの視点）

Ø 個人的な成功：生活の質の向上、挑戦、やりがい

Ø 技術的な成功：技術的卓越、開発の仕組み

Ø 組織的な成功：無駄の削減、ROI向上

è 個人的なせいこうなくして、組織の成功はない

l マネージャに対する誤解

Ø 組織のルールでがんじがらめ

Ø 人間を軽視している

Ø 売り上げと利益がすべて

l マネージャの成功モデル：２つの価値のバランス

Ø 仕事の論理（生産性）：プロセス、道具

Ø 労働の力学（生き生き）：人間関係、生活基盤、自己実現

l 本質的に開発チームも、マネージャも同じゴールを共有

Ø 仕事の論理 ß 組織的成功、技術的成功

Ø 労働の力学 ß 個人的な成功

l 緊張緩和に向けて

Ø お互いに、成功モデルの本質は同じであることを知り、歩み寄ること重要。

l どうして歩み寄れないのか？ à じつは「透明の壁」は相互に築いているのでは？

Ø 実は、開発者はマネージャに依存している。

Ø 実は、マネージャは開発者に権限を渡したくない。

l 開発チームとマネージャのWinWin

Ø 開発チームの「主体性の発揮」

Ø マネージャーからの「権限・責任」の委譲

l 「グループ」は、各メンバーがそれぞれの役割を果たして共同作業をできるようになって「チーム」になる。

l 「チームは最終状態ではなくプロセスである」

l 「カマスの実験」の続き

Ø 弱ったカマスは、えさを食べない。どうやっても。

Ø そんなときは、新しいカマス、を入れれば、みんなえさを食べるようになる。

Ø チームが停滞したときでも、新しい仲間を巻き込めば、状況を打破できる。

Agile Japan 2009 セッションメモ(1)：午前の部

2009-04-23T09:30:00Z

午前はリーン開発の Mary Poppendiek さんのセッションと、元トヨタの黒岩さんのセッション。

Mary のセッションは、平鍋さんが超訳の逐次通訳をされました。とても斬新なスタイル！エッセンスとしては、マネジメント（リーダー）の意識変化によって、ソフトウェア開発における成果物をよりよくできる、といったメッセージを受け取りました。

そして、黒岩さんのセッションは、、、、すいません面白いところのほとんどはメモできていません。てか、ライブで聴いてこそのセッションでした！エッセンスとしては、自分で考えて、日々改善を進めていくことが重要で、リーダーはそれが可能なメンバーを育成することが重要である、と（それができない人は給料泥棒）いったメッセージを受け取りました。

ということで、以下は走り書きのメモです。

キーノート(1)

ソフトウェア開発における新しいリーダーシップ

Mary Poppendieck with 平鍋さん

l 1900―Taylor の仮説と効率化

Ø ただ1つの「最高の方法」をみつけて実践する

l 1920―Charles Allen / Industrial Training : OJT

Ø Train to Trainer.

Ø 88,000 people trained in 2 years

l 1940―戦時中。内地に残された女性が中心の Inexperienced Workforce

Ø Allen のアプローチにより、「現場の上司」の教育を実施

Ø Training Within Industry(TWI)：驚異的な生産性をあげる。日本では戦後復興で活躍

Ø Job Instruction / Job Method / Job Relations 等のドキュメント

Ø TWIの前提：良い監督者の５つのスキル

² 仕事の知識、責任と役割の知識、教えるスキル、改善のスキル、監督のスキル

l 1950―Toyota 生産方式(大野耐一)

Ø 「Standard Work」

² Standard should br changed constantly

² Should not create away from Genba

l 1980― Edward Deming：「深遠な知識」のシステム

Ø システムについての知識

Ø 変動についての知識：一般原因の変動と、特殊要因による変動。一般原因の変動はシステム改善へ。

Ø 知識の理論

Ø 心理学

l 何を作っているの？（イタリアの石切り場で3人に聞いた）

Ø 石を切り出しています。

Ø 生計を立てています。

Ø 聖堂を作っています。

l リトマス試験紙：作業の仕事がうまくいかないとき

Ø 文句を言う

Ø 無視をする

Ø 自分で治す

l リーダーシップの4象限：官僚的リーダー、作業管理者、ファシリテーター、Learning Organization の創り手

Ø Toyota Leadership は「Leaning Organization の創り手」の象限に近い

² 「一緒について着て、そして一緒に考えよう」

² ３つの役割

l 先生としての役割

l 一人ひとりが主体的に問題解決し、仕事を改善するように指導

l 一人ひとりの仕事が「顧客の価値」と「会社の繁栄」両方に沿うようにうながす

l ソフトウェア開発におけるイーダーシップ

Ø Champion(3MにおけるChief Engineerの役職)

² Marketing Leader

² Technical Leader

Ø Functional Leader (部署のリーダー、育成/キャリア)

Ø 上記の2つが重要。

l TPS：Toyota Production System / Thinking People System

l Change the System ：システムを変える

キーノート(2)

ソフト開発に生かすトヨタ生産方式：ものづくり、人づくり

黒岩恵

l 世界初のプロセッサ開発は、日本人の嶋正利。4004プロセッサ。インテルが買収し、その後デファクトへ

Ø http://itpro.nikkeibp.co.jp/watcher/shima/index.html

l 技術はオープンにすべき

Ø 一人が考えたアイディアなんてたかが知れている

Ø オープンにすれば改善が進む

Ø で、コンサルタントでお金をしっかり取ればよい

l 製造業における日米間の経営手法の導入

Ø 日本的経営を学び90年代に復活した米国企業も今や品詞状態

Ø 80年代日本に学んだUSの方法論(TOCやAgile.Lean)が日本に戻ってくる

l 19C：クラフトマン、20C前半：マス大量生産、20C後半：リーン

l Toyota 1984にUSへの進出

Ø GMをレイオフされた労働者を多能工化

² ソフトウェア開発はまさに細分化されている。多能工化が必要。

Ø テクノロジーや、メソドロジーは重要ではない。人間性を尊重。

l USのソフト業界は日本の「ものづくり」に学び、日本のIT業界はUSから学ぶ

l 今日のメッセージ

Ø ルールや、”Know how” よりも “How Why” を

Ø 人的能力/人間性尊重：課題解決、問題発見改善・改革力、惻隠の情、人倫5条の精神。

Ø ノウハウを知るレベルから、「実践せきるレベル」へ。

Ø 「改善」し続ける人間集団を創り上げる。

l 徹底した無駄の排除

Ø ドキュメント：無駄。コード/オブジェクトコードが重要。

Ø 作業

² ①無駄 50%以上

² ②付加価値はないが必要な作業 45-30%

² ③付加価値のある正味作業 5-20%

l コラボレーション、コミュニケーション

Ø A3一枚でまとめる（5億の決済も、50億の決済も、トヨタでは1枚で済ませる）

l 工場の現場：徹底的にコンピューターを使用しなかった

Ø コンピューターは見えないので改善できない

Ø エアーシューターによる情報伝達、など現場で対応可能な手法で改善を実施する

Agile Japan 2009、非常に面白かったです！

2009-04-23T09:08:00Z

昨日、Agile Japan 2009 に参加してきました。

今回は、ソフト開発未来会議の関係者、ということで特別参加させていただきました！（ありがとうございます！）

参加者を巻き込んだ和気あいあいとしたイベントで、平鍋さんや前田さん、スピーカーの黒岩さん、本間さんなど、主催側の「人間味」がよく現れたとてもよいイベントでした！個人的には、Object Day や Developer Summit の立ち上げごろの雰囲気を感じたイベントで、今後も是非継続的に開催してほしいな－、と強く感じたイベントでした。

実はこのイベントですが、テーマが「Agile」ということで、いまさら感を感じながらの参加だったのですが、実際の内容としては「Agile」にとらわれず、広く「日本のソフトウェア開発者」にフォーカスをあて、ユーザー企業と開発者の関係、あるいは開発者自身（と開発チームのリーダー）の成長をテーマにした楽しい1日でした。

特に、ユーザー企業と開発者の関係に関しては、ユーザー企業の担当者と開発者の信頼関係が重要である点、そこにおいて多層的な発注体制はリスク要因となる点などが、多くのスピーカーによって語られていました。端的には、ユーザーと開発者の距離を縮めることで、ユーザーの便益に最適化された開発体制を作ることが重要である、ということかと。

背景にはソフト開発におけるいくつかのリスクのうち、①技術的リスク、と②要件的リスク、を考えた場合に、①の技術的リスクが以前に比べ小さくなったがゆえに、②の要件的リスクにより向かい合う必要がある、というようなコンテキストがあるのでは、と思いました。多層的な発注体制というのは、商社的なリスクヘッジの機能としてはうまく機能するので、要件が決まっていて、①の技術リスクに着目する必要がある場合にはユーザーのメリットも大きいのでしょうが、①の技術リスクが相対的に低くなり、②の要件的リスクに最適化したソフトウェア開発を行う必要がある場合は、ユーザーと開発者の直結型の開発スタイルが有効、という感じ。

ということで、セッションメモを次から公開します！

追記：公開したメモ

午前の部：http://blogs.msdn.com/toiwade/archive/2009/04/23/agile-japan-2009-1.aspx

午後の部：http://blogs.msdn.com/toiwade/archive/2009/04/23/agile-japan-2.aspx

ソフト開発未来会議に新しい記事：開発現場の要請で生まれたアーキテクトチーム

2009-04-14T07:28:00Z

ソフト開発未来会議の「開発者のためのケーススタディ」に新しい記事が掲載されました。

http://developerscafe.jp/future/casestudy/vol02_necsoft.html

今回は、NECソフトのアーキテクトチームのインタビュー記事です。

NECソフトでは、顧客の業種にあわせた縦軸と、テーマ別の横軸の2つの組み合わせによるマトリクス型の組織構造をとられています（マトリクス型組織にかんしては、たとえばこのあたりを参照ください）。今回取材させていただいたチームは、このうちの横軸の分類によって位置づけられているチームで、技術的な専門知識を提供することを一つのミッションとされているチームです。

たとえば、ある業界に属する顧客Aのプロジェクトが立ち上がると、業種別の縦軸側で分類されるチームメンバーと、横軸側で分類されるチームメンバーがプロジェクトチームとして活動するのですが、その中で技術的な観点からシステムの設計や、技術検証に携わる、といったイメージでしょうか？

（マイクロソフトも顧客軸で分類されたチームと、製品/技術別に分類されたチームの組み合わせで動くので、その辺はよく似ているなぁ、と思いました）

今回の記事もとてもおもしろい記事になっていますので、ぜひお読みいただければ、とおもいます。

http://developerscafe.jp/future/casestudy/vol02_necsoft.html

では！

デザイナー×開発者で生まれるRIAの理想形 @ Ascii.jp

2009-03-11T05:24:00Z

Ascii 主催で行われた Web 開発のセミナーレポートが掲載されました。

http://ascii.jp/elem/000/000/217/217460/

Ascii さんといえば、昨年は Visual Studio Robot の企画で Visual Studio 2008 と Silverlight を盛り上げていただき、あわせてセミナーも開催させていただきましたが、今回はより実践的な内容ということで、実際にその場で Silverlight のアプリケーション開発を体験いただくという企画、、、、

ゲストとして女優の松木里菜さんに参加いただくなど、楽しい企画となりました。

楽しさあふれるレポートをぜひお読みください！

http://ascii.jp/elem/000/000/217/217460/

「『くだらない』『恥ずかしい』を無視して自分の手を動かせ！」＠ソフト開発未来会議

2009-03-10T13:04:00Z

ソフト開発未来会議にて、新規記事が公開されました！

『くだらない』『恥ずかしい』を無視して自分の手を動かせ！

このインタビューではインフォテリアの平野様と、アリエル・ネットワークの小松様に「開発者への提言」として、日本のソフトウェアビジネス、エンジニアとしてのこれからについて語っていただいています。

とても熱いメッセージのこもった記事ですのでぜひごらんいただければ幸いです。

それでは！

P.S.

「開発者のためのケーススタディ」の第２回、３回についても徐々に進んでいますので、ご期待ください！

Something about Development Technology :-)

商用サービスが始まる前に Windows Azure を楽しもう！ ～ Cloud Bootstrap × Cloud Bootstrap ～

VSS 大好き！なあなたにも ～ Team Foundation Server ”簡易版”

Tech・Ed Bof 会場の盛り上がりを再現 ～ "Web Form" vs "MVC"

絵で見て理解する ASP.NET シリーズ：Routing の仕組み

Windows Mobile のアプリケーション開発コンテスト、"Race To Market" 始まる。

Tech・Ed の季節がやってきました。今年は8月26日から！

直感マインドマップ by アークウェイ がリリース。

Windows Live Writer からの投稿！

Visual Studio 2010 英語版 Beta 1 を MSDN サブスクライバダウンロードで公開しました！

Agile Japan セッションメモ(2)：午後の部

Agile Japan 2009 セッションメモ(1)：午前の部

Agile Japan 2009、非常に面白かったです！

ソフト開発未来会議に新しい記事：開発現場の要請で生まれたアーキテクトチーム

デザイナー×開発者で生まれるRIAの理想形 @ Ascii.jp

「『くだらない』『恥ずかしい』を無視して自分の手を動かせ！」＠ソフト開発未来会議

商用サービスが始まる前に Windows Azure を楽しもう！～ Cloud Bootstrap × Cloud Bootstrap ～

VSS 大好き！なあなたにも～ Team Foundation Server ”簡易版”

Tech・Ed Bof 会場の盛り上がりを再現～ "Web Form" vs "MVC"

直感マインドマップ by アークウェイがリリース。