タグ

2006年9月16日のブックマーク (30件)

  • 出産について聞いたこと: 極東ブログ

    先日文仁親王妃が出産を終え宮邸にお帰りになるというニュースがあったが、こうしたことは庶民の出産でも同じで、病気というわけではないが母親は産後一週間ほど入院する。別段どうという話でもないのだが、先日ラジオ深夜便でオーストラリアの出産事情について興味深い話を聞いた。出産後の入院だが出産後四日もすると病院ではなく高級ホテルに移ることもあるというのだ。もちろん夫も休暇を取り、三、四日、と新生児と過ごす。お祝いのシャンペンとかも出るらしい。病院とホテルでも連携はできているらしく、ホテルには常勤の看護師もいるとのこと。 話を聞いてこれはいいんじゃないかと思ったし、日とかでもやればできそうな気がするが、実際にはいろいろ規制があってだめなのだろう。 そういえば以前まついなつきの「笑う出産〈2〉やっぱり2人目もおもしろい」(参照)を読んだおり(このはもう手元にはないので記憶によるだが)、二人目の出産は

  • Map2.0-スゴイ地図はスゴイ : 大西 宏のマーケティング・エッセンス

    2006年09月16日16:06 Map2.0-スゴイ地図はスゴイ カテゴリインターネット kinkiboy Comment(1)Trackback(1) リクルートが公開したMap2.0ともいえるβ版の地図情報サイト「スゴイ地図」が話題になっています。公開サイトにアクセスが殺到してアクセスできない状態になっています。まずそれがスゴイですね。だからその動作の面白さが経験できなくなっていますが、ご覧になれなかった方のために、コピーしておいた画面を掲載しておきます。 地図にスポットが表示され、下にはお店の写真がでてきます。それ自体が視覚的に楽しめる地図になっていますが、お店も含めてスポット情報として自由に登録でき、さらに「ドコイク?」というお店情報にもリンクさせるというしくみは、まさに地図をツールからメディアに進化させるものとして注目されます。 >>「スゴイ地図」はウェブのリッチ・インタラクシ

    Map2.0-スゴイ地図はスゴイ : 大西 宏のマーケティング・エッセンス
  • “正しいログ”と日本版SOX法の関係は?

    “正しいログ”と日版SOX法の関係は?:セキュリティツールで作る内部統制(6)(1/2 ページ) 最近いろいろなお客さまから「ログを集約したい」という要望をいただいており、話をする機会も増えています。 実際にはログを集約する前に検討しなくてはいけないことや、ログを集約した後も検討すべきことがあり、こういった事前の検討が非常に重要です。今回は監査と監視をテーマに、主にログに関して考えるべきことを解説していきます。 なぜ「ログ」を収集するのか? まず、ログを集約する前に、その対象となる「ログ」とは何なのでしょうか? そして、何のためにログを取得するのでしょうか? ログは、監査ログ(audit log)、監査証跡(audit trail)ともいわれますが、実際には「活動の記録」、つまりは「業務プロセスの実行の記録」です。このような「記録=ログ」の取得の目的は、以下のようなものになります。 目的

  • ドキュメントを作成しないユーザーは、失敗する − @IT情報マネジメント

    ドキュメントを作成しないユーザーは、失敗する:ユーザーサイド・プロジェクト推進ガイド(15)(1/2 ページ) システム開発にドキュメントはつきものだ。しかし、しばしばドキュメントが作られないプロジェクトが見られる。ドキュメントがないとどのような事態が発生するのだろうか? コンピュータ・システム開発プロジェクトにおいて、ユーザーサイドではどのようなドキュメントが作成、準備されているのでしょうか? 対象業務の概要を個条書きしたもの、現状使われている伝票や帳票類、現行システムのソフトやハードの構成図、それに画面のハードコピー、もしくは完成図書一式を資料として用意すれば十分でしょうか? あとは打ち合わせの中でベンダへ口頭で伝えればよい──といえるでしょうか? 関係部署が1つか2つ程度で限られた業務だけを対象とする小規模なシステム、あるいは現行システムの単純な更新であれば、この程度の資料だけで間に

    ドキュメントを作成しないユーザーは、失敗する − @IT情報マネジメント
  • 企画提案の“知見”を組織で拡充する「プロセス

    前回「企画提案のやり方を変革する『方法論』」で、コンサルティング・プロモーション方法論のコンセプトについて解説を行い、特に「提案仮説」について詳細な説明を行った。今回はコンセプトから展開される「コンサルティング・プロモーションのプロセス」の説明を行う。コンサルティング・プロモーションは、次に図示するプロセスを持つ。 プロセスの重要性 前回、方法論とは何かを解説した。その中で、方法論の価値はコンセプトの優劣で決まること、プロセスとはコンセプトおよび方法から展開された仕事の進め方であることを述べた。しかしこれを単純に受け止めて、「コンセプトが分かればプロセスは重要ではない」と理解してはならない。実は組織的に企画提案のレベルを上げるためには、プロセスは非常に重要である。 仮にいまのあなたが、すでに「顧客の意向を超え、競争相手の水準を超える」レベルでシステムの企画提案ができるのであれば、コンサル

    企画提案の“知見”を組織で拡充する「プロセス
  • プロトタイプを重視するカルチャー

    最近、UIEJのメンバーの間で「うみがめ」というGoogleの「20%ルール」に相当するルール作りの話が盛り上がっている。ルール作りはおおいに結構なのだが、「なぜうみがめが必要か」というプリンシプル(相当する良い日語がないが、あえて選ぶなら「筋」-詳しくは「プリンシプルのない日」参照)を見失って「ルールのためのルール作り」に陥らないで欲しい、というのが私からのお願いである。 そこで、今まで私がプロトタイプ作り、ベータ版サービスの重要性に関して言って来たことをまとめてみた。 1.UIEのような会社にとって何よりも大切なものは、賢くてクリエイティブな人。そんな人たちが働きたいと思うような、そして彼らがクリエイティビティを最大に発揮できるような環境を提供することが大切。 2.当のイノベーションはごく少人数でおこすもの。一人とか二人とかのクリエイティブな人が、「こんなもの作りたい」という情熱

  • サッカーに新たな大技? 話題呼ぶ「くっつきドリブル」とは。

    熱烈なサッカーファンの間では少し前から知られているようなりが、最近、じわじわと話題になっているサッカーの新技「くっつきドリブル」をご存知なりか? 正式な技の名前はまだ固まっていないようなりが、すでに「くっつきドリブル」という、何とも締まらない名前で認知されているこの大技。長い歴史を持つサッカーの世界で、誰も実践してこなかった&誰も考えつかなかった技を繰り出す一人のブラジル人サッカー選手が注目を集めているなりよ。 その選手は18歳のケルロン・ソウザ・モウラ選手。ブラジルの名門クラブであるクルゼイロ所属のMFの選手なりよ。ケルロン選手が繰り出す「くっつきドリブル」は、ズバリ「足を使わないドリブル」。なんと、頭でリフティングをしながらピッチを走り回り、相手陣地に切り込んでいく大技なりね。「普通にドリブルするよりも遅いスピードだから止めようもあるのでは?」と思うところなりが、頭の上をはねるボールを

  • はてぶがドンドン馬鹿になっていく | fladdict

    はてなブックマークが物凄い勢いで衆愚化していっている。 別にGigazineが悪いわけではまったくないけれど、Gigazineのエントリーが頻出するようになったあたりから、どんどんエントリーの質が下がってきている。もう最近あまりホッテントリも読まなくなった。 新しいこと画期的な概念、難解な議論は、とくに吟味もされずにスルーされて、まとめサイトや実務系tipsのような単なる再生産なのだけど実務での使用に耐える、そんなんばかりが増えていく。 結局ユーザー参加型コンテンツがたどり着くところはココなのか? なんかみんなロングーテールスゴスって言ってるけど、逆を言えばあれは流通するコンテンツの8割方は箸にも棒にも引っかからないレベルってことなんしょ? っていうか、ブクマ系サービスがみんなスコアリングが単にユーザー総数ってどうなのよ?? と思う。 そんなメモ。 <追記> 最近マジメなエントリを書いても

  • AKIBA PC Hotline! Junk Blog.: サクラエディタはベンチマークの夢を見るか?

    12日(土)に行われたAMDによるAthlon 64 X2対Core 2 Duoのベンチマーク対決は、いくつかの点で意表を突かれた。競争の軸が最上位モデル同士のピーク性能ではなく、ボリュームゾーンの価格帯で選出された製品同士の性能比較だったという点は、周囲の業界関係者も思わず「えっ」といった反応。CPUメーカーから大々的に予告された対決デモの内容が、まさか中・下位モデルのAthlon 64 X2 4200+とCore 2 Duo E6300との対決だったとは誰も予想しなかったろう(笑)。 上位モデルでの比較では不利だからなのか?と勘ぐることもできるが、相手に興奮状態で殴りかかったように見せておいて、実は相手に有利な土俵にはあえて乗らずに勝負したのだとすれば、それはそれで驚くべき冷静さだ。CPU自体はすでにどちらも普通に使う分には十分すぎる性能を持ち、省電力設計という点である意味ようやく肩を

  • わたしが知らないスゴ本は、きっとあなたが読んでいる: 名著!「デッドライン」

    長くなりすぎたこのエントリのレジュメ …というか、見出しの一覧。これ見てご興味ある方はお読み下さいませ。 マネジメントの4つの質 マネジメントおける簡潔で痛切なエッセンス(一部) 設計とデバッグに関する恐ろしい事実 残業と生産性とプレッシャーに関する恐ろしい事実 生産性の測定について 管理者の怒りについて 会議を効率よく行うための、たったひとつの冴えたやりかた 大事なことが、ずばり書いてある。背中を押したのは「ソフトウェア開発の名著を読む」なんだけど、確かに名著だ。初読は物語を楽しみ、再読、再々読で血肉にすべきだな。 延ばし延ばしにしてた一冊を読み始めて「どうして今まで読まなかったんだあぁぁっ」と叫びだすような逸品がある。書がまさにそう。デマルコは「ピープルウェア」がピカイチと決め付けてた自分が恥ずかしい。 「ピープル」がプログラマ・チームリーダーの視点で書いているが、「デッドライン」

    わたしが知らないスゴ本は、きっとあなたが読んでいる: 名著!「デッドライン」
  • Amazon.co.jp: 映画『太陽』オフィシャルブック: アレクサンドルソクーロフ (著), Sokurov,Aleksander (原名): 本

    Amazon.co.jp: 映画『太陽』オフィシャルブック: アレクサンドルソクーロフ (著), Sokurov,Aleksander (原名): 本
  • Amazon.co.jp: 日本のいちばん長い日 [DVD]: 岡本喜八 (監督), 三船敏郎 (出演), 加山雄三 (出演), 黒沢年男 (出演), 小林桂樹 (出演), 宮口精二 (出演), 戸浦六宏 (出演), 笠智衆 (出演), 大宅壮一 (原名), 三船敏郎 (Unknown), 橋本忍 (脚本): DVD

    Amazon.co.jp: 日本のいちばん長い日 [DVD]: 岡本喜八 (監督), 三船敏郎 (出演), 加山雄三 (出演), 黒沢年男 (出演), 小林桂樹 (出演), 宮口精二 (出演), 戸浦六宏 (出演), 笠智衆 (出演), 大宅壮一 (原名), 三船敏郎 (Unknown), 橋本忍 (脚本): DVD
  • kuranukiの日記-アジャイル問答:ドキュメントと動くソフトウェア

    アジャイルでは、ドキュメントより動くソフトウェアを重視すると言いますが、そのソフトウェアが正しいことを証明するための有効な方法は? 確かに、ドキュメントよりも動くソフトウェアを重視しますが、まったくドキュメントが無いわけではありません。私の考える不要なドキュメントは、主に、システムの中身、モジュール構造などを表した内部設計仕様書です。ソフトウェアの内部構造については、リファクタリングを実施するので、頻繁に変化してしまうということもあり、それが動くソフトウェアを重視する理由の一つです。 ただし、ソフトウェアそのものの、振る舞いであるとか、動きの機能については、資料が必要だと思っています。所謂、外部設計仕様書です。これは、リファクタリングでは変更されない部分になります。そして、この部分は、お客様の合意が必要な部分であり、お客様がソースコードを読めればドキュメントでなくても良いですが、そういう場

    kuranukiの日記-アジャイル問答:ドキュメントと動くソフトウェア
  • いぬビーム - backup_mixi

    mixiの各データを、手元のハードディスク等に保存するツールです。特徴は以下の通り。 メッセージ(受信、送信、下書き、ごみ箱)を一括保存します。 日記も一括保存します。 日記にアップロードした画像や、メッセージ中の顔写真も保存します。 html形式で目次を作ります。 2回目以降は追加分だけを取得するので高速です。 日記をはてなダイアリー形式に変換できます。対応した各種ブログに移行できます。 気に入ったら広めてくださいね。 ダウンロード ひな。さんが機能拡張版を公開しておられます。 → http://milk-tea.que.jp/milk-cake/soft/ オリジナル版はmixiの仕様変更により正しく動作しないため、公開を中止しています。 使い方(Windowsの場合) backup_mixi.exe をダブルクリックして下さい。 「msvcr71.dllが無い」ってダイアログが出る場

    いぬビーム - backup_mixi
  • kuranukiの日記 改善型開発について

    現在のシステム開発という開発モデルを考えてみると、そのシステムを必要としており開発の依頼を発注する発注側と、実際の開発作業を請け負う開発側の間で、プロジェクトに対し契約を結んだ段階からシステム開発は始まる、というのが当たり前の話。そして、この当たり前と思われている関係でビジネスを続けると問題があるのでは、と考察したのが以前のエントリ、「ディフェンシブな開発*1」だった。 今回は、その当たり前だと思われているところについて、発想の転換を取り入れて考えてみようと思う。社会における通念や物事を大きく変えるためには、コペルニクス的転回が必要だからだ。 ノウハウを集約できないSI企業 まずこの「プロジェクト開始してからシステム開発を始める」という点について、ディフェンシブであるということ以外にも、SI企業として重大な問題点が隠されている。それは、IT技術に対するノウハウの蓄積に関する問題である。今の

    kuranukiの日記 改善型開発について
  • User Support & Training for Astah Software - Astah

    Astah believes in the power of design and modeling. Our flexible and powerful software helps you clearly explain and demonstrate your ideas, and our support resources help you make the most of Astah’s tools. Find everything you need below, from user manuals to modeling best practices.

  • 要求定義における“品質”確保の方法 ― @IT情報マネジメント

    「Gemini時代」のGoogleの広告ビジネスはどう変わる? ピチャイCEOが語ったこと テック業界の巨人の第1四半期決算発表で議論の中心となったのは、生成AIおよび「YouTube ... 「マーケティングオートメーション」 国内売れ筋TOP10(2024年5月) 今週は、マーケティングオートメーション(MA)ツールの売れ筋TOP10を紹介します。 サッカー欧州CLを早朝に観戦するアジアのファンのためにハイネケンが仕掛けた意外過ぎるキャンペーンの中身 時差のためUEFAチャンピオンズリーグを早朝に視聴せざるを得ない韓国サッカーファンの... 「ITmedia マーケティング」新着記事 Copyright(c) 2000-2017 ITmedia Inc. 著作権はアイティメディア株式会社またはその記事の筆者に属します。(著作権について) 当サイトに掲載されている記事や画像などの無断転

  • 続マジカのひみつ

    マジカを使って若手に実験。なかなか興味深い結果が得られた。前回のマジカのひみつはここ。 実験対象 入社2-4年の若手社員(♂3人) SEとして分析・設計をやるかたわら、テスターとして試験もやってる java読み書きはできるが、プログラマではない 予備知識なし (゜Д゜)ハァ? まじかァ? という連中 実験1:マジカなし マジカの説明なし。ある企業の業務フローをポンと渡し、「明日このヒアリングを顧客とする、という状況で、疑問・質問・ツッコミをピックアップしてね、15分でね」 対象となった業務フローはセミナーでもらったもの。どこの企業にもある「与信業務」「受注業務」に限定して分析を行う。 マジカなしの場合、出てくる質問はさもありなんなものばかりだった。つまり、誰でも思いつく質問だし、回答する方もそれなりな準備がされているものばかり。 手続きのフォーマットはありますか? 与信の基準となるものはあ

    続マジカのひみつ
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: マジカのひみつ

    羽生章洋さんの業務分析セミナーを聴講した(業務プロセス改善技法ワークショップ第2回)。ここで紹介されたMagiCa は「いますぐ」「ここで」「誰でも」使える方法ナリ。「MagiCa って何?」という人はここからダウンロードどうぞ(要メールアドレス)。羽生さんご人のマジカ説明はここ。謳い文句「現場主体で仕事の棚卸と見える化を簡単に実現する」は禿同。自分なりの分析手法は確立しているんだが、上手くMagiCaを盗んでみよう。 ひみつ1 : 最初はチョキ 「さあ、業務分析しましょう」と話を持ってきても、人は動かない。現場の人はどうしても構えてしまう。「業務フロー」なんてSEやコンサルならともかく、普通の現場の仕事している人は書いたことがないから、「間違えたらどうしよう」と固くなってしまう。 凝ったココロをどうするかというと、ハサミが登場する。MagiCa はA4用紙を8分割した程度の大きさ。最初

    わたしが知らないスゴ本は、きっとあなたが読んでいる: マジカのひみつ
  • http://blog.nikkeibp.co.jp/itpro/it-service/archives/2005/06/post_2.html

  • "コモディティ化と人月"の現実 (arclamp.jp アークランプ)

    arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ まだ反響をいただくこともあり、やはりみんなが興味があるところなんだなと実感しています。 まず、大前提なのですが、「ハッカーが集められない」「アジャイルは大規模開発では難しい」という事実は、もちろんそうです。僕もそう思います。だからこそ、それをどう乗り越えるのか、という話になります(ハッカーがいると良いシステムになるとか、アジャイルは顧客満足度が高いというのも前提ですね)。 倉貫さんがトラバいただいたエントリで提唱されているEXPも同じような問題意識から始まっています。XP祭り2005に倉貫さんのオープンニングセッション資料(PDF)があります。 SIerは、クライアントにとってリスク回避になっているのか? まず、自社でハッカーを雇うのが現実解でないのもわかります。

  • 企業の健康を診断する「業務分析」~IT技術者のための戦略・業務分析入門~

    企業の健康を診断する「業務分析」~IT技術者のための戦略・業務分析入門~:事例で学ぶビジネスモデリング(4)(1/3 ページ) 企業における健康志向 皆さんは、深夜のテレビCMを見て思わず健康器具を購入してしまったとか、効果が出るかどうか分からないサプリメントに何万円も費やしてしまった経験はないだろうか。実は、企業においてシステムを構築する場合にも、これと同じようなことが往々にして起きている。競合他社がERPを導入したので自社も導入を検討するとか、コンサル会社から成功事例を聞いて、CRMパッケージの導入を決断するといった話を聞くと、個人が健康器具やサプリメントを購入する話に似ていると思うことがある。当にその企業の健康状態に合った健康法の導入が行われているといえるのだろうか(図1)。 企業と個人の違い?企業は多くの視点・価値観の集合である? 健康法を導入する場合、個人ならば自分の考えで何を

    企業の健康を診断する「業務分析」~IT技術者のための戦略・業務分析入門~
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: 空気が読めないSE、話を聞かないコンサルタント

    ここしばらく開発の現場を離れ、「こんさるたんと」のお手伝いをしている。彼らのやり口が分かるにつれ、これもアリなんだと納得できるようになった。一方、彼らの「実態」を垣間見て、SE/PMとしてやりきれない無力感を抱かされたことも事実。ここでは「なぜすれ違う? SEとコンサルタント」の感想文に擬装して書きなぐる。 書によると、SEとコンサルタントの決定的な違いは2点ある。 違い1 : SEはKPI無知 目標に対しどれだけ達成できたかを測定するための指標値をKPI (key performance indicator)という。KPIは以下の4分野において設定され、モニタリングを繰り返すことで経営全体を把握する。SEはそのうち(3)のみに囚われ、全体的な視座が抜け落ちている場合が多い。 (1)財務的視点 (2)顧客の視点 (3)社内ビジネス・プロセスの視点 (4)学習と成長の視点 あるいは、SEに

    わたしが知らないスゴ本は、きっとあなたが読んでいる: 空気が読めないSE、話を聞かないコンサルタント
  • 職場でやる気を維持する方法

    「新聞」とテレビを見なくなって10年で、私が「失ったもの」、「得たもの」。(けんじろう と コラ…) 【休日ネタ】どこのどなただかわかりませんが、誠にありがとうございました。(抱き込め!ユーザー、…) 【休日ネタ】どこのどなただかわかりませんが、誠にありがとうございました。(抱き込め!ユーザー、…) 58冊+α ~ オススメしたい COMPLETE(事務局だより…) 58冊+α ~ オススメしたい COMPLETE(事務局だより…) Twitterを使っているとブログが書けなくなるのか(『ビジネス2.0』の…) 【ミッション】あの人にオススメしたい、この1冊 ~ 番長と遊ぼう!=『GOOD to GREAT ビジョナリー カンパニー2 飛躍の法則』 なのですが・・・(1/2)(破壊的イノベーション…) 【140文字】 Twitter つぶやきなのに 書き直し…お粗末(中村昭典の、気まま

  • ZDNet Japan - 強い現場を実現する“見える化”:“見える化”を支援するテクノロジ

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 2006年に入り、新聞や雑誌、フリーペパーの記事など、またセミナーやイベントの講演など、さまざまなところで“見える化”という言葉を目に、耳にする機会が多くなってきた。なぜ今“見える化”が注目されるのか。また、“見える化”とは、何であり、どのような効果をもたらしてくれるのだろうか。 “見える化”をひと言でいえば、ビジネスにおける問題を常に見えるようにしておくことで、問題が発生してもすぐに解決できる環境を実現すると共に、問題が発生しにくい環境を実現するための取り組みだ。“見える化”の実現により、コスト上の無駄や改善の余地がどこにあるかなどを明確にし、強い企業を実現できる。 強いトヨタを作り上げた“見える化” “見える化”は、何も新しい言葉で

    ZDNet Japan - 強い現場を実現する“見える化”:“見える化”を支援するテクノロジ
  • “見える化”でシステム開発を革新するチェンジビジョン:“見える化”を支援するテクノロジ(2)

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 「ソフトウェア開発は、ほかの分野に比べて見えにくい。JavaやXMLなど、テクノロジは進化を続けているのに、ソフトウェア開発の現場は昔のままのやり方で、どんなにお金をかけて最新技術を導入しても、ソフトウェア開発の現場はよくならない。それは、現場の問題にミートしていないためだ」 こう話すのはチェンジビジョンの代表取締役社長である平鍋健児氏だ。2006年2月22日に設立されたばかりのチェンジビジョンでは、企業や組織、そしてシステム開発プロジェクトの現場が抱えるさまざまな課題を“見える化”により解決することをビジョンとしている。 チェンジビジョンという社名には、“見える化”による革新的なビジョンを実践することで、顧客のビジネスを変化させていく

    “見える化”でシステム開発を革新するチェンジビジョン:“見える化”を支援するテクノロジ(2)
  • マルチタスクで人間の知力が低下する?--情報化時代のアイロニー

    これは情報化時代における最大の皮肉といえるかもしれない。 電子メールやインスタントメッセージ、携帯電話、ボイスメール、BlackBerryなど、さまざまな通信手段を通じて押し寄せてくるあらゆる情報が、実は人間に悪影響を及ぼしている可能性がある。 Dr. Edward Hallowellは、過去10年以上にわたって注意力欠如障害(Attention Deficit Disorder:ADD)の研究を続けてきた精神科医だ。同氏はADDに関連して発見した別の問題--注意力欠如特質(Attention Deficit Trait:ADT)と同氏は呼ぶ--が今、企業社会のなかで大流行しつつあるという。ADDと違い、ADTは先天的なものではない。これは現代の職場環境の産物だと同氏は主張する。コンピュータや電話、そして他のさまざまなハイテク機器から、絶え間なくしかも容赦なく情報が流れ込んでくるために、人

    マルチタスクで人間の知力が低下する?--情報化時代のアイロニー
  • http://diary.yuco.net/20060512.html

  • 河合拓氏のOUTLOOK運用法 - toyahの日記

    再開時に予告していた内容です。お待たせしました。 FRIという団体があります。私は5年ほど前からWatchしつづけているのですが、この団体を主宰していた河合拓さんの発行するメルマガ、個人的に大ファンなのです。河合さんのメルマガの言葉は、ここ数年、いつも私の心の糧になってきました。 http://premium.mag2.com/mmf/P0/00/09/P0000975.html さて、その河合さんより、この前お会いしたときに、許可をもらったので、私がGTD的な管理法をスタートするきっかけとなった河合さんのメルマガ101号を全文掲載したいと思います。(ちなみに、河合拓氏がGTDをご存知かどうかはわかりません。河合拓氏の方法はGTDに100%沿っているわけではありませんが、たくさんの類似点があると感じました) ちなみに河合拓氏のブログは以下です。 http://blogs.yahoo.co.

    河合拓氏のOUTLOOK運用法 - toyahの日記
  • 要求開発アライアンスのビジネス・モデリング道場

    要求開発とコタツモデル(2)−−アンチパターンを活用する [2008年06月17日] 前回は,要求開発・要件定義フェーズを成功させるためのポイント「コタツモデル」についての説明を行いました。今回は,具体的な「コタツモデル」形成のテクニックの一部についてご紹介したいと思います。 要求開発とコタツモデル(1)−−失敗パターンに陥らないために [2008年05月29日] 今回は,要求開発アライアンスの会員にしか知られていない,プロジェクト成功のための秘訣をご紹介します。この秘訣は要求開発アライアンスの中では「コタツモデル」と呼ばれています。 目標追跡型グローバルソフトウエア生産システムを考える(2) [2008年02月28日] 前回は,機能要件を対象とした国内開発をまず先に実施し,その後オフショア拠点を利用して非機能要件を満たすフトウエアを完成させるという基的な考え方について説明した。前