混乱するプロジェクトを1から10までガチガチに管理するのではなく、うまくいくようにそっと手を貸してやること。そんな発想の転換が実はいまどきのプロジェクトを上手に運営するコツなのかもしれない。本連載では「自己組織化」という概念をプロジェクト運営に応用するノウハウをお伝えする。（＠IT編集部） 1. プロローグ～大火事プロジェクトの火消し役が計画した、あるひそかな実験 昨年、火が付いたプロジェクトに火消しマネージャとして参画することになりました。チームメンバーは連日の徹夜で疲弊し切っていました。マネージャ陣との信頼関係すら怪しい状況でした。クライアントからは怒声が飛び、連日のように詳細な進ちょく状況報告を求められます。報告作業自体が開発スケジュールを圧迫していました。データベースのテーブル定義でもめている段階なのにもかかわらず、カットオーバー予定日は目前に迫っていました。タフな判断と徹夜の作業

日ごろ何気なくショッピングサイトなどで見かける暗号化（SSL）や情報保存（Cookie）の仕組み。そのセキュリティは本当に信じられる状態にあるのか？　今回の記事では、利用者が必ず知っておくべき真偽の判断基準を解説する。 オンライン・ムック「スパム時代のサニタイズ開発手法」では、ソフトウェア開発におけるネットワークセキュリティの考え方について解説する。このムック連載でポイントとするのは開発手法ではない。企業のマネジャーや経営層が理解しておくべきセキュリティそのものの考え方だ。 既報のようにネットワークセキュリティの対象は、OSからアプリケーションの脆弱性を突くものへとシフトしつつある。その理由にはさまざまなものがあるが、企業はいまセキュリティ対策をどのように考えるべきなのか？　脆弱性がニュースとなり数時間のうちに世界中へ情報伝達する昨今、根本的なセキュリティへの周知が問われているのだ。 この

ウォークスルーで新システム、新業務のイメージ共有：企業システム戦略の基礎知識（13）（1/2 ページ） コンピュータの専門家ではないユーザー企業の担当者であっても、発注企業として行うべき最も大切なことは、業務フローをはっきりさせることだ。今回はそのテクニックとしての“ウォークスルー”を解説する。 前回までで12回にわたり、企業システム戦略の立案・実施に役立つ基礎知識として、そのポイントを各作業フェイズの順に一通り解説してきた。ここで成功への鍵となるプロジェクト管理について、発注企業の立場として押さえておくべき基礎知識を総括して解説する。まず今回は、ウォークスルーについてだ。ウォークスルーとは、芝居の立ち稽古（げいこ）のこと。台本を初めから終わりまで一通りに演じてみる稽古のことである。 システムは目に見えない“業務”というものを対象として要件を考えなければならないので、当初の思惑と実際のシス

ってあまり知られてないのかなあ。Windows限定ですが、足跡追跡がイヤンな人は使うとよいです。 mixiCat http://homepage3.nifty.com/neko33/lzh/mixicat.htm もちろん普通のブラウザ上はmixiからログアウトしとく。 昨日、新案件のお話を私の師匠の会社から戴く。コンペになりそうなんだけど、取り敢えずざっくり見積もりを出さねばならん。 お客様が出したRFPを見ると、業務フローとビジネス要件の箇条書きが、割と丁寧に書いてあったので、それを元にマジカってみました。 こないだのセミナーでおしごとパズルに超燃えだったのだけど、おしごとパズルはまだ公開されてないので、セミナーで貰った資料をコピーして修正液で矢印や文字を消して自分で作りました。 作業中 隣に座ってるお姉さんに「お子さんのですか？」とゆわれました。 印刷して、プリンタの前に行ったら、他

携帯アドレス、Gmail、YahooMailにメルマガが届かない場合 こちらから受信設定をお試しください。 また、購読期間内のメルマガ(有料・無料)はマイページから再送できます。 マイページをお持ちでない方は、新規にご登録ください！ →informationページへ

［ラウンドアップ］2005年にもっとも読まれた記事、編集部が選んだ重要ニュース、ブロガーからのトラックバックランキング、検索キーワードランキング、IT・インターネット業界のIPO総括から2005年一体どんな年だったのかをまとめてみよう。

いかに生産性を上げつつ、高品質なソフトウェアを開発するか。この究極の課題に応えるのが、「テストファースト」だ。「＠IT ITアーキテクト塾」第2回では、テストファーストの概要、メリットおよびその実践について、会場と講演者を交えてディスカッションを展開した 通常のテストと「テストファースト」の違い セミナーの第1部は、アークウェイの黒石氏による講演「テストファーストの実践」。黒石氏はマイクロソフトのコンサルティング本部を経て、現在は.NETを中心とするコンサルタントとして活躍している。マイクロソフトに所属していたとき、顧客企業が先行して実践していた「テストファースト」に衝撃を受け、これがコンサルタントとして独立する契機になったそうだ。 では、そのテストファーストとはいかなる手法なのか。黒石氏は冒頭で「一般的なテストとは、システムに何らかを入力し、バグを見つけ出すこと」と説明し、「こうした一般

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

受託開発など、ソフトウエアに絡む取引の会計処理が厳格化されることになった。日本の会計基準作りを担う企業会計基準委員会（ASBJ）がガイドラインを公表したもので、2007年4月以降に始まる事業年度から適用する。今回のガイドラインは、受託開発とパッケージソフトの開発・販売の両方が対象だが、受託開発への影響が大きい。1年の猶予期間で、ITサービス会社は売上計上の方法を見直し、現場に新ガイドラインを徹底させる必要がある。 具体的には、次のケースで売上計上するには、「取引の存在を確認し、客観的に説明できるようにする」ことを義務付けた。（1）取引契約がITサービス企業間にとどまり最終顧客とまだ契約できていないない、または契約書がドラフト段階にある、（2）成果物の提供が終わったことを示す検収書などが入手できてない、または検収書があっても入金が遅れていたり、バグの発生などで作業が続いていたりしている、（3

30分間データモデリング ～ER図を描こう！～：データベースエンジニアへの道（2）（1/4 ページ） 本連載は、ITシステム開発の現場でプログラミングやSQLのコーディングを行っているエンジニア（データベース利用者）が、データ管理者（DA）やデータベース管理者（DBA）へステップアップするための第一歩として有効な基礎知識を紹介する（編集局）