« 2013年12月 | トップページ | 2014年2月 »

2014年1月

2014/01/29

ハイブリッドアジャイル開発・変形WF型開発のプロセスパターン

以下の記事にインスピレーションを受けて、ハイブリッドアジャイル開発・変形WF型開発のプロセスパターンを洗練させてみた。
ラフなメモ書き。

【元ネタ】
サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ

ウォーターフォール開発とアジャイルの本質 - プロマネブログ

UMTP Japan - 第9回UMTPモデリング技術ワークショップ 議論詳細

【概要】

【1】ハイブリッド・アジャイル開発は、WF型開発とアジャイル開発を組み合わせた開発プロセス。
和風ブレンド(!)の変形アジャイル型開発と言っていい。

ハイブリッド・アジャイル開発で最も使われている開発プロセスは、「ウォーター・スクラム・フォール」。
要件定義、システムテスト、リリースというV字モデルの上流部分はWF型開発として残し、設計・開発・テスト工程というV字モデルの下流部分はAgile開発を取り入れる手法。

ハイブリッドアジャイルの実践」の本が有名。

IMPACT MAPPING」にも、「ウォーター・スクラム・フォール」の用語が出てくる。
(ただし、「IMPACT MAPPING」では、要件定義をウォーターフォール型開発でしか運用できない事象を問題として、解決策を提示している)

なぜ、ハイブリッド・アジャイル開発をわざわざ作って、運用したいのか?
その理由は、WF型開発にもアジャイル開発の利点を取り入れたい動機があるから。

自社では、標準プロセスとしてWF型開発がガッチリと決められており、内部統制やシステム監査とも絡んでいるために、従来のプロセスを抜本的に変えることは難しい現状がある。
でも、「チケット駆動開発」の適用について考える|コラム「ITよもやま話」|特集│株式会社JSOLにも書かれているが、アジャイル開発の利点である俊敏さ、ツール連携による自動化などの利点を取り入れたいのだ。

つまり、自社独自のWF型開発にAgileの要素をブレンドした変形Agile型開発(純粋なAgile開発ではないので、Agile型、Agile風味とわざと呼んでいる)をカスタマイズしているわけだ。

【2】ハイブリッド・アジャイル開発にはいくつかのパターンがある。
サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログにインスピレーションを受けて、自分が今までに経験してきたプロセスをまとめてみた。

(1)ウォーター・スクラム・フォール

 ハイブリッド・アジャイル開発の中で、もっともよく使われているプロセス。
 「ハイブリッドアジャイルの実践」の元ネタとなる記事が以前から掲載されていた。

グラス片手にアジャイル開発 第1回 ― 実践的アジャイル開発とは (1/5):CodeZine

グラス片手にアジャイル開発 第2回 - アジャイルの主な実践手法とその取捨選択 (1/3):CodeZine

グラス片手にアジャイル開発 第3回 - アジャイル開発における計画と運営サイクル (1/6):CodeZine

グラス片手にアジャイル開発 第4回 - ハイブリッドアジャイルの実践法 (1/2):CodeZine

グラス片手にアジャイル開発 第5回(前編) - イテレーション単位のアクティビティ (1/3):CodeZine

 ウォーター・スクラム・フォールの利点は、要件定義で開発スコープをガッチリ固めることができれば、製造工程に関わる作業をAgile風味の開発スタイルで実施することにより、スピーディに開発できることだろう。
 やはり、一つの機能でもまず画面で確認できるようになれば、設計者も開発者もイメージがわきやすいし、フィードバックを生かして、次の機能の品質を高めることもできる。
 しかし、本番リリースは1回しかないので、Agile開発の最大の強みである「頻繁にリリースしながら品質や機能をVerUpしていく」戦略は取れない。

(2)リーン・WF

 ウォーター・スクラム・フォールとは逆に、要件定義工程をプロダクトバックログとして要件(ストーリー)を優先順位づけした後、WF型開発で順次リリースしていく開発プロセス。
 適用場面は、変更の多い小規模案件だろう。

 特に、業務システムの細かな運用保守でよく使われるだろう。
 なぜなら、1~5MDくらいの小さな保守案件では、機能改善や障害修正の重要度や難易度を設計者が十分に調査した後、リリース計画を作ると、それがプロダクトバックログのようになっているから。
 普通は、定期的にプロダクトバックログを棚卸しして、優先順位やリリース時期を修正している。
 もちろん、突発的に発生した本番障害があれば、他の要件をそっちのけで、最優先で暫定対応しなくてはならないから、頻繁に変わりやすい。

 リーンWF型開発をやっているなら、完全にAgile開発を運用してしまえばいいと思うだろうが、内部統制やシステム監査で承認された自社独自のWF型開発を見直すのは、調整にとても手間がかかるので、できない状況があるのだ。
 その意味では、割と現実的なカスタマイズされたアジャイル型開発だろう。

(3)コデザイン・WF(協調設計型WF)

 WF型開発のチームとAgile開発のチームが並行開発しながら、協調して開発するプロセス。
 適用場面は、ハードウェアチーム(WF)とソフトウェアチーム(Agile)が成果物を提供・共有しながら、開発する組み込み製品開発が多いだろう。
 
 ハードウェアチームは、設計して金型から作り、部品を組み立てながら、ソフトウェアを流し込んで、少しずつ動作させていく。
 その時に、ソフトウェアチームは先回りして、必要なソフトウェア部品を作っておき、ハードウェアチームに提供して、動作不備があればフィードバックを受けて修正していく流れになるだろう。

 逆に、業務システム開発ならば、インフラチームがWF型開発風に基盤設計→基盤構築→基盤テストを実施するときに、ソフトウェアチームのスプリント終了時に基盤の情報を連携するパターンもあるだろう。
 このパターンも、割と現実的によくある。

(4)アダプタブル・WF

 @sakaba37さんが提唱している限定的なAgile風味のWF型開発。
 
 WF型開発の各工程の管理は標準プロセス通りに行うが、どうしても管理しづらい作業はある。
 課題管理や障害管理のように、突発的に発生して、それらを取りまとめてもすぐに変更が発生してしまうために、従来型の手法では管理しづらいのだ。
 その場面では、標準プロセスを適用しにくい作業に対して、チケット駆動開発を取り入れて、アジャイルの効果を出す。
 これが、補完型チケット駆動開発と呼ばれるスタイル。

 補完型チケット駆動開発を運用した事例が、「チケット駆動開発」の適用について考える|コラム「ITよもやま話」|特集│株式会社JSOLに相当する。

【3】WF型開発も、変形されたパターンがいくつかある。

(1)パラレルWF

 WF型開発の工程のうち、V字型モデルの下流部分(設計→開発→テスト)を分割して並行に走らせる開発プロセス。
 大規模案件で一括請負の場合、サブシステム単位にチームが分かれ、チーム単位にWF型開発を運用する事例に相当するだろう。
 このパターンでは、製造工程を並行開発できる分、納期を短縮できそうに見えるが、実際は、結合テストがビッグバンテストになってしまうので、普通は破綻しやすい。

 大規模な受託案件は大抵、このパターンに当てはまり、本番リリースできても、たくさんの障害修正と改善要望に追われやすい。
 典型的なデスマーチプロジェクトになりやすいと思う。

(2)五月雨式WF(インクリメンタル・漸進型)

 WF型開発でやる大規模案件だとしても、分割納品が可能な場合、機能単位に分割して順次リリースしていく開発プロセス。
 いわゆる段階リリースとも呼ばれる。

 Agile開発に割と近いが、Agile開発では工程という明確な作業単位がないのに対し、五月雨式WFでは、工程が明確に意識され、工程ごとに役割を持つ人がいるのが違う。
 
 経験のあるプロマネならば、大規模な新規開発案件は一発リリースだとリスクが大きいので、最初は基本的機能の部分稼働で納期を間に合わせて、その後、段階的に機能追加しては順次リリースしていくように、プロジェクト計画を組み立てるだろう。
 そうでなければ、大規模案件をWF型開発でやる場合、リスクヘッジできないと思う。

(3)スパイラル(イテレーティブ・反復型)

 プロトタイプを作って、少しずつ作りながら、成果物のスコープを広げていく開発プロセス。
 リリースされる成果物は、動かないプロトタイプでもよい点がAgile開発とは違う。

 割と昔から提唱されていた、改良されたWF型開発。
 RUPがこのパターンに相当する。
 このやり方を採用できる場合、リスクの大小によって、早めに作る部分と後回しする部分に分けておくことができる。
 リスクが高いものを先に試して、そのノウハウを生かして、次のイテレーションでWF型開発で作りこむことができる。
 XPで言うアーキテクチャスパイクをスパイラル開発でもやっている。

 ただし、このパターンを成功させるには、開発のリスクをきちんと把握してプロジェクト計画に反映して、予実管理していくのが重要になる。
 そうでなければ、いつまで経っても、肝心の成果物の品質が向上しない。
 動かない成果物を作っても無意味。

【4】ハイブリッドアジャイル開発や変形WF型開発のように、WF型開発やAgile開発をカスタマイズして変形するプロセスパターンは、日本のSIならほとんど経験しているのではないだろうか。
 そして、それぞれのプロセスパターンの特徴や利点、弱点、適用状況を十分に把握できているだろう。

 単純なWF型開発では、大規模案件ほど失敗が怖い。
 だからと言って、自社独自の標準プロセスを修正するのはできない。
 そこで、プロジェクトを成功させるために、標準のWF型開発をカスタマイズしてハイブリッドアジャイル開発で作業する。
 
 その動機や手法は理解できるし、いいだろう。
 でも、何となく腑に落ちないのはなぜか?
 その理由は、WF型開発を実践していると標榜しながら、裏プロセスという表面に出てこないプロセスを故意に作っているからだろう。
 裏プロセスは表面に出さないからこそ、従来のWF型開発と同じであるかのように、システム監査も通る。
 しかし、裏プロセスを表面に出さなければ、そこで得られた知見をプロセス改善として使うことがやりにくい。

 その辺りの違和感については、下記の記事が詳しい。

「現状のソフトウェア開発は間違っていないか?」(プロセス編) - @IT自分戦略研究所

裏プロセスは並行プロセス: プログラマの思索

 いろいろ考えてみる。

| | コメント (0)

2014/01/26

消費税の6つの落とし穴

日経コンピュータ2014年1月9日号の記事をメモ。

【参考】
日経コンピュータ2014.01.09|HATのブログ

【1】2014年4月から消費税率が5%から8%に上がる。
企業の社内システムも3月末までに、消費税対応を終わらせる必要がある。
しかし、消費税対応には6つの落とし穴がある、という記事。

普通は、税率マスタを別テーブルとして保持しておき、5→8へデータ更新するだけで良いはず。
でも、1997年に消費税率が3→5%へ上がった時とは違う状況がある。

以下は、6つの問題の内容を記事から抜粋して、感想を書いてみた。

【2】社内調整に想定外の時間がかかる

小売流通・アパレルなどの消費者に近い業界では、価格表示は、税込の総額表示にするか、外税表示にするか、で売れ行きが大きく変わる。

記事の例では、税込98円で販売していたとき、本体価格は端数切捨てなら94円になる。
(いわゆる税はがし)
すると、94円に8%の消費税を加えると、101円になり、100円を上回ってしまう。

政府は、消費税率は適正に転嫁すべき、と指示を出しているからには、その方針に従って価格転嫁するか、利益を下げてでも元の値段で売るか、システム部門だけでは決められない。

例えば、100円という価格を維持するために、肝心の商品の質や量を下げて、原価を下げ、利益を確保する戦略もあるだろう。
実際、食品・食材・洗剤などの生活必需品は、値段は変わらなくても、商品やボトルの容量が減ってくるかもしれない。

システム修正としては、販売期間単位に商品の価格を保持する価格マスタにも影響を受けるため、販売部門や製造部門と1つずつ調整せざるを得ないだろう。

4月以降、100円ショップでは、どう販売していくのか、見てみたい。

【3】Excelマクロにも税率計算が潜む

販売や会計システムのように、ERPなどのパッケージ化されたシステムでは、消費税率の変更の影響調査はまだやりやすい。

問題なのは、財務や総務などの担当者がExcelマクロで消費税率を計算して作成したデータを、ITシステムに流し込んでいる場合などだ。
つまり、情報システム部門が管理していない場所で、担当者がシステム外で作ったデータには、消費税率の変更まで考慮が行き届いていない。
すると、社内の全ての部門の業務フローをシステムだけでなく運用の観点からも、再調査する工数が発生する。

【4】ERPもマスタ変更だけでは済まない

ERPを納入しているSIならば、税率マスタの変更だけで対応できます、と言うだろうが、それだけでは収まらない。
ERPの標準機能としては問題ないかもしれない。

しかし、普通のERPはその会社独自の追加機能というアドオンが必ずあり、その箇所が税率マスタを使っていないとなれば、修正工数が発生する。
特に、バッチ処理はカスタマイズして作る場合が多いから、税率を固定値だけのヘッダファイルに書き込んでいたり、最悪な場合は、ハードコーディングしている時があるだろう。

すると、ソースのリコンパイルが発生し、機能がデグレしていないか、回帰テストの工数が更に発生してしまう。

【5】5%対応の経験は通用しない

内部統制(J-SOX)の法律順守によって、変わった点が二つある。
一つは、価格表示が外税表示から総額表示が義務付けられたこと。
価格表示のソース修正は、その企業の売り上げに直結するから、影響が大きい。

もう一つは、特に会計システムの変更作業が正しい手続きを踏んで行われたかどうか、システム監査・会計監査が適用されて、保守作業プロセスの監査が厳しくなったこと。
消費税率変更の仕様や設定手続に関する文書をきちんと残しておかないと、システム監査や会計監査で、不備や改ざんを指摘されるリスクがある。

最近の日本の製造業がバブル期以前のような発想豊かな製造活動ができない原因の一つは、内部統制が厳しくなり、会社の資産や労働時間を使って自由にアイデアをはぐくむことができなくなったからではないか、と個人的に思ったりする。

【6】SI契約は経過措置の可能性あり

ユーザ企業がITベンダと契約している案件では、普通は、3月まで税率5%だが4月以降は8%になる。
SaaSのような利用料金を支払うスタイルがそう。
つまり、期をまたぐと消費税率が変わるので、2013年度と2014年度をまたぐ案件の売上や原価の管理は注意が必要。

ただし、4月以降も税率5%のままでよい時もあるらしい。
すると、消費税の経過措置に関わる範囲を事前調査しておかないと、無駄に払い過ぎになってしまう。

例えば、工事進行基準を適用している案件が相当するらしい。
工事進行基準を適用しているSI案件は、普通は大規模案件だろうから、原価管理に一層の注意が必要になる。
そのほかにも色々あるらしいので、注意すべき。

【7】8%対応はしばらく続く

2015年4月には税率が10%に上がると推測されている。
つまり、直近2~3年は消費税対応に振り回される。
経過措置など、消費税対応の法律の内容は十分に調査しておくべき。

また、10%適用になると、消費税の金額も増えるため、請求書などの帳票の金額の桁あふれが発生するバグが出る可能性もある。
業務システムで使われるすべての帳票の項目の桁数を洗い出し、消費税対応で影響があるか調査していくのは、とても工数がかかるだろう。
あるいは、消費税率が2桁に対応していないような税率マスタや価格マスタもあるかもしれない。
そうなれば、DBのテーブル変更をすることになり、より影響が大きくなってしまう。

【8】記事でちょっと面白かった内容は、自動販売機やコンビニ、ファミレスは4月1日の何時に消費税率が切り替わるのか、という疑問。

全国津々浦々にある自動販売機や24時間稼働のコンビニ、ファミレスがすべて消費税に対応するのは、直感的には大変そうだ。

記事によれば、自販機は日頃から売価変更が頻繁に起きるため、システムで一括変更できる仕掛けになっているので消費税対応は容易であるらしい。
また、コンビニやファミレスも、毎日の日次締め処理と同じ手順で一斉に切り替えられる、とのこと。

POSシステムは普通、システム日付以外に営業日という概念も持つ。
したがって、営業日の単位で切り替えるために、4月1日0時ではなく、例えば、深夜2~3時に一斉に切り替えるようになるらしい。
ゆえに、3月31日の23時59分に買い物して、レジに並んだら24時を過ぎてしまうと、消費税率が5%から8%に上がって、支払額が増えてしまうケースはないらしい。
でも、4月1日の2~3時にコンビニで買い物するときは、消費税率に注意した方がいいのかもしれない。

僕も、自販機の値段が3月31日と4月1日で変わっているか、確認してみたいと思う(笑)

| | コメント (0)

2014/01/25

アジャイル開発とWF型開発をハイブリッドにしたマネジメント・デザインパターン

アジャイル開発を日本風にアレンジしたプロセスをマネジメント・デザインパターンとして説明した記事があったのでメモ。

【参考】
ウォーターフォール開発とアジャイルの本質 - プロマネブログ

サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ

炎上プロジェクトの責任はプロマネが9割 - プロマネブログ

【1】WF型開発とアジャイル開発には、それぞれの特徴があり、適用の問題点がある。

WF型開発は、仕様変更に弱く、無駄なドキュメントが多い。
アジャイル開発は、変化に強く、スピード重視で開発できるが、従来のプロセス手法と発想を変えないといけないので、実現しづらい。

上記の記事によれば、各プロセスの特徴は、「WFが形式知の作成を行うことで、開発体制と開発工程を管理する手法」「(アジャイル開発は)フォーカス管理の最適化」。

つまり、WF型開発は、体制と工程を形式知として残すために、ドキュメントを重視し、厳密に管理しようとする。

アジャイル開発は、イテレーション単位に開発するために、全工程を一気通貫で開発するので、小さい機能を実装対象にする。
すなわち、各工程はとても小さいので、形式知に残さずとも暗黙知でもやれる、と。
すると、「暗黙知をもつメンバーを如何に活かすか、という観点が重視されるようになり、スクラムなど各種手法が生きてくるようになります。」と、上記の記事では言っている。

【2】上記の記事で面白いのは、アジャイル開発とWF型開発を日本風にアレンジしたプロセスをパターンとして分類しようと試みていること。

【2-1】ウォーターフォールベースのスクラム/ウォーター・スクラム・フォール

ハイブリッドアジャイルの実践」でも提唱されている手法。
要件定義などの上流工程はWF型開発、開発・テスト工程はアジャイル開発で分けて行う手法。

「スパイラルモデルに近く、SIerなどで導入しやすということで最近注目のデザインパターンです。」

確かに、日本のSIでアジャイル開発を実践する場合、ウォータースクラムフォールのパターンになる場合が多いだろう。
受託した開発案件が一括請負契約の場合、要件定義で開発スコープを顧客と握っておかないと、スコープクリープが発生してしまい、納期前に必ず破たんする危険が大きいから。
つまり、日本の契約スタイルでは、どうしても上流工程はWF型開発でやらざるを得ない。

【2-2】リーン開発のフォーカス管理を利用したウォーターフォール/リーン・ウォーターフォール

スクラムウォーターフォールとは逆に、上流工程をリーン開発、下流工程をイテレーション単位のWF型開発で行う手法。

「要求仕様をリーン開発と同様に分解、優先度付けを行い、優先度の高いものからWFで開発を行うことで柔軟性を高めたデザインパターンです。
開発部分を五月雨式WFなどと併用して更に速度を上げることもあります。」

SIの運用保守、保守案件では、工数が確定した委任契約になりやすいので、このパターンを使っている事例は多いのではないか。
なぜなら、予定している機能改良の作業だけでなく、突発的に発生する本番障害や問合せをやりくりするには、開発チームに作業指示を出す前に、やるべき作業をプロジェクトリーダーが優先順位づけしなければ、破たんしてしまうから。
プロジェクトリーダーが保守作業の内容を優先順位づけしておけば、開発チームはそれに従って作業を開始し、WFが開発のフローに沿って、設計書を書き、テストやレビューをきちんとやる、という流れになるだろう。

【2-3】複雑なシステムを分解/スクラム&ウォーターフォール

要件定義をきちんと行った後、設計・開発・テストの各工程内でスパイラルに開発する手法。

「最初の要件定義だけを行い、要件のウチ変更の多い部分と変更の少ない部分を分け、それぞれを平行して開発するデザインパターンです。」

適用場面としては、初めてのフレームワークの技術検証や性能要件の事前検証などを設計工程で早めに行ってリスクを事前に洗い出し、開発やテスト工程で、判明したリスクをつぶしていく手法。
一部の画面やUIを開発して、顧客に事前に評価してもらうプロトタイプ開発もあるだろう。

つまり、技術リスクが大きい案件では、このプロセスを使って、リスクを事前に洗い出して潰していく戦略を取る時が多いだろう。

【2-4】期間短縮を目指した改良型ウォーターフォール/パラレル・ウォーターフォール

「WFとアジャイルのハイブリッドではなく、WF単体の組み合わせです。
前回、五月雨式WFを説明いたしましたので、オマケで。
ベースはWFですが、中間の開発~テスト工程を分割可能な機能単位などに分解し、並列開発を行うデザインパターンです。
純WFよりも、開発工程をパラレルにした分だけ開発期間短縮を行えることがポイントです。」

いわゆるパラレル・WF、ないし、五月雨WF型開発。
大規模案件を担当したプロジェクトマネージャで、経験が深い人は、サブシステムに分割し、五月雨形式で開発する手法を採用する時が多い。
結合テストでビッグバンテストを実施したら、障害を収束できなくなると気付いているから。

【3】上記4つのパターンは、日本のSIではおそらくどれも経験しているだろう。
アジャイル開発をそのまま実践できる環境にないけれど、アジャイル開発の利点を生かしたい時に、WF型開発をカスタマイズして変形するパターンとして、とてもうまくまとまっている。

上記の記事のパターン集が優れている点は、日本のSIでも既にアジャイル開発に近いプロセスは経験しているよ、とよく言っている事例をパターンカタログとして分類し、そのパターンの本質に焦点を当てている点だ。

経験知をパターンで整理するだけでは、オリジナリティはない。
それらパターンについて、適用範囲やその構造、効果や課題を整理し、単独のWF型開発とアジャイル開発に対して何が異なるのか、を深く掘り下げて考察することが大切だ。
その「考察」こそが、本来の研究だ。

上記の記事はラフに書かれているけれども、筆者の経験の深さを感じられる部分がある。
ただ、もっと考察できる部分があると思うので、いろいろ考えてみる。

| | コメント (0)

2014/01/23

第6回品川Redmine勉強会をデブサミ2014の翌日に開催します #47redmine

昨年12月に「Redmine超入門」が出版されたことを記念して、第6回品川Redmine勉強会をデブサミ2014の翌日2/15(土)に開催します。
今回のテーマは、「Redmine超入門」と「エンタープライズ製品としてのRedmine」です。
奮ってご参加ください。

【開催内容】
第6回勉強会 - shinagawa.redmine

◆概要
shinagawa.redmine 関係者も執筆に関わった Redmine超入門 の発売を記念して第6回勉強会を開催します。
今回は初心者から使い慣れた人までRedmineの導入から応用例などを多数ご紹介します。

◆日時
2014/02/15(土) 13:00~

◆場所
東京都品川区大崎1-2-2 アートヴィレッジ大崎セントラルタワー

※会場はフューチャーアーキテクト株式会社様のご好意でご提供していただいています。

◆ハッシュタグ
#47redmine

協賛
今回の勉強会は株式会社 アジャイルウェア 様の後援で開催します。

◆申し込み
第6回shinagawa.redmine勉強会 - PARTAKE

第6回shinagawa.redmine勉強会 懇親会 (夜の部) - PARTAKE

【個人的な思い】
【1】「Redmine超入門」はスタッフが中心となって執筆されました。
内容は、Redmineの初心者から中/上級者向けまで幅広いです。
また、プロジェクトリーダーや開発者、テスト担当者の観点もあり、対象とする読者層も広いです。

私も、品川Redmine勉強会と関西のRxTStudyで講演したり、スタッフとしてお手伝いした経緯もあり、「Redmine超入門」が出版されたのはとてもうれしい出来事でした。

Twitter / edgvaly:ちょっと流行ってきたんかな? > Redmine超入門 (日経BPムック) 日経SYSTEMS @Amazon http://www.amazon.co.jp/dp/4822277089/ref=cm_sw_r_udp_awd_aW43sb1B3XQS9 …

【2】品川Redmine勉強会は2011年に発足して、丸3年で第6回を迎えます。
Redmine導入の目的は、当初はアジャイル開発への適用に注目されたと思います。
その間、Redmineは静かに、そして広く運用されていったように思います。
しかし、現在はむしろ、既存のWF型開発を補完するアダプタブルウォーターフォールの適用事例を聞く時が多いように思います。

その時によく聞く話は、開発者はすぐに馴染んでくれるのですが、マネージャから、Redmineは使いづらい、という話がよく出ます。
その理由は、彼らが必要とする機能がRedmineにないからです。

Twitter / akipii: Redmineを運用して改めて思うのは、RedmineやTrac、Jira、GitHubなどのチケット駆動ツールは、開発者のためのツールであって、マネージャのためのツールではないこと。マネージャ視点では、進捗をコスト(工数)やリスクの観点をもっと見える化して欲しい要望が多い

Twitter / fmkt: この @akipii さんのツイートRTされまくっててマネージャ多いんだなとかおもったり http://twitter.com/akipii/status/423808940111966208 …

その機能としては、例えば、下記が挙げられます。

・リソースチャート(メンバーの作業負荷を一覧にする)
・工数管理(特にEVMによる進行基準会計)
・原価管理の観点のコスト集計(人月計算から原価集計)
・品質管理の観点の集計機能(信頼度成長曲線、管理図、パレート図など)

などがあります。

そもそも、RedmineやTrac、Jiraなどのチケット管理ツールは、開発者が欲しいと思う機能を実装したツールであるがゆえに、マネージャの観点で作られたツールではないです。
すると、今後のRedmineの方向性を考えると、特に日本ではWF型開発が主流ということもあり、マネージャの観点で強化する観点が考えられます。

【3】今回の勉強会では、「Redmine超入門」を執筆したスタッフが初級~中級者向けにお話した後、上級者向けに、Redmineをベースとしたエンタープライズ製品や運用事例についてお話をします。

講演では、関西でアジャイルやRubyをキーワードとしてビジネスを活動されている@agilekawabataさんをお招きして、Redmineをエンタープライズ向け製品としてどのように機能拡張されたのか、という話が後半のメインになります。
また、その前座として、私が、Redmineをエンタープライズ向け製品の開発基盤として使いたい場合、どこに焦点を当ててカスタマイズするとよいのか、という観点について、ざっくり話す予定でいます。

個人的には、Redmineをベースとしたチケット駆動開発がソフトウェア開発の基幹システムになるべきだ、と思っているので、Redmineはもっともっと拡張の余地があると思っています。

勉強会にご期待ください。

| | コメント (0)

2014/01/20

なぜ超高速開発が話題になるのか~キーワードはビジネスルール管理システム(BRMS)

最近なぜ超高速開発が話題になるのか、何となく分かった気がした。
ラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
超高速開発先進国、知られざる韓国企業の実態 - サムスン電子に見る「威力」:ITpro

NC特集 - 「超高速開発」が日本を救う:ITpro

俊敏な企業を構築するためのビジネスアナリシスとビジネスルール - 第3回 ビジネスの俊敏性を実現する:ITpro

俊敏な企業を構築するためのビジネスアナリシスとビジネスルール - 第4回 スマートなシステムを生み出す:ITpro

ITエンジニアのためのビジネスアナリシスを読んだ - 勘と経験と読経

ビジネスルールとビジネスプロセス(その1) | 株式会社KBマネジメント

ビジネスルールとビジネスプロセス(その2) | 株式会社KBマネジメント

ビジネスルールとビジネスプロセス(その3) | 株式会社KBマネジメント

ビジネスルールとビジネスプロセス(その4) | 株式会社KBマネジメント

ビジネスルールとビジネスプロセス(その5) | 株式会社KBマネジメント

ビジネスルールとビジネスプロセス(その6) | 株式会社KBマネジメント

ビジネスマンのためのビジネスルール入門① - blazeconsulting

ビジネスマンのためのビジネスルール入門② - blazeconsulting

ビジネスマンのためのビジネスルール入門③ - blazeconsulting

ビジネスマンのためのビジネスルール入門④ - blazeconsulting

【1】最近、超高速開発コミュニティができたりして、すごく活発だ。
何も知らないと、90年代初頭のCASEツールの再現、2000年代前半のモデル駆動開発(MDA)によるモデルからのソース自動生成を連想させて、何となく否定的なイメージを持ってしまう。

実際、超高速開発コミュニティで紹介されているツールを見ると、モデルからソースを自動生成するツールのように思えて、過去のツールと何が違うのか、分かりにくかった。

しかし、超高速開発が提唱される背景には、ビジネスプロセスからビジネスルールを分離し、ビジネスルールから業務プロセスを自動生成する方向があるようだ。

【1-1】たとえば、ビジネスマンのためのビジネスルール入門① - blazeconsultingでは、こんな文章から始まる。

(引用開始)
昨年あたりから、IT業界においてようやくBRMS(ビジネスルール管理システム)に対する熱いまなざしが注がれるようになってきました。ITに従事する方にとっては、超高速開発を実現するツールとしての期待も多いかと思います。
(引用終了)

ビジネスルールとビジネスプロセス(その1) | 株式会社KBマネジメントは下記の通り。

(引用開始)
最近、ビジネスルールが重要だという話を耳にすることが多くなりました。
日経コンピュータ誌でも「超高速開発が日本を救う」などというエキセントリックなタイトルでビジネスルール管理システム(BRMS)を大々的に取り上げたりもしています(2012年3月15日号)。
また直近では本格的にビジネスルールを扱った「ITエンジニアのためのビジネスアナリシス」(日経BP)が出版されるなど、多方面で注目を集めています。
(引用終了)

つまり、ビジネスルールを対象とするビジネスルール管理システム(BRMS)こそが超高速開発が目指すもののように思える。
なぜ、ビジネスルールがそれほど重要なのか?

【1-2】ビジネスルールとビジネスプロセス(その2) | 株式会社KBマネジメントによれば、従来の業務システムでは、ビジネスルールが業務プロセスに入り交じって、保守性が低下してしまうのが最大の問題だった。

(引用開始)
 業務アプリケーション= プロセス + ルール + データ
のはすが、実際のアプリケーションでは
 業務アプリケーション= プロセス[ルール含む] + データ
だったのです。
(引用終了)

実際、我々が受託開発で作る業務システムは、複雑怪奇なシロモノだ。
DOAの普及によって、データとプロセスは分離できた。
しかし、いくらオブジェクト指向で作ったとしても、MVCモデルなどの3層アーキテクチャとして作ったとしても、業務プロセスと業務ルールは入り交じっているのが普通。

たとえば、「10万円以上の買い物をしたら5%値引きする」「経費申請を提出したら上司が承認しなければ次プロセスに進めない」などのビジネスルールは、業務ロジックに密接に絡んでいて、モデルという一つの塊に密結合されている。

だから、運用保守の期間が長くなるほど、修正工数は増大していくのが普通。
ユーザから見れば、たったこれだけの機能追加でなぜこんなに時間がかかるのか、不審に思ってしまう現象はどこでも見られるだろう。
特に最近は市場環境の流れが速いのに、その変化に業務システムが追いつけていない現状がある。

そこで、ビジネスルールをプロセスから分離して、業務システムの保守性を高められたとしたら、どんなメリットがあるか?

アプリケーションコードをいじらず、設定ファイルの入れ替えだけでシステム運用ができるだろう。
あるいは、ビジネスルールは業務に直結した知識のため、IT技術者ではなく、業務の専門家ないし業務の担当者が自身で書いて、システムを運用することもできるかもしれない。

つまり、業務システムの保守性の向上が期待できるし、ビジネスルールはエンドユーザコンピューティングで対応できる可能性を秘めている。

BRMSでは、それらビジネスルールをビジネス・プロセスから分離し、部品交換のようにつなげる発想のように思える。

ビジネスルールとビジネスプロセスを分離する発想が有効な業界は、保険や証券などの金融商品のビジネスルールなどがあるらしい。

【1-3】最近の事例では、日経ITProの記事のように、サムスンがBRMSを導入し、業務プロセスの変革を素早く行えたらしい。
韓国製のBRMSとしてイノルールズ社のinnoRulesがかなり有名らしい。

ビジネスルールとビジネスプロセス(その2) | 株式会社KBマネジメントによれば、こんな内容が書かれている。

(引用開始)
このような状況で、ルールがプロセスに混在したままアプリケーションコードを作成してしまうと、ビジネスの環境変化に対応することが大変困難です。
ルールだけ変更するためにも、システム開発するのに匹敵するだけの工数を必要とすることになりかねません(すべてのプロセスを見直す必要が生じた場合)。
競合状況も悪化します。
ルールを環境に合わせるのに数か月かかってしまうと、競合状況も一変してしまいます。競合に差をつけられるだけでなく、顧客満足度にも影響が出るかもしれません。
スポンサーの期待からもほど遠いものになるでしょう。
社員のリストラや工場売却などが現実味を帯びてきます。
かつての日本を代表する超一流メーカーの凋落ぶりは大変歯がゆいものがあります。韓国のサムソンに大きく差をつけられている要因かもしれません。
(引用終了)

日経BPの記事でも、サムスンがBRMSを導入して結果を出している内容を宣伝していたから、日本の製造業の凋落ぶりと対比させているのだろう。
たしかに、ハードウェアよりもソフトウェアを重視していない日本の現状と被って見える。

だからこそ、BRMSによる超高速開発が最近注目されているのだろう。

【2】でも、BRMSはそう簡単なシロモノではない。
ビジネスルールとビジネスプロセス(その4) | 株式会社KBマネジメントでは、BRMS導入の課題を2つ上げている。

一つは、ビジネスルールそのものを整備するのが大変なこと。
もう一つは、ビジネスルールはビジネス戦略に依存しているため、そのトレース(追跡)の確保が難しいこと。

前者は、ユーザ企業の業務ルールを洗い出すだけでなく、漏れ無く矛盾なく、整理する必要がある。
しかし、たとえば、製造業の場合、各工場で標準プロセスがあったとしても、作る製品は微妙に違うため、それに適したプロセスやルールを作りこんで、製品の品質を維持している時が多い。
つまり、実際の現場の業務は、各現場でバラバラで、ビジネスルールを統一化することすら難しい場合が多い。

後者は、ビジネスルールがなぜ存在するのか、を突き詰めると、それは経営戦略にたどり着くので、ビジネスルールは全て、ビジネス戦略から派生するはずである。
しかし、ビジネスルールはたくさんあり、しかも複雑怪奇だから、そのルールが何故必要なのか、を逐一理由付けて整合性をとっていくのは、業務にかなり詳しい専門家でなければ難しい。

特に最近は、内部統制やISMSの情報セキュリティ管理のように、法律上決まっているから、という理由で、無駄に複雑な機能が実装されている場合が多い。
したがって、現場の運用に詳しいだけでなく、最近の法体系の変化にも詳しくなければ、それらビジネスルールの正当性を保証するのは難しい。

個人的には、業務システムの要件の大半は、内部統制・ISMS・会計監査・システム監査などのような法律があるために、複雑怪奇な仕様となった業務システムが作られてしまうように思えて仕方ない。
その業務要件の正当性はIT技術者が保証するのではなく、システム監査人や公認会計士の都合で作っているように思えて仕方ない。

【3】BRMSが注目される理由として、BABOKとの関連もあげられる。
BABOKは僕は知らないのでなんとも言えないが、ITエンジニアのためのビジネスアナリシスを読んだ - 勘と経験と読経を読むと、BABOKを使って設計されるシステムの一事例としてあげられるようだ。

ITエンジニアのための ビジネスアナリシス」という本が有名らしい。

(引用開始)
・BABOK V2ベースで言うならば「エンタープライズアナリシス」と「要求アナリシス」あたりの知識エリアが記述の対象だと思う。
・ざっくりと整理すると2つの段階に分かれると思う。
 ・「ポリシー憲章」を作成してビジネスの目的とゴールを整理する流れ(「エンタープライズアナリシス」的)
 ・「ビジネスルール」の導出を中心とした各種の分析アクティビティ(「要求アナリシス」的)
・最終的には「ビジネスルール」から(ITシステムを作るための)「ビジネス要求」を導出する。
・また「ビジネスルール」は継続的にルールブックとしてマネジメントされる。
(引用終了)

【4】以上のように、BRMSが海外では使われて結果を出している事例があること、BABOKの設計事例としてあげられていることから、BRMSとそれを実装する超高速開発が注目されているといえる。

しかし、BRMSの一番の疑問点は、どうやって実装するのか、だ。

ITエンジニアのためのビジネスアナリシスを読んだ - 勘と経験と読経にも書かれている。

(引用開始)
疑問点:どうやって実装するか
本書で紹介されているビジネスルール中心の分析は興味深いし、実際に活用してみたいと思えるような内容なのだけれども、1点気になるのは「どうやって実装するのか」である。
(引用終了)

【4-1】直感的には、ビジネスプロセスからビジネスルールを分離するモデルは、ファウラーのアナリシスパターンである知識・操作パターンに相当するように思える。
つまり、操作レベルがビジネスプロセス、知識レベルがビジネスルールに相当する。

しかし、知識・操作パターンの実装は、かなり難しいと思う。
素人的考えでは、Strategyパターンで入れ替えればよいように思えるが、ビジネスルールというメタクラスでビジネスプロセスを制御しなければならないからだ。
つまり、条件分岐やルールをメタモデルとして表現できるメタプログラミング、ないし、リフレクションが必要になると思う。

【4-2】また、Webシステムの基本アーキテクチャであるMVC2モデルや、渡辺式DOAの3要素分析法では、ビジネスルールはどこで表現されるべきなのか、という疑問がある。

MVC2モデルならば、Modelにビジネスルールが含まれるだろう。
しかし、Modelには業務ロジック、つまり、業務プロセスも含まれているから、ビジネスルールと密結合にならざるを得ない。

また、渡辺式DOAの3要素分析法では、ロバストネス技法と対比させると、

・業務=バウンダリ、インターフェイス、業務マニュアル
・機能=コントローラ、システムの機能そのもの
・データ=永続データ、マスタやトランザクションデータ

という3層構造になるが、ビジネスルールはどこに存在するのか?

ビジネスプロセスは「機能」に含まれる。
もし、ビジネスルールもシステム化対象とすれば、「機能」に含まれてしまい、密結合にならざるを得ない。

XEAD Driverなどの開発の背景を読み解くと、ビジネスルールはおそらく「データ」で実現されるのだろうと想像する。
つまり、「10万円以上の買い物は5%引き」などのビジネスルールは、パラメータとしてDBに設定してしまい、自由に変更できるような仕組みにするのだろう。
もちろん、メタプログラミングないしリフレクションで、RDBから取り出したパラメータ値でビジネスルールを生成する実装方法になるだろう。

ビジネスルールがRDBに格納されるような構造ならば、確かにユーザが業務ルールをパラメータという宣言的データとして作成すれば、システムを停止することなく、運用できる利点がある。
ただし、ビジネスルールがRDBの中でメタデータとして登録されてしまうために、ビジネスルールをモデルとして理解するのはとても難しくなる弱点もある。

【4-3】具体的な実装方法としては、ビジネスルールをXMLファイルとして書き下ろし、そのXMLファイルをロードしたらビジネスルールが生成される方法があげられるだろう。
つまり、ビジネスルールをDSLで書く手法が考えられるだろう。

DSLの一番簡単な例は、JavaのビルドツールAntだ。
XMLファイルに、ビルド手順を宣言的に書く。
同様に、XMLファイルへビジネスルールを宣言的に書けばいい。

似たような事例として、BPMN(ビジネスプロセスモデル)をGUIベースで書いたらXMLで保存できるツールもある。

Eclipse BPMN2 Modeler

また、最近ならば、DSLとしてXTextが有名だろう。

Xtext - Language Development Made Easy!

つまり、ビジネスルールを同様にDSLで実装し、エンドユーザはGUI上で入力できるようなI/Fを作ればいいだろう。

但し、この手法は、ERPではパラメータ設定としてよくやる方法であり、使いにくくなることであまり評判は良くなかったように思う。
最近はまた変わってきたのだろうか?

【5】自分の理解でBRMSについて考えてみたが、今後、どのように発展していくのか、いろいろ考えてみたい。

| | コメント (0)

2014/01/18

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。

【参考】
GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録

GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ]

Fujimura ? GitHubで既存のissueに対してpull requestする

hub コマンドで github から fork して pull request をさくっと - #生存戦略 、それは - subtech

Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記

bleis-tift/Git-Hooks

かんばん!~もし女子高生がRedmineでスクラム開発をしたら(6):Redmine×Gitのハーモニーは涙のチケット駆動開発!? (1/3) - @IT

mikoto20000/redmine_git_branch_hook

Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技:ゆめみスタッフブログ)

Git+Redmine+チケット駆動開発のワークフロー

Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineers' Blog

GitHub直伝 プルリクエスト活用の3つのコツ | A-Listers

yuroyoro/git-issue ・ GitHub

percolとgit-issueを使って、redmineのチケットをブランチに切って作業するのが捗る設定 | Technology-Gym

Gitブランチを使いこなすgit-flow/GitHub Flow入門(1):いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 (1/2) - @IT

Gitブランチを使いこなすgit-flow/GitHub Flow入門(2):git-flowのインストールとブランチ運用前のリポジトリ準備 (1/2) - @IT

【1】GitHubでも、チケット駆動開発を運用することはもちろん可能だ。
チケット駆動開発の利点であるトレーサビリティを実現するには、コミットログにGitHubのIssueNoを書く運用をすればいい。

しかし、GitHub上でプルリクエストする時には、以下の問題点がある。

(引用開始)
しかし GitHub では、Issue 番号を発行するためには Pull Request を作る必要があり、Pull Request を作るためにはコミットを作る必要がありますが、コミットをする際には予め Issue 番号を知らなければならないため、 Issue 番号付きでのコミットができません。

そのため、しばらくは

1.チケット番号を発行するための Issue をまずは発行する
2.そのチケット番号をコミットログに含めてコミットする
3.その番号とは別に Pull Request を発行する

といった運用をしていました。
一つのトピックに対して、Issue 番号と Pull Request 番号の2つができてしまうため、あまりイケていませんでした。
(引用終了)

GitHubでプルリクエストを行う時、このパッチをマージして下さい、というコメントを書くが、そのチケット番号は新規発行されるために、そのチケット番号をプルリクエストするパッチに紐付けすることができない問題点がある。

【2】解決方法としては、他の記事「GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ]」にもあるように、hubコマンドを使う方法があるだろう。

(引用開始)
#例: pullreq ブランチから master ブランチに対して Pull Request を送りたいが、その際に既存の Issue#123 にコードを添付したい

git checkout -b pullreq
hub pull-request -i 123
(引用終了)

【3】上記の記事の問題点は、チケット駆動開発とGitとの相性が良くない点があることに起因しているように思う。
第9回RxTstudy勉強会の感想~Redmineとチケット駆動開発の今後の課題 #RxTStudy: プログラマの思索にも書いたけれど、Gitでチケット単位にトピックブランチを作る運用では、幾つかの問題点が提起されていた。

一つ目は、コミット履歴が故意に改変される危険があること。
これは、特に、trunkの履歴は改変できないように、運用ルールでカバーするしかないだろう。

2つ目は、チケットNo付きトピックブランチで作業していたとしても、trunkへpullする場合、squashで過去のコミット履歴をまとめてパッチ1個で送ろうとすると、新たにチケット番号を付与しなくてはいけないこと。

上記の記事のように、トピックブランチ上のコミット履歴をそのままtrunkに反映する場合は、hubコマンドを使って、トピックブランチと関連付けられたチケット番号を付与してPullRequestすれば良い。

しかし、trunkのコミット履歴には、トピックブランチ上の試行錯誤した履歴は特に欲しくない時もある。
修正のレビューも終わり、完成版のパッチのみを記録したいのが普通だから。

すると、PullRequest用のパッチを作るために、別のブランチを作って操作する必要が出てくる。
そのための新たなチケット番号を作るしか無い。

さらには、本来は、Atlassian製品のように、folkすると自動でチケット番号が付与され、pullされる時にチケットも自動でCloseされるように運用したいのだ。

Atlassian製品による「No Ticket, No fork!」: プログラマの思索

そうなれば、仕様変更や機能追加、障害修正、課題が発生するたびに、チケットを起票する癖がつき、そのチケットに作業履歴を残す運用が徹底される。

また、それらチケットと、トピックブランチが密に関連付けられることによって、何のためにソースを修正しているのか、をいつも自覚するようになるから、ソース修正の意図も明確になる。
プログラミングにはまっていると、ソースを綺麗にしたり、たくさんの機能を追加することに気を取られてしまいがちだから。

【4】トピックブランチとチケット駆動開発の運用ルールや運用方法については、色んなツールが出てきており、試してみる価値があると思っている。

そんなことを思う理由は、チケット駆動開発はTrac+Subversionの運用が発端であったために、Gitのような優れた分散バージョン管理の機能とチケット管理ツールの連携が不十分な面がまだあるように思えるからだ。

【4-1】例えば、Redmineチケットごとにトピックブランチを「id/12」のように作った場合、bleis-tiftというフックスクリプトを使うと、id/12というブランチで作業してるときは、コミットメッセージの末尾にrefs 12を自動付与してくれる。

Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記

bleis-tift/Git-Hooks

このフックスクリプトのメリットは、チケットNo付きトピックブランチをいちいち気にしなくても作業できることだ。
つまり、トピックブランチ上で作業している時、「No Ticket, No Commit」を意識せずとも、ツールが自動補完してくれるわけだ。

【4-2】例えば、「Redmine Git Branch Hook」スクリプトを使うと、トピックブランチをマージするタイミングでRedmineチケットを自動でCloseする運用も可能だ。

かんばん!~もし女子高生がRedmineでスクラム開発をしたら(6):Redmine×Gitのハーモニーは涙のチケット駆動開発!? (1/3) - @IT

mikoto20000/redmine_git_branch_hook

このフックスクリプトのメリットは、マージしてトピックブランチが廃止される時に、チケットをCloseする手間を省いてくれることだ。
つまり、Redmine+SVNで、「fixes #12」でコミットした時にチケットがCloseされる運用をGitのブランチのマージへ適用したものだ。

【4-3】上記の2つの運用は、Gitのトピックブランチ上で「No Ticket, No Commit」「No Ticket, No Merge」をサポートするためのツールといえる。
それらのツールを運用すれば、開発者はトレーサビリティや変更管理、構成管理などの複雑な標準プロセスを意識せずとも、プログラミングに専念するだけでいい。

本来のアジャイルな開発は、複雑で無駄が多い標準プロセスを意識せずとも、プログラミングだけに専念すれば、ユーザに価値あるソフトウェアを即座にリリースできる環境を整えることにあるはずだ。

これらの観点で、分散バージョン管理Gitとチケット管理ツールの相性について、もっと考えてみたいと思う。

【参考】

| | コメント (0)

SourceTreeのメモ

GitクライアントSourceTreeをメモ。

ユカイ、ツーカイ、カイハツ環境!(31):これでGitも怖くない! GUIでのバージョン管理が無料でできるSourceTreeの7つの特徴とは (1/3) - @IT

僕はTortoiseGitの方を愛用しているが、最近はSourceTreeの方が流行しているらしい。
上記の岡本(@LightningX)さんの記事はとても分かりやすい。

<SourceTreeの特徴>
・グラフィカルなコミット履歴の表示
・直観的なコミット単位の選択
・簡単なマージ
・直観的なリベース
・チェリーピック
・自動フェッチ
・git-flowにも対応

GUI画面から、マージ・リベース・チェリーピックができるのは便利だ。

ソース管理で難しい作業は、これらマージ作業であり、コマンドラインでは慎重にやる必要があった。
従来では、本番リリースを行うライブラリアンは、ビルドする前に、どのリビジョンを本番ソースにマージするか、Excelのリリース管理台帳に記載して、参照して、作業記録を残す必要があった。
こういう作業が、Gitのような強力なツールのおかげで、格段にやりやすくなってきている。

SourceTreeで面白いのは、git-flowで扱うブランチ管理もGUI上で行える点だ。
厳格なソース管理を行う場合、A successful git branching modelをGit上で実現するgit-flowモデルを採用する時が多く、このような開発スタイルになるだろう。
しかし、ブランチ管理が大変になりやすいが、GUI上で簡単に操作したり、切り替えできるのは便利だ。

A successful git branching model とgithub flowの比較: プログラマの思索

SourceTreeは単なるGitクライアントに過ぎないかもしれないが、初心者が使えるようになることで、Gitが持つ構成管理のベストプラクティスを自然に身に付けられる可能性を秘めている。

ツールの習熟が、スキル習得を支援する。
ツールがプロセスも支援する。

ちょっと使ってみようと思う。

| | コメント (0)

2014/01/17

組織のプロジェクトマネジメント能力よりも組織内のロールを重視した開発へ

最近の開発スタイルの流れとして、組織のプロジェクトマネジメント能力よりも組織内のロールを重視した開発スタイルがあるように思える。
ラフなメモ書き。

【元ネタ】
開発の背景|総合プロジェクト管理ツール SI Object Browser PM

CMMI とは:梅田弘之のプロジェクトマネジメント講座:【第2章】CMMIを意識しよう

[ThinkIT] 第3回:CMMI導入がもたらす光と影 ? 日本の文化にあったプロセス改善 (1/3)

スクラムの新しさ: プログラマの思索

従来のウォーターフォール型開発では、組織のプロジェクトマネジメント能力を重視するスタイル。
PMBOKやCMMIがまさにそう。

PMBOKでは、かつて様々なマネージャが経験した暗黙知を全て形式知として体系化することで、プロジェクトマネジメントの知識とプロセスを標準化した。
さらに、QCDというゴールに向けて、進捗管理や品質管理のような典型的なプロセス管理だけでなく、要員の管理のような人的資源管理、要件の範囲を確定させるスコープ管理、機材や外注や契約など調達管理もプロセスの範疇に入れて、管理対象とした。

CMMIは、組織のプロセスの成熟度モデルを導入することで、組織のプロジェクトマネジメント能力を評価する技法を導入した。
日本の製造業の流れを受けつぐソフトウェア開発スタイルを追いかけるならば、最終的にはCMMIに行き着くのではないか。

一時期、日本の経済産業省がCMMIの日本版を作り、発注企業の要件の一つにしようとする試みがあった。
しかし、結局実現されていない。
あれだけCMMIを注目していた時期があったのに、CMMIレベル5の認定を受けている日本の企業は、かなり少ないらしい。
おそらく、中国やインドのソフトウェア企業よりも数が少ないのではないか。

CMMIモデルについて。CMMIレベル5の認定を受けている日本の企業はどこでしょうか... - Yahoo!知恵袋

ウォーターフォール型開発では、開発プロセスを重視し、開発者の属人性を廃し、手続きの標準化に注力する。
しかし、そのやり方は、製造業に向いていても、ソフトウェア開発に向いているとは言えない。

ドキュメントや開発手順を標準化しても、IT技術の進化についていけずに、その標準化したフォーマットそのもんが陳腐化してしまう。
どの開発・運用保守案件でも、どの人でもアサインできるようにしたいが、業務知識やアーキテクチャ設計、フレームワーク、インフラなどの技術が特有であるために、結局、特定のメンバーに依存してしまい、プロジェクトからメンバーを剥がせない。
誰でも担当できるような案件は、単価が安すぎて、逆に旨みがない。

むしろ、メンバー全員がプロジェクトマネジメント能力を持つように研修で教育して、メンバーの意識やスキルを向上するような雰囲気を作ると、自然に、メンバーが役割分担を自ら調整するようになる。

10年以上前のソフトウェア開発では、ロールが多すぎ。
論理的な業務データを扱うDA(データ管理者)、物理的なDBサーバーの保守担当者(DBA)、Webサーバの保守担当者、フレームワーク設計者、そして、たくさんの実装メンバー。
その周囲に、各チームリーダー、リーダーを束ねるプロジェクトマネージャ、そして、重役ないし取締役、など、数多くのロールが必要だった。
もちろん、顧客側にも、情報システム部門、本来のユーザである業務部門、そして稟議を承認する経営者などもいる。

XPの白本「XPエクストリーム・プログラミング入門―変化を受け入れる」を読んでも、ソフトウェア開発に必要なロールが10種類以上出てくる。
ウォーターフォール型開発なら、そのロールはもっと増える。

しかし、それらのロールは、IT技術の発展によって、どんどん消滅したり、統合されていった。
クラウド技術のおかげで、DB・Webサーバなどのインフラ担当は、開発者が担当できる。
業務知識を持つデータ管理者、アーキテクチャ設計者も、優れたフレームワークがオープンソースで普及している今は、上級のプログラマで十分に担当できる。

一方、アジャイル開発では組織内のロールを重視した開発スタイルなので、ウォーターフォール型開発とは全く違う。
スクラムでは、もっと過激に、アジャイルなチームは3種類のロールしか必要ない、と言い切っている。
ロールが少ない方が開発はしやすい。
プロジェクトマネージャが得意とする「調整」という名の無駄な政治力を発揮する必要もない。
チーム内の風通しも良くなる。
マネージャの大好きな言葉「見える化」も、ロールの種類が少ない分、簡単に実現できる。
スクラムの言う「透明化」は、ロールの種類の少なさからも発生する。

必要なのは、3種類のロール(チーム・スクラムマスター・プロダクトオーナー)が一体化したスクラムチームで邁進するだけだ。
優れたプログラミング技術を持つ人達が集まって、スクラムチームを形成できれば、政治力の行使という無駄な労力がない分、速く開発できる。
スクラムの逸話でよく話題となる「ニワトリとブタ」は、その文脈で捉えると、より実感できると思う。
外部のステークホルダーによる政治的干渉は、ソフトウェア開発を邪魔するだけの無駄なものなのだ。

なのに、特に日本のシステム開発は、上司の顔を立てるために稟議が多かったり、ナントカ会議という合議制で誰も責任を追わない体制が幅を利かせている。
肝心のシステム開発そのものを阻害する組織的な壁が日本では特に多いと思う。

最近のソフトウェア開発プロセスの歴史を考えると、数多くのロールがIT技術の進化によってどんどん淘汰されたり統合されることで、ロールの種類が少なくなり、チームの透明性を高めていく方向に進化しているように思える。
組織パターン」を読んでいると、改めてそう思う。

| | コメント (0)

2014/01/12

レスポンシブWebデザインの現状と課題

Webユーザエクスペリエンスとして、レスポンシブデザインの技術は最近普通になってきた。
以下、情報をリンクしておく。

レスポンシブデザインとは 【 responsive design 】 〔 レスポンシブWebデザイン 〕 - 意味/解説/説明/定義 : IT用語辞典

レスポンシブWebデザインがユーザー体験に最適化できていない5つの実例 | SEO Japan

ASCII.jp:レスポンシブWebデザインとは (1/5)|ゼロから始めるレスポンシブWebデザイン入門

スマートフォンからのアクセスでCSSを切り替える方法。レスポンシブwebデザインの作り方。 | Web制作会社スタイル

レスポンシブ・ウェブデザインでの CSS コードの書き方

Google ウェブマスター向け公式ブログ: Google がお勧めするスマートフォンに最適化されたウェブサイトの構築方法

Rails 4.1 の新機能 - rochefort's blog

【1】デスクトップPC以外に、スマフォやタブレットなどのクライアント端末の種類が爆発的に増えてきたために、Webデザインがすごく難しくなっている。
PCなら広いディスプレイでいろんな操作ができるのに、スマフォのような小さな画面では、PCで表示できるWebページのサイズでは読みにくい。
タブレットは、Androidなら星の数ほど色んなサイズが必要になる。
Android端末の開発者が一番困っているのではないだろうか?

レスポンシブWebデザインの最大の特徴は、ワンソースで各デバイスの画面サイズに対応したレイアウトを実現できること。
最近の企業のWebページでは、レスポンシブルなデザインになっているのが普通だろう。

一つのHTMLで、スマフォ・タブレット・PCからアクセスして普通に読めるようにすれば、ソースの更新作業コストがかなり楽になる。
デバイスごとに、似たようなソースを修正して履歴管理していくのは、とても面倒だし、回帰テストの工数も大きい。
Webページは更新頻度が高いので、たった1行のソース変更でも、デバイスごとにソースを反映していくのはとても大変だ。
特に、CMSでWebページを作っているならば、新しいデバイスが増えるごとに、スクラッチで機能追加しなければならない。

また、一つのURLでPC・スマフォ・タブレットからアクセスできるので、SEO対策やアクセス解析する作業も減る。
デバイスごとのURLがある場合、PCからスマフォや携帯端末にはアクセスできないから、そこでアクセスがロストしてしまうことで、機会損失にもなる。

【2】レスポンシブのデザインにするには、CSSのviewportやmediaタグで制御するのが普通だろう。
CSS修正は、デザイナーの担当というイメージが強かったけれども、最近は、開発者も理解する必要が出てきたように思う。

でも、レスポンシブWebデザインが全ての問題を解決してくれるわけではない。
スマフォやタブレットの回線速度はPCに比べると遅いために、画像サイズや情報量を減らすなどのチューニングも必要。
また、PCでもスマフォでも似たようなレイアウトにするには、そもそものWebページの構成をきちんと設計して、画面遷移も考えないといけない。
PCでの導線とスマフォでの導線は違うのが普通だから、全画面を含めた設計を練り直す必要も出てくる。

レスポンシブWebデザインは、最近バズワードになっているWebユーザエクスペリエンスやアジャイルUXとも絡んでくるだろうと思う。
顧客のフィードバックを頻繁に反映しながら、Webデザインをより良いものへ頻繁にVerUpしていく。
つまり、アジャイル開発ととても相性が良いだろうと思う。

【3】レスポンシブWebデザインの解説本としては、レスポンシブWebデザイン マルチデバイス時代のコンセプトとテクニック」が良いらしいので、読んでみたいと思う。

RWDの入門書「レスポンシブWebデザイン」(菊池崇氏著) を読んだよ | [M] mbdb

「レスポンシブWebデザイン マルチデバイス時代のコンセプトとテクニック」レビュー | AIRLife.net

【書評】「レスポンシブWebデザイン マルチデバイス時代のコンセプトとテクニック」菊池崇 著 | ねんざブログ

| | コメント (0)

BYODとMDMの現状と課題

スマフォ・タブレットが普及してから、バズワードとなったBYODとMDMについてメモ。
以下ラフなメモ書き。

【参考】
BYODとは 【 Bring Your Own Device 】 - 意味/解説/説明/定義 : IT用語辞典

記者の眼 - BYODのできる会社に就職したい:ITpro

どこまで許す?BYOD - 第2回 コストをかけず告知で“私物”を利用禁止:ITpro

「BYOD」に潜むワナ(1)「ウチはBYODをやらない」では済まない現状 - ZDNet Japan

一般層への広がりを欠いた「BYOD」は今年のバズワードだったのか? | 東京IT新聞

【MDM情報室】 モバイルデバイス管理(MDM)とは? -クラウド Watch

MDMとは 〔 モバイルデバイス管理 〕 【 Mobile Device Management 】 - 意味/解説/説明/定義 : IT用語辞典

基礎から学ぶ「MDM(モバイルデバイス管理)ツール」の選び方 | ビジネスネットワーク.jp

日経コンピュータ2013.12.26|HATのブログ

【1】BYODやMDMの需要は増えているのが現実。
日経コンピュータでも、「タブレット導入・失敗のワケ」という特集記事を記載してた。
最近のシステムリプレース案件では、タブレットやスマフォをクライアント端末として使えるようにしたい要望が多いのではないだろうか?

特集記事では、MicrosoftのWindowsタブレットSurfaceとSharePointなどを組み合わせた事例が多い。
大企業向けに業務システム活用の一手段として使っているから。
Surface導入の理由は、Officeが使えること、ノートPCのようにも使えること、従来のデスクトップPCの代わりになることがあげられるようだ。

例えば、小売店の従業員や営業マンにタブレットを渡して、遠隔地でも自由な時間に業務活用できるインフラを提供したいわけだ。
最近では、コンビニや量販店の店員は、タブレットで商品の棚をチェックして回るのが普通だろう。

アーキテクチャ設計上は、サーバー側のフロント向けシステムはクラウドベースで作っておけば、既存の基幹系業務システムと連携するだけでいいし、クライアントアプリから直接、既存システムにアクセスしないので、セキュリティも安全とも言える。

とはいえ、@hatsanhat さんが日経コンピュータ2013.12.26|HATのブログで言っているように、WindowsタブレットSurfaceを長期間使えるのかというリスクもある。
iPhoneにせよAndroidタブレットにせよ、ハードもソフトもバージョンアップが激しいので、実際に使える期間は、普通のデスクトップPCよりもはるかに短い。

まだまだ試行錯誤の段階かな。

【2】個人所有のスマフォ・タブレットを業務活用するBYODは、企業の情報セキュリティをクリアすべき技術的課題が大きすぎる。

最近は、ノートPCの紛失だけで新聞沙汰になるご時世だ。
そこに、顧客情報や学生の成績情報などの個人情報があり、ノートPCなどの携帯端末が暗号化されていなければ、簡単に盗まれてしまう。
公務員や大企業ならすぐに社会的糾弾を浴びる。

だから、会社が提供する端末のみアクセス可能とするMDMツールの方が、一般的だろうと思う。

でも、MDMのような管理ツールは必須だろうが、情報セキュリティの技術的課題は完全とはいえない。
リモートワイプ(リモートで端末の個人情報を消去する)機能があっても、紛失からデータ消去までのタイムラグがあるし、ネットワークに接続できていなければ、そもそも実施不可能だ。
また、端末で動作しているエージェントアプリを悪意を持って消去されてしまうと、そもそもリモートで操作することすらできない。

しかし、BYODを実現するためのMDMの進化も早い。
本来ならば、中小企業向けにBYODやMDMを普及すべきだろう。
中小企業では、PCやスマフォ、タブレットを個人に配布するコストが大きく感じるので、BYODになれば、配布コストを削減できる。
MDMで個人所有のタブレット端末にある企業情報をリモート管理できれば、セキュリティやライセンス更新の管理も楽になるはず。

MDMツールの進化がBYODの成功可否を握るだろう。
今後もいろいろ調べてみる。

| | コメント (0)

2014/01/11

論文の文章作法の悪文パターン

「超」文章法」を読みながら、論文の文章作法の悪文パターンをまとめてみた。
ラフなメモ書き。

【参考】
こんな本を読みました。: 「超」文章法

論文作成の技法part1~論文の構造: プログラマの思索

論文作成の技法part2~論文作成の観点 : プログラマの思索

論文作成の技法part3~論文作成のIT技術: プログラマの思索

【0】日本語の文章を書くのは難しいと思う時がある。
書いた文章を後で読むと、違和感があったりする。
他人に読んでもらうと、自分の思いや意見をなかなか汲み取ってくれない。

小論文を書く場合はもっと難しい。
ストーリーラインを決めたとしても、筆が流れるまま書いてみて後で読むと、本当はこう書きたかったのに、という気持ちになる時がある。

「超」文章法」などを読んでみて、論文の文章作法の悪文パターンがあることに気づいた。
そんな悪文パターンに陥らないように、自分のために書いてみる。

【1】法律文・主語述語泣き別れシンドローム・主語述語ねじれシンドローム

アンチパターンとしては、主語述語ねじれシンドローム・主語述語泣き別れシンドロームがある。
主語述語泣き別れシンドロームとは、主語と述語が離れているために、主語がどれなのか、分かりにくいこと。
主語述語ねじれシンドロームとは、主語に対応しない述語が現れること。

いずれも、日本語では、主語と述語が離れていて、最後の述語が出てくるまで、肯定なのか否定なのか分かりにくいという特徴(弱点)から発生している。

日本語の文章は、小説なら長文でもよいみたいだが、最近の流れは、論文調ならば、複文よりも短文にしろ、という方針が多い。
短い文章の方が、論理関係が分かりやすい。

複文になったために分かりにくい文章の悪例としては、法律の文章が多い。
例えば、「「超」文章法」P190では、日本国憲法前文を複文の問題点としてあげている。

日本国憲法前文 - Wikipedia

(引用開始)
われらは、いづれの国家も,自国のことのみに専念して他国を無視してはならないのであつて、政治道徳の法則は、普遍的なものであり、この法則に従ふことは、自国の主権を維持し、他国と対等関係に立たうとする各国の責務であると信ずる。
(引用終了)

日本国憲法、英文付

(引用開始)
We believe that no nation is responsible to itself alone, but that laws of political morality are universal; and that obedience to such laws is incumbent upon all nations who would sustain their own sovereignty and justify their sovereign relationship with other nations.
(引用終了)

日本語の文章では、「われらは」「いづれの国家も」の2つの主語が出てきて、論理関係が分かりにくい。
「法則は」「従ふことは」も主語のように思える。
上記の文章は複文なので、論理関係を読み取りにくいのだ。
昔の日本人の政治家の演説もそうだったが、文章が長いので、何を言いたいのか、分からなくなる。

それに比べて、英文の場合、Weが主語で、believeが述語であることがすごくよく分かる。
英文の方が分かりやすい理由は、thatやwhich、;を使って、論理関係を明らかにしているから。

thatや「;」は、「すなわち」に言い換えられる。
whichのような関係代名詞は、主語にかかる長い修飾詞の代替として使われている。
だから、論理関係を読み取りやすい。

法律の文章が理解しにくい最大の理由は、上記のような複文になっているからだろうと思う。
最近なら、消費税10%の時期の解釈をどうとでも取れるようなニュースもあった。
法律や政治では、故意にあいまいで分かりにくくするのが良いのだろう。
しかし、論文のような文章を書く時は、法律文は真似ない方がいい。

【2】飾りすぎの主語

飾りすぎの主語アンチパターンとしては、「「超」文章法」には、以下の例が挙げられている。

黒い目の綺麗な女の子

この表現は、8つの異なる意味に解釈できるらしい。
つまり、修飾詞が長すぎて、論理関係が分かりにくくなっている。
一方、英文ならば、関係代名詞という手段があるので、より明確に表現できる。

また、英語は、句読点の種類が多い。
「.」>「:」>「;」>「,」の順で、文章の区切りの意味が変わる。
その分、論理関係の強弱もつけやすい。

逆に日本語の文章は、句読点の種類が少ない。
古文などを読むと、古い日本の文章はとても長く、句読点の意識が薄いように思える。

最近の日本語では、主語にかかる修飾詞が長くなる場合、補足説明として「()」を使うやり方がある。
あるいは、「:」記号を使って、「すなわち」「つまり」の意味で使うやり方もある。
句読点は単に、文章を区切るだけでなく、論理関係をつなげるために使われるべき。

【3】他人事表現・キツネ文・では文・アリバイ文・言い訳文

他人事表現とは、「~と思われる」「~と言われている」という文体が多いアンチパターン。
論文のような文章では、自分の意見を主張するのがメイン。
だから、「私は~と考える」「私は~と主張する」と書くべき。
言い切ることが基本。

似たアンチパターンとして、キツネ文・では文がある。
キツネ文は「マルクスによれば」「ケインズによれば」と他人の文章を引用する文体。
では文は「アメリカでは」「経済学では」と上から目線で書く文体。

いずれも、自分の意見を言い切る文体ではないから、書いた人はどんな考えを持っているのか、何が言いたいのか、分からない。

他のアンチパターンとして、アリバイ文・言い訳文もある。
例えば、「私はこの問題の専門家ではないのだが」のようなアリバイ文、「残念ながら紙幅も尽きた」のような言い訳文。
こんな文章はそもそも必要ない。
自信がないから、こんな文章を書くだけ。

ChikirinさんのBlogでも、日本人の上司には「AともいえるがBともいえる」と言う人が多いという指摘もある。
その事象は、単に自分の意見を主張できない弱さを表明しているだけ。

「AともいえるがBともいえる」とか言う人の役立たなさ - Chikirinの日記

日本人の謙譲の意識が強すぎると、こんな文章が増えていくのかもしれない。

【4】一般論

「~が一般的である」という文章は、さんざん考えさせたあげく、なんだ一般論なのか、と読者をがっかりさせる。
読者にとって不快感が残る。
論文の文体は明確な方がいいので、「一般に~」と冒頭に宣言するのが良い。

日本語の文章では、述語が最後に来るので、一般論のようなアンチパターンが出てくる。

【5】必要性の羅列文

「~が必要である」の羅列で文章が終わるアンチパターン。
問題に対して、長々と思いついたことを書いただけ。
言いたいことが整理されていない時が多い。

このアンチパターンの原因の多くは、知識不足か、自分の言いたいことが整理されていない未熟さにある。
問題に対して、必要な項目があるのならば、知識を全面に出して、対策を主張すればいい。
対策を主張したいならば、その内容を整理すべき。

自分の論理をロジカルシンキングで鍛えるべきだろう。

【6】おいては病

「~において」「おいては~」「~に関しては」「~としては」を修飾語に多用して、そこから持論を述べるアンチパターン。
そもそも「おいては」は話し言葉であり、論文のような文体では話し言葉は多用してはいけない。

おいては病では必要性の羅列文アンチパターンとくっついて、「~においては~が必要である」という文体になりがち。
つまり、自分の言いたいことが整理されていないのだ。
ロジカルシンキングで主張を整理すべき。

【7】またまた病

文章をつなげる時に「また」を2回以上使ってしまうアンチパターン。
例えば「~である。また~である。また~である。」のような文体。
小学生がよく使っている。

原因は、接続詞を使うという習慣がないから。
「また」以外に「さらに」「その上」などの接続詞を使えば、単調な文章ではなくなる。

複文よりも短文にすべき、という論文スタイルでは、接続詞の使い方が重要になってくる。
英語ならば接続詞を使った主張パターンが結構あるが、日本語ではその辺りが明確で無い。

下記の記事でも、外国人留学生の方が日本語の接続詞について敏感になっているという話がある。

国際交流基金 > 日本語教育 > 調査研究・情報提供 > 日本語教育通信

「超」文章法」でも、短文を多用するなら接続詞を意識すべき、と主張している。

良良の良良聊吧:日本語の接続詞一覧 - livedoor Blog(ブログ)

文章は接続詞で決まる→(保存版)接続詞の常識チートシートにまとめてみた 読書猿Classic: between / beyond readers

僕が日本語の文章を書いていてよく感じるのは、「つまり」「すなわち」のような言い換える接続詞をよく使う時が多いこと。
英語ならば、概念の説明が長くなる時に、thatを多用して修飾詞を分離して、言い換えるパターンに相当するだろうと思う。
でも、多用しすぎると、何となく変な感じになる。

文章は接続詞で決まる」でも、学者が素人向けに解説文を書く時に頻出しやすく、読みにくくなると書かれている。

英語なら、thatやコロンを使うことで解決できるのに、日本語では、そのような使い分けが難しいのだ。
でも、論文のような文章では、日本語でも多用すべきだと思う。

【8】「こと」「もの」多用

硬い日本語の文章を書く場合、「こと」「もの」のような代名詞を多用する時が多い。
例えば、「~ということを意味していて」「~ということになる」「~することにした」「~ということができる」「~のことであった」。

「こと」「もの」のような代名詞が何を示しているか、あいまいになってしまうために、説明した内容が分かりにくくなる。
一般に「こと」の意味は、~の事実、~の場合、~の結果、~の内容、などに相当するので、できるだけ言い換えた方がいい。

【9】日記論文・したした論文

事象を時系列に記述する時に多い。
小学生が日記で、「今日は~した。ぼくは~した。そして~した」のように書くパターンと同じ。

経験論文を書く時に、日記論文・したした論文のアンチパターンにはまりやすい。
なぜなら、こんな状況でこんな問題が出たので、このように自分は解決したのだ、と主張するために、自分の成果をアピールしてしまいがちだから。

解決方法としては、状況や問題を提示した後で、「その問題に対し、私は~と考えた。なぜなら~だからだ」のように、自分の意見と根拠を書くようにすれば良い。
そうすれば、論者がより深く問題を考えているとアピールすることもできる。

論文では、自分の意見を主張するだけでなく、その意見には確かな根拠がある、という組み立てが必要。
そうでなければ、反論にびくともしない、正当性のある意見とはいえない。

似たようなアンチパターンとして、自分の意見だけを主張して、その根拠に触れられていない「独り善がり文」アンチパターンもある。
司法論文ではこのアンチパターンに対しては「私は~と考えた。なぜならば~であるからだ。そこで私は~の対策を採用した」という流れで書くと良い、という王道パターンがあるらしい。

【10】自慢論文・お山の大将論文・お涙ちょうだい論文

自慢論文は、自分が担当した作業が有名な施設や有名な事件を対象にしている点だけを説明しているアンチパターン。
お山の大将論文は、自分の社会的地位や職位、学会での地位を自慢するだけで、自分の技術や知識の能力が感じられないアンチパターン。
お涙ちょうだい論文は、自分が担当した作業が、不幸にも数々の問題にさらされて、苦労してやっと解決した、という物語風のアンチパターン。

いずれのアンチパターンも、どんな問題に対して、どんな着眼点を持って、どんな対策を立てて、どんな成果をあげたのか、というストーリーが欠けている。
そのストーリーがなければ、論文として、論者に専門の能力があるとは思えない。

【まとめ・感想】
このようにあげてみると、日本語は難しい。
おそらく意識して矯正する必要があるだろう。

・主語と述語が離れがちなので、論理関係を明示しにくい。
・句読点の種類が少ないので、文章のバリエーションが少ない。
・接続詞を頻繁に使う癖が少ないので、複文や長文になりやすい。

また、僕も含めた日本人が、自分の意見を人前で主張するという訓練を学校時代に教育されていないこともあるだろう。
そもそも、普通の日本人は、人前でプレゼンしたり、発表する経験がない。
(そう言い切ってもおかしくないと思う)

僕自身、IT勉強会で発表し始めてから、プレゼンや論文をすごく意識するようになり、自分の意見を主張することの重要性を経験した。
そして、自分の意見を世の中に流布してもらうには、その根拠を明確に提示する必要があると、発表した後に初めて分かった。

今後も注意していく。

| | コメント (0)

2014/01/05

@tomohnさんのプレゼン作成技術メモ

@tomohn(長沢智治)さんのパワポ作成技術のページを見つけたので、リンクしておく。
とても参考になる。

【参考】
私の反復型プレゼン作成術 | Re:WorkStyle

パワポ職人芸 Vol.1 - 図形の合成を活用せよ | Re:WorkStyle

私がプレゼンのときに意識しているたった3つのポイント | Re:WorkStyle

パワポ芸 | Re:WorkStyle

最近なら、PowerPointよりもMacのKeyNoteでプレゼン資料を作る人の方が多いかもしれない。
特に、IT勉強会ではそうだ。
KeyNoteの方が、ジョブズのようなプレゼンができるイメージがある。

とは言え、実際の仕事では、WindowsパソコンでPowerPointでプレゼン資料を作る方が圧倒的に多い。
@tomohnさんのプレゼン作成技術がとても参考になるので、以下メモ。

以下メモ。

・プレゼンテーション資料は、反復型で作成する。
 RUPスタイルに、方向づけ → 推敲 → 作成 → 移行

・PowerPointでも、たくさんのテクニックがある。
 パワポ芸 | Re:WorkStyle参照。

・プレゼンの時に意識している3つのポイント:
 ・What を伝えるのではなく、Why を伝え、What を感じてもらう
 ・3つの感覚タイプを織り交ぜる
 ・オーディエンスの力を信じる

・聴衆の感覚タイプは下記の3通り。それら感覚に訴えるように、資料や言葉、身振りを加える。
 ・数字 Love ~ 「○○%の△△は、、、」
 ・感覚重視 ~ 「安心を手に入れられます」
 ・スケール感重視 ~ 「これにより、個人から、チーム、組織に広がっていきます」

| | コメント (0)

2014/01/04

ITの地殻変動はどこで起きているのか~アーキテクチャ設計技術にクラウドが必須になった時代

2014年になって、ITの地殻変動がどこに起こっているのか、を考えてみる。
#ラフなメモ書き。

【1】最近感じることは、Webアプリをプログラミングするアプリケーションエンジニアよりも、サーバー基盤を構築するインフラエンジニアの方が目立つというか輝いて見える時が多い。
何故なのだろう?

また、先月の日経BP主催のITアーキテクト カンファレンスでは、エンタープライズシステムの構築に携わるITアーキテクトを対象にしているが、その内容はすべて、クラウドがキーワードだった。
DOAやOOAは全く含まれていない点が衝撃だった。

ITアーキテクト カンファレンス 2013

最近の流れを見ると、アーキテクチャ設計の技術では、DOAやOOAは既に古い技術であり、クラウドが席巻しているように見える。

【2】最近のバズワードである「クラウド」には、否定的な意見を持つ人も多い。
ITの歴史の延長線上にあるだけで、そんなにすごい価値があるわけではないだろう、と。
単に仮想化なんでしょ、と。

クラウドサービスも、大昔のデータ計算センターや電算受託から始まったシステムサービス提供形態の現時点での変化形に過ぎない、と。

実際、ERPやメールサーバなどをクラウドへ構築する場合でも、フィットギャップ分析、セキュリティレベル、運営のコンセプト確認、負うべきリスクの整理、サービスレベル(SLA)の定義、など、従来の手法で検討する必要がある点は変わらない。
システム、ネットワークなどの利用面の進展があっても、利用に当たっての検討項目は本質的には同じである。

【3】しかし、クラウドが新しい観点をもたらし、アーキテクチャ設計に大きな影響を与えた点は2つあると思う。

【3-1】一つは、インフラ構築もアジャイルにプログラミングで開発できること。
その意味については、下記の記事で色々考察した。

クラウドの本質はインフラ管理のIT化: プログラマの思索

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

JenkinsによるLinuxサーバの設定変更管理yggdrasilの運用事例: プログラマの思索

「Infrastructure as Code」というキーワードがまさにそうであるように、サーバー構築手順は全てプログラム化できる。
従来は、サーバー購入や構築手順をあらかじめ計画段階で入念に実施し、レビューしてから作るというウォーターフォール型開発っぽいやり方しかなかったけれど、クラウドのおかげでサーバー構築もアジャイルに開発できる。

アジャイルに開発できる利点の一つは、失敗を何度も許容できる点があるだろう。
特に、サーバーの障害テストや負荷テストを何度もやり直せる利点はとても大きい。
従来なら、サーバーの負荷テストや障害テストは、準備も実行もすごく手間がかかりすぎて、何度もやり直すべき作業ではなかった。
アジャイルに障害テストや負荷テストを実施できることで、最初の計画を完璧にしなくても、プロトタイプのようにサーバーを構築して実現可能性(フィージビリティ)を調査したり、運用に合わせてハードウェア構成を柔軟に変える、などのオプションを持つことができる。

障害を故意に起こさせるツールで耐障害性を高める: プログラマの思索

また、クラウド化することで新たに判明する点は、ソフトウェアの品質がそのままコストに跳ね返ってくる点だろう。
例えば、CPU使用量やメモリ使用量を10%削減できれば、請求代金を10%削減できるのだ。

クラウドではソフトウェアの品質が課金の差として出てくる: プログラマの思索

つまり、クラウドでは下記の公式が成り立つ。

ソフトウェアの品質の差=パフォーマンスの差=課金の差=コストの差=利益率の差

従来は、一度、サーバーを構築したら、そのハードウェア構成を変えるのは、次のハードウェアリプレースまでできなかったが、クラウドなら、柔軟にハードウェア構成を変えることができる。
したがって、クラウドによって、ソフトウェアの品質特性として、特に効率性(パフォーマンス)がより重要になってきた側面があるだろう。

他にも、クラウドによって、システムの移植性が高まる、信頼性の観点は壊れないシステムよりもすぐに直せるシステムの方が重要、など、品質特性の観点が変わってきた。
今後は、クラウドとエンタープライズのシステムの組合せでは、機能性や信頼性よりも、保守性・移植性・効率性の品質の方が重視されてくるだろう。

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

なお、クラウドで使われるツールで注意すべき点は、Chefなど、Rubyで書かれたプログラムが多いこと。
クラウド時代のサーバー構築では、Rubyという技術が必須になってきているように思える。

【3-2】もう一つは、DOAやOOAやサーバー構築の設計では、その時代の技術の制約があったために、バッドノウハウになっていた箇所に対し、クラウドを使うことで本来の目的がクローズアップされたこと。

クラウドを使ったサーバー構築の設計では、クラウドデザインパターンがまとめられているので、参考にすべきだろうと思う。

クラウドデザインパターン~インフラ方式設計のベストプラクティス集: プログラマの思索

クラウドアーキテクティング原則 - AWS-CloudDesignPatternに掲げられた下記の原則は、クラウドの使い方について的確に示していると思う。

◆できるだけサービスを利用
◆机上実験よりも実証実験
◆スモールスタートからスケールアウト
◆変化に対し全レイヤで対処
◆故障のための設計(Design For Failure)
◆最初だけでなく周期的なカイゼン

また、DOAでは、サマリ系テーブルは夜間の日次バッチ処理(特にCobol)で作る、とか、正規化しているために参照関係の複雑なテーブルを結合して参照するしかない、などの弱点が従来はあった。
でも、クラウドが出てきて変わった点は、MapReduceのような並列処理と相性が良いので、大量データを短時間で処理できる設計も可能になったこと。

更には、RDBを使うとパフォーマンスが出ない場面では、クラウドと相性の良いNoSQLを組み合わせて、KVSやドキュメント指向DB、列指向DBなどを使うことで、問題解決できる場面があること。
よく聞く場面は、SNSやソーシャルゲームのログイン時にユーザ情報を参照する処理のように、単純な参照処理だが大量のアクセスが発生する状況で使われる。

データベース技術の今後の動向: プログラマの思索

最近「ビッグデータ」というバズワードが頻出される理由は、クラウドが並列処理と相性が良く、大量データを短時間に処理できるために、大量データから意味ある論理を導くデータマイニングが注目されているからだろうと思う。
従来のDOAでは、データウェアハウスのような設計思想もあったけれど、パフォーマンスが悪くて、なかなか手軽に使えなかった状況があったからだ。

現場の業務システムは、運用後にかなりのトランザクションをためているものの、それらのデータを解析(データマイニング)して、そこから得られた知恵を再利用する手法はほとんど取られていない。
よくある例は、購買履歴から顧客の購買動向を分析するCRMが欲しいという要望が多かったが、その仕組みが従来はなかなか作りにくかった、という弱点があったと思う。
Amazonのおすすめ商品のような協調フィルタリングを実装するのは敷居が高い。

他にも、従来のDOAでは、製造業向け生産管理システムのMRP(部品の所要量計算)、会計システムの自動仕訳とPL・BSレポート出力も、普通は日次バッチ処理で1日1回(または月次バッチで月末1回、年次バッチで1年に1回)作られるだけだった。
従来のDOAを支えるRDBMSの制約、バッチ処理プログラムの性能が出ないなどの制約などの理由で、夜間バッチ処理でしか対応できなかったのだ。

「オンプレミス・システムの終わり」の始まり~AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道

基幹系バッチ処理をHadoopで高速化: プログラマの思索

Hadoopの本質は分散I/Oにあり~クラウド時代の非同期処理: プログラマの思索

クラウドのもう一つの本質~ソフトウェアの可搬性を確保する: プログラマの思索

でも、クラウドとデータマイニング・データ集計の並列処理を組合せることで、CRMのデータを手軽に作り出せる。
MRPによる原価計算や、自動仕訳後のPL・BS出力も1日数回以上実施できるようになる。
そうすれば、原価計算や会計処理、CRMなどの経営分析も、アジャイル開発っぽく、何度も試行錯誤しながら仮説検証していくスタイルを実施しやすくなる利点がある。

最近、リーンスタートアップという経営手法が注目されている。
その理由は、経営手法でもアジャイル開発のやり方を実践して効果が出せるからだと思うが、その背景には、クラウドを使って、少人数でWebサービスをリリースすればすぐにビジネスを開始でき、スケールアップも容易である特徴を生かしているからだと思う。

クラウドという単なる一つの技術が、従来のDOAやOOAでは解決しにくかった問題に対して有効である場面が増えてきている。
それら効果についても今後、追いかけてみる。

【追記】
クラウドとセットで語られるNoSQLについては、7つのデータベース 7つの世界の本が個人的にはお勧め。
7種類のDB(PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4J、Redis)の特徴について、広く深く記載している。サンプルソースもあるので、とっつきやすい。

| | コメント (0)

2014/01/03

パターンを使うもう一つの動機~パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する

パターンを使う動機が2種類あり、最近は別の動機があるという記事を見つけたのでメモ。

【元ネタ】
Ajaxデザインパターン|Ouobpo

パターンの次世代|Ouobpo

【参考】

(引用開始)
 以前も書いたが、この書籍で見られるのも、知識を体系化するための技法としてのパターン言語だ。本書から引用すれば、次の通りだ。
Since the Ajax Patterns began to be published, the focus has always been on the "Ajax" and not the "Patterns."
(このAjaxパターンを公開し始めてから、常に「パターン」ではなく「Ajax」に力点を置いてきた。)
発見されるべきものとしてのパターンではなく、知識をまとめるツールとしてのパターンの動きは、今後ますます充実していきそうだ。
(引用終了)

(引用開始)
 つまり、ここで挙げた2つの書籍はどちらも、パターンを書くために書いたものではなく、著者が言いたいことを上手く伝えるための手段として、書籍の形式としてのパターンが選ばれただけなのだ。

 結果的にできあがる書籍は同じようなパターン書籍であったにしても、この両者の執筆スタンスの違いは大きな違いを生み出すと考えられる。
 パターンを書籍の一形式として扱う場合、パターンを書く、という行為に対する自制はほとんど効かなくなる。
 「古典的な」パターンコミュニティにおいては、パターンとは時間の試練によって鍛えられたものであって、決して斬新な発明であってはならないという認識がある。パターンの著者たちは、「実際に三回以上出会ってからでないと、それをパターンとして記述してはならない」というルールをもっている。
 しかし、パターンを単にコミュニケーションを円滑にするための形式だと捉えてしまうと、こうした厳格な自制は働かなくなっていくだろう。
 コミュニケーションの手段というエクスキューズによって、よりカジュアルにパターンをでっち上げられるようになる。
 (HohpeやEvansが軽い気持ちでパターンを書いたと思っている訳ではない。
 彼らは長年の経験から、何度も使ってきたノウハウを文書化したはずである。
 私が指摘したいのは、今後パターンがたんに書籍の一形式になりうる可能性である)
(引用終了)

古典的なパターンの考え方は、長年の経験から、繰り返し出現する問題やその問題解決を抽出し、カタログ化し、パターン言語としてまとめるためのものだった。
しかし、最近の特徴として、「エリック・エヴァンスのドメイン駆動設計」「Ajaxデザインパターン」では、知識を体系化するための一技法としてパターンが使われているらしい。

この考え方にはとても共感する。
XPでは、プロセスのパターンを故意に「プラクティス」と呼んで、実践的な運用ルールとして提示し、その過激さの裏でその重要性を示した。

更に1歩進めると、現場で得られた経験知、実践知は、パターンという形式でまとめることで、そのノウハウを再利用できるだけでなく、コミュニケーションを促進することもできる。

何らかの事象に「パターン名」という名前をネーミングすることで、その言葉に新たな価値を注入し、よりたくさんの現場で実践されて、検証されて、人々の中で確かな知識や概念として定着していく。

以前の下記のTwitterを思い出しながらすごく共感している。

Twitter / quicy: チケット駆動開発は、ミニマムなライトウェイト手法に一通りの体系化とカッコいい名前を与えてくれたことが、ものすごく大きな功績だと思います。

Twitter / sakaba37: それまでどこのメーカーでもしていたことが、プロダクトラインと言う言葉ができて議論できるようになりました。チケット駆動開発もその言葉の普及は重要なことの一つだと思っています。

Twitter / sakaba37: 新しい言葉がはやる時、その言葉は新しい意味・新しい価値を持っている。チケット駆動開発という言葉がはやるのも、多くの人がその価値を感じているからだろう。


| | コメント (0)

2014/01/02

Webユーザエクスペリエンスのためのパターン集~Ajaxデザインパターン

Ajaxデザインパターン」という本を見つけたのでメモ。

【参考】
O'Reilly Japan - Ajaxデザインパターン

Main Page - Ajax Patterns

パターンとライブラリで作るAjaxおいしいレシピ(1):jQueryを使ってTwitterをおいしくマッシュアップ (1/4) - @IT

JSONP - @IT リッチクライアント用語事典

Ajaxデザインパターン|Ouobpo

Ajaxデザインパターン - プログラミングパターン (1)|Ouobpo

Ajaxデザインパターン - プログラミングパターン (2)|Ouobpo

Ajaxデザインパターン ―ユーザビリティと開発効率の向上のために - Foo am I?

up J's street on Blog: Ajaxデザインパターン ―ユーザビリティと開発効率の向上のために

@ITでAjaxネタ(デザインパターン, MVC等)の連載をさせていただくことになりました : アークウェブのブログ

【1】RedmineのVer2.3から、管理画面に「JSONPを有効にする」チェックボックスがいつの間にやら付いている。

JSONPとは、JSONP - @IT リッチクライアント用語事典にあるように、JavaScriptから外部ドメイン上のJSONデータを取得する技術だ。

JSONPを有効にすることで、クライアントPCのブラウザで動くJavaScriptプログラムから、RESTやSOAPなどのAPIを簡単に扱えるようになる。

Redmineは外部接続I/Fの種類がとても多いので、クライアントPCも含む外部システムからデータ操作したい場合、JSONPが使えるようになれば、選択肢がより広がる。

ここで、JavaScriptでリッチUIをプログラミングする時に、Ajaxデザインパターンという考え方があるらしい。
Blog記事を読むと、Ajaxデザインパターンは2007年頃に出版されたらしいが、最近ならJQueryでも同じような設計手法が使えるだろうと思う。

アジャイル開発から発展したリーンスタートアップのように、スタートアップ企業がWebサービスで起業する事例が最近多い。
その場合、ユーザが触れるユーザインターフェイスの使いやすさが、以前にも増して重要になっている。

最近なら、Microsoftが検索エンジンBingで、青色のテキストリンクを変えただけで、70億円もの利益を増やしたという事例があった。
たかがテキストリンクの色と思うだろうが、そういう細かなユーザインターフェイスを変えただけでも、利益が大きく変わるのだ。

テキストリンク色の変更で、70億円(!)を稼ぎだすことに成功したマイクロソフト - Feel Like A Fallinstar

クリック率の高いテキストリンクの色は?【2013年版】 | ウェブ力学

そこから、ユーザエクスペリエンスという言葉が生まれて、アジャイル界隈で、アジャイルUXなる言葉も出てきたのだろうと推測する。

UIのパターンは色々あるだろうが、Webシステム開発に携わるならば、Ajaxデザインパターンのような考え方も理解しておくといいかもしれない。

@ITでAjaxネタ(デザインパターン, MVC等)の連載をさせていただくことになりました : アークウェブのブログに書かれている下記の内容は全く同意。

(引用開始)
Ajaxデザインパターンの方は、これを使うとコミュニケーションのコストを下げることができますし、また、コードの再利用もしやすくなります。
たとえば、「検索フォームでキーワードを入力すると、入力途中でも検索結果が表示されるやつ」というよりも、「LiveSearchパターン」と言った方が簡潔で伝わりやすいですよね。
(引用終了)

パターン名が、機能の内容やパターンが使える状況を暗黙的に説明してくれる。
パターンは単なる設計ノウハウだけでなく、コミュニケーションの一部でもある。

【2】以下、下記のBlog記事がとても優れているので、後で参考にするために、引用しておく。

Ajaxデザインパターン - プログラミングパターン (1)|Ouobpo

Ajaxデザインパターン - プログラミングパターン (2)|Ouobpo

(引用開始)
【Webサービス】
●RESTful Service (RESTサービス)
 Webサービスを構築する方法の1つに、REST(Representational State Transfer)スタイルを使う方法がある。

●RPC Service (RPCサービス)
 Webサービスを構築する方法の1つに、RPCスタイルを使う方法がある。

●Ajax Stub (Ajaxスタブ)
 RPCスタイルのWebサービスをJavaScript側で呼び出す場合、直接XMLHttpRequestを使う方法もあるが、サービスの呼び出しをJavaScriptコードから隠蔽する「Ajaxスタブ」をブラウザ側で用意して、それを介してサービスを利用するようにする方法もある。Ajaxスタブを使うと、リモート通信のコードを、Ajaxアプリのコントロールロジックから切り離すことができる。SAJAXやDWRなど、Ajaxスタブを作成するためのフレームワークがある。

●HTML Message (HTMLメッセージ)
 サーバが返すレスポンスのデータ形式の1選択肢として、HTMLの断片を直接送る方法がある。この場合、ブラウザ側では innerHTML 属性を使ってHTMLをそのまま描画する。

●Plain-Text Message (テキストメッセージ)
 サーバが返すレスポンスのデータ形式の1選択肢として、シンプルなテキストをそのまま送る方法がある。ブラウザ側では、テキストをそのまま使うか、簡単なデータフォーマットを解析してデータを抽出して使う。

●XML Message (XMLメッセージ)
 サーバが返すレスポンスのデータ形式の1選択肢として、XMLを使う方法がある。XMLだと、複雑なデータ構造を表現できる。また標準のデータ形式なので、多くのツールやライブラリのサポートを利用できる。

●JSON Message (JSONメッセージ)
 サーバが返すレスポンスのデータ形式の1選択肢として、JSON(JavaScript Object Notation)形式を使う方法がある。JSONはJavaScript標準のオブジェクトシリアル化のフォーマットなので、JavaScript側で非常に簡単に扱うことができる。XMLと同様複雑なデータ構造を表現できるが、XMLよりコンパクトになるのが特徴。

【ブラウザ-サーバ間の対話】
●Call Tracking (呼び出しトラッキング)
 複数のXMLHttpRequestコールを制御するには、コールのトラッキングをする。トラッキングの具体的な方法はXMLHttpRequestのラッパを作ることで、トラッキングによってコールのプーリングや直列化、ロギングなどを実現する。

●Periodic Refresh (定期的な再読み込み)
 サーバ側の変更をAjaxアプリに常に察知させるには、ブラウザ側で定期的にXMLHttpRequestコールを実行して、サーバ側の情報を取得しつづけるようにする。

●Submission Throttling (送信スロットリング)
 ブラウザからのデータ送信が断続的に複数回行なわれるような場合、送信イベントの度にサーバへデータを送信する代わりに、ブラウザ側で送信バッファを作って、一定間隔でまとめて送信を行なうようにする。Prototypeの TimedObserver オブジェクトなどが送信スロットリングの用途に使える。

●Explicit Submission (明示的送信)
 ブラウザからのデータ送信の一方法として、ユーザに送信ボタンを押させることで明示的に送信する方法がある。

●Distributed Events (分散イベント)
 AjaxアプリでMVCを意識した疎結合の設計を実現するには、JavaScriptのイベントメカニズムを積極的に使う。

●Cross-Domain Proxy (ドメイン横断プロキシ)
 外部サービスを組み合わせた(マッシュアップ)アプリを作りたいときは、Ajaxアプリが直接複数のサービスと通信するのではなく、外部サービスを連携させるプロキシサービスを作り、Ajaxアプリはそこだけと通信するようにする。
(引用終了)

(引用開始)
【DOMの読み込み】
●XML Data Island (XMLデータ貯蔵庫)
 サーバから受け取ったXMLデータをブラウザ側で一時的に保存しておくには、HTMLノード中に タグで囲まれたXMLデータを埋め込んでおく。

●Browser-Side XSLT (ブラウザ側XSLT)
 サーバから受け取ったXMLデータをレンダリングする方法の1つとして、ブラウザ側でXSLTを使ってXMLからXHTMLに変換する方法がある。

●Browser-Side Templating (ブラウザ側テンプレート)
 サーバから受け取ったXMLデータをレンダリングする方法の1つとして、JavaScriptベースのテンプレートエンジンを使って、ブラウザ側でXMLとテンプレートからHTMLをレンダリングする方法がある。JavaScriptベースのテンプレートエンジンには、Ajax PagesやJavaScript Templatesなどがある。

【コード自動生成と再利用】
●Server-Side Code Generation (サーバ側コード生成)
 HTMLとJavaScriptを自動生成するサーバ側のフレームワークやコンポーネントを使うことで、サーバ側のプログラミングだけでAjaxアプリを構築することができる。利用できる技術には、Ruby on Railsフレームワークや、JavaのAjaxTagsタグライブラリがある。

●Cross-Browser Component (ブラウザ非依存コンポーネント)
 IEやFirefox、Safariなどブラウザ間の微妙な非互換性に対処するには、ブラウザ非依存の汎用コンポーネントを作成し、それを使う。

【パフォーマンス最適化】
●Browser-Side Cache (ブラウザ側キャッシュ)
 Ajaxアプリのレスポンスのパフォーマンスを上げる方法の1つに、サーバから受け取ったデータをブラウザ側でキャッシュしておく方法がある。キャッシュは、クエリと結果のペアを保持したJavaScriptのマップで実現する。

●Predictive Fetch (予想読み込み)
 Ajaxアプリのレスポンスのパフォーマンスを上げる方法の1つに、次のユーザのアクションを予想してあらかじめコンテンツを読み込んでおく方法がある。Google Map では、地図のナビゲーション中に表示されていない部分も予め取得しているので、ユーザは読み込みを待つことなく地図のスクロールができる。

●Guesstimate (当て推量)
 サーバへのアクセスを減らす方法として、必要がある度にサーバへアクセスするのではなく、アクセスを少なくして、その代わりアクセスによって得られた情報を元にブラウザ側で推測値を計算して使う方法がある。たとえば、GMailのトップに表示されるメールサーバのディスク容量表示は、実際の情報を表示しているのではなく、一定間隔でサーバから得た情報を元に当て推量で表示されている。

●Multi-Stage Download (多段階ダウンロード)
 コンテンツダウンロードのパフォーマンスを最適化する方法として、一度にすべてのデータをダウンロードするのでなく、重要なものから順番に、いくつかの段階に分けてダウンロードする方法がある。

●Fat Client (重量クライアント)
 デスクトップアプリのように高機能で応答性の高いアプリを設計するには、作業のほとんどをブラウザ上で処理し、必要最低限のサーバアクセスを行なうAjaxアプリを構築する。たとえば、GMailがその一例。
(引用終了)

| | コメント (0)

« 2013年12月 | トップページ | 2014年2月 »