• ITマネジメント
  1. IT戦略&IT投資
  2. ITインフラ
• システム構築
  1. アーキテクチャ
  2. プロジェクト管理
• ITユーザー
  1. 仕事の改善
  2. 業務アプリケーション
  3. Webマーケティング

ITアーキテクト

ITアーキテクトとは組織の情報戦略に基づいて、ITシステム全体のアーキテクチャを設計する存在だ。システムの要素となり得るさまざまな技術・製品から、ビジネス上の要求と技術・製品の将来性、利用者側の使いこなし能力などを加味して、最適な組み合わせを選び出すことが求められる。ビジネスと情報技術の双方で広範な知識が求められる人材だ。

新着記事

エンジニアは「仕事が全て」の生き物 連載：ディルバート 第268回　エンジニアにとって人生は仕事が全てなんでしょうか？ そんなことはないですよね。でも周囲の人たちはそう誤解しているのかもしれません…… New! 情報マネジメント > IT戦略 2012/05/25

ITリーダーは、“IT部門本来の使命”を実現せよ ガートナーと考える「明日のITイノベーターへ」（8）　「収益への貢献」と「日々の運用管理業務」の板ばさみになっている中で、今後IT部門はどう脱皮して行けば良いのだろう New! 情報マネジメント > IT戦略 2012/05/24

“開発のよくある問題”を解決するCMMIの3大メリット 今日からできる“CMMI流”開発効率改善術（2）　アジャイルなど、どのような開発手法を使っていても、さらなる効率化に導いてくれるCMMI。今回はその3大メリットを紹介する New! 情報マネジメント > IT戦略 2012/05/23

ナイトライダーも示唆する人とシステムのあるべき関係 情報マネージャとSEのための「今週の1冊」（90）　“使ってもらえる”システム、“なくてはならない”システムを開発する上で、重要な視点とは何なのだろうか？ New! 情報マネジメント > IT戦略 2012/05/22

上司には、真実を告げてはいけない 連載：ディルバート 第267回　たとえそれが真実だとしても、上司にとって不利になるようなことを言うのは極力避けましょう。いつ落とし穴に突き落とされるか分かりません 情報マネジメント > IT戦略 2012/05/18

新着ニュース

＠IT Special

• マネージャ職を目指すSIエンジニアの職歴書を徹底指導
• 仮想デスクトップのウイルス対策、どうする？
• iPad＋モバイル化で“革命的”生産性向上！

ITアーキテクト

ITアーキテクトを探して ITアーキテクトに求められるスキル要件が固まり始めている。まずは、国内で独自に活動を開始したITSS アーキテクト委員会の活動を報告しよう 第1回 ITアーキテクトが備えるべきスキル標準 第2回 ITアーキテクトとスーパーSEの違い 第3回 情報家電とITアーキテクト、その密接な関係 第4回 ITアーキテクトの仕事術：要求の「見える」化 第5回 ITアーキテクトはプロジェクトも設計する 第6回 わたしはビジネス寄りの技術者です 第7回 ITアーキテクトに必要な3つの視点 第8回 国のIT基盤を設計するITアーキテクト 第9回 ソニー生命保険が考えるITアーキテクト像 第10回 ソフトウェア開発の守・破・離 第11回 ITアーキテクトの専門分野を3つに整理 第12回 アーキテクトはコンポーネントをうまく使う 第13回 開発現場を3T（楽しい、定時に帰れる、高い給料）に 第14回 デスマーチの構造 Vol.1 第15回 デスマーチの構造 Vol.2 第16回 見えるビジネスモデリング 第17回 経営者はなぜソフトウェア開発環境展に足を運ぶのか Last Update 2007/6/14

28歳から挑戦するITアーキテクト いまも現場でもがき続ける現役ITアーキテクトの1人として、悩ましい20代への「次のステップ」の手引となるものを残していきたい 第1回 ITアーキテクトへの“脱皮”の覚悟 第2回 アーキテクチャの採用理由を説明できるか？ 第3回 その設計で運用は救われるのか 第4回 その設計はちゃんと動くのか？ 第5回 誰のためにシステムをつくっているのか？ 第6回 ITアーキテクトになった後の試練 第7回 ITアーキテクトを実践する 第8回 基盤技術にロック・オンされていないか？ 第9回 システム全体を連続稼働に持ち込め！ 第10回 アプリケーションサーバを自在に操れ！ 第11回 最低10年使える業務アプリケーション（前編） 第12回 最低10年使える業務アプリケーション（後編） Last Update 2006/8/9

ITアーキテクチャ構築の勘所 ITアーキテクトの役割は要求に応える良いアーキテクチャを構築すること。問題は、どうすれば良いアーキテクチャを構築できるか、だ 第1回 アーキテクチャ設計の手順 第2回 アーキテクチャ要件の洗い出し 第3回 機能的なアーキテクチャの設計 第4回 配置設計の手順と注意点 第5回 製品／技術の適用と実現性の検証 最終回 ITアーキテクチャ設計の反復と吟味 Last Update 2006/4/14

こんな時にはこのITアーキテクチャ 　状況に応じて必要となるアーキテクチャは異なる。本連載では状況に応じたアーキテクチャの選択と構築のノウハウをお伝えする 第1回 良好なレスポンスを実現するアーキテクチャ 第2回 大量トランザクション処理に適したアーキテクチャ 第3回 高可用性システムのためのアーキテクチャ 第4回 止められないシステムのためのアーキテクチャ 第5回 使いやすいシステムのためのアーキテクチャ 最終回 変化に強いシステムのためのアーキテクチャ Last Update 2007/3/22

ソフトウェア開発をちゃんと考える ソフトウェア開発という行為の本質をきちんと考えること。筆者が日頃仕事の参考にしている書籍を元に読者と一緒に考える 第1回 開発コストと工数を下げるためのアイデア 第2回 開発者の集合はどのように形作られているか 第3回 口に出す前に考える、「システムって何？」 第4回 XPの欠陥修正フィードバック・ループを分析する 第5回 自然言語としてのパターン 第6回 パターンと生きたプロセス 第7回 滑らかなアーキテクチャ 第8回 セル生産方式＋アジャイルという枠組み 第9回 制約理論を読みほどく 第10回 価値工学とソフトウェア開発 第11回 「価値工学」批判 第12回 「要求」と「システム」のしなやかな平衡 第13回 柳生新陰流プロジェクトマネジメント Last Update 2007/9/11

「ITアーキテクト塾」レポート ＠IT ITアーキテクト フォーラム主催のITアーキテクト塾 第1回目は、ビジネスプロセス・モデリングのいまと今後の可能性について議論した 第1回 ビジネスモデリングと“見える化”のいま 第2回 テストファーストでユーザーも開発者も幸せに Last Update 2006/2/24

モデリング

UML BASIC LECTURE ユースケース定義（イベントフロー）の管理の一部をダイヤグラムで行う場合の考え方、そしてそのヒントを詳細に解説する 第1回 あなたはテキスト指向、ダイヤグラム指向？ 第2回 クラス図の落とし穴 第3回 「関連」や「関係」の落とし穴（前編） 第4回 「関連」や「関係」の落とし穴（後編） 第5回 状態モデリングとステートチャート図（前編） 第6回 状態モデリングとステートチャート図（後編） 第7回 オブジェクト制約言語（OCL）の基本 第8回 オブジェクト制約言語について 応用編 第9回 開発プロセスとUMLの拡張性（前編） 第10回 開発プロセスとUMLの拡張性（後編） Last Update 2005/3/23

【改訂版】初歩のUML 上級モデラーを目指す人へおくるUML入門講座の決定版。中断していた好評連載が大幅な加筆・修正で再登場 第1回 まずはUMLのクラス図を書いてみよう 第2回 クラス図の詳細化とその目的 第3回 モデリングにおける「汎化」と「特化」 第4回 少しだけ高度なモデリング技術（その1） 第5回 クラスの依存関係と実現関係 第6回 「関連」の理解をさらに深める 第7回 オブジェクトの動的側面を見極める 第8回 顧客の要求をユースケースに反映させる 第9回 UMLベース開発プロセスの流れ 第10回 開発プロセスの上手な組み合わせ 第11回 UMLモデリングの開発過程 モデリング編 第12回 UMLモデリングの開発過程 開発編 最終回 UMLモデリングのノウハウ、最後の秘訣 Last Update 2004/1/10

モデリング修行 入門編 モデリングは「ないとシステム構築において欠陥を呼ぶ」必須の技法である。まずはモデリングの重要性を理解することから始めよう 第1回 オブジェクトモデリングの基礎としてのデータモデリング 最終回 モデリングなしで開発はできない Last Update 2002/12/21

Javaオブジェクトモデリング モデリングがきっちりできても、結局のところJavaのコードに落ちなければイミがない。UMLとJavaのマッピングについて連載開始！ 第1回 UMLをJavaに落とし込む流れを概観する 第2回 Javaとのマッピングにおける静的モデル 第3回 UMLとJavaのクラスをメタモデルから把握する 第4回 UMLとJavaのマッピングを考える 第5回 UMLのデータ型とJavaのマッピング戦略 第6回 バリューオブジェクトをJavaで実装する方法 第7回 リレーションシップの定義を解きほぐす 第8回 リレーションシップの関係とそれぞれの機能 第9回 UMLのアソシエーション（関連）を考える 第10回 静的モデル：アソシエーションエンドの部品 第11回 静的モデル：アソシエーションの付加情報 第12回 静的モデル：アソシエーションのUML部品のまとめ 第13回 静的モデル：アソシエーションのJavaの部品 第14回 静的モデル：Javaを前提としたUMLアソシエーション 第15回 UMLアソシエーションの詳細解説 Last Update 2003/11/19

良い設計モデルの作り方 「良い設計モデルとは何を意味するのか」「どうすれば良い設計モデルを作ることができるのか」。前後編の2回でこれらの疑問に答えていく 第1回 正しい設計と理想的なモデル 第2回 モデル推敲に有効ないくつかの手法 Last Update 2004/4/27

上流モデリング研修 この連載では架空の会社を取り上げ、一連のビジネスシナリオに沿った演習問題の形式で、具体的にモデリングを解説していく 第1回 視点を分けて業務システムを可視化 第2回 利害関係者の目的を可視化するプロセス 第3回 業務の目的を果たす手順を可視化するプロセス Last Update 2005/8/31

事例で学ぶビジネスモデリング 本連載では、IT技術者にビジネスモデリングのイメージを持ってもらうため、われわれが行ってきたコンサルティング事例を紹介していく 第1回 IT技術者が「上流」に出て行く理由 第2回 システム開発は「戦略立案」から始まる 第3回 戦略コンサルの基本「仮説検証プロセス」 第4回 企業の健康を診断する「業務分析」 第5回 ビジネスモデリングだけでは語れない業務分析の現場 第6回 ビジネスモデリングの使いどころ 第7回 戦略実現の鍵を握る情報システム部 第8回 戦略と技術のコラボレーションで事業をつくる 第9回 初めての上流コンサルティング 最終回 IT技術者は上流に向けて飛翔せよ Last Update 2007/3/29

BPMNを活用したビジネスプロセス・モデリング 顧客にUMLで記述したビジネスプロセスをみせてもわかってはもらえない、さてどうする。BPMNなら大丈夫かもしれない 第1回 ビジネスを可視化するモデル記述言語「BPMN」 第2回 「BPMN」の基本要素を理解する 第3回 ビジネス要件をBPMNで記述してみよう（前編） 第4回 ビジネス要件をBPMNで記述してみよう（後編） 第5回 設計と実装をシームレスにつなげ！ 最終回 BPMNをもっと知りたい人のために Last Update 2005/9/28

実践！ UMLビジネスモデリング 企業システム開発には、ビジネスの見える化が欠かせない。ビジネスとシステムをブリッジするビジネスモデリング技法を紹介する 第1回 なぜ、ビジネスモデリングなのか？ 第2回 戦略マップとビジネスモデルの融合 第3回 「モノ」を中心としたビジネスモデリング 第4回 UMLとBPMN、それぞれのビジネスモデリング 第5回 ビジネスモデルをあるべき姿へ 第6回 ビジネスモデルからシステムを見いだす 第7回 ビジネスへの貢献度で評価するビジネスモデル 第8回 ビジネスモデルは優れた組織あってのもの 最終回 SOAの効果を引き出すためのビジネスモデリング Last Update 2008/3/27

5分で絶対に分かるUML

ソフトウェア開発において、分析や設計の精度を向上させ、技術者間のコミュニケーションも円滑にするUML。わずか、5分でその概要と、使い方について解説！

アーキテクチャ 2002/6/12

開発プロセス

いまなぜ開発プロセスを注目するのか 　ソフトウェア開発を成功に導くには開発プロセスが重要だ。だが、従来のプロセスは多くの課題を抱えている 第1回 従来の開発プロセスと現場が抱える課題 第2回 新しい開発プロセス「RUP」と「XP」 Last Update 2002/3/1

アスペクト指向のバリエーション解説 この連載では「アスペクト指向とは何か？」というところから始め、AspectJやJBossAOPなどを用いたAOPの実装を紹介していく 第1回 アスペクト指向の基礎とさまざまな実装 第2回 AspectJから学ぶアスペクト指向の理解 第3回 JBoss AOPとAOPフレームワークの役目 第4回 「AspectWerkz」の利用法 第5回 アスペクト指向理解のまとめ Last Update 2005/6/4

オブジェクト指向

ここから始めるオブジェクト指向 いまさら人に聞けないオブジェクト指向の基本を教えます。ここから始めなければ、オブジェクト指向開発は始まらない 第1回 オブジェクト指向の考え方 第2回 オブジェクトに必要な4つの特性とは？ 第3回 複雑なものを単純に〜分類と分解〜 第4回 オブジェクトをUMLで表現する 第5回 分類と分解をUMLで表現する 第6回 振る舞いをUMLで表現する−相互作用図 第7回 振る舞いをUMLで表現する−ステートチャート図 最終回 振る舞いをUMLで表現する − アクティビティ図 Last Update 2003/5/31

オブジェクト指向実践レポート インターネット時代の到来、オープン系システムの登場、短期開発。そろそろ開発スタイルに変革が必要なときではないだろうか 第1回 ソフトウェア産業の近代化をいまこそ 第2回 ソフトウェア開発環境の転換期到来 Last Update 2002/12/5

オブジェクト指向の世界 JavaやUMLといったソフトウェア開発の話題とは少し離れて、オブジェクト指向そのものの哲学的意味を考えてみたいと思います 第1回 流れ去るものと不変なもの 第2回 自然言語をUMLで表現してみる 第3回 UMLで新聞記事を読む 第4回 「ピカソ、113億円で落札」をUMLで表現する 第5回 全体最適とアーキテクチャ 第6回 名前のない品質とパターン言語 第7回 パターンとパターン言語入門 第8回 分析から設計へのモデル変換などについて 第9回 分析手法のキホン：「分解と分類」 第10回 プラトン編−イデア論とクラス／インスタンス 第11回 アリストテレス編−“what & why”4つの原因説 第12回 “what & why”4原因説をビジネスモデルに応用 第13回 モノとコトによるモデリング 第14回 分かりやすいモノ・コト方式のモデリング 第15回 モノ・コト分析の段階的モデリング 第16回 モノ・コト分析をパターン言語で表現 第17回 パレートの法則 vs. ロングテール現象 第18回 ネットコミュニティのQWAN（無名の質） 第19回 RUPをパターン言語として考える 第20回 RUP7で開発の「苦」から解放される 第21回 オブジェクト指向のソクラテス式対話編 第22回 ソフトウェアは知識の結晶 第23回 UML2メタモデルを読む−知識とは何か？ 第24回 UML2メタモデルを読む − 知識とは何か？（2） 第25回 オブジェクト指向を考える──普遍の知識 第26回 世界はらせん的に進化する 第27回 クラウドの潮流を考える――らせん的進化・その2 第28回 パターン言語事例 − 慶應SFCの『学習パターン』 第29回 フラクタル - 自己相似形とべき乗則 第30回 SFC学習パターンを新人研修に適用する 第31回 情報を媒体に転写する？ 形相と質料 Last Update 2011/6/27

良い設計モデルの作り方 「良い設計モデルとは何を意味するのか」「どうすれば良い設計モデルを作ることができるのか」。前後編の2回でこれらの疑問に答えていく 第1回 正しい設計と理想的なモデル 第2回 モデル推敲に有効ないくつかの手法 Last Update 2004/4/27

要求定義

隠れた要求を見極める！ 　要求定義では、顧客の「思い」を掘り下げ、「隠れた要求」を引き出さなくてはいけない。そのための新たな方法論「MOYA」を紹介する 第1回 ユーザーが欲しいのはシステムではない 第2回 そのプロジェクトの「目的」、見えてますか？ 第3回 ユーザーの「思い」は、1つだけではない 第4回 ユーザーの「世界観」を見極めるためには 第5回 役立つシステムへと至る「道筋」を考える 最終回 役立つシステムへ向け、隠れた要求を見極めよ！ Last Update 2008/3/10

マインド・マップとUMLを使った要求分析支援 マインド・マップという記法を、UMLを補完するツールとして、要求分析などの上流工程で応用する方法を紹介 第1回 マインド・マップの基本と応用 最終回 マインド・マップとUMLの連携術 Last Update 2005/7/12

みんなが悩む要求管理 本連載では、RUPにおける要求管理の成果物とワークフローを取り上げ、要求管理の基本をできるだけ分かりやすく解説していきたい 第1回 いまさら聞けない要求管理の基本 第2回 ソフトウェア要求の詳細な分類 第3回 システムが解決すべき問題を整理する 第4回 システムを定義する 初歩編 第5回 要求管理プロセスの全体像 第6回 反復型開発における要求管理の流れ 第7回 要求管理と変更依頼管理の違いを理解しよう 最終回 要求管理ツールの賢い使い方 Last Update 2005/8/12

ソフトウェア品質・性能

ソフトウェアテスト・エンジニアの本音 ソフトウェアテストのエキスパートたちが月に一度集まって、議論を繰り広げている。テストに関する最新のテーマはいつもここにある 第1回 モデル駆動型ソフトウェアテストの可能性 第2回 テスト設計の基本とさまざまなテスト技法 第3回 テスト計画が失敗する原因、その回避策 第4回 テストという破壊的な作業の建設的なやり方 第5回 テスト設計の方針は千差万別 Last Update 2005/4/28

ソフトウェア品質を高めるには 　行き当たりばったりのテストはもうやめよう。テストには戦略を導入するべきだ。テストを戦略的に進めるための考え方をいくつか紹介する 第1回 Quality Architectによる戦略的なテスト 第2回 カイゼンを実践するマインド Last Update 2006/11/22

攻めの性能マネジメント 出そうで出ないのが「性能」の困ったところ。「性能」は開発工程の最初から管理しなければならないのだ。考え方と実践的な解決策を提示する 第1回 出そうで出ないシステム性能 第2回 性能問題の失敗事例集 第3回 ハード性能以上の性能は出ないんです 第4回 失敗事例に学ぶ運用性能品質向上策 第5回 システムは変化し続ける――キャパシティプランニング 最終回 保存版 性能品質の作り方 Last Update 2008/2/21

ディルバート

ディルバート 　あのDilbertが＠IT情報マネジメントに登場！ エンジニアのディルバートと職場の変なやつらが強烈な日常バトル！ 第1回 電子メール送信者失格？ 第2回 見積もりとらせてくださいよ 第3回 「だらしないオーラ」を利用せよ 第4回 出張には勇気が必要!? 第5回 あーっ！ データ消しちゃった 第6回 ちょっと俺の部屋へ来い 第7回 プロジェクトは反省から始めよう 第8回 果てしなき給与査定バトル 第9回 部下として雇いたいのはどんな人？ 第10回 たまにはほめてもらえます？ 第11回 君に2つの達成目標を与えよう 第12回 僕がいま、達成感で満たされている理由 第13回 給料、どれくらい上がったの？ 第14回 僕がもし、無限の力を発明したら…… 第15回 息子の手術なので休みたいんですが 第16回 古代エジプト人に特許取られてない？ 第17回 体で覚える携帯電話の使い方 第18回 あのうわさ、本当ですか？ 第19回 建国の父たちよ、静かに眠れ 第20回 CEOとインターンの価値 第21回 変化を恐れない、働き者のいい男 第22回 会社の命運を握る男の仕事場 第23回 この世に存在しているということ 第24回 最優秀社員賞がうれしくない理由 第25回 本当に、正直に話していいの？ 第26回 「忙しい」は会社員の処世術？ 第27回 うちの企業戦略って何だっけ？ 第28回 迷惑なやつにはお仕置きだ！ 第29回 地球温暖化が労働者をダメにする 第30回 開発には枯れた技術がイチバン？ 第31回 雇ってくれなくてもいいんだけど 第32回 経営コンサルタントにはコンサルが必要 第33回 システムのお届けは何便にしますか？ 第34回 もう次の機種が出ちゃうの？ 第35回 勝てる提案をひねり出せ！ 第36回 ボスは会議で無駄にメールを読む 第37回 質問が多いヤツは昇給をあきらめろ 第38回 CEOの息子から部の秘密を守れ！ 第39回 Web 2.0で会議を混乱させろ！ 第40回 また1カ月後にお会いしましょう 第41回 最初にちゃんと指示してくださいよ 第42回 今日もオフィスで大漁だ 第43回 健康な社員なんか要らない!? 第44回 ボクって仕事デキるでしょ！ 第45回 人の役に立つって気持ちいい！ 第46回 何もしてくれなくてありがとう 第47回 こうして仕事は進歩する 第48回 ボクたち、大丈夫だよね？ 第49回 上司への質問は段階的に!? 第50回 エンジニアの仕事を正しく子どもに説明しよう 第51回 ディルバート、ちょっと時間ある？ 第52回 プロジェクトのコスト見積りを出せ 第53回 正しい給与査定は正しい目標設定から 第54回 今日は楽しいマネージャ合宿 第55回 私、マネージャになりたい!? 第56回 ボクなんか、生き返ったんだぞ！ 第57回 どっちのプロジェクトが重要？ 第58回 無知な上司の愛のムチ!? 第59回 「大丈夫」なんて言えない 第60回 態度が悪いのには訳がある 第61回 アリスの恍惚と悲哀 第62回 ボクって面倒くさがり屋？ それとも触り屋？ 第63回 究極のナンパ術はこれだ!? 第64回 診断書をナメんなよ!? 第65回 古いやり方じゃダメ！ 第66回 大変だ、新人教育は…… 第67回 間違っていないか、この社内手続き 第68回 それが現実だ 第69回 プロジェクトの質問メール？ 第70回 アリスの陰謀 第71回 部内のみんなが幸せになれる提案？ 第72回 このアイデアは誰が考えた？ 第73回 ディルバート、プロジェクトリーダーに 第74回 ウォーリー、報いを与える 第75回 アリスとボスの昇給を巡る攻防戦 第76回 エンジニアに心理鑑定は必要、ホント？ 第77回 リスクマネジメントにご用心 第78回 ディルバート、テレビに進出？ 第79回 クビにするのはテッドかプリンタか 第80回 定年は負け組みのもの？ 第81回 ボーナス廃止決定で大騒動 第82回 ディルバート流、デートの誘い方 第83回 技術変化に遅れず付いていくコツ 第84回 四半期目標を達成できなかった理由 第85回 ボスとプロジェクト、やりたくない！ 第86回 またクビの危機、テッド？ 第87回 ディルバート、謎のアレンのアドバイスを得よ 第88回 ボス、マネジメントのコツを大いに語る 第89回 ちょっとだけ払ってたくさんお金をもうける？ 第90回 ウォーリーとボスの成果主義を巡る駆け引き 第91回 ボスの中間管理職悲哀物語 第92回 ごまかせ、携帯電話の不具合を？ 第93回 社内面談でディルバート、落ち込む 第94回 ディルバート、顧客の襲撃で死んだフリ 第95回 雇われたコンサルタントいわく 第96回 ディルバートが営業に成功 第97回 アイデア・リスとの死闘 第98回 ディルバートが大発明、のはずがない？ 第99回 ディルバート、プロジェクトの崩壊曲線を解説 第100回 ウォーリー、悪という名の経験を誇る 第101回 ボスは会議がお好き 第102回 ボスの得意技、ごまかしとディルバートの対決 第103回 お灸を据えるはずが…… 第104回 ディルバートのあまのじゃくマネジメント法 第105回 不況下の人事改革の目玉はやっぱりクビ？ 第106回 偉い人にアイデアを婉曲にアピールする方法 第107回 ウォーリーの実践セクハラ・パワハラ対策講座 第108回 失敗確実なウォーリーの昇給交渉 第109回 ディルバートの環境よりもまし 第110回 ディルバートと牛の待遇は等価 第111回 ボス、悪評レビューになりすましで対抗？ 第112回 なぜ簡単にできる引き継ぎはないのか 第113回 嫌われ者ウォーリーとプロジェクトの運命は？ 第114回 ディルバートの間違いだらけのエコプロジェクト 第115回 ボスのコミュニケーション改善策は最悪か？ 第116回 ボスの安物買いの銭失い 第117回 ボス、現実から逃避する 第118回 経費削減アイデアとテッドのクビの関係は？ 第119回 はみ出し者テッドの行く末は？ 第120回 見えない敵、ステークホルダーのプロジェクト妨害 第121回 怪しいヘッジファンドの勧誘法 第122回 製品を安く買うまでの遠く険しい道 第123回 謎の訪問者 第124回 ディルバート担当プロジェクトは迷走中 第125回 ディルバート、資本主義を疑う？ 第126回 ウォーリー、仕事をしないことを宣言！ 第127回 エンジニア、意味のない用語対決の結果は？ 第128回 ディルバートのママ、ほえる 第129回 ディルバート、勝手にリストラ対策を妄想す 第130回 採用ってそんな基準なのか？ 第131回 ボス、休暇中のマネージャ代行を決められず 第132回 エグゼクティブ向けスカウトビジネス参入？ 第133回 リストラの有無よりも会社の存続を心配しろ 第134回 使われないことを願うベストプラクティスって？ 第135回 ボスの提案、却下のはずが 第136回 次世代商品の開発費用はいくら？ 第137回 意味のないチームワーク賞プログラムって？ 第138回 データセンターという名の産業廃棄物誕生 第139回 成果不足は泥棒のせいに 第140回 楽しいプレゼンの極意 第141回 ボスが念には念を入れるとき 第142回 地球がぺちゃんこになっても答えない交渉術 第143回 質問は4つ！ 第144回 オブラートにくるまない戦略会議 第145回 ホワイトペーパーと共にあらんことを 第146回 ボスがツイッターを始めたわけ 第147回 プロセス改善は隗より始める？ 第148回 非生産的な時間をめぐる非生産的な議論 第149回 最も有効なコストセービング方法 第150回 その仕事ができない4つの理由 第151回 中断する会話は続く 第152回 妥協なきウイルス対策 第153回 やる気を引き出す冴えたやりかた 第154回 キッチンに入るべからず 第155回 米国流振り込め電話 第156回 プロジェクト・コストマネジメントは非情の掟 第157回 悲しみと絶望の文房具 第158回 沈黙の男は天才アドバイザー 第159回 エルゴノミクスの秘術 第160回 経理部の見解と態度 第161回 プロジェクトに必須のWDG 第162回 部門マネージャの修辞学 第163回 ハゲー・ポッターの華麗なへりくつ 第164回 すべてのエンジニアは役立たずになる 第165回 アシュックのKY度チェック 第166回 人生の半分を乗り切る方法 第167回 ディルバート、「TIME」の表紙を飾る 第168回 業務命令違反スレスレでも給料を守れ 第169回 ディルバート流、上司との付き合い方 第170回 ディルバートもキレる、ボスのトンデモPM哲学 第171回 ディルバートも気分が悪くなるボスの悪知恵 第172回 サボるなら、誇りを持って堂々とサボれ 第173回 いますぐ作れる、サボり正当化システム 第174回 “伝説のプログラマ”になる方法 第175回 部下をキレさせてでも、IT予算を削減するボス 第176回 ゴリ押せば、たいていのことはうまくいく 第177回 女同士が凍りつく瞬間 第178回 コンサルの極意はボッたくりに気付かせないこと 第179回 ボスは大腸で判断を下す 第180回 情報システム部員には“ハグ”が必要だ 第181回 ヨーダとウォーリーは役立たず 第182回 ボスの知能は小学生並み 第183回 “犯罪的なまでに間違っている”マーケティングとは 第184回 “セクシーなパワポ”は窓際への片道切符 第185回 ママからの頼みごとが多いときは要注意 第186回 ワーキングマザーの電話は聞いていられない 第187回 “全員参加”を実現する究極の会議体 第188回 誰にも相手にされないと、人はお化けになる 第189回 敏腕セールスマンも美女には負ける 第190回 都合の悪いことは“プラシーボ効果”で乗り切る 第191回 ダメ上司のせいで会社がつぶれる 第192回 今日も部長はパワハラ天国 第193回 組織では、マトモな人ほどねたまれる 第194回 ビジネスは、“新語／造語”を作った者勝ち 第195回 コーディングにはインスピレーションが大事!? 第196回 法律違反を防ぐために、わいろを着服 第197回 同僚を利用できる奴がナンバーワンになれる 第198回 スキルアップは退職覚悟で 第199回 無駄なテストをさせたやつは万死に値する 第200回 頻繁なメールチェックが身を守る 第201回 技術革新の資金は、顧客をだました分から捻出 第202回 やる気とは「出すもの」ではなく「搾取されるもの」 第203回 せめて、“理想の上司”のフリだけでもしてほしい 第204回 “権限委譲”の別名は「責任逃れ」 第205回 ペーパーレス化なんてカンタンだ 第206回 コミュニケーションが下手な人はメールが長い 第207回 相手を傷つけずにランチを断る方法 第208回 言い掛かりも“遠回し”に付けるのがビジネスマナー 第209回 ボスの命令を無視すれば、うまくいく 第210回 友達になるかストーカーになるかは金次第 第211回 どうせ無視されるならこう言おう 第212回 言いにくいことほど、ストレートに言うべきだ 第213回 株主の利益より、自分の将来の方が大事 第214回 うそつきだらけの予算争奪戦 第215回 絶対に失敗させないボス流PM術 第216回 「仕事の先」より「上司の欲」を読む方が大切 第217回 チームワークはうそで成り立っている 第218回 “社長の本音”は商売のタネ 第219回 ちょっと言いにくいオフショア開発の“真実” 第220回 競争社会を生き残るための社交術 第221回 一つの遅れが全プロジェクトの納期を遅らせる 第222回 空気が読めない人にとって、自慢と流行語は鬼門 第223回 効率を追求し過ぎるとクビになる 第224回 気まずいデートを乗り切る方法 第225回 説得力は、見た目とプロフィールで決まる 第226回 上司と部下は、夫婦のようなもの 第227回 職場では、毒のない人間を探す方が難しい 第228回 転職の悩みは万国共通 第229回 節電しないと、データセンターがお化けになる 第230回 有事への備えも効率的に 第231回 メディアとベンダはもうけの種 第232回 会社とは、ストレス強度を測る生体実験の場 第233回 開発関係者にとって、夕方の電話は不吉 第234回 上司の「遠慮はいらん」を信じてはいけない 第235回 今すぐできる、納期を引き伸ばす方法 第236回 突然のクビは飛躍のきっかけ 第237回 会話への割り込みは上司の特権 第238回 個人目標とその評価は、深く考えない方がいい 第239回 職場では、“役立たずのアホ”ほどその自覚がない 第240回 優れた提案は、他人の迷惑 第241回 無理難題を押し付けることほど、簡単なことはない 第242回 無知な相手は適当にいなすに限る 第243回 キュレーターも知らない「キュレーション」の意味 第244回 ビッグデータ時代の就職面接 第245回 多忙に見せかけてサボる方法 第246回 転職理由を隠さなければ、転職先に早くなじめる 第247回 ロクでもない選択肢しかないときは笑える方を選べ 第248回 ヒーローと泥棒の違いは紙一重 第249回 会社では、アホな目標でも真面目に受け止めよう 第250回 男目線のロマンは、女性にとって不気味なだけ 第251回 プロジェクトの失敗原因と責められる人間はいつも同じ 第252回 部下の不快に快感を抱くようになったら一人前 第253回 組織では、エラくなるほど下らない気遣いが必要 第254回 来年度予算を獲得する秘けつは“アホ”になること 第255回 「サポート」と「嫌がらせ」は紙一重 第256回 “言いっ放し”は勝ち組の特権 第257回 ランチがランチになるか会議になるかは相手次第 第258回 優秀なサポートは、何もせずにチケットを完了させる 第259回 企業が目指すべきは、顧客との虐待関係 第260回 コミュニケーションが下手な人は、いつも間が悪い 第261回 革命や反乱を簡単に阻止する方法 第262回 エラい人ほど、自社の業務分野の知識がない 第263回 相手を落とす極意は、ロジックより思いつき 第264回 情シス部員の考えは、ユーザーには伝わらない 第265回 「危機感を持て」と迫る上司には知力も決断力もない 第266回 「Photoshop」という言葉を悪口に使ってはいけない 第267回 上司には、真実を告げてはいけない 第268回 エンジニアは「仕事が全て」の生き物 New!Last Update 2012/5/25

コーナー

日本版SOX法＆コンプライアンス

仮想化時代のインフラ選択

グリーンIT

いまこそITマネジメント

ソフトウェアテスト・プラクティス

モデリング・プラクティス

工事進行基準

BPMプロフェッショナル

アジャイル・エンタープライズ

NewsFlash