会社におけるログの重要性を考える―捜査技術の第5条「情報収集がターゲットを絞り込ませる」―：ビジネス刑事の捜査技術（10）（1/3 ページ） 警察活動において、最重要とされる「警ら活動」が民間ではあまり重視されていない。これはなぜだろうか。今回は、捜査の技術第5条「足元を固める情報収集活動がターゲット像を絞り込ませる」について、警ら活動とログの話を中心に考える。 筆者が警察組織を辞めてコンサルタント会社に勤め始めたとき、自社内の仕事を警察の仕事に置き換えて理解しようとしていた。例えば、営業は捜査に、製造はサービスを企画・設計するという意味で企画、購買は調達、総務は総務、人事労務は警務・教養、経理は会計といった感じで置き換えてみた。 特に「顧客を捜し出す営業」のような仕事には捜査の技術が役に立つ、ということに筆者は早くから気が付いていた。そんな中で、不思議だったのが警察活動の基礎ともいうべき

“紙の”ノートの取り方の工夫について紹介。また、自分専用のカスタムノートを作って、PDFとしてダウンロードできるサービスも紹介する。（Lifehacker） 【この記事は、2006年4月14日付で米ブログメディア「Lifehacker」に掲載された記事を翻訳したものです。】 好むと好まざるとにかかわらず、人生は会議の連続だ――状況確認のためのミーティング、プランニングのための電話会議、ブレーンストーミングのための集まり、そして会議のための会議もある。だが、全員が会議室を去った後、どのようなアクションが取られたかも、会議と同等かそれ以上に重要なことだ。 ビジネス会議であれ大学の講義であれカンファレンスであれ、効率よくノートを取ることは、プロジェクトを動かし、キャリアと知識を積み上げていく上で不可欠のスキルだ。今回は、筆者のお気に入りのノートの取り方を紹介する。自分のニーズにあったカスタムノー

The 18 Mistakes That Kill Startups だが、じきに誰かが日本語に訳すのだろうが、それまで待てない人のために18のポイントをざっと列挙しておこう。 創業者が一人（マイクロソフトもアップルもYahoo!もGoogleも二人ですな） 場所が悪い（シリコンバレーが一番！） 入り込むニッチが小さい 既存企業の事業から派生したアイデア 頑固（最初のプランがそのまま成功することは少ない） ダメなプログラマを雇用する ダメなプラットフォームを採用する（ヒント：Windows） 立ち上げがゆっくり過ぎ 立ち上げを急ぎ過ぎ 対象となる想定ユーザを持たない 少ししか資金を調達しない 資金を浪費し過ぎ （二つ前と矛盾するようだが）資金を調達し過ぎ 投資家へのサポートが貧弱 取らぬ狸の利益のためにユーザを犠牲にする 自分の手を汚して泥臭いことをしたがらない 創業者同士でケンカ 努力が

一般的なオフィスでは，席の配置などが元々決まっており，自由にカスタマイズできないことが多いだろう。では自由にカスタマイズしてよいと言われたら，皆さんはどのような配置にするだろうか？ 今回はTRICHORDチームで実施しているプラクティスの一つ，ワークスペース・メイキングについて解説する。 多くのオフィスでは，部署やチーム・メンバーの机を向き合わせて「島」を作る，いわゆる「島」スタイルのレイアウトを採用している。ではなぜ島スタイルで席を配置するのだろう？ オフィス・レイアウトは専門の業者に頼むため，特別な理由がない限り島スタイルの配置になる，というのが本当のところではないだろうか。 島スタイルの席配置は，「限られたオフィス空間に効率よく机を配置する」「人の動線を適切に確保する」「上司が部下を監視できるようにする（上司の席が島全体を見渡せる場所にある場合）」といった目的では一定の効果を上げてい

システムが以前よりも複雑化している現在，多くの開発者やユーザーは，「仕様変更がある程度起こるのは仕方がないこと」と前向きに受け止めてはいる。だが一方で，仕様変更によるコスト超過などが原因で，プロジェクトが失敗に陥ることが非常に多い。仕様変更によるトラブルを極力防ぐにはどうすればよいのか。現場担当者の知恵から解決法を探ってみた。 「設計書の50％に手を加えなければならないほど仕様変更が続出し，収拾がつかなくなってしまった」。NTTデータ東北の太田雅典氏（法人システム事業部 第一開発担当課長）は，数年前に手がけたある出版社の広告管理システムで，開発中に起こった仕様変更のトラブルを振り返る。このプロジェクトでは，設計が一通り終わり，実装（プログラミング）フェーズに入ってから，データベース（DB）の構造や，帳票出力用の計算式，他システムとの接続インタフェースなど，システムの根幹をなす仕様の変更を次

ノートの書き写しは、テスト前の勉強法の中でも時間のかかる方法だ。しかし学生時代を振り返ると、筆者にとって本当に有効な学習方法は唯一これだけだった。今秋、8年ぶりに学生に戻って講義を受けることになった。来週にはノートにペンを走らせているはずの筆者だが、今度こそ完璧な戦略で臨むつもりだ。「コーネル大学式ノート作成法」を正しく実践するのだ。 コーネル式については、過去にもこの記事（7月24日の記事参照）やここで取り上げたが、今回は、学期を通して――書き写しすることなく――学習・参照がスムーズに行えるノートの取り方について詳しく見ていこう。 コーネル式にページをレイアウト コーネル式にのっとり、以下のようにノートを3つの領域に分割する。 ノート欄（右）には、受講中に講義の内容を書き取る。短文や単語で、後に自分が必要とするであろうファクトを書き取っていく。必要のない言葉はすべて省略する。箇条書きにす

アプリケーション・パッケージの採用を前提としたシステム構築では，ユーザー側（発注側）と設計/導入側（ベンダー側）の間で，作業の進め方や方法で食い違いが生じることがある。今回と次回の2回に分けて，二つのケースを材料にして考えてみたい。 一つ目は，財務会計システムと受注/原価管理の基幹系業務システムを再構築しようというプラント・メーカーのケースである。このプラント・メーカーのユーザーの意向は，「できるだけパッケージの考え方や機能を受け入れてカスタマイズの範囲を最小にとどめたいが，同業他社とは異なる仕事のやり方もあるので，その部分はしっかり追加機能として実装する」というものだった。 受注したベンダーは，上流工程で「フィット＆ギャップ分析」を行い，その結果を基に直ちに概要設計をした。程なくアンフィット機能の要件一覧と見積もりが提示された。 作業はもっぱらベンダー側が用意した質問シートとチェックリス

LOCが増えると変更が難しくなるように、既存の機能(てゆか仕様?)がたくさんあると機能追加、仕様変更が難しくなるよねえ。とくに工夫しなかったら、イテレーションごとにどんどん変更速度が落ちていくと予想されます。だけど、イテレーションが進んでも、だいたい同じペースで変更できたとしたら、チームがなにかを工夫したり、うまくなったりしていると言えるんじゃないかなあ。どうだろ。 そして、ストーリーの見積もりの値の意味へ続く。 かも。

前回，PMBOKガイドで定義する三つの見積もり技法について解説しました。今回は，ベーム博士が提唱する七つの技法について解説しましょう。 ベーム博士はCOCOMOを提唱した人です。その著書「SOFTWARE ENGINEERING ECONOMICS」(1981年)の中で，工数に関する見積もり技法を以下の七つに分類しています。 (1)類推法（Estimation by Analogy） (2)トップダウン法（Top-down Estimating） (3)数式モデル法（Algorithmic Models） (4)ボトムアップ法（Bottom-up Estimating） (5)専門家判断法（Expert Judgment） (6)プライス・ツー・ウィン法（Price to Win Estimating） (7)パーキンソン法（Perkinsonian Estimating） このうち(1)

前回は，「要求開発は，ユーザー企業のためのもの」ということを知ることで，方法論（Openthology）のモデリングやプロセスの目的と価値について，改めて考えるようになったことを書きました。 この論議に続いて，ある方が「モデリングには目的がある，目的のないモデルには意味がない」と言われました。私には，衝撃的な言葉でした。そこで，今回はモデリングの目的について，考えてみようと思います。 筆者は，SI企業のSEという立場で，ユーザー企業のシステム開発プロジェクトに参画します。システム要求がきちんと整理されたRFPが存在する場合は，どうやって実装するかについてモデリングを行います。これは，「正しく」システムをつくるためのモデリングです。 一方で，そこまでの具体性がないままに発注されている場合もよくあります。この場合，ユーザー企業側でも，ビジネス要求に基づくシステム要求が整理しきれておらず，まずは

高橋さんのエントリを見て少し思うところがあった。 個人に帰着されるべきではない問題に対して個人の努力を奮起させて解決させようとするあらゆるものが大嫌い そこが分かっていないファシリテーションやコーチングは、単なる害悪だと思います。 あなたが変わることは単なる手段であり、本来はどうでもよいことのはず。肝心なことはsocialがchangeするかどうか、問題が解決・解消するかどうかで、それさえなされるのであれば、あなたも私も変わる必要などないはずなのではないでしょうか。 高橋さんのこの文章自体には客観的に賛成だけど、主観的にはちょっと違う感想を持った。どういうことかというと、つまり結城は「自分の変化」に対して非常な関心を持っていて――もしかすると問題の解決以上に自分の変化を重視しているかもしれない、ということ。他の人に対してはそんなことを要求も期待もしないんだけれど。 うーん、あまりうまく説明

まだできていません。 その言葉は言うものじゃなくて、実行するものだから。 ましてやひとに言うものじゃなくて、自分で実行するものだから。 啓蒙が不要であるとまでは言いません。でも、言葉のとおりに実行した後で、その変化を見たひとに「どうすればできるのか？」と問われてはじめて「Social change is changing yourself」とか「Social change starts with you」と答えるのが、この言葉のよい使い方だと思います。 ……とかいうことを、↓ここを見ながら思いました。 http://www.atmarkit.co.jp/im/cpm/serial/need02/need02.html そこが分かっていないファシリテーションやコーチングは、単なる害悪だと思います。 あなたが変わることは単なる手段であり、本来はどうでもよいことのはず。肝心なことはsocialが

私はSIベンチャーのサイバーテックで，読者のみなさん同様，忙しい日々を過ごしている女性SEの伊藤翠です。日経ITプロフェッショナルのWebサイトで3年間，「女性SE　さばいばる日記」というコラムを書いていました。そのコラムは今年の3月で終了したのですが，縁あって今度はITproのWebサイトで連載を開始することとなりました。以前の連載をご存知の方もいらっしゃると思いますが，初めての方もたくさんいらっしゃると思いますので，まずは簡単な自己紹介をしたいと思います。 文系バリバリの女子学生がSEに？ 大学の専攻は日本文学。バリバリの文系女子学生だった私ですが，なぜか就職した会社は独立系のSI会社でした。そこで，社会人としての第一歩をエンジニアとして踏み出すことになったのです。それまで特にIT業界に特化した勉強などはしておらず（本当は商社マンになりたかったのです），知っていることといえばメールとイ