TOP業界裏話注目ニュース徒然コメントリンク紹介
『外資系企業に住む住人の視点からIT業界の出来事を伝えます。』

以前好評いただいた『資料作成の基本』から図解作成だけにテーマを絞って抽出した本が2018年6月23日に発売となります。 https://www.amazon.co.jp/dp/4799106511

図解作成の基本
本書は「資料」ではなく「図解」の作成に特化しています。図解は、論理的にわかりやすい内容、感覚的に心地よい見た目が好まれます。図形のカタチ(フォーム)と配置(ポジション)で生み出される「要素のバランス」、色の使い分け(カラー)によって醸し出される「コンテンツの強弱」です。それらを「図解キューブ」というモデルで表し、その実践例をチャートとグラフの「図解パターン」として体系的・網羅的に整理しました。これらを「エグゼクティブ図解術」と私は呼んでいます。本書を図解作成のハンドブックとして、ぜひ使ってみてください。


【吉澤準特の本:累計10万部以上】
外資系コンサルのビジネス文書作成術』はロングセラーで重版多数
外資系コンサルが実践する資料作成の基本』はロングセラーで重版多数
外資系コンサルの仕事を片づける技術』はロングセラーで重版多数
フレームワーク使いこなしブック』はロングセラーで重版多数
兄弟本の『ビジネス思考法使いこなしブック』はロングセラーで重版多数

【吉澤準特の過去配布レポート】
「外資系コンサルの仕事を片づける技術」特別抜粋版のダウンロード
「最新会議運営の基本と実践がよ〜くわかる小冊子」のダウンロード
できる人の9つの法則
コンサルタント直伝!コミュニケーションのプロになれる!


IT業界の裏話(まぐまぐ殿堂入りメルマガ)へ
メルマガ登録ならコチラ メルマガ解除ならコチラ
メールアドレス:
メールアドレス:



2009年02月28日

Yahoo!Japanのシステム開発と運用の裏側
このエントリーを含むはてなブックマーク

Yahoo!Japanでシステム統括部にいらっしゃる方が、Yahooのシステム開発と運用の分離について書いています。

http://techblog.yahoo.co.jp/cat207/cat209/post_6/

当開発部では開発者と運用者とを明確に分離し、

  • 開発者はリリースモジュールに触れる事が出来ない。
  • 運用者はソースコードに触れる事が出来ない。

というシステムを確立する事にいたしました。


そこで、リリースフローを見直し、
ソース管理からリリースモジュールの作成までを自動化させる事により、
人為的操作の介在を許さないリリースフローの構築を目指したのです。

ITILでいうところの変更管理、リリース管理、構成管理の仕組みを図解して説明してあるので分かり易いですね。 一般的な話ではありますが、実際にYahooほどの企業で行われていることが中の人によって説明されていると実感が湧きますね。

 

 

 

posted by 吉澤準特 at 11:45 | Comment(0) | TrackBack(0) | 注目記事

2009年02月27日

世界は1970年1月1日に作られ、2038年に終わるという衝撃
このエントリーを含むはてなブックマーク

神はこの世界を39年前に作り上げました。

そして、この素晴らしき世界は今から29年後に終わりを迎えます。これは誰も防ぐことができぬ運命(さだめ)であり、その刻が来るまでただ待つことしかできないのです・・・・・







一部の方には出オチでしたかね。

ご存知無い方のために説明しますと、これは2038年問題と呼ばれるUNIX時間にまつわる話です。業務用コンピュータのOSに採用されることが多いのがUNIXですが、UNIXが持っているシステム時間は1970年1月1日を起点として32ビット整数で計算されており、この数値が最大値を迎えるのが”2038年1月19日3時14分7秒”なのです。

キーマンズネット
で紹介されていたのでちょっと取り上げてみました。

90年代後半に騒がれた2000年問題と似たようなものですけど、今回はそれほど問題にはならないでしょう。なぜなら、すでに64ビット整数によるシステム時間が登場しており、これによってあと3000億年分はカウントできるようになったから。

32ビット整数で管理しているUNIXマシンもあと30年もすれば全て置き換えられていることでしょう。

posted by 吉澤準特 at 21:48 | Comment(0) | TrackBack(0) | 徒然コメント

役に立たない情報システムができる本当の理由とは?
このエントリーを含むはてなブックマーク

ITシステムの開発でトラブルの元になるのが業務部門とシステム部門のすれ違いにより生じる要件ギャップの発生です。

このことについて@ITで面白い記事があったので紹介します。

 「スピードを上げたい」「死に筋を発見したい」といった目的で情報システム投資を推進したつもりでいたのに、システムはできたものの、効果が上がらないといったことはありませんか? 経営者や管理者の皆さんが、課題解決手段の1つとして採用したはずのIT(情報技術)投資が、いつしか目的を外れてしまう。こんな経験はありませんか?

 あなたの決断を受けて、情報システムの構築あるいは運用という手段を使って目的遂行を担う人・組織を“システム屋”と呼ぶことにします。具体的には、外部のITベンダー・システムインテグレーターに所属するシステムエンジニア(SE)、営業担当者・責任者、社内のシステム企画担当者、プロジェクトマネジャーなどが含まれます。

 彼らシステム屋に対して、「コストが高い」とか「腰が重い」といった現象面での苦情を心に秘める人は多いと思います。一方で、「真面目にがんばってくれている」こともあながちウソではない。それではなぜ、多額のIT投資に見合う効果がなかなか出ないのでしょうか?

 私は、システム屋があなたの狙いを理解しようとしていないのが、根本的な問題だと考えています。

 システム屋は、あなたが発する具体的な指示や、決められた納期あるいはコストなどは肝に銘じて動きます。一方で、あなたの真の狙いを理解しようとしていないのです。「狙いを理解する」のはあくまで経営者の役割で、自分の役割だと思っていない可能性もあります。コンピュータが人間の言語を理解しないように、システム屋は経営者の言語を理解しないのです。

 例えば、「金融商品のコンビニエンスストア業態みたいなものをやりたい」「どのプロセスがボトルネックになっているかが知りたい」「企業買収のコモディティー化が事業コンセプトだ」「ベストマッチングではなく仮説・検証を繰り返すようにしたい」といった経営者の狙いは、システム屋にとっては外国語みたいなものでしょう。「システム化の範囲を定義してください」などと、システム屋から切り返されるのがオチかもしれません。

 それではと、経営者がもっと具体的に、目的や機能、範囲、利用者、利用局面などを説明すると、システム屋は「やっと自分の出番だ」とばかりに仕事を始めます。実はここが要注意です。目的や狙いが、機能・範囲・利用者・利用局面などと整合性が取れているかどうか、つまり、狙いが実現されるかどうかについては、「自分の仕事ではないや」とシステム屋は安心するのです。

http://itpro.nikkeibp.co.jp/article/COLUMN/20090218/324986/



私は業務コンサルタントであると同時にシステム屋の仕事もこなしているので、経営層とIT部門の温度差を肌で感じる機会は多いです。記事の著者は業務とシステムの両面で経験が豊富のようですので、きっと私が書こうと思っていることの多くを代弁してくれることでしょう。期待します。
posted by 吉澤準特 at 05:14 | Comment(0) | TrackBack(0) | 注目記事

2009年02月26日

世界最大のコンサル会社が最低な仕事をする理由
このエントリーを含むはてなブックマーク

世の中にコンサルティングファームというものがあります。

クライアントの課題や悩みを解決することを目的としており、そのために優れた人材が集まる組織であると一般的には言われています。事実、優秀な人材は集まっているのですが、一方でこんな話を耳にしたことのある方もいるのではないでしょうか。


・私よりも経験の浅いコンサルタントが来たせいで、一から業界の知識を教えなきゃいけなかった。

・口を開けば一般論しか出てこない。このコンサルタントはうちの会社のことを本当に理解して提案しているのか疑問だ。

・コンサルに入ってもらったのに結局課題は解決しないまま。ムダに高いカネを払っただけで意味がなかった。


これが世界最大と言われるコンサルティングファームのコンサルタントに対する評判だと聞いて、はたしてあなたはどう思うでしょうか? 高い金だけ払わせて残した成果は大したものではなかった、これなら自分でやった方が良い結果が出せた、そう感じたクライアントがいることを聞いて「大したことないね」と思ったのなら、ちょっと耳を傾けてください。


唐突ですが、ここでマクドナルドという会社に注目してみたいと思います。

世界最大のハンバーガーチェーンであるマクドナルドは世界中で同じハンバーガーを売っていますが、これは文字通り、寸分狂わぬ”同じ味”のハンバーガーを消費者に提供し続けていることを意味しています。あなたが最近食べたマクドナルドのハンバーガーの味を思い出してください。

「それほどうまくないけど不味くて吐き出すほどでもない、まあいつも通り可もなく不可もない味だよ」

そんな感想を持つ人が多いと思います。そしてそれは世界の何処に行っても変わる事なく同じ感想を抱くことでしょう。こうした、いつどこで食べても同じような味わいを持つ食事を作るということに秘密があります。

ご存知の通り、マクドナルドは世界中のどこの店舗に行っても同じマニュアルを使ってハンバーガーを作っています。東京銀座のマクドナルドでパティ(肉)が焼かれる時間が38秒だとすれば、それはシンガポールのマクドナルドでもそうですし、ニューヨークでも変わりません。およそ38秒で焼き上げるのがマクドナルドのハンバーガーなのであり、それより焼き時間が長くても短くてもマクドナルドのハンバーガーではないのです。


さて、このマクドナルドと世界最大のコンサルティングファームにある共通点があることをあなたは知っていますか?

ヒントはもう出ています。さきほどマクドナルドのハンバーガーの焼き方について説明しましたが、これはマクドナルドのハンバーガー大学で開発された方法論(メソドロジー)にしたがっているだけです。それ以上でもそれ以下でもありません。その結果が、あの美味くもなく不味くもない”あの味”を作り出しています、常にね。

では、マクドナルドよりも美味いハンバーガーを作ることが難しいかといえば、答えはNo。簡単とは言いませんが、頑張ればあなたでも美味しく作ることはできるでしょうし、実際にモスバーガーなどは明らかにマクドナルドよりも美味しいハンバーガーをチェーン展開で提供しています。

しかし、まったく同じ味のハンバーガーを世界中で常に提供し続けることができるかといえば、その答えもNo。作り方が厳密に定義されていないから作り手によって味が微妙に変わってきますし、材料の品質にも地域差が出てくることでしょう。とある天才料理人がものすごく美味しいハンバーガーを作ることに成功したとしても、その味を楽しめるのは天才料理人が実際に腕をふるうお店だけなのです。

どんな素人でも同じ味のハンバーガーを作れるよう、マクドナルドは膨大なメソドロジーによって調理方法を厳密に定義しました。どんな素人も失敗せずにハンバーガーを作れるためにはこれがベターな方法だったのです。


ここまで読んだあなたはもう気付いたかもしれませんね。

この話はJoel on Softwareというソフトウェア技術者向けに書かれた書籍の「ビッグマック 対 裸のシェフ」という話で触れられている話題です。

この話の要点は、


1. ある種のことをうまくやるには才能が必要
2. 個人の才能を他者にスケールさせるのは困難
3. 人々が才能をスケールしようとしてやるのは、才能ある者に作らせたルールに才能のない者を従わせる、ということ
4. 結果として得られるものの品質は一定だが低くなる


ということなのですが、これをITコンサルタントに当てはめて論理展開をしているのがジョエルの面白いところ。この方、もともとはマイクロソフトでソフトウェア設計を担当していた経歴を持っています。

コンサルティングに当てはめた話は読み物として純粋に面白いのですけど、少し文章が長いので以下リンクで読めるようにしておきました。ITコンサルタント、SE、PGなどIT業界に生きる方は読んでおくと参考になりそうです。


【Joel on Software:ビッグマック 対 裸のシェフ】
 → http://it-ura.seesaa.net/article/114822481.html

posted by 吉澤準特 at 03:09 | Comment(2) | TrackBack(0) | 業界裏話

Joel on Software:ビッグマック 対 裸のシェフ
このエントリーを含むはてなブックマーク

なぜクールな新興コンサルティング会社が、事業開始早々目を見張るような成功を立て続けに収め、急速に成長し、それから平凡な会社になってしまうのか?

マイクは参っていた。彼は大きなITコンサルタント会社にシステムを依頼した。そのITコンサルタントは「メソドロジー」の話をするばかりの無能者で、何百万ドルも使いながら、なにひとつ作れなかった。

幸運にもマイクは、とても頭のいい才能ある若いプログラマを見つけた。その若いプログラマは$20のギャラとピザだけでシステムを丸ごと、一日で作り上げた。マイクは非常に喜び、友人たちにもその若いプログラマを勧めた。

「若きプログラマ」は大金を稼ぐようになった。彼はすぐに自分でできるよりも多くの仕事を依頼されるようになり、一団の人々サポートに雇った。優秀な連中はあまりに多くのストックオプションを要求するので、彼は大学を出たての若いプログラマを雇うことにし、6週間のコースで彼らを「トレーニング」することにした。

問題はこの「トレーニング」が一貫した結果を生み出さなかったことで、そのため「若きプログラマ」はもっと一貫した結果が得られるようにルールと手順を作り始めた。何年にもわたってルールブックは成長し続け、すぐにそれはザ・メソドロジーと呼ばれる6巻のマニュアルになった。

数十年後、「若きプログラマ」は今や大文字Mのメソドロジーで知られる、巨大で無能なITコンサルタントとなっており、それが機能しそうにないときでも人々は盲目的にそのメソドロジーに従っていた。というのは彼らは他の考えというのは何も持っておらず、それに彼らは本当に才能のあるプログラマというわけではなかったからだ。彼らはただの政治学専攻の善良な人々で、6週間コースを聴講したのだった。

この新しい巨大で無能なITコンサルタントは混乱し始め、その顧客はみな不幸だった。そして別な才能あるプログラマが現れ、彼らの仕事をすべて奪い、そして新たなサイクルが始まる。


これはジョエルオンソフトウェアの一説です。有志がオンラインで翻訳しているので、一度読んでおくことをオススメします。

【ジョエルオンソフトウェア Online翻訳】
http://local.joelonsoftware.com/wiki/Japanese



posted by 吉澤準特 at 03:01 | Comment(0) | TrackBack(0) | リンク紹介

2009年02月25日

コンサルを目指す学生との対話『向いている人』
このエントリーを含むはてなブックマーク

私の所属している事務所ではコンサルタント業界を目指す人向けの指南書を提供するとともにカウンセリングを行っています。これまで複数の方に利用頂いているのですが、業界の本質に触れた相談や就職活動全般に関する素朴な疑問を受けることがしばしばあり、興味深かったので一つのテーマとして扱ってみます。

これは大学生のMさんから受けた質問です。


『コンサル業界は、目に見える形で商品を提供される訳でもなく、また、BtoBということもあり、ホームページ上にアップされている先輩社員の仕事紹介などを見ても、どういう人が働いているのか、またどういう特徴の人が多いのか、がピンと来ません

(たぶん、考える癖の付けたアンテナを張り巡らした優秀な人が多い、という印象です)

そこで質問ですが、コンサル業界ではどのような特徴の人が働いていると思いますか? また、特にITコンサルタントにはどんな特徴を持つ人が多いですか?』



みなさんはどう思いますか? 頭の良い人、洞察力のある人、パワーポイントの資料を作るのがうまい人、きっと色々な特徴を考えつくことと思いますが、私がMさんに回答した人材像は次の通りです。


『コンサル業界の人材の特徴を主に在籍年数から大別すると次のようになると思います。

1年:一定以上のストレス耐性と向上心を有する
3年:自分のタスクをコントロールする術を有する
5年:他人のタスクをコントロールする術を有する

クライアントへの奉仕の精神だとか成果物への品質のこだわりだとか、色々な要素はあると思いますけど、根源的な特徴は上記の通りでしょうね。

よく言われる話ですが、人間を農耕民族と狩猟民族に分けるとすれば、コンサルタントとして5年以上仕事を続けている人は間違いなく狩猟民族です。

狩猟民族というのは、常に獲物(成長の機会)を伺って周囲を見回し、隙あらば飛び込んでいくマインドセットを持った人を意味します。IT系コンサルと呼ばれるところだと狩猟民族っぽくない人達がある程度いますが、そういう方はベンダーから来た中途入社の場合が多いですね。

このカテゴリのコンサルファームや総研はシステムインテグレート(SI)を行うことが多いので自分の守備範囲の仕事で満足してしまう人も出てきますが、それが許されるのは入社3年目くらいまででしょう。

ITコンサルとして働く人の特徴は、システムに落とし込む思考ができる、という点だと思ってくださって結構です。』



例外というのは常にありますから、私の回答が絶対的に正しいという保証はありません。これはあくまでも私の経験則に基づくひとつの意見ですが、当てはまる事例は多いと覆っています。

もちろん、ストレスコントロール、そしてタスクコントロールを身に着けるのと並行して、強みとなる【概念スキル】を磨き上げるのを忘れずに。

概念スキル:
 http://it-ura.seesaa.net/article/114775904.html
posted by 吉澤準特 at 04:10 | Comment(0) | TrackBack(0) | 業界裏話

コンサルタントの中核的スキルである概念スキル
このエントリーを含むはてなブックマーク

概念スキルに関する説明:

コンサルタントは、会社の中の各部門がどのような役割を担い、それぞれがどのように関連しているかを理解し鳥観するためにヒヤリングを行う。ヒヤリングによって各部門の業務内容を把握し、相互依存関係を理解するのだ。

その際、ヒヤリングですべての情報を把握しようとすると、非常に多くの時間と労力を必要としてしまう。また、「情報をどのような形に整理すれば目的を達するのか?」が明確でないと、収集すべき情報も明確にはならない。

 従って、これらを容易にするためには、会社の中に通常ある業務機能と、業務機能間の関係を整理したテンプレートを、知識として事前に習得しておく必要があるのだ。


『コンサルタントの中核スキルに必要な知識は?』
http://www.atmarkit.co.jp/im/cits/serial/consultant/04/01.html
posted by 吉澤準特 at 03:38 | Comment(0) | TrackBack(0) | 注目記事

日本で苦戦する「パッケージ型」のシステム開発
このエントリーを含むはてなブックマーク

システム開発には「カスタム開発」と「パッケージ開発」の2種類が存在します。前者は業務要件にしたがってゼロからシステムを作り上げていくアプローチ、後者は出来合いの製品を購入してきて業務に使うアプローチです。一時期、パッケージ導入が時代の最先端だと謳われていた時期がありましたが、まだ主流とはなっていないことが調査によって分かりました。

『日本で苦戦する「パッケージ型」のシステム開発』
http://www.itmedia.co.jp/enterprise/articles/0902/20/news077.html

ミック経済研究所によると、システムの中核を担うアプリケーション開発について、国内の市場規模は、2008年度で11兆7700億円と予測。その手法を大別すると「スクラッチ型」が8兆5484億円(72.6%)で4分の3弱を占めた。一方「パッケージ型」は3兆2220億円(27.4%)にとどまった。

 2013年度にはスクラッチ型が9兆3109億円(68.7%)、パッケージ型が4兆2460億円(31.3%)の市場規模になる見通しで、アプリケーション開発の主流は5年後も大きく変化しないとみられる。

 国内企業でスクラッチ志向が根強いのは「業務フローをパッケージ製品に合わせるのではなく、業務フローに合わせてシステムを構築することを好むため」とミック経済研究所は説明する。不採算案件になる比率が低く「平均打率が高い」(同)パッケージ型は欧米で浸透しているものの、「特に金融・公共・通信分野では大手のユーザー企業が限られており、パッケージ製品を使うと同じサービスになる。独自性を出すために、スクラッチ開発を採用する企業が多い」(同)ことなどから、国内では依然としてスクラッチ型が支持を集めている。


さて、あなたの周りではどちらの開発が多いですか?

posted by 吉澤準特 at 02:58 | Comment(0) | TrackBack(0) | 注目記事

2009年02月24日

IT技術者は交換可能な部品?
このエントリーを含むはてなブックマーク

大規模なSIプロジェクトに入っていると、プロジェクト管理チームと現場の各チームの間で対立が生じることがしばしばあります。お互いの無理解からもたらされる誤解は、時に深刻な対立を招き、プロジェクトが大炎上することにもなりかねず、こうした話題は枚挙に暇がありません。

ちょうど@ITでこれに関連した記事を見つけたので紹介します。
http://el.jibun.atmarkit.co.jp/takada/2009/02/post-a68c.html

ある進捗会議でのことです。チーム全体の進捗に遅れが出始めたので、プロジェクトマネージャから遅れている原因について聞かれました。わたしは「最初はある程度の勉強期間が必要です。計画では単純に作業量を日数で割っただけですので、遅れているように見えるのでしょう。後半に伸びてくるのでキャッチアップ可能な程度の遅れと認識しています」と答えました。

 しかし、驚いたことにそのマネージャは「A機能は難しい機能だからBさんじゃなくてCさんに担当させる。それと作業中のおしゃべりが目立つから、仕事に専念させるため知り合い同士は近づけないように席替えして」と言うのです。わたしは耳を疑いました。このマネージャは技術者を機械の部品の一部や家畜程度に考えているのだろうか。

 今まで機能の担当者していた人間に代わって、その機能について何も知らない人間が代打を務めることは容易なことではありません。設計書に記載していない背景や事情を知らないため、非常にリスクを伴います。また職場とはいえ、知らない人に囲まれ、冗談も言い合えない環境では緊張し続けてしまい良い仕事ができるはずもありません。


引用先の記事、最後の一文がちょっと狙いすぎでした。
posted by 吉澤準特 at 01:00 | Comment(0) | TrackBack(0) | 注目記事

2009年02月22日

ヤフー、自社データセンター所有へ
このエントリーを含むはてなブックマーク

今までYahooの大量のサーバ群はソフトバンクIDC(インターネットデータセンター)という別組織が運用していたのですが、ついにYahooが全てを管理することになりました。

『次世代インターネット事業の戦略的基盤構築に向けた当社子会社株式のヤフー株式会社への譲渡について』
http://www.softbank.co.jp/ja/news/press/2009/20090219_02/index.html
これまでYahoo! JAPANは、データセンターを自ら所有せず、IDCなどの事業者から調達してきましたが、今回の決定でデータセンターを自社所有し、将来の需要の増加への対応やサービス増強などを主体的に進めていける体制・設備を確保でき、今後、Yahoo! JAPANの事業全般において、データセンター関連コストの大幅な削減、調達の効率化、サービス投入のスピードアップ、計画的な事業遂行の実現などが可能になると考えています。

これによってYahooのシステム運用はさら柔軟に行われることになるでしょうね。”グーグル”は自前のDCを持っていますからいいとして、同業の括りになる”楽天”がどうするのか注目ですね。楽天はまだ独自のデータセンター運用会社を有していないと思います。

Paasということでプラットフォームを柔軟に調達可能な仕組みが注目を集めていますが、Yahooの今回の動きはそれを見越したアクションと考えることもできるでしょう。

なお、ソフトバンクのサイトには次のようなメリットが述べられていたので紹介します。

・Yahoo! JAPAN自身が持つ膨大な需要の合理的な配置により、スケールメリットが得られる。
・Yahoo! JAPANが所有することでのみ可能となる「大量サーバーの独自運用管理技術」を適用することで得られるデータセンター事業の効率化が実現できる。
posted by 吉澤準特 at 16:11 | Comment(2) | TrackBack(0) | 注目記事

2009年02月20日

ベリングポイント破産法適用
このエントリーを含むはてなブックマーク

ついにコンサル会社にも不景気の波が来ましたね。昨年9月以降の景気冷え込みでギリギリの経営を迫られていたと思いますが、ついに耐え切れなくなったようで。第1号はベリングポイントさんになってしまいました。

http://enterprise.watch.impress.co.jp/cda/foreign/2009/02/19/14969.html
posted by 吉澤準特 at 08:54 | Comment(2) | TrackBack(0) | 注目記事

2009年02月16日

IT業界、悪魔の辞典『SI編』
このエントリーを含むはてなブックマーク

IT業界にいると様々なプロジェクトに関わることになりますが、やはりSI(システムインテグレーション)に関わるものは変わったものが色々とあります。前回に続いて、今度はSIそのものにまつわる皮肉めいた表現を紹介しましょう。

【ウォーターフォール・モデル】=水が瀧を流れ落ちるようにプロジェクト危機が進んでいくことから、このような名称になった

【アジャイル開発宣言】=真に迅速な開発手法は、コード感覚を持たない設計者たちが撤退することである

【見積り】=この時点で予算と人員とデスマーチが確定する

【要件定義】=顧客の大事な要求を理解可能な20%の範囲に絞り込む工程

【基本設計書】=顧客が80%理解できないIT知識で顧客を満足させる品物

【詳細設計書】=設計者の理解できないプログラミング知識で設計者を満足させる品物

【ソースのコメント】=設計書よりも正確な仕様が記述されている箇所

【ソース解析】=一日のうちで最も脳の深い眠りが出現する作業時間

【コーディング】=コピペする作業のこと

【単体テスト】=プログラムを作りはじめる工程

【結合テスト】=プログラマが始めて仕様を理解する工程

【システムテスト】=SEが始めてシステムを理解する工程

【テスト仕様書】=設計書ではなく、コードにそって作成する書類

【デバッグ】=プログラムをコメント化すること

【進捗報告】=優秀なエンジニアは進捗ではなくスケジュールを進捗報告するものである

【レビュー】=仕事のやり直しを指示されること

【引継ぎ】=前任者の潜在バグを引き継ぐこと

【仕様変更】=2週間以上の作業をリセットされること

【バージョン】=仕様書とソースのバージョンは2世代以上ずれているのが通常である

【デスマーチ/デスマ】=仕事量がmaxを超え、プロジェクト要員の思考が一斉に停止する現象

【ユーザー教育】=ユーザーの前でバグ出しをする工程

【納品日】=まだ半分しか出来ていないシステムを稼動させる日

【リリース】=大量バグの市場開放

【カットオーバー】=生産性の高い先鋭部隊が一斉に退陣し、仕事をしていなかった人材のみが残される日


悪魔の辞典『ヒト編』はこちら。
http://it-ura.seesaa.net/article/114314527.html

『IT業界の病理コミュニティ』
http://mixi.jp/view_community.pl?id=1683753

posted by 吉澤準特 at 23:31 | Comment(0) | TrackBack(0) | 徒然コメント

IT業界、悪魔の辞典『ヒト編』
このエントリーを含むはてなブックマーク

IT業界にもありますよ、悪魔の辞典。多分知っている人は多いようで少ないと思いますから紹介しておきます。元ネタはmixiの「IT業界の病理コミュニティ」です。

今回はそのなかでもヒトにまつわる箇所を紹介します。

【プログラマ】=不条理なSEの言葉をプログラム言語に翻訳できるスゴイ頭脳の人

【SE】=顧客と話して仕様書を書き直し、プログラマと話して仕様書を書き直し、納品後も仕様書を書き直し続ける人

【リーダー】=プログラマの進捗を2倍に報告してくれる人

【プロジェクトマネージャー/プロマネ】=自分の作ったスケジュールを毎日書き直している人

【SIer】=プログラムも書かずにエンジニアを名乗っている世界的に稀有な存在

【外注】=プログラムが書けない正社員のためにプログラムを書く人

【中級者】=1つ質問をすると10倍わからない専門用語で懇切丁寧に説明してくれる人

【管理職】=独立しやすいこの業界において、適齢期に独立・起業しそこなって会社に残っている人

【熟練者】=顔色が白くて表情が乏しく生気が失われた人

【増員】=火を吹いたプロジェクトに油を注ぐ人

【営業】=突然職場に出てこなくなった開発者を探し出す人

【協力会社】=偽装請負/多重派遣という犯罪の共犯

【社長】=現場で不祥事が起こった時に辞職することを主な業務とする人

【35歳】=定年非退職の年齢



『IT業界の病理コミュニティ』
http://mixi.jp/view_community.pl?id=1683753





posted by 吉澤準特 at 02:25 | Comment(0) | TrackBack(0) | 徒然コメント

2009年02月11日

自分が決めたルールに違反するGoogle(グーグル)
このエントリーを含むはてなブックマーク

Google(グーグル)は厳しい検索ポリシーを持っていることで有名です。一昨年は、不正な検索誘導があったとしてBMWの本社ウェブサイトがグーグルで表示されないという事態も起き、村八分ならず「グーグル八分」なる恐怖の言葉までできました。

そんなグーグルですが、さすがにこれだけ巨大な組織になってくると社内での情報伝達も不備が出てくるようです。先日、日本のグーグルがBlogツールをリリースしましたが、このプロモーションにあたってグローバルのグーグルが定めたサーチガイドラインに抵触してしまったとのこと。

具体的には「Google急上昇ワードランキング ブログパーツ CyberBuzz」というキーワードで検索すると分かります。

CNETに詳しい解説があるので、そちらを見ると分かりやすいです。

『まずGoogleは、急上昇ワードランキングのブログパーツをプロモーションするにあたって、ブログを使ったクチコミマーケティング手法が有効であると考えた。そしてCyberBuzzの会員ブロガーに、ブログパーツの紹介、プログパーツの貼付け、ダウンロードサイトへのURLの掲載を依頼し、これを実施した会員ブロガーに対してメディア掲載費を支払った。

 Googleは、これら一連の行為がGoogle検索のガイドラインに抵触したと認めている。具体的には下記の2点だ。

* 掲載されたブログ記事は、Googleが契約した外部代理店経由でGoogleへリンクしていたが、明確に両社の関係性を示していなかった。
* Google検索における自社のサイトのランキングを人為的に上昇させる行為、また人為的にそのランキングを上昇させていると意図されてしまう行為に対して、Google自身が厳しいルールを持っている。

 つまり今回のプロモーションで、Googleは外部のブログにGoogleのガジェットについて記述してもらい、サイトへリンクしてもらった。このことはGoogle検索のランキングに影響を与えた可能性がある。よって、それらの行為はGoogleが持つガイドラインに反する、ということだ。

 現在、Googleは当該プロモーションを中止している。すでに書かれたブログについては、運営者に個別にメールで状況を説明し、削除を依頼していくという。また、運営者が削除に応じなかった場合は、グーグルとの関係性を明確に示すように修正を依頼するとのこと。』

http://japan.cnet.com/marketing/story/0,3800080523,20388004,00.htm
posted by 吉澤準特 at 13:18 | Comment(0) | TrackBack(0) | 注目記事

2009年02月08日

経済産業省が「萌えアイドル」をプロデュース:セキュリーナとは?
このエントリーを含むはてなブックマーク

経済産業省と聞くとお堅い組織に思いがちですが、実はこんな破天荒なコトもやっているところなのです。

セキュリーナ.jpg

一見すると萌えキャラのプロモーションに見えますが、扱っているテーマは情報セキュリティの細かいお話というところがギャップがあって良いですね。

情報漏洩のあんな話やこんな話をプロモーションビデオに仕立てて公開しているのですけど、経産省のお役人さんたちが真剣な面持ちで議論をした末がこのPVかと思うと、とても微笑ましいですよ。

【デビュー曲PV】
http://www.checkpc.go.jp/pv/popup.html?TB_iframe=true&width=548&height=336&modal=true

【ブログパーツ】
http://www.checkpc.go.jp/blog_parts/index.html

posted by 吉澤準特 at 23:43 | Comment(0) | TrackBack(0) | 徒然コメント

「知るぽると」、知っている?
このエントリーを含むはてなブックマーク

知るぽると、というサイトがあるのを先日知りました。

http://www.shiruporuto.jp/

東京都内の地下鉄などに最近広告が良く出ているので、それで知った方もいるかと思いますが、 私は官公庁に勤める友人から教えてもらいました。

金融に関する仕組みや暮らしの役立ち情報など、お金にまつわる話がとても分かりやすくまとめられており、無償の家計簿ソフト (しかも高機能)も配布しています。

自分の金融に関する知識を試してみたのですけど、かなりトホホな結果に終わってしまいました。 知っているようで知らないことって多いですよね。

知るぽると

でも、自分の資産を自己防衛するためにも、いろいろと勉強すべきだと思いました。

posted by 吉澤準特 at 13:48 | Comment(0) | TrackBack(0) | 業界裏話

2009年02月05日

「オマエの知識はオレのモノ」
このエントリーを含むはてなブックマーク

「Bさん、1ヶ月前に頼んだシステム監視製品の比較検討資料、金曜の会議で使いたいんだけど、もうできた?」
「えっと、とりあえず使えそうな製品をいくつか調べてるんですけどまだ整理できてないです。」
「まだ調べ終わってないのか?単純に製品情報をベンダーから貰ってまとめるだけだろ?」
「そうなんですけど、回答に1週間くらいかかるってベンダーの人に言われまして・・・」
「それくらい普通だよ。1ヶ月もあったのだから別に問題ないだろう。」
「すぐに回答してもらえると思ってしばらくベンダーに連絡取ってなくて、昨日頼んだらそう言われたんですよ。」
「問い合わせ先の目星がついた時点でさっさと連絡しておけって!まったく・・・それで、比較する観点ぐらいはもう出来上がってるよね?」
「そうなんですけど、どういった観点でまとめたらいいのか決まらなくて・・・」
「それで1ヶ月進捗がないって、おまえはアホか!次の会議に間に合わないぞ!」


さすがにここまで極端に叱られることは少ないかもしれませんが、仕事の進め方が悪くて上司から何らかの指導を受けた経験を持つ方は多いと思います。事前に決めた期限に成果物が間に合わなかった場合、何らかの影響が周囲に及ぶのは必定であり、叱られるのも当然ですよね。

ファシリテーションとは会議をスムーズに進めるだけでなく、仕事の段取りそのものを効率的にする術ですから、こういった場面がそもそも生じないようにする方法も考えるのもファシリテーションです。前回はコンテクストの観点から資料の作り方やパワーポイント道の守・破・離を説明しましたが、今回は効率性の観点で話をしたいと思います。

上記の例は、私が以前に参画したプロジェクトのシステム基盤チームで繰り広げられていたワンシーンです。このプロジェクトでは基幹システムの刷新に合わせてシステムインフラの見直しも行っており、システム監視の機能を持つ複数製品を調べて一番良さそうなものを導入しようと取り組んでいる最中でした。

システム監視製品には、JP1(日立)、Tivoli(IBM)、SystemWalker(富士通)など多くのベンダーから様々な製品が発表されており、ニーズに合致する製品を絞り込んでいくのは意外に骨の折れる仕事です。普通は代表的な製品を提供しているベンダーさんや取扱代理店から基本的な製品情報を提供してもらい、ある程度情報を集めたら評価を行うという流れですから、製品決定には3週間〜4週間をかけることになります。しかし、製品情報を集めて比較検討の材料となる資料を作る程度なら2週間もあれば十分でしょう。

予定工数が2週間の作業に1ヶ月も手間をかけていてはA課長が怒鳴りだすのも当然です。まずBさんは自分の作業の進め方について効率的に進めるための改善に取り組まなければなりません。

ここでもうひとつ見落としてはならない重要なポイントがあります。怒鳴られた原因はBさんの仕事の遅さによるものですが、その根本原因となったのは報告・連絡・相談(ほうれんそう)の不足でした。Bさんの仕事が遅かったとしても、作業開始から2週間たった時点でA課長に状況を報告し、ベンダーへの連絡も速やかに行い、悩んでいるポイントをA課長と共有できていればもっと早く作業を終えることもできたでしょう。

仕事を効率的に進めるためには2つの側面に着目することが重要です。前述の例では、「A課長やベンダーへの適切な報告・連絡・相談」そして「Bさん自身の作業」が該当するのですが、これをもう少し一般的な表現に改めると次のようになります。

 ・人の知恵を借りる作業
 ・自分で考える作業

1点目の「人の知恵を借りる作業」というのは、自分自身が経験したことがない、もしくは経験が浅い領域に取り組まなければならない際に、別の経験豊富な人にアドバイスを求めたり資料を提供してもらうことで進めるものを指します。

知らないことでも知っている人に頼ればあっという間に済んでしまうというのはよくある話です。料理に詳しくない人が料理をしようとすれば、まずは母親や奥さんなど料理に詳しい人に相談するでしょうし、インターネットを使い慣れた人ならば、YahooやGoogleでレシピを調べたり、Yahoo知恵袋やはてななど人力検索サイトや2ちゃんねるのような大規模掲示板で質問するかもしれません。”料理に詳しい人の知恵を借りて”自分で料理できるだけの情報を仕入れているのです。

2点目の「自分で考える作業」というのは、前述の1点目を利用して作業の段取りを考える行為です。厳密に言えば、どういった情報を集めてくるかは自分自身で考えることですが、単純化して話をするためにこのように定義します。

さきほどの料理の例にあてはめてみましょう。他の人に教えてもらったレシピをもとに何の食材が必要かは分かりました。次はその食材をどの店で買ってくるのかを考える必要があります。駅前の商店街で買うべきか、それともセールをやっている隣町のスーパーまで足を伸ばすか、はたまた一部の食材は好みではないから買うのをやめるか。すべて”自分自身が考える”ことで決めることです。

1点目は効率的な調べ方を知っていれば作業時間を短縮できますし、2点目は論点を整理する考え方を身に付けていれば素早く決断を下すことができます。しかし、前者はやり方を知っていれば実現できますが、後者は一朝一夕に身に着けることは難しいでしょう。野球やゴルフのフォーム練習と一緒で、思考アプローチが頭に染み付くぐらい何度も繰り返して実践で経験する必要があります。ゆえに、2点目の「自分で考える作業」を効率的に進める努力は地道に続けるとして、まずは1点目の「人の知恵を借りる作業」で作業時間の短縮を目指すことを優先しましょう。

各作業の進め方のコツはこちらで詳しく説明しています。

(EnterpriseZine寄稿記事)
「オマエの知識はオレのモノ」
posted by 吉澤準特 at 00:59 | Comment(0) | TrackBack(0) | 業界裏話





【IT業界の裏話】過去コラム(No.1-337)
[ TOP ]IT業界の裏話

▼ IT業界の人々
「内製率を高めたい」のに「世界...
人の話を聞かないIT技術者の...
コンサルを目指す学生との対話...
IT業界、悪魔の辞典『ヒト編』
改善は「自分が楽をすること...
近くて遠きもの、プログラ...
IT企業が求めるプログラマ...
ITプロの3割が機密情報に...
10年働くソルジャーが欲しい...
PGとSEの仕事の面白みは何...
メールをすぐ返信する人、しな...
├ ITコンサルタントになる方法
我がコードは我流。我流は無...
欧米人がグリーンITに積極的...
実は変化など望んでいないエ...
├ 実はコミュニケーション能力に...
IT業界人は自分のドッグフード...
IT業界を不人気にした重鎮...
IT業界の変わった人々
電子メール禁止!ゼロメール...
名言集−運用フェーズ−
システム開発における名言集
失敗から学ぶ人、学ばない人...
SEに多いコーチングタイプは...
あなたのコーチングタイプは...
ITエンジニアの年収公開サ...
CTCは何の略?
会議は踊る、されど進まず...
繰り返し使われるメールアド...
遅刻しそうなので面接受け...
社内SEが人気を集めている...
サポートセンターの悪夢
IT業界に向いていない人
日本の夏、熱暴走の夏
客前で後ろから刺される
システム障害でクビが飛ぶ人
病欠って何ですか?
昼休みって何ですか?
Windowsに弱いIT技術者2
Windowsに弱いIT技術者
エンジニアは音を伸ばさない
話しにくい人
転職する人しない人
サイコロ一振りで給料を決め...
コンサルがお絵描き好きなの...
コンサルの報酬額って?
ITコンサルとSEの違い
SEのITリテラシ
公私のケジメ

▼ 仕事のやり方
客先で自分のPCが差し押さえられ...
「闇リリース」は善意でやっても...
新人のための7つのワークハック...
仕事の質を落とさないメソドロ...
組織が150人を超えると仕事の質...
世界最大のコンサル会社が最低...
IT業界、悪魔の辞典『SI編』
パワーポイントを紙芝居に貶め...
日本と米国の違い:ベンダーサ...
定時退社日に罪悪感を感じるIT...
ストレス厳しい職場を生き抜く...
おまえが呼ぶな、俺が呼ぶ「ハ...
ITプロレタリアートは多機能工...
図表をリッチにする5つのシン...
セクシーパワーポイント道
エンジニア御用達のIT誌
メールコミュニケーションを200.
├ ニッポン・エンジニア・レボリュ...
ITのプロって何ですか?
クールビズにも限界、冷房28...
真夏に長袖!なのに裸より涼...
測定しにくいものを測定する方...
山田さんの使いやすいシス...
SEの品格
コンサルの品格
ダメシステムはひとまず葬れ
眠気対策アイテムを考える
長篠メソッド
ITサポートがユーザーに教え...
資格の価値
出張先のホテルでインターネ...
お口の恋人
絶対に潰れない会社の悩み
エアエッジが必要になる理由
ハイプ曲線+キャズム理論
ユンケル黄帝液とスーパー黄...
一貫性が信用を生む
デビルズ・アドボケイト
落とし所を見定める
クライアントの良き友人たれ
キャンペーンでたたみかける
比較で暴利をごまかす
権威を活用する
ヒヤリハットの考え方
密談のタバコ部屋
「えいや」で決まる、魔法の言葉
海外テレカンの心得
IT業界でうまく生きていくコツ
ポンチ絵
仕事と作業の違い
上司に背を向けると怒られる?
ロケットスタートのススメ
人の考えを利用すべし
「見える」化
仕事の範囲
ワークシートのススメ
フローチャートの基本
仕事のやり方、片付け方
もんたメソッド
高橋メソッド
作業時間の見積り方
仁義を切る
アクションプラン
ミーティングと議事録
ベンダー選定の基準
ITと数学
レスポンシビリティとアカウンタ..
仕事の密度
リクルーティング
ドキュメントプロパティ
クライアントが納得する答え

▼ 仕事の環境
こんなのITのプロらしい仕事...
デスマーチに陥るお決まりパ...
外資が休暇を大切にする”真”...
HTMLメールとテキストメール...
ペーパーレス化が紙の無駄...
携帯電話のSDカードも禁止す...
人々は安定性と安全性の両方...
カタカナ会社はあやしい会社?
サービスリリースの落とし穴
IT業界の職場環境
IT業界の労働環境悪化は...
英語の必要性
正月出勤
年末年始の過ごし方
止められないコンピュータ
動かないコンピュータ
リリース直前の危機

▼ IT業界の動向
クラウドプレイヤーの名言集...
ネット史上最大の惨事、マイクロ...
ベンダー努力を台無しにするIFRS...
電子政府構想は無駄遣いの温床...
NASAのレポートがIT業界に与える...
中国当局によるプログラム盗用は...
コンサルもSIerもいらない内製...
中国のソースコード強制開示制度...
IBMは当て馬、Oracleが演出する...
PWCCが復活、ベリングポイントを...
IBMに喰われたSun、IT業界に訪れ...
ヤフー、自社データセンター所有...
自分が決めたルールに違反するGo...
SOAは死んだ
データセンターを巡るIT業界三...
├ リーマン破綻にみる米国証券業界...
IT史に輝く「すべったテクノロジ...
冷却を必要としない常温データ...
過去のIT業界10大予測を振り...
├ エンジニアよ、大志を抱け!
├ 黒箱襲来!コンテナがDC...
IT業界進化論: SIer 2.0を目...
IT業界がダメな理由を学生の...
IT業界温室効果の1/4はDC...
新生ニコニコ動画、ニコンド...
システム前線異常アリ!ゆう...
ニコニコ動画は文化の架け橋
Web2.0の向こう側〜サードリ...
セカンドライフだけで宣伝の...
国家戦争にも利用されるDDo...
DoCoMo2.0に見る情報格差...
DoCoMo2.0とWeb2.0
ITIL準拠という幻想
システム障害訓練の日を制...
WAONとnanacoが提携したい...
NTT東西の野望〜光回線編...
mixi招待制の綻び
Vistaが売れない理由
独自仕様に走り過ぎて泣き...
米国事情から見る日本のIT...
MVCからAjaxへ
外字ってなんですか?
Sunがx86サーバにIntel採用...
やりたい放題バッドウェア!
アウトソーシングという名の幻...
ソフトバンクモバイル、MNP停...
やっぱり止まったソフトバンク...
あらゆる意味でやり過ぎの...
経営者不在の日本版SOX法...
働いてみたいIT企業ランキン...
サーバの進化がデータセン...
_システム運用にRSSを活用
電力線通信が認可される日...
携帯メールはSSL通信よりも...
経営者不在の日本版SOX法...
Microsoftがサイトリニューア...
停電に脆弱なシステム
システムは誰のためにある...
ITILで運用が楽になる?
進化するコールセンター
Vacademy
IT業界にロングテールはある...
時間をお金で買う
あなたの猫はコンピュータウ...
個人情報保護法の範囲
あなたvsプロジェクト構成管理
ドラマ24にみるシステム最前...
次世代トレンドと枯れた...
日本版SOX法の施行に向け...
新しいWindowsはWeb決済...
地震に強いシステムをお持...
IT Doesn't Matter
SOAと分散コンピューティン...
各社で定義が異なるESB
おサイフケータイに見...(2/2)
おサイフケータイに見...(1/2)
子会社のシマを荒らす親会社
アインシュタインに学ぶソフ...
公職選挙法とインターネット
マイレージ負債
インターネットの舞台裏:海底...
ゼロ・クライアント
サーバのトレンド
外資系パッケージベンダー

▼ 業界の構造
対極にあるIT業界とコンビニ業...
IT業界は成果報酬型のサービス...
特定ベンダー以外をふるい落と...
欧米人なら爆笑するレベルと...
IT業界が詐欺師集団と言われる...
IT業界の格差社会、年収200...
├ 新基準導入でデスマーチがな...
公式では言えないニコニコ動...
├ コンサルとアプリ開発者、格差...
システム運用はIT業界の最下...
テストフェーズの呼び方は千...
2000年問題再来!?サマー..
減り続ける正社員の割合
労働局が偽装請負の抜け道...
会社貸与のPCは何年償却?
ITIL Foundationを2万円で買..
IT製品もイメージ重視?
お試しできない製品は売れない
IT業界は無免許制
どんぶり勘定
標準価格と提供価格
ソフトウェアライセンス
社外秘の秘密度合
偽装請負 
システム開発の流れ7 テス...
システム開発の流れ6 開発...
├ システム開発の流れ5 開発...
システム開発の流れ4
システム開発の流れ3
システム開発の流れ2
システム開発の流れ1
IT業界の構造

▼ 業界ランキング
SIerランキング2005
コンサルランキング2005

▼ その他
「幣社」という表現は相手を見下...
コミュニケーション力の不足は...
聞く耳を持たないYahooニュース...
黒デスクトップ事件に見る中国...
ITコンサルから見たブラッディ...
違法ダウンロードでネット追放...
就職難民=不出来な学生とい...
モンスターペアレント、会社襲来
あえて言おう、Yahooの掲示...
プログラマ向きなカフェをオー..
├ Japan Brog Award 2008を..
日立さん、IT大喜利をもう一度
インターネット上の信頼できる...
IT業界でありそうな迷惑勧誘...
倒産してもカネを要求する悪2...
倒産してもカネを要求する悪1...
├ 枯れた技術の水平思考で
├ ずさん極まりない環境保護ラ...
世界の奇妙な法律を集めた...
50万円のキーボード
洋楽を1曲10円で購入できる...
CNETとZDNetは同じ会社
情報の価値(情報商材)
コンパイル1回12時間の世界
楽天ポイント事件
楽天ポイント事件〜利用者...
楽天300ポイント付与で謝罪
ライブドア強制捜査
└ ネットワークベンダー