「不幸箱」発売のお知らせ
クレバリーは、楽天市場店特設コーナーにおいて、6月23日の午後10時より「不幸箱3000」を発売する。 「不幸箱」はジャンク品を詰め合わせた内容不明のパッケージで、通常の福袋とは異なり、購入者を“やるせない”気持ちにさせてくれるのが特徴だ。秋葉原の店舗では新年初売り恒例行事である「不幸袋」としても知られており、その歴史は1997年にさかのぼるという。また、その謳い文句である「本当の不幸を見せてやる！」という言葉通り、購入者の悲鳴とともに数々の悲劇を生んできた。が、かつて600個を5分で完売した実績を持つ人気商品でもある。 今回販売される不幸箱3000は、価格3000円で300個の限定販売。商品内容はジャンク商材の詰め合わせ5～7点となっている。もちろん、保証は一切ない。そのほかの注意事項として、「不幸箱単体での販売ですので他の商品と一緒にお買い求めいただく事はできません」と記載されている。
プロジェクトキックオフ！ オリエンテーションで話すこと
プロジェクトキックオフ！ オリエンテーションで話すこと：ユーザーサイド・プロジェクト推進ガイド（11）（1/2 ページ） システム開発の経験に乏しいメンバーからなるプロジェクトチームを始めるに当たって、まずは“オリエンテーション”が必要だ。強いプロジェクトチームを作るには、最初に何を伝えるべきだろうか？ キックオフをオリエンテーションとする チームを発足する際には、まずキックオフミーティングを開催して、プロジェクトの概要、すなわち、目的、スケジュール、組織、その役割などの説明と、メンバーの自己紹介とチーム内での役割と作業の分担を決定します。 ここでは、キックオフミーティングのことを「オリエンテーション」と呼ぶことにします。 この連載では、コンピュータ・システム開発の経験があまり豊富とはいえない企業で、メンバーを業務部門から出してもらっているプロジェクトチームを想定しています。このような未経
プロジェクトチームのリーダーに向く人、向かない人 ― ＠IT情報マネジメント
チームで遂行されるプロジェクトにおいて、優秀なリーダーの存在は極めて重要です。そこで今回から、リーダーについて考えてみることにします。リーダーシップの具体的な技術に関してはコーチングなどの記事を参考にしていただくことにして、ここではもっとベーシックなところをターゲットにします。なお対象としては、ユーザーサイドに限らずプロジェクト一般についての話となります。 誰でも持っているリーダーの素質 よく話題になることに、リーダーにはリーダーとしての素質がなければならないのか、ということがあります。ある程度の素質は必要でしょうが、それは大多数の人が持っているはずです。そのように考えられる根拠はあります。 例えば、ふさわしい人が地位に就くのではなく、「地位が人を育てる」ケースはよく知られています（年功序列主義の会社ではよく見られることです）。これは、リーダーとして特別な素質がないと思われたり、思い込んだ
簡単に情報を話す人たち
ソーシャルエンジニアリングには、他人になりすますだけでなく情報を聞き出す複数のテクニックが利用される。その1つ1つに目新しさはないが、世間のセキュリティ意識の低さによって情報は簡単に引き出される。 ソーシャルエンジニアリングは、前回紹介したように他人をなりすますだけでなく情報を聞き出す幾つかテクニックが利用される。現在はセキュリティコンサルタントで、かつてソーシャルエンジニアリングを使って情報を聞き出した経験のあるA氏は、人間の会話における心理を説明してくれた。ごく当たり前にも思えるテクニックでも、意外と簡単に重要な情報を引き出せるという。 A氏が話してくれた手法を整理すると、相手に対し情報を矢継ぎ早に与えることで、混乱させることが基本となる。専門用語を多用したり、具体的な情報を一度に大量に与えることで、相手の「うっかり」や「安心」を誘い出す。通常であれば疑う内容でも、このような状態になる
“J-フォンブランド”の可能性を考えてみよう
3月17日、英Vodafone Groupとソフトバンクがボーダフォン日本法人の買収に合意した（3月17日の記事参照）。このニュースは携帯電話業界だけでなく、日本中を駆けめぐった。 あれから一週間余り。Vodafone Groupからソフトバンクに移行する狭間ということで、先週のボーダフォン日本法人は奇妙な虚脱状態に置かれていた。日常業務は滞りなく進行しているが、プロジェクトのいくつかは停滞。Vodafone Groupの息がかかった社員の中には、「本国帰還の手みやげか、就職活動しか頭にない人間もいる」（ボーダフォン日本法人 関係者）状況だという。ヘッドハンティング会社の活動も、半ば公然と行われている有様だ。 しかし、その一方で、古くからの日本法人社員達は意外と落ち着いている。Vodafone Groupと縁が切れることを喜ぶ声も少なくない。依然として待遇面への不安の声は聞かれるが、それを
テスト計画の立案
今回は、どのビルドでどのようなテストをすべきかを計画する方法について説明します。ソフトウェア開発プロジェクトでは、いろいろな計画を立てなければいけませんが、テスト計画はその中でも大事なものです。テスト範囲とテスト戦略、QA要員やテストに必要なソフトウェア／ハードウェアなどのリソース調達、そしてスケジュールなどについて、テスト計画書を記述します。また、具体的なテストケースの記述と、この実施についても計画しなければなりません（一般に、テスト計画書の中にはテストケースは含まれません）。一口にテストといっても大変に奥が深く、テストのすべてを包括的に説明しようとすれば分厚い本が書けてしまうほどですが、今回は反復型開発において注意すべき事柄に的を絞って説明したいと思います。 テストの目的 テスト計画を立案・実施する前に、なぜそのテストをするのか、そのテストの目的を明らかにしておきましょう。ソフトウェア
ITmedia No More「Adminでログイン」を呼びかけるMicrosoft
さまざまなマルウェアからPCを保護するためにも、管理者権限でのログインは避けるべきだとMicrosoftは説明する。 「Administrator権限（管理者権限）でWindowsにログインして動作させることは、マルウェアに対し、より感染しやすい方法を提供するようなものだ」――米Microsoftのマイク・ダンセジリオ氏はRSA Conference 2006のセッション「Admin No More」においてこのように語った。 スパイウェアやアドウェア、rootkitといったさまざまなマルウェアからPCを保護するために、ウイルス対策ソフトやゲートウェイでのフィルタリングなど、いくつかの対策が提供されている。しかし、ユーザーの権限を必要最低限のものに留めておくことも、多層防御の一環として重要なポイントだとダンセジリオ氏。仮にこうした対策をかいくぐってマルウェアが侵入したとしても、アカウントが
「iPodへのCDリッピングは公正使用にあらず」とレコード業界
エンターテインメント業界は、CDをリッピングして楽曲をiPodに格納する行為を合法とは認めていない。電子フロンティア財団（EFF）のフレッド・フォン・ローマン弁護士が指摘している。 現在、3年ごとに行われるデジタルミレニアム著作権法（DMCA）の見直しプロセスが進められており、その中で全米レコード協会（RIAA）などの業界団体は、手持ちのCDをコピーする場合でも、コンテンツの場所やフォーマットを変えるのは非侵害的な利用とは見なさないと主張しているという。 MGM対Grokster訴訟において、レコード業界側の弁護士だったドン・ベリリ氏は米最高裁で、「レコード会社はしばらく前から、自分で購入したCDを自分のコンピュータやiPodにアップロードするのは完全に合法だと述べていた」と話していた。 しかし業界が提出した書類には、この発言は「公正使用ではなく、単に許可に関するものである」と記されている
ライブドア関連株に売り殺到
証券取引法違反の疑いによるライブドアの家宅捜索を受け、1月17日の東京株式市場では、ライブドア関連銘柄に売りが殺到。マーケット全般にも波及し、平均株価を下げた。 ライブドアは値幅制限の下限（ストップ安）となる前日比100円安の596円で約80万6000株が比例配分されたが、発行済み株式総数の20％超に当たる約2億6000万株の売り注文を残した。ライブドアマーケティングやライブドアオート、ターボリナックス、メディアエクスチェンジ、セシールなど関連銘柄もストップ安売り気配で大引けとなった。 ライブドア株式を保有するフジテレビは前日比2万9000円安（-9.03％）の29万2000円で取引を終えた。楽天やインデックスなど新興IT系が広く売られ、日経平均株価に影響が大きいソフトバンクも480円安（-11.11％）の3840円に下げた。 関連記事 堀江社長が会見 「社内調査で現状把握に努めたい」 証
ITmedia D LifeStyle：「MacBook Pro」の気になるトコロ (1/2)
Apple Computerは、米サンフランシスコで開催中の「Macworld Expo」でIntel Dual Coreプロセッサを搭載したノートPC「MacBook Pro」と「iMac」を発表した。Intelチップを搭載したことで、MacユーザーのみならずPCユーザーからも熱い視線を浴びるMacBook Proだが、初めてのチップだけに気になる部分も多い。同日、都内で開催されたアップルの基調講演イベントで話を聞いた。 ネイティブアプリはいつそろう？ まずは、MacBook Proのシステムを簡単におさらいしておこう。MacBook Proは、開発コード“Yonah”と呼ばれたIntelのモバイル向けチップ「Intel Core Duo」を搭載している。Core Duoの名前が示す通り、2つのコアとプロセッサと同じクロックで動作する2MバイトのL2キャッシュを内蔵。FSB（フロントサイ
不良システムを作らないプロジェクトの枠組み
業務システム構築プロジェクトでは、業務部門の理解と協力が不可欠だ。これらの人々にシステム開発の意義、そしてシステムというものの特性などを説明することを省略してはいけない。 不良システムが業務に及ぼす影響を説明する システム開発の成功には、上司や業務部門の理解や協力が絶対に必要です（本連載では、プロジェクトチームの上司はITに不明であることを前提にしています）。 こうした理解・協力を獲得するには、「不良プロジェクトは不良システムを生み、不良システムを使う業務は未来永劫、業務効率の向上など望めない」という主張が効果的です。プロジェクトチームは折に触れ、何度もこの主張を繰り返すべきです。 不良システムは業務を妨害する 各業務部門にとって不良システム（すなわち、利用するのに我慢を強いるようなシステム）が業務効率の向上に寄与しないことは当然であり、場合によってはトラブルを頻発させるなど業務効率を悪化
いまさら聞けない要求管理の基本
なぜ、要求を管理する必要があるのか なぜ、要求を管理するのでしょうか？ 一言でいうと、要求を管理することが、プロジェクトの成功を大きく左右するからです。まず、一般的なプロジェクトのゴールを考えてみましょう。次のような定義を見てください。 「顧客の真のニーズを満たす」「高品質」「期間内」「予算内」という4つのキーワードが出てきますが、どれも要求管理と大きくかかわってきます。まず、「高品質」な製品を作るためには、要求管理において、信頼性やスループットといった製品の機能面以外の要求も確実に把握することが重要です。また、「期間内」「予算内」で製品を開発するには何が問題でしょうか？ プロジェクトは、時間と予算とリソースが制限された状態で製品を開発しなければなりません。与えられた時間、予算、リソースを用いてどれくらいの作業ができるか考慮して、製品の要求仕様の範囲を、作業が可能である範囲に抑えねばならな
ドキュメントレビューに役立つ40のチェックポイント
設計書のチェックリスト 設計書の内容は技術的になるので、ある程度ITに対する知識がないと難しいが、できれば設計レビューにも参加することを勧めする。 早い段階で、以下のチェック項目を確認しておくことで、設計者の勘違いなどを早期に是正できる。これらが運用試験などの後工程で発覚し、後戻りや繰り返しを重ねるよりは、コストや期間を抑制できる。 （1）仕様書の要求事項との追跡性が確保されているか 仕様書の要求事項が、確実に設計に反映されていることを追跡しやすいように記述されていること。例えば、仕様書の記載項目のページ番号や章・節と、設計事項との対応リストなど。 （2）設計手法やフレームワークは、明確か 使用している設計手法やフレームワークが示され、その選択理由が明確であること。 （3）アーキテクチャが論理的に説明できるか アーキテクチャについて、なぜ、それが最善の方式であるのか明確かつ、論理的に説明で
ドキュメントレビューに役立つ40のチェックポイント
見積書のチェックリスト ソフトウェアの原価は、ほとんどが人工（にんく）費であるので、生産量と生産性の合意が基本となる。 ここでは、ファンクションポイント法（FP法）による見積もりを前提に、チェックポイントを紹介する。従って、仕様書上で要求されている画面・帳票・ファイルに対して過不足がないこと、各構成要素の難易度や改修率に応じたファンクションポイント数（FP数）、単位FP数当たりの生産性や原単位などが妥当かどうか、がチェックのポイントとなる。複数の業者から相見積もりを取る場合も、このような見積もりであれば比較検討しやすい。一式いくらでは、比較検討のしようがない。単に安いか高いかだけでは、もしかすると大きな見積もり漏れや、作業範囲などに相違があるかもしれない。見積書は、提案書でもあるので、その内容を見れば実力や誠意をうかがい知ることができる。 （1）数量・単価・金額が、明示されているか 数量（
ドキュメントレビューに役立つ40のチェックポイント ― 1/3 ― ＠IT情報マネジメント
プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。 仕様書のチェックリスト 以下に仕様書の基本的なチェックポイントを紹介する（なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい）。 ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物（ドキュメント）を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。 （1）題名は、システム名を明記しているか 仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”
紛争勃発に備えよ！──受け入れ検査時のトラブル対策
紛争勃発に備えよ！──受け入れ検査時のトラブル対策：企業システム戦略の基礎知識（10）（1/2 ページ） 受け入れ検査において、明らかに「欠陥」であると判定できる場合は問題ないが、発注側では欠陥だと思って指摘しても、業者からは「それは欠陥ではなく、仕様書に書いてなかったので仕様変更である」と反論されることが少なくない。これは、業務という抽象的なものを対象としているうえに、要求仕様が日本語特有のあいまいな表現で記述され、発注側の意図が業者に正しく伝わっていないことが要因である。 こうした“見解の相違”は、欠陥であれば業者が無償で是正することになり、仕様変更であれば発注側が追加費用を負担する──つまり両者の利害は対立しているので、容易に紛争へと発展する。そうなった場合に、できるだけ禍根を残さずに両者が納得できるような形で解決するには、どうすればよいか考えてみたい。 仕様変更か、欠陥か──それが
第1回 要求仕様に関係する落とし穴
整理術的改善ポイント では、ここから改善のポイントを1つずつ解説していきます。 （1）要求仕様書とリリース製品が正しく保管されていること （2） 要求仕様書とリリース製品が関連付けされていること まず、製品開発時に参照すべき唯一の要求仕様書が、正しく管理されていることが大前提として挙げられます。正しくとは、管理されている要求仕様書が間違いなく参照すべき唯一の要求仕様書であることを識別できること、開発メンバーの全員が同一の要求仕様書を参照していること、勝手な改ざんができないことを意味します。この大前提が成り立っていれば、少なくとも、開発メンバー全員が、同じ要求仕様書を基に同じものを開発しようと試みているといえるわけです。 次に、この要求仕様書を基に出来上がったリリース製品について、いつでも誰でも、要求仕様書とリリース製品を一対一で特定できることが重要です。このためには、何らかの手段で対応を識
ここ一番の会議は「段取り力」で勝負
DO：会議実施 いよいよ、実際の会議である。事前準備がもれなく完了したら、会議が成功するか否かは、ファシリテーターの貢献によるところが非常に大きい。 先述のように、ファシリテーターは、会議のアウトプットを最大化すべく、議論の中味に中立な立場で、論点整理と交通整理を行う役回りである。 ここでは、会議開催時、会議中、会議終了前の3つのフェーズ別に、ファシリテーターの行動について説明していきたい。 オープニング 会議開催時には、以下の4点に留意しつつ、会議資料1枚目につけてあるアジェンダに従って説明を行う。限られた会議時間中、目的に沿った有益な議論が行われるよう、冒頭で十分時間を取ってアジェンダを説明する必要がある。 忙しいプロジェクトでは、事前の会議資料配布が間に合わず、会議開催時に担当者が資料をそれぞれ配るようなケースも多い。そういった場合にも、参加者がスムーズに議論に入れるよう、アジェンダ
中堅企業のコンサルタント活用法――「先生コンサル」には気をつけろ
中堅企業とコンサルタントは本当の意味で効率的に仕事ができているだろうか。中堅企業と仕事をすることが多い私は、彼らからコンサルタントに対する苦言を聞くたびに疑問を感じてしまう。 神宮司 剛（ヘッドストロングジャパン シニアコンサルタント） 営業を見直して売り上げをアップしたい、業務の無駄を省きたい、社員をやる気にさせる人事制度を導入したい……。課題や必要性は分かっていても、ノウハウがなく、思うように取り組めていない企業も少なくない。そのため、人材が不足がちで、有識者を抱えておくことが困難な中堅企業にとって、コンサルタントの力を借りることは有効な選択肢の1つになる。実際に、コンサルタントを活用している企業はたくさんあり、また、中堅企業へのサービス提供を中心に活動しているコンサルタントも多い。 だが、中堅企業とコンサルタントは本当の意味で効率的に仕事ができているのだろうか。中堅企業と仕事をするこ
PMノウハウとは何か？──組織的ノウハウ共有の事例から ― 1/2 ― ＠IT情報マネジメント
株式会社プライド 執行役員 チーフ・システム・コンサルタント 大上 建（だいじょう たける）氏 前職で上流工程を担当する中、顧客の利用部門は必ずしも「開発すること」を望んでおらず、それを前提としないスタンスの方が良いコミュニケーションを得られることに気付き、「情報の経営への最適化」を模索することのできる場を求めてプライドに入社。株式会社プライドは、1975年に米国より社名と同名のシステム開発方法論の日本企業への導入を開始して以来、これまで140社余りの企業への導入支援を通じて、情報システム部門の独立自尊の努力を間近に見てきた。 会社の業務やプロジェクトの中で秀でた成果を上げる人がいますが、一般的な人と表面的に大きな差があるわけではありません。しかし、成果に違いがあるわけです。 どこが違うのかというと、各界有能者は、秀でた成果を上げる「ノウハウ」を持っているのです。短い言葉で表現され、絶大な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
