全111件 (111件中 1-50件目)
-
説得の技法
今行っている仕事で、社員の方が組織改革の方針をまとめて取締役会に上申する、という場面に出くわした。その資料を読ませてもらったのだが、これがかなりよろしくない。コンサル会社の人間で言えば新入社員並みの資料で、2年目以降でこんな資料を作っていたら即クビになる、という代物である。簡単に言ってしまうと、「相手を説得する」ということにほとんど注意が払われていない。自分の考えをただ並べるだけの資料になっている。具体的には、以下のような点があげられる。・網羅性がない・展開が論理的でない・求める判断の範囲が大きい・網羅性がないコンサルが資料を作るときに絶対的に注意を払うのがこの「網羅性」である。「あれは考えなくて良いの？」と指摘されると、その時点でゲームオーバーだからである。例えば問題点として6つ挙げました、ということであれば、なぜ各種の問題が6つに絞り込まれたかのロジックを記述しなければならない。昔自民党の総裁選で亀井さんが立候補したとき、公約として「高速料金をただにする」とかいくつかの公約を掲げていた。これが「網羅性がない」典型的なパターンである。なぜ日本の諸問題の解決策が数個なのか、亀井さんはまったく示していなかった。・展開が論理的でない「風吹けば桶屋が儲かる」ではないが、自分の意図する結論に導くためには、論理的に話が展開すること、展開するときには必ず説得力のある「事実」を付加すること、が必要である。「○○の問題がある」よって「組織変更が必要だ」では論理が飛躍しすぎて同意できない。・求める判断の範囲が大きいこの資料の最大の敗因は、組織の変更策を具体的に示した点である。組織の変更は会社にとっては大きな判断になるため、おいそれとは決断することが出来ない。そもそも組織を変更すると問題が解決するかどうかがまったく見えないので、YESかNOかで判断を迫られれば、答えはNOとなってしまう。しかし、「いろいろな問題があるので、その解決策を検討するタスクフォースを立ち上げましょう」とか「組織変更で解決するかシュミレーションしてみましょう」といった提案であれば、経営者も同意することが可能である。判断の範囲を絞って、YES/NOを迫っていく、これも重要な技法である。ちなみにこの資料は取締役会預かり、ということで棚上げ（ゴミ箱行き？）しているようである。まあ当然か...
2005/07/19
コメント(58)
-
人に仕事をさせる
前日の日記に、「人に仕事をさせる時には精神的に追い込むこと」などという物騒なことを書いたが、それを具体的に書いてみたい。まず、締め切り日になったら必ず連絡すること。出来れば直接会うのが良いが、無理であれば電話でも構わない。メールはダメ。そこで必ず遅れた理由を徹底的に問いただす。「なぜ出来ないのか？」「何時間の作業と見積もっているのか？」「1日1時間でも作業すれば○日で終わるのではないか？」「遅れるのであれば事前に連絡をくれないのか？」「明日の○時に必ず状況報告のための電話をして欲しい」等々これだけ攻め込めば、相手は相当いやな気分になる。そうすると、「こいつから頼まれた仕事に遅れると、とてもいやな気分になるので早くやってしまおう」という気持ちになり、その人の中で作業の優先度が高くなる。ただし、心理的に追い込まれているが、相手の言うことはすべてもっとな事なので、自分で作業を進めるしかない、という状況にすることが重要。高圧的な話し方をして、「あの言い方は腹がたつな！」と思われると逆効果になる。このようなすすめ方をすれば、頼む相手の役職が上でも下でも関係なくなる。（直属の上司を追い込むのはやや危険かも知れないが．．．）是非お試しあれ。
2005/07/18
コメント(1)
-
プロジェクトマネージメント
プロジェクトマネージメントの本質は、・自分でスケジュールを立てること・他人にスケジュールを守らせることの2点だと思っている。「おいおい簡単すぎるぞ～」、と思われるかも知れないが、これがなかなか難しい。・自分でスケジュールを立てることプロマネの勝利の第一歩は、スケジュールを立てることである。まず、スケジュールとは、管理可能でなくてはならない。すなわち、終わったか終わってないのかが分からなくてはいけない。「～の検討」とかいう項目はダメである。「検討」の終了が何かが分からない。「設計」とかいうのもダメ。漠然としすぎていて、進捗を把握することが出来ない。また、盛り込む項目に、想定できるすべてのオプションを盛り込めるかどうかも勝負どころになる。突発的な事項でも、それが「想定内」であれば対処は楽勝である。想定していなければ、ダメージは大きい。・他人にスケジュールを守らせること次に厄介なのが、他人にスケジュールを守らせることである。他人に頼んだ時点で満足している人が多いが、それはプロマネ失格である。頼んだ相手が期日通りに作業を進めないことを想定して、しかるべき手を打つことが必要である。あまり良い手ではないが、期日を守らせるためには、精神的に追い込むのが効果が大きい。サラ金が借り手を追い込むパターンとよく似ている。サボるよりも作業をやった方が精神的に楽な状態に追い込めば、大抵こちらの意図どおりに作業してもらえる。もちろん、頼めばきちんとやってくれる人にはこんな手を使う必要はないが、世の中そういう人ばかりではないので、姑息な技が必要になってくる。これを実戦で鍛えるのみ！
2005/07/17
コメント(0)
-
郵政民営化
ネタ切れにつき時事ネタで、今話題の郵政民営化。新聞、テレビを見てもどうも各社の主張がよく分からない。マスコミの宿命として、小泉さんを全面的に支持している論調は皆無である。すすめ方が強引だ、とか、もっと他にやるべきことがあるだろ、とか批判している。ただし、郵政民営化そのものに正面きって反対しているところはない。私の個人的意見は、郵政民営化「賛成」何がなんでも今国会で成立してほしいと思っている。道路公団の談合を見るまでもなく、公的な機関にお金をたくさん持たせておくと必ず無駄使いをする。郵政公社に流れ込んだ340兆円は、どぶに捨てられていく。民間より金利が高いという理由で間抜けな人間は郵便局にお金を預ける。結局無駄使いは回収出来ずに税金が投入される。おきまりのパターン。なんの根拠も無いが、私と同意見の人は多いと思う。少なくとも日本経済新聞や経済界の論調は、郵政民営化をなんとか進めるべきだ、というトーンである。もし、参院で不成立、衆院解散になった場合、私は、小泉自民党（＝郵政民営化賛成党）が圧勝するような気がしている。永田町では、勢力が拮抗しているそうであるが、世論はそんなことはないと思っている。民主党は、郵政民営化に「反対」してしまっている。これはかなりの判断ミスと思われる。どうであろうか?
2005/07/07
コメント(1)
-
資格の悪用
コンピュータ関連の資格はたくさんあり、ベンダーの人間は自分に「ハク」をつけるため資格の取得に走る。取得した資格を名刺に刷り込んだりする。普通は、名刺に例えば、「ITコーディネーター」なんて書いてあると、すごい、この人は信頼できると考えてしまう。ところが、最近私は、コンサルとして会議等に参加し、ベンダー側に資格のある人が参加しているとついついそれを悪用してしまう。簡単に言えば、「ITコーディネーター」なんだからそっちでやってよ！ってな感じである。ベンダーの人間としては当然のことなのだが、自分たちのリスクや作業負荷を軽減し利益率を高くしたいと考えている。しかし、資格で提唱されていることは通常理想論なので、その資格を逆手にとって作業をベンダーに押し付けてしまう。当然こちら側に、相手を凌駕する圧倒的な経験、スキルがあることが前提だが、こうやって攻め込んでいくと、相手はかなりつらい状態におちいる。まったく自分はいやな人間になったものだと感心する...
2005/07/02
コメント(2)
-
システムとは？
「システムとは？」と聞かれたときに最も明確な答えは、「金持ちと父さん」シリーズの中でロバート・キヨサキ氏が答えている回答であろう。「経営者が1年間いなくなっても勝手にお金を稼いでくれる仕組み」もちろんこんな理想的なことはなかなか起こらないので、幸か不幸か世の中の経営者は皆忙しく働いている。しかし、目指すところはここである。こういう定義で考えれば、システム構築≠コンピュータの導入、であることは明白である。コンピュータだけ作って、明日からこれでよろしく！と言ったところで、それを利用する人間や業務プロセスがついてこなければ、システムでもなんでもない。社員全員をクビにしてアルバイトを同人数雇っても、問題なく会社が収益をあげることが出来る、これが理想のシステムであろう。
2005/06/29
コメント(2)
-
外資系コンサルタントのつぶやき
面白い記事を発見！外資系コンサルタントのつぶやき・外資系コンサルティングファームに就職しようとしている人・コンサルタントとして独立したい人・コンサルタントに仕事を依頼したい人・コンサルタントと一緒に仕事をしている人は是非ご一読を進めます。コンサルタントという人間の思考がとてもよくわかります。
2005/06/28
コメント(0)
-
「きれいな絵」をかくのがコンサルの役目
コンサルは「きれいな絵をかくことしか出来ない」ということがよく言われる。これはもちろん、「絵をかく」＝「それらしい構成を作る」＝「実際の構築では役に立たない」、ということが言われているのであって、「コンサルはもっともらしいことを言うけど、実際のシステム作りでは役に立たない」とバカにされているのである。しかし普通の人が考える以上に「きれいな絵」をかくことは大変である。さらに、一回「きれいな絵」が出来てしまえば、その絵の通りに忠実にシステムを構築する、もしくはダメだしをしてその絵を修正していく、という作業が可能になる。ところが「絵」が存在しないと、その後の作業を進めることが非常に難しい。「営業力が落ちているのでSFAを導入したい」、「情報共有がなされていないのでグループウェアを導入したい」とかいう希望がユーザ企業から発信される。わかりしました！とすぐに製品を提案するのが普通の人。コンサルであれば、本当？本質的な問題はもっと別のところにあるんじゃないの？と疑ってかかり、問題を解決する本質的な方法を「きれいな絵」にまとめようとする。（確かにこの絵は荒唐無稽なことが多く、実際に構築するとなると破綻するものものも多いのだが...）ユーザの希望（つぶやき？）を真に受けて製品を紹介し着実に作りこむ人、本質的な解決を目指し「きれいな絵」をかこうとする人、どちらが良いかは自明。そもそも世の中「きれいな絵」もかけないコンサルが多すぎる。
2005/06/27
コメント(0)
-
プロジェクトマネージメント
個人的には、「プロマネ」ほど胡散臭いスキルはないと思っている。しかし世の中では「プロマネ」は流行りの様子で、ITProでも、「プロマネ」は多すぎる？足りない？という記事が出ていたりする。私は「プロマネ」というのは「社長」と同じようなものだと思っている。「人」「もの」「金」といった必要な資源を駆使し、決められたゴールに向かって組織を動かして行く。「プロマネ」も「社長」もやることは一緒である。「社長」のスキルを養成する講座、なるものが出来たら、普通の人は笑ってしまう。「社長」のスキルなどとして一般化できるようなものはほとんどないし、逆に「人事」「会計」などの分野を学んだとしても、社長として成功するとは限らない。業界によっても必要なスキルは異なるであろうし、成功のためにはある程度の運も必要であろうし、意志の強さ、といった人格的な要素も強いであろう。「プロマネ」などという名前の単体のスキルはない。それは、「システム開発方法論」「IT技術」「経営」をきちんと理解していることであり、逆境をも跳ね返す「精神力」と物事を正しく考える「思考力」、といった各種のスキルの総合的な産物である。「プロマネ養成講座」に行ったからといって「プロマネ」にはなれない。金の無駄。
2005/06/24
コメント(0)
-
お客さんが決めてくれないから決まらない
進捗が遅れるときによく言われる言い訳のに「お客さんが決めてくれないから決まらない」というのがある。私も昔ベンダーにいたときは、よく使っていた言葉であり、お客さんが早く決断してくれれば、もっとスムーズに開発が進むのに、と「本当に」思っていた。しかし、コンサルになってみてこの考え方は180度変わった。今は、ベンダーが悪いからお客さんが決められないのだと考えている。例えば、A案とB案がありますがどっちにしましょうか？とかいう相談もあるだろう。これなどまだ良い方で、ひどいのになると、このままいくと納期に間に合いません。どうしましょうか？などと相談してくる場合もある。お客さんの立場から言えば、「自分で勝手に決めろ！」ということなのだが、ベンダー側はなぜか「お客さんが決めてくれないから...」というなぞの解釈をする。A案とB案がありますがどっちにしましょうか？という場合でも、そのメリットデメリット、費用対効果、スケジュールへのインパクト、顧客の組織を意識しての根回しプラン、等を綿密準備して相談すれば、大抵は早期に決着してもらえるはずである。それをなんの準備もしないで、ただどっちにしましょうか？と言ったところでお客さんは判断できるわけがない。逆に前提条件が不足している中で判断するような人は、キーマンとも思えないので、その人の決定に従うのはとても危険であろう。「お客さんが決めてくれないから決まらない」のではなく、「決めてもらうストリーを作っていないから決まらない」のである。人のせいにするのはやめよう。うまく行かなければ、悪いのは自分である。
2005/06/23
コメント(2)
-
Yahooサーチ
久しぶりに日記を復活させたのだが、いままでどんなことを書いてきたのか忘れてしまった。この半年間におきたことはぼちぼち書いていくとして、今日ニュースを見て笑ったこと。シンプルな「Yahoo！SEARCH」ベータ公開これってgoogle「ライク」とかいうレベルではなくて「ぱくり」じゃないの?恐るべしIT業界...
2005/06/21
コメント(0)
-
お久しぶりです～
ちょ～久々に日記を書いています。去年の12/1以来ですから、約半年ぶり！とりあえず、今日はこの辺で、
2005/06/20
コメント(0)
-
今日の朝日新聞から
かなり久しぶりの更新です。が、ITネタが尽きたので、時事ネタにします。今日のasahi.comを読んでの感想をいくつか。長男絞殺に猶予判決「万策尽きた父、罪償わせる必要ない」 この手の記事を読むたびに思うのだが、地域社会はどうしてこのような悲劇をふせげないのだろうか。親戚・近所から減刑の嘆願書がでた、とあるが、嘆願書なんかを出す前にやることがあったのではないか。もっと、隣近所の生活に介入してもよいのではなかろうか。児童虐待も根は同じだと思う。新紙幣、アイロンがけ要注意 ホログラム、熱で変質この記事の最後の行、「ホログラムが壊れても紙幣としての価値は変わらない」 それじゃ、偽札防止の効果がないと思うのだが．．．釧路沖の地震は「予測していた地震」 調査委が確認「３０年以内に８０％程度の確率で発生」って、そういうのを予想と言うかね．．．「世界選抜」中田が１得点 エイズ撲滅の国際慈善試合中田というのはいまさらながら、すごい人だ。世界選抜チームで活躍して、得点まで入れてしまう。やはり、今の日本チームでは別格の存在なのであろう。来年からのW杯予選、ジーコ監督は中田をどう使うのだろうか。使わないほうがチームとして良くまとまったりして．．．
2004/12/01
コメント(0)
-
提案書の威力！？
例によって日経の記事ブックレビュー---提案書作成技術を学ぶ7冊この中では、1番最初の「考える技術・書く技術」しか読んだことがないのだが、たぶんその他の本もそれなりの良い本なのだろう。この記事でちょっと気になったのが、「良い提案書が顧客に受け入れられて受注に結びついた．．．」のところ。個人的にはこの手の資料作成技術はシステムの計画・開発作業中に大いに威力を発揮すると思っている。逆に営業段階の有効性については懐疑的である。営業段階で重要なのは、プレゼンの力なんかよりも営業マンの力量に尽きると思っている。顧客のキーマンと近づき重要な情報を取得する。それを提案内容に反映させ、営業に支障が出る部分があれば速やかにそれを取り除く。プレゼンの技術よりも、接待の技術の方が重要な気がするが？私が思っているよりも、世の中ガチンコで勝負しているのだそうか？
2004/11/26
コメント(0)
-
特許の活用！？
おもしろい記事を発見した。破産企業の特許競売をめぐり、大手ハイテク企業がピリピリ--共同入札も検討この記事を読んで感じたことは2つ。1つ目は、Commerce Oneっていつのまにかつぶれてしまったんだ．．ということ。一時期B2Bアプリの筆頭みたいなことを言われていたのだが。2つ目は、特許の活用。日本でも無形資産として特許を見積もる動きが出ているが、それが進めば、特許が投資対象となり、安く仕入れて、高くライセンス料を巻き上げる、という当然商売が出てくる。最近、特許というものは、その発明者に報いるためという利点よりも、企業が自分の技術をネタに他人をゆするという欠点ばかりが目立つような気がする。とは言え、日本でも今のうちにこんなビジネスを始めておけば儲かるかも。
2004/11/25
コメント(0)
-
Novell
Novell、Linux事業好調で黒字転換という記事をみてびっくりしてしまった。Novell、こんな会社がまだ生きていたのか．．．Novellと言えば、10年ほど前、まだNetwork OSなる言葉が存在した頃、NetWareという製品で一世を風靡した会社である。しかし、この会社も、その他大勢の会社と同様、MSに撃破されてしまった。個人的には、8年ほど前、NovellがTuxedoというTPモニタ（今のアプリケーション・サーバの前身）をBEAに売却した時、BEA側のセミナーに参加したことを思い出した。今はなき某証券会社のお客さんとフロリダのタンパまで事例を発表しに行ったのが思い出される。その後BEAはWebLogicというアプリケーション・サーバを軸に事業を急拡大させていくのだが、逆にNovellは何をしているか分からない会社になってしまった。（しかし、その私の所属していた会社も、買収され名前がなくなってしまっているのであるから人のことは言えないが．．．）NovellはデスクトップLinuxの会社も買収して、Linuxディストリビュータとして地位を築くそうである。この動きをなぜかMSも歓迎しており、「やっぱり企業の関与しないソフトはダメでしょう」という感じである。10年ひと昔、とはよく言うが、この業界の10年前は江戸時代ぐらい昔のような気がする。
2004/11/22
コメント(0)
-
GDPデフレータ
このブログはIT関連オンリーでやろうと思っていたのだが、最近少しネタ切れ気味なのと、土日は時間が無いことから、週末は時事ネタを書いていこうかな、などと考えている。今日のお題は「GDPデフレータ」何日か前の日経新聞で、GDPデフレータの算出方式が変わることによって、成長率も変わってくる可能性がある、という記事を見つけた。経済成長率とはGDPの成長率で測られる。しかし、GDPが去年500兆円で今年が505兆円だったら1%成長か、というそうではない。物価の変動が加味されるからである。デフレが進んで、物価が1%下落しているのであれば、今年の505兆円は去年に換算すれば510兆円の価値があるはずだ、と考え、成長率は2%になる。去年と今年の単純な比を名目成長率、デフレを加味した成長率を実質成長率、物価の変動分をGDPデフレータという。ということは、乱暴に言ってしまえば、GDPデフレータの値次第で（実質）成長率などはどうにでもなる、ということである。名目成長率がマイナスでも、GDPデフレータがさらに大きなマイナスになれば、実質成長率はプラスになる。さらに、直感的に考えれば分かることだが、経済全体での物価の変動を数値化することはきわめて難しい。大根とか卵とかの値段なら比較は可能であろうが、工業製品は、そもそも機能が違っているのだから単純な比較は難しい。したがって、値自体もいい加減なものにならざる得ない。その数値を基にしている成長率も相当にまゆつばものである。この手の統計数値というものはよくよく吟味して意味を理解しないといけないと改めて思った今日この頃でした。
2004/11/20
コメント(0)
-
トヨタ自動車とIT産業
続・なぜ「IT産業のトヨタ」は出ないのかという記事の題名をみて笑ってしまったのだが、そんな比較をしても意味がないだろう、とついつい思ってしまう。自動車作りは、戦前から日本の得意とする分野であり、また、よいものを作れば売れていく、という単純な構図が成り立ちやすい世界である。片やITは、その誕生時点からアメリカの軍事技術として保護され、標準というものが大きくものをいい、良いものが売れるとは限らない世界である。そもそも、世界で名前がとどろくことが良いことなのか疑問に思ってしまう。「ナンバーワンよりオンリーワン」と言われているのだから、日本国内でユーザに強く支持される良心的な製品を作ることも、すばらしいことだと思うのだが。IT産業に何を期待しているのか、よくわからない。
2004/11/19
コメント(0)
-
企業合併と情報システム統合
企業合併と情報システムの統合に関してひとつの記事が目についた。熊谷組と飛島建設、合併を白紙に 統合に予想超す費用はたして、この記事に書いてあることは本当であろうか？企業や組織の合併分割時に、情報システムの取り扱いがその大きな足かせとなる例が最近増えているのは事実である。みずほ銀行や地方自治体の合併、いわゆる平成の大合併など例は山ほどある。しかしながら、上述の記事や、郵政公社の改革への反対理由として、情報システムが挙げられてしまうのを見ると、どうもうさんくささを感じてしまう。この記事の合併にしても、つまるところは銀行筋から合併を強制されただけで、両社とも合併したくはないのが本心であろう。情報システムの統合に費用がかかるという格好のスケープゴードができたため、それを理由に合併をつぶしてしまったように思えるのは気のせいか？通常、企業合併の最大のメリットは間接部門の経費削減である。情報システムなどはもっともコストがかかるわけであるから、その統合により経費削減を図るのは当然の行いである。したがって、情報システムが統合できない＝間接部門の経費が削減できない、ので企業統合ができない、という論理は本末転倒であって、理解に苦しむ。企業経営の中で、情報システムの比重が高まっていることを認識してもらうのは良いことだと思う。しかし、議題として情報システムが持ち出されると、なにか議論がブラックホールの中に落ち込んだようになり、なかなか突っ込んだ検討が行われない。こういった記事をきちんと解説するのがマスコミの役目だと思うのだが、なかなかそうはいかないようである。
2004/11/17
コメント(0)
-
マイクロソフト
会社がすごいのか、ビルゲイツ個人がすごいのかは良く分からないが、マイクロソフトという会社には常々感心させられる。世の中からよくたたかれるのも、皆がマイクロソフトの強さを肌で感じている裏返しの作用だと思われる。まず最初に感心したのが、Windowsのリリース。当時、MS-DOSは圧倒的なシェアを持っていたにもかかわらず、これからはGUIの時代だ、ということで、Macのパクリだとかなんだとか批判されようとも強引に開発をおし進め、世の中に広めてしまった。次にOffice製品。結局パソコンを使う人の目的はWinodwsではなく、その上位のアプリであることに気がつくと、事務用アプリをOfficeという名前でパッケージングして、これまた強引に世の中に広めてしまう。さらには、Windowsがいらなくなる世の中、すなわち、Webだけで全てが済む世界も見据えて、Netscapeを駆逐し、IEを標準にしてしまう。さらには、アプリケーションをパソコンにインストールするのではなく、ネット上での「サービス」として利用する時代を見据えて、「.NET」を提唱している。この会社の恐ろしいところは、たとえ自社製品と競合したとしても、世の中で受け入れられるのものであれば、どんどん開発していくことであろう。IBMがつぶれかけたのも、メインフレームに固執したからであり、SUNもUNIXに固執し苦しんでいる。マイクロソフトはすごい会社である。
2004/11/16
コメント(0)
-
デスクトップLinux
世の中のデスクトップ環境はほぼWindows一色である。Microsoftの寡占状態が続くことに対して、技術者が本能的に危機を感じ、対抗馬を担ぎ出そうとしているのがLinuxであろう。個人的には、デスクトップLinuxというものが広まる可能性はゼロだと思っている。1：コスト面確かに、初期コストはWindowsの方が高い。Windowsが1万円、Linuxが千円ぐらいであろうか。しかし、PCの値段が10万円ほどすることを考えてみれば、OSの価格差9千円はそれほど大きなインパクトにならないのではないか。さらにランニングコストであるが、おそらくLinuxの方が断然高額になるであろう。何か問題が起こったときの情報量は、圧倒的にWindowsの方が多い。情報が少なければ、対応のコストが大きくなるのは自明である。2：機能面ビジネスユースのデスクトップ環境で必要なものは、結局Ofiice製品であろう。それがきちんと動く環境として、Windows以上のものはない。Linux上でMS Office製品を動かすのはどう考えても変である。結論として、デスクトップ環境でのWindowsの優位はゆるぎないであろう。キーボード、マウス、ディスプレイを使ってOffice製品を使う環境では、Windows以外のものを使うメリットは考えにくい。今後、世の中が大きく変わって、ウェアラブルPCとかで、ディスプレイがメガネになったり、とかのものすごい環境変化が起これば、Windowsの天下も終わるかも知れない。しかし、逆に言えばそんなことでもない限り、Windowsの天下はまだまだ続くであろう。
2004/11/15
コメント(0)
-
オフショア開発のメリット
なんとなく発注して、なんとなく検収して、なんとなく利用して、トラブルが起これば、なんとなく修正してもらう。今世の中で行われているシステム開発の大部分がこのような「なんとなく」ベースで行われているはずである。発信者と受け手の間に、共通の認識があり、特に突っ込んだコミュニケーションをとる必要がなければ、もちろんこれでも構わない。関係者にとって当たり前の情報を、わざわざ文書化等する必要はない。しかしながらこういった「あいまいさ」が後々のトラブルを引き起こすことは非常に多い。近頃IT業界では、家電や衣料の成功を見習って、開発を海外で行うケースが増えてきているらしい。もちろん目的はコスト削減だが、そのためには発注時の「あいまいさ」を排除しなければならないというデメリット（！？）が発生する。なぜ、中国オフショア開発の見積もりは高いのか？という記事を読んで、オフショア開発のメリットは、コスト削減よりも、開発時のあいまいさの排除、があるのではないか、という気がしている。言葉や文化の通じない人たちに開発を依頼するのであれば、当然依頼内容は厳密にならざる得ない。ある意味、コンピュータに作業を依頼する（＝プログラミング）ことと同じ作業が必要になってくる。内容の厳密化が強まれば、元請（SIer）が吸収できる部分にも限度ができ、結局本当の発注者であるユーザ企業にも、厳密化の波が及ぶに違いない。そうなれば、ユーザ企業のシステム設計のスキルが上らざる得ないのではないか。オフショア開発を起爆剤として、ユーザ企業が、あいまいさを排除したレベルの高い設計をできるようになればすばらしいことだと思う。
2004/11/12
コメント(0)
-
プロ野球チームの親会社
プロ野球チームの親会社をすこし変わった視点から分析してみた。巨人→新聞（固定収入）中日→新聞（固定収入）ヤクルト→食品横浜→テレビ阪神→電鉄広島→???西武→電鉄オリックス→金融（固定収入）ロッテ→食品日本ハム→食品近鉄→電鉄ダイエー→小売楽天→モール（固定収入）ソフトバンク→通信（固定収入）こうして見ると、利用者が契約として定期的にお金を払ってくれる会社、すなわち固定収入がある企業は財務的に安定するため強い。弱いのは、電鉄、小売。近鉄は消滅したし、ダイエーも風前のともし火、西武も売却されそうである。食品は、固定収入があるわけではないので安定性はそれほど高くない。ヤクルト、ロッテ、日ハムもそのうち売却されるかもしれない。（テレビ会社の収益構造が安定しているのかは良く分からない。広島はそもそも親会社はどこ？）こう考えてみると、安定した企業を作るためには、固定収入が入る仕組みを考えるのが一番なのであろう。ITベンチャーが金融事業に手を出すのも、ソフトバンクが携帯に参入するのもそうであり。マイクロソフトがWebサービスに力を入れるのもその発想の延長であろう。ちょっと強引！？
2004/11/10
コメント(0)
-
電子投票システム
大統領選は、どうやらブッシュ氏の再選で決着がつきそうであるが、今回もいろいろと物議をかもしたのが、電子投票システム。素人が考えるととても単純なことでも、プロがきちんと考えると実は非常にむずかしいことはよくある。この電子投票システムはその典型のような気がする。システム的にどこが難しいのかさっぱり分からなかった。単純に考えれば、数人の候補者の中の1人を選んで、ボタンを押す（画面にタッチする）だけである。その情報は一瞬にしてセンターのDBに蓄積され、開票時間の1秒後には結果が判明する、だけであると素人は考えてしまう。ところが、いろいろ調べてみると問題は大きく2つあるらしい。1：電子投票システムの範囲は、「投票」だけでなく「有権者確認」も含む2：投票データのセキュリティには万全の体制を要する確かに1：の有権者確認の仕組みは難しそうだ。2：投票データの管理（正確なこと、途中で改ざんされないこと、投票者が特定されないこと）が大変なことはなんとなく理解でる。スターリンは「選挙結果は、選挙人が決めるのではなく、選挙集計者がきめるのだ！」と言い切ったらしいが、今の日本でそんなことが許されるわけではなく、票の集計には細心の注意が必要になり、それに伴ってシステムも複雑なものになるのであろう。日本の選挙は、秘密投票と言いながらも、地区ごとの選挙結果が簡単に分かったりして、厳密には秘密投票でない。電子投票システムを導入すれば解決できるような気がしていたが、なかなか一筋縄ではいかないことが判明した。むずかしいものです。
2004/11/04
コメント(0)
-
マネーボール
久しぶりに読んだ本でなかなか感心したのが、この本↓マネー・ボール 奇跡のチームを作った男マイケル・ルイス著ランダムハウス講談社1600円貧乏球団であるアスレチックスの若きGMが、いかに乏しい資金力で強いチームを作っているか、と言う話である。その答えは単純で、安くて良く働く選手をかき集めているから、ということである。お金がたくさんあれば強い組織を作れるか、と言えばそんなことはないのだが、野球の世界ではなぜか、資金力＝チームの力、と思われている。投資家にしても同じ話で、手持ち資金が潤沢であっても、目のつけどころ悪ければ利益はあげられない。逆に、資金が少なくても、上手に運用すれば相当の利益をあげることが可能である。この「マネー・ボール」の選手選考のキモは、選手の実績をすべて数値化していることである。勝つためにはどんな能力の高い選手を集めればよいのか、その基準に沿った数値が高い選手はどこにいるのか、その選手は高いのか安いのか。安ければ採用する。いたって簡単なメカニズムである。この本を読んで感じたのは、今まで職人的な「カン」によって選択していたことを、数字の裏付けを元に科学的に選択すると、驚くほど効率がよくなるケースがある、ということである。情報システムの構築においても、右が左か迷うとき多々あるが、結局たいしたデータにも基づかず、なんとなく、ベンダーの言うがままに決定されることが多い。野球と情報システム構築の大きな違いは、そのデータの公開度であろう。情報システムの構築においては、構築費用、工数、採用パッケージ等が公開されることはあまりない。特に失敗したプロジェクトの情報はまず公開されないし、成功したプロジェクトでも、公開されるのは人間ドラマ的内容が多く、分析に役立つ情報は乏しい。国が情報システム構築時のいろいろなデータを収集し分析する公的機関を作ったら面白いと思う。協力した企業には、税務面での優遇措置を与えてもよい。集めたデータを分析すれば非常に役に立つ情報が得られるだろう。「1億円以上のコストをかけたパッケージの導入プロジェクトは、その半数が失敗している」などという結論がでれば、安易な導入は激減するであろう。成功例ばかりを並べ立て、さも導入簡単であるかのように見せるかけるベンダーにだまされることはなくなるはずである。
2004/11/01
コメント(0)
-
Windows XP SP2のインストール
通常、大型コンピュータの世界では、インストールされている全てのプログラムのタイムスタンプ、バージョン、サイズ等を記録します。プログラムを入れ替が必要な時には、影響範囲を細かく調査し、動作確認をした後に行う、というのが普通です。自動的にプログラムが置き換わっているなどということは考えられません。したがって、大勢に影響のないトラブルであれば、プログラム入れ替えを見送る、という決断も良くなされていました。また、OSのバージョンアップなどという作業はそれこそ一大イベントで、メーカの技術者が張り付き、綿密な計画を立てて行ったものでした。さて、今巷で話題のWindows XP SP2ですが、私もインストールを行いました。このWindows Updateという機能、確かに便利だとは思っていますが、若干ひっかかりを感じるのは、自分が元大型コンピュータの技術者だったからでしょうか。Windows XP SP2の問題は、セキュリティ関連の機能を強化したおかげで、ウィルスのような振る舞いをする正常な（？）ソフト、までが動かなくなってしまう、という点にあるようです。一応各ベンダーから情報は公開されているのですが、不十分なものも多く、ある程度リスク承知しながらインストールを行わざる得ませんでした。企業の管理者であれば問題が発生すれば業務影響は甚大です。綿密なテストを行った後、SP2を導入することになるでしょう。Windows Updateという、管理者いらずの便利な機能をいったん封印することになります。悩ましい話です。PCの管理とはなかなか厄介なものだ、と再認識させれました。
2004/10/28
コメント(0)
-
ユビキタス・コンピューティング
IT業界では定期的に流行語を生み出して、マーケティングに活用する。大抵の場合その言葉に意味はなく、内容を理解する必要すらないことが多い。最近、よく耳にするのが「ユビキタス」という言葉。検索したところ、一つの記事が引っかかった。「ユビキタスで世界は変わる？」この記事によると、>>家電や普通の電話、時計やポータブルMDプレーヤなどが>>ネットワークで結ばれ、駅の自動券売機やコーラの自販機>>までもがネットワークにつながれ、車や電車の中からでも>>インターネットにアクセスできるような社会が>>「ユビキタス社会」だという。だということである。家電がネットワークでつながっても個人的には利便を感じない。ネットワークにつながってない電話とは何？、時計がつながると遠隔地から目覚ましの時間を設定できる？、コーラの自動販売機がつながると在庫が少なくなったら自動的に発注が上がる？コンピュータやネットワークが発達しても所詮便利になるのは、情報という抽象的なものだけである。どれだけインターネットで便利に買い物ができても、実際に物を届けるのは人間である。コンピュータができることには限度があり、その範囲は大して大きくはない。また、使いやすさと堅牢性はトレードオフの関係である。どこでもコンピューティングができて便利な社会は、セキュリティ的には問題が多い社会であろう。ユビキタス・コンピューティングこの言葉もあと数ヶ月もすれば消えるであろう。内容がない言葉である。
2004/10/26
コメント(0)
-
情報システム構築の2つのハードル
ある業務を情報システム化する場合、その業務が人間でできるものであれば、積極的に人間で行った方が良いと考えている。それは、情報システム構築の困難さは、コンピュータ上の作業だけにとどまらないからである。情報システム構築のハードルは2つあると考える。1：情報システム自体の構築2：出来上がった情報システムを利用した新業務の構築1：のシステム構築だけでも大変な作業である。プロジェクトが紛糾して「動かないコンピュータ」と言われてしまうケースが多々ある。技術者は、プロジェクト管理やコンピュータ技術を修練して、なんとかシステムをを無事構築できるように大変な努力をする。ところが本当に重要なのは、2：の新業務構築作業である。情報システムだけ立派なものが出来上がっても、それが業務で利用され、投資費用に見合う新たな効果を生み出さなければ、意味が無い。通常、システムの構築には、半年～1年あるは数年という期間が必要になる。その構築期間の間に、ビジネス状況が一変することは十分に考えられるであろう。したがって、当初の設計どおりにシステムを構築したとしても、完成時点ですでに役に立たないものになっている可能性すらある。システム構築が成功したからといって、新業務構築が成功するとは限らない。雑誌の記事では、「このシステムを使って業務を改革していくのが課題です」という担当者のコメントで終わることが多い。システムは一応成功しているが、新業務はこれからというケースでも、成功と大々的に宣伝されてしまう。情報システム構築の2つのハードルを無事にクリアすることは非常に難しい。難しいのであれば、システム構築のハードルを避ける、すなわち人間でできるものは積極的に人間で行う、ことが重要になるのであろう。無用な戦いはしない。得るものは何もない。
2004/10/25
コメント(0)
-
二者択一の心構え
企業情報システムの構築に参画していると、二者（もしくは数者）択一の場面に遭遇することは多い。それが上流フェーズであればその選択が後々まで影響を及ぼすことになるので、安易な判断は許されない。そんな場合に出会った時に、心がけていることを書いてみたい。以下のポイントがある。・評価軸を決める・評価軸に沿って客観的な事実を集める・自分ひとりで判断しない。関係者全員に判断してもらう例えば、OSをWindowsにするかLinuxにするかを迷ったとする。個人的にはLinuxにしたいとかいう願望を持っていたとしても、それはいったん心の奥底にしまう。評価軸としては、・価格・事例・構築ノウハウ・将来性・業務への適用度などが考えられる。それぞれの評価軸に対して、客観的な事実を収集し、Windows、Linuxに対して、マルバツをつけていく。こうして出来上がった評価シートによって、総合ポイントでWindowsが良いのか、Linuxが良いのかが判断できる。どうしてもLinuxがよければLinuxが有利になる判断軸を追加していけばよい。最後に出来上がった評価資料を関係者で確認し、全員で決定する。このような方法をとることによって以下のメリットがある。・個人的な思い入れによるミスチョイスを防ぐ・責任を分散することができる二つ目のメリットが重要である。例えばLinuxを選択したとしても、リスクはいろいろと存在する。関係者に評価内容を知らせることによって、そのリスクを認識してもらうことをが可能になる。何か問題が起こったときに、そんなことは聞いていない、自分でなんとかしろ、と言われることを避けることができる。実はこんなことを考えた理由は、「町長を説得してLinuxを導入」という記事を読んだからである。この記事のように個人の思い入れ（のように見える）でLinuxを決定した場合、何か問題が起これば、個人が批判の矢面に立たされる可能性が高い。また、実際の選考に関して、冷静かつ客観的な評価を行ったのかも疑問が残る。何かを選択するときは、人のせいにできる材料を探しておくこと、これはとても重要だと思っている。一見後ろ向きの考えのようだが、客観的な評価を行う、リスクを関係者に知らせる、という大きな効果があるからである。
2004/10/21
コメント(0)
-
役人はベンダーの味方！？
中堅・中小企業のIT導入成功戦略2004というセミナーが11月の上旬に東京・大阪で催されるそうである。こういうセミナーを見かけるたびに、役人はベンダー企業とユーザ企業のどっちの味方だ！？と疑問を感じてしまう。おそらく役人の頭の中では、中小企業はIT活用推進の方法として、ユーザ企業を直接指導するやり方と、ベンダー経由でユーザ企業に教育していくやり方とがあが、中小ユーザ企業に直接指導するのは大変なので、ベンダーを推進することで間接的にユーザ企業を指導しよう、と考えているに違いない。しかし、それはベンダーの販売活動に協力しているだけである。このようなセミナーを催せば催すほど、IT活用＝ツールの導入、という短絡的な図式が出来上がってしまい、中小企業は苦しい中からひねり出したシステム構築費用をどぶに捨てることになる。役人がやるべきことはひとつ。ベンダーからの影響をまったく受けない中立な機関を作って、ベンダーの製品およびシステム構築方法を評価し、経営改革のためには何が必要かを、IT化、非IT化を含めて検討、支援していくことである。実は、ITコーディネータという団体にその役割を期待していたが、結局ここもベンダーと手を握ってしまった。ベンダーと手を握っている団体はベンダーの利益のために動くので、ユーザ企業にとって真に役に立つものではない。こういうセミナーでだまされるかわいそうな企業がいないことを祈るばかりである。
2004/10/19
コメント(0)
-
システム化しないことの評価
業務をシステム化するとその瞬間は正確性、迅速性が高まり、メリットが多いような気になる。しかし、開発費用、その後のメンテナンス費用、新規機能の追加の費用（場合によっては追加できない）を考えると、最終的にメリットが本当にあったのか、判断に苦しむ場合も多い。にもかかわらず、世の中では「ITを活用した業務改革」に補助金がつくなど、安易なシステム化を助長する動きばかりで、大変苦々しく思っている。そもそも、システム開発では、構想フェーズで計画された数多くの機能を、開発フェーズで削除しまくるのが、典型的なパターンである。であれば、最初の段階でシステム化「しない」機能を積極的に判別していくのは重要なことではなかろうか。システム化しないことを評価する軸としては、機能の・永続性・非柔軟性・人間系でのコストが重要になる。1年程度で無くなる機能、機能追加が頻繁に発生する機能、人間系でも低コストで代替可能な機能、であればシステム化する必要性は低いかも知れない。システム化しないことを積極的に評価していくことが、今後のシステム開発では重要となるであろう。
2004/10/17
コメント(0)
-
米HP社がSAP導入でトラブル
1ヶ月ほど前に、米HP社がSAP導入でトラブルを起こし、自社の業務に多大な影響を与えた、との記事があった。また、この部門の責任者は更迭されてしまったらしい。この記事を読んで3点ほど思いついたので書いてみたい。1つ目は、コンピュータ会社だからといってパッケージの導入に必ず成功するわけではない。それこそ医者が風邪をひくのと同じことで、システムの導入時にトラブルはつきものである。2つ目は、自社のコンサルが構築にどの程度関与したか、ということである。通常コンピュータベンダーのコンサルは、顧客の企業に稼ぎに行く。自社のシステム構築を支援する人はあまりいない。今回のトラブルをもって、HPの外部に対するシステム構築能力を疑問視するのは早計であろう。3つ目は、業績不振の言い訳にトラブルが利用された可能性はないか？という点である。システムがトラブルを起こしたので、業績が悪化しましたと言えば、一般の人は、そんなものか、と思うかもしれないが、専門家が見れば眉唾である。以上、気が付いたことを書いてみました。米HPも今回のトラブルの詳細を公にして、こんなトラブルにならないように注意しましょう！という活動ができれば、かなりのものなのだが．．．フィオリーナさん、どうですか？
2004/10/15
コメント(0)
-
情報システムが改革の足を引っ張る
最近、情報システムが改革の足を引っ張る大きな例が話題を集めている。一つは平成の大合併に伴う市町村のシステム統合、もう一つは郵政公社の民営化に伴うシステム変更・分割である。両者とも、政治的にきな臭い話なのでまゆにつばをつけて吟味しないとだまされる危険性が大いにあるのだが、大筋システム統合が組織統合・分割の足かせになっていることは間違いないであろう。人間は柔軟であるがミスが多く、作業が遅い。コンピュータはミスはなく作業は早い、しかし柔軟性はまったく無い。したがって、こういった変革の場面に出くわすとコンピュータの頑固さがマイナスとなって、改革のスピードを鈍らせることになるのは当然である。こういった局面の打開策としては月並みな方策ではあるが、ある程度スピードは重視するがあまり急いではいけない、という解になるであろう。要は、個々の機能やサービスレベルに応じた工期・工数をきちんと算出し、いつまでであればどこまでできるかをはっきりさせる。その上で、絶対に必要なものがそろわなければ、リリース時期を延ばさなければならないし、リリース時期を絶対視するなら、機能・サービスレベルを落とさなければならない。しかし、この話の仕切りはとても大変だろう。民間企業であれば経営者を相手に説得すればよいが、公的機関の場合は政治家を相手にしないといけない。これは大変そうだ．．．
2004/10/13
コメント(1)
-
デジタル家電って？？？
今幕張メッセで開催されているCEATEC JAPANなる催しに、デジタル家電の実験ブースがあり、そこでは、ベットから起き上がると、荷重が低くなったのを自動的に検知して、カーテンが上がり、電気が点灯され、お目覚めの音楽がかかる、という部屋が展示されているらしい。よく分からないのだが、もしなんかの用事で夜中にベットから起き上がったら、同じようにカーテンが上がり、電気がつき、音楽がかかるのであろうか？だとしたら、めちゃくちゃ迷惑な仕組みである。そもそも起きたら、手でカーテンを開けて、スイッチをいくつかつければ済むだけの話である。それだけのために、追加の投資をする人がこの世にいるのだろうか？さらにデジタル家電では、家の外からいろいろなスイッチを入れることができるらしいが、そうすると何が便利になるのだろうか？家に帰った瞬間にお風呂入りたいというニーズを持つ人で、しかも家族がいない人はどれだけいるのか？デジタル家電は絶対に売れない。開発をしている人は、炊事や洗濯や掃除をやったことがあるのだろうか？こんなニーズはどこにもない。タダでもいらない。
2004/10/08
コメント(2)
-
長崎県庁の開発モデル
日記のネタもだいぶ尽きてきたので、インターネットを徘徊してたら、おもしろい記事に遭遇した。自治体の丸投げ意識を変えた、という長崎県庁の開発モデル。しっかりとしたシステムを構築するためには、発注側の努力が重要。基本設計までは発注側が書くべし！、というのが私の考えだったのだが、長崎県庁では、なんと詳細設計まで職員が記述しているらしい。詳細設計がかけるということは、ハードウェア、OS、ミドルウェア、開発言語など、システムのローレベルを理解しているということである。記事によると構築費用が半減したとのことであるが、それもそのはずで、詳細設計レベルで仕様がきちっと決まっているシステムの開発なんて誰でもできる。安くなって当然である。さらに、このモデルは、地元の中小開発業者にとっては、今までより好条件になっていると考えられる。元受企業のピンはねが消滅しているのであるから、単価は高くなっているはずである。やや心配なのが、プロマネ、テスト、運用などであろうか。丸投げ方式であれば、心配する必要はないが、詳細設計レベルにまで踏み込んでいるということは、開発にまつわる周辺作業も県庁側でこなさないといけなくなる。その辺が失敗すると、それ見たことかと抵抗勢力に攻撃される。このモデル、県庁というおそらく優秀な人が多い環境での事例なので、なかなか一般には広がらないかも知れないが、少なくとも自治体レベルでは広まってほしいと思う。発注側のスキルアップによるシステム構築の健全化、私の目指す世界そのものである。
2004/10/07
コメント(2)
-
お客が増えたので値上げします！？
R-10さんの日記を見てびっくりしたのだが、世の中にはお客さんが増えたので値上げをする人がいるらしい。詳細は記事を読んでいただければ分かるが、この日本情報処理開発協会（JIPDEC）という団体は、今話題の個人情報保護に関するお墨付き（プライバシーマーク）を付与する機関で、マークの申請が増大したために値上げに踏み切ったとの内容である。通常お客が増えれば、スケールメリットにより価格は下がるはずなのに、非常に不思議である。お客さんが増えて値上げをする場合、一般には値上げによる申請抑止効果が考えられるが、制度の趣旨からいってそれは考えにくい。とすれば、原因はなんであろうか？以下に想像してみた。1：そもそも余剰人員で対応していた。この団体は、将棋をしたりスポーツ新聞を読んだりする人ばかりで、仕事があまりなかった。そこにプライバシーマークの認定作業が飛び込んできた。そもそも余剰の人員が対応するのだから、費用はそれほどもらわなくても良い。と思っていたら、申請が山のようにきて、とても余剰人員だけでは対応できなくなった。仕方なく、費用も適正費用に変更し、人員の増強も図ることにした。2：作業量の見積もりを間違えていたひとつの申請に対する作業量を1人月程度と考えていたが、実際やってみると2倍以上かかることが判明した。見積もりミスを公にしたくなかったので、料金はそのままにしておいた。しかし申請の増大によりそれも限界に達したので、値上げに踏み切ることにした。3：お客が増えると作業量が増える業務プロセス人員の配置も作業量の見積もりも問題なければ、申請者が増えると作業量が増えるという業務プロセスになっていることしか考えられない。人と人とのコミュニケーションが増大して、処理量が2倍に増えると作業量が4倍になるようなことが発生してるのであろうか？真相はまったく分からない。根拠はないが上の1：～3：のあわせ技だと思われる。値上げによって、人員を拡張して処理時間の短縮を図るそうであるが、「遅れているプロジェクトに人を投入するとさらに遅れる」というありがちなパターンに陥らないように注意してほしい。きちんと原因が分析された上で値上げしたのか、とっても不安．．．
2004/10/06
コメント(2)
-
ICタグ－アメリカの底力
アメリカという国は良くも悪くも無茶をする国だな、とびっくりさせられられることが多いが、IT関連のテクノロジに関しても同様に驚かされる。最近感心したのは、ICタグ。アメリカでは国防省とウォールマートが納入業者にICタグの導入を義務付け始めている。ICタグというと、アンテナを振り回せば棚卸が一瞬にしてできてしまうような幻想があるが、現時点の技術はまだまだ発展途上で、タグのつける場所によっては読み取り率が1割、とかいう悲惨なことも起こっているらしい。しかし、感心するのは、そんな状況にも関わらず、国家的な戦略として、世界最大のバイヤーである国防省とウォールマートに導入の旗振り役をやらせてしまうことである。この2者を中心に導入が広まれば、当然のことながら仕様も2者すなわちアメリカを中心に決まっていくであろう。先行者利益とはまさしくこのことである。ことITに関しては、21世紀もアメリカの天下は続きそうである。
2004/10/05
コメント(3)
-
文章を書く訓練
文章力は重要である。自分が何かを成し遂げたいと思ったときにはまわりのメンバーにそれを納得してもらう必要がある。納得させる方法には3種類ある。・言葉による説得・文章による説得・言葉・文章・図による説得（＝プレゼン）今回はそのうち、文章によるものをあげてみたい。情報処理試験のいくつかには論文記述問題が存在する。試験対策ということだけではないが、文章だけで相手を説得しなければならない機会もまま存在する。文章力をつけると一概に言っても、そこには3つの技術があると考えている。・思考技術・構成技術・てにおは技術私はそれぞれの部分の訓練に、以下の書物を参照にしてきた。・思考技術「考える技術・書く技術」バーバラミント著 ダイヤモンド社・構成技術「論理的に書く方法」小野寺博一著 日本実業出版社・てにおは技術「ことばの訓練教室－書く技術」一ノ坪俊一著 日本経済新聞社「考える技術・書く技術」は、この本を読んでいないコンサルは、モグリと言われるほどの超有名本。「論理的に書く方法」は「考える技術・書く技術」と内容的に重なるところもあるが、日本人が書いた本だけあって読みやすい。「ことばの訓練教室－書く技術」は前2書とはやや違って、主語と述語の対応や接続詞、修飾語の使い方など、作文上の細かいテクニックが書かれている。文章を書くという力は、ITコンサルや上級のIT技術者には必須のスキルであろう。情報処理試験や各種の試験で論文作成の問題が出題されるのももっともなことだと思う。
2004/10/03
コメント(0)
-
コンサル業と教育業の結合
前回まで書いてきた、情報システム部長育成派遣業は、コンサル業と教育業が合体したようなビジネスになる。この形態に大きく3つのメリットがある。1：仕事がたくさんできる自分で教育した信頼できる人間を送り込むことができるので、安心して後を託して別の仕事に向かうことができる。地道で耐久力の必要な仕事は、人に任せて、自分はおいしいところだけをつまみ食いできる。2：教育内容がニーズにマッチするコンサル業の中で、現場で発生しているいろいろな問題やそれに対応するニーズを吸収しているのであるから、それに即した教育内容を用意することができる。大学で勉強したことは、世の中の役には立たない．．．とかいうことは絶対に発生しない。役に立たないことは教育しない。3：企業のニーズにマッチした人を送り込める企業のニーズが分からない場合、採用は企業側に依頼することになるが、企業側ではどのような人間を採用すべきなのか分からない場合が多い。コンサルとして企業に入り込んでいれば企業のニーズを把握することは容易である。まとめれば、・自分の分身をたくさん作ることができる・世の中のニーズにマッチした教育ができる・企業のニーズにマッチした人間を推薦できるということになる。とても魅力的だと思う。（自画自賛）
2004/10/01
コメント(0)
-
情報システム部長育成派遣業－まとめ
情報システム部長育成派遣業を簡単に言えば、私と一緒にコンサルをやってくれる人や、企業に管理職として推薦できる人、こういった人さがすのはめんどくさいので育ててしまえ！ということになる。さらには、PG→SE→PM→部長、なんておきまりのルートをたどっていたら、時間がかかってしょうがない、そんなに時間をかけずに短期間で必要なノウハウを身に付けさせたい、という狙いもある。そう考えてみると、このビジネスは、育ってくれた人間がのちのち恩返ししてくれれば良いわけで、短期的な利益は求めていないことになる。今後の具体的な動きとしては、まず、必要とされた資格の精査、それから実戦シミュレーションの構築、その後、パンフかなんか作り、近所の専門学校や大学をまわって生きの良い若者を4～5人選んで、課外学習会みたいな感じで勉強する。その後本人の希望で、情報システム部長またはコンサルまたは普通の人生、を選んでもらう。教育マテリアルさえしっかりできあがれば後は何とでもなりそうな気がしてきた。（本当か？）
2004/09/30
コメント(0)
-
情報システム部長育成派遣業－ドライブ力
情報システム部長育成教育プログラムの中で、実際の開発を想定した実戦シミュレーションは非常に重要な意味をもつ。実戦シュミレーションの目的は、コンピュータに関わる個々の要素技術を有機的に結合させていくことあるが、もうひとつの目的として、集団を目標に向かって引っ張っていくスキルの取得があげられる。この力を、ドライブ力と呼ぶことにする。ドライブ力には大きく2つの要素がある。1：なぜその行動が必要かを説明し納得させること2：メンバーのおしりをたたいて仕事をさせることシステム構築時には、いろいろな局面で判断に迷う時が発生する。その時に集団をコンセンサスをもって1つの方向に導くためには、なぜその方法が良いのかを論理的にきちんと説明しなくてはならない。それが1：の説明能力である。納得してもらうことが目的であるから、納得してもらえるように説明しなければならない。評論とは違う。また、作業を個人に割り振った後、その作業がきちんと行われているかをチェックする。きちんと行われていなければ、メンバーのおしりをたたく必要がある。単純にサボっているのなら対応は簡単であるが、余計な仕事をして本来の作業が滞っていることがままある。こういった場合、なぜ別の作業をやっているのかを調査し、本来の作業に戻させるような対策が必要となる。システム部長は所詮個人では何もできない。まわりのメンバーを動かしてシステム構築にまい進させなければならない。そのために、・メンバーが納得して作業をするようにすること・メンバーの作業の進捗状況を管理することすなわち、ドライブ力がきわめて重要になる。コンピュータの要素技術の学習は、この集団のドライブを円滑に進めるために存在すると言っても過言ではない。情報システム部長育成教育プログラムのの良し悪しは、このドライブ力をどれぐらいつけさせることが可能かにかかっている。
2004/09/29
コメント(0)
-
情報システム部長育成派遣業－個別技術の有機的結合
情報システム部長は、・コンピュータの要素技術・経営技術・システム開発技術の知識を個々に習得すことが必要だが、その個々の知識を有機的に結合して実戦の中で役立てることがさらに重要である。本来この部分は現場で培っていくものであるが、短期間で習得するにはシュミレーションを行うしかない。シュミレーションは大きく以下の流れで進んでいく。1：具体的な課題の識別2：コンピュータでの支援可否の検討3：要件定義4：システム設計5：システム開発6：システムテスト7：導入8：運用9：評価まず、1：具体的な課題の識別である。売上が落ちている、利益率が減少している、という課題は「具体的」ではない。何が原因で売上、利益が落ちているのか、または、何が原因かを探るためにはどんな情報が必要で、なぜその情報が手元にないのか、を把握することが、具体的な課題の識別である。2：コンピュータ支援可否の検討は、1：の具体的な課題を解決する手段として本当にコンピュータ導入が効果的なのかの精査である。ここでは、どちらかと言うと、IT化を否定する方向で検討することになる。コンピュータの専門家はついついシステムを構築することに気持ちを奪われがちであるが、本当にそのシステムが意味があるかを、立ち止まって吟味することは非常に重要である。このフェーズで費用対効果の算出も行う。IT化の効果が高かったとしても、コストがそれ以上にかかれば、もちろん導入は見送られることになる。3：要件定義～6：システムテストのフェーズはシステム開発ではお決まりのフェーズである。ここでポイントとなるのは、いかに後続のフェーズにとって有用な情報を作成するか、保守性に優れた文書を作成するか、という2点であろう。7：導入フェーズでは、システムの導入だけではなく、新業務への導入支援（教育）が含まれる。コンピュータの専門家はシステムを作ってしまうと、それで満足しがちであるが、構築後のフェーズは重要である。簡単に言えば、いくら立派なシステムを作っても使ってもらえなければ意味が意味がないからである。8：運用フェーズは、トラブル対応が主たる部分を占める。いかに障害を予防するか、発生した障害にいかにすばやく対応するかがポイントとなる。9：評価は、全フェーズのなかで最も重要だと言っても良い。当初見積もられた費用の枠内に収まっているのか、期待された効果を生み出しているのかを精査する。個人的にはこのフェーズをきちんとやっている企業には出会ったことがない。しかし、失敗の含めたノウハウを次の開発に生かして行くためには、最も重要な行いであろう。といった流れのシュミレーションを行い、個別に学習した知識を有機的に結合させることになる。
2004/09/28
コメント(0)
-
情報システム部長育成派遣業－実戦トレーニング
情報システム部長に必要な教育は、1:コンピュータの技術→情報処理試験テクニカルエンジニア試験（DB、ネットワーク、システム管理）2:企業経営→中小企業診断士（1次）3:システム構築技術→情報処理試験プロジェクトマネージャ試験、アプリケーションエンジニア試験と記述した。ではこれらの資格を持てば、資質として十分かというとそうではない。もうひとつ重要なのが、4：その他→1～3を実戦で適用する。という訓練で、これがこの「情報システム部長育成派遣業」の最重要ポイントである。資格という無味乾燥なものに命を吹き込む作業が、この実戦トレーニングである。資格を取得する中で身に着けた知識は、ある意味「正論」である。しかし、現実のシステム構築時には、正論で物事が進むことはほとんどない。身に着けた正論をいかに応用して、最適な解を生み出し、まわりを納得させるか、がポイントになる。今挙げたように、1：最適な解を生み出すこと2：まわりを納得させることという2つの技術が、実戦トレーニングのキモになる。具体的には、企業システム構築のシュミレーションを行い、その中で、これらの技術について訓練することになる。この実戦トレーニング（システム構築シュミレーション）の出来の良し悪しが、このビジネス成功の第一関門だと考える。
2004/09/27
コメント(0)
-
ビジネスモデル－情報システム部長育成派遣業その3
さて、この「情報システム部長育成派遣業」であるが最大のポイントは、短期間で情報システム部長としての基礎的知識を叩き込むことにある。その教育カリキュラムをどうするか？情報システム部長に必要な知識は大きく3つあげられる。1:コンピュータの技術→コンピュータの仕組み、データベース、ネットワークなど2:企業経営→会計、人事、経済などの基礎3:システム構築技術→プロジェクトマネージメント、システム開発技術など4:その他→1～3を実戦で適用する。これらの勉強をするにあたって一から新しいものを開発する気は毛頭ない。既存の資格を利用する。1:コンピュータの技術→情報処理試験テクニカルエンジニア試験（DB、ネットワーク、システム管理）2:企業経営→中小企業診断士（1次）3:システム構築技術→情報処理試験プロジェクトマネージャ試験、アプリケーションエンジニア試験情報処理試験が5科目、中小企業診断士（1次）は8科目、計13科目を勉強する。1年間でこれだけの資格を取得することを目指すのがまず最初のステップとなる。
2004/09/25
コメント(0)
-
ビジネスモデル－情報システム部長育成派遣業その2
前回「情報システム部長育成派遣業」について記述したところ、何名かの方から前向きなご意見をいただいたので、気分を良くして続けてみたい。企業の情報システム部門の管理者を短期間に育成し派遣するというビジネスであるが、大きく、・教育機能・コンサルティング機能が存在する。教育機能は非常に短期間の間に、企業の情報システム部門を管理するために必要なノウハウを若い人間に叩き込む仕組みである。コンサルティング部門は、コンサルティング活動をするだけなのだが、相手の企業から情報システム部長の候補者の斡旋依頼があった場合は、自社の人間（または自分）を推薦する。採用する企業にには大きく3つのメリットがある。1：コンサルティング活動を通じて信頼関係のある人物からの推薦であるから、ちまたのヘッドハンティング企業に依頼するよりもはるかに安心感がある。もし、優秀でない人間が推薦されたと感じたら、推薦したコンサルタントに文句を言うことも可能である。2：安い。大学や専門学校卒業程度の20歳前後の人間を教育し派遣することを想定している。通常IT管理者として推薦されるのは、実務経験10年以上の人間であり、35歳以上であろう。こういった人材に比べてはるかに安い賃金で雇用することが可能になる。3：若い人を派遣するメリットとして、相手先企業の文化に染まることが可能、ということがあげられる。こちら側でIT管理者としての基本を吸収した後に、相手先企業で企業文化や業務内容や吸収すればよい。35歳以上の人間を送り込んだ場合、相手先企業のカルチャーに染まることはなかなか難しいと思われる。さらに、この会社の社員（教育される側）にもメリットは多い。1：短期間のうちに質の高い教育を受けられる。また受けた教育を実践で試す場（コンサルティング経験）が存在する。2：通常10年ぐらい下積み生活を送らないと採用されないIT管理者のポストに若い段階でつくことができる。3：もし、相手先企業を卒業（退職）した場合は、また自社に戻ればよい。コンサルティング活動をしながら自分の再就職先を探すことも可能である。どんなもんでしょう？
2004/09/24
コメント(0)
-
ビジネスモデル－情報システム部長育成派遣業
これから何回かに分けて自分がぼやっと考えているビジネスモデルについて書いてみたい。私は、IT技術者が独立すること自体は比較的簡単だと思っている。お客さんを開拓するという点が一番困難だが、いざとなったらバイトのような身分でどこかの仕事をもらうことも可能であろう。それなりにマーケットバリューがあれば何らかの方法で食いつないでいくことはできる。問題はビジネスの構築である。ビジネスとは、自分自身が死んでしまってもお金を生み出していくことのできるシステム、お金を生み出す永久機関、と定義する。これを構築するのは相当大変なことだと思う。何と言っても、まず人を雇わないといけない。自分がいなくても動き続けるためには、自分以外の人は必須である。さて、「ユーザ企業のために真に役に立つ」なにか、を提供するビジネスを考えた場合、一番役に立つのは当然「人」の提供であろう。ユーザ企業に足りないのが、経営とコンピュータの間を取り持つ情報システム部長である。これを短期間で養成し、そういった役職の人間が存在しないユーザ企業に提供すれば、非常に喜ばれるはずである。どんなに優秀なコンサルタントがつくよりも、その会社のことを24時間常に考え続けている正社員の方が断然戦力になる。正社員として情報システム部長の素養のある人間を送り込むことはメリットが大きいはずである。社内で情報システム部長を育てるという考えもあるが、指導役として情報システム部長のさらに上をいく、コンピュータと経営のノウハウを持つ人間が必要となるが、それはなかなか難しい。付加価値型人材派遣業、しかも買い取り式、みたいな感じである。
2004/09/22
コメント(3)
-
顧客が求めているのはITコンサルタント
ユーザ企業がベンダーにシステム構築を依頼する場合、ユーザ企業はベンダーの担当者に対して、コンサルタントの役割を期待している。ユーザ企業の担当者は、提示した案を厳しく精査して、問題がないかどうかを判断し、もっと良いアイデアがあれば提示してほしい、切に思っている。発注側の担当者がこんなことでは心もとないのであるが、現実は残念ながらこうである。つべこべ言わずにこうやれ！とベンダーの担当者に細かく指示をする、そんな場面に出会ったことはない。しかし恐ろしいことに、ベンダー企業がその案を厳しく精査することはほとんどない。ユーザ企業の提示したあいまいな構築案をベンダーがうやうやしくいただいてそのまま実装する。そして使い物にならないシステムが出来上がる。ユーザ企業は、なんで構築前に指摘してくれなかったのだ、と文句を言うし、ベンダーは言われたとおりに作っただけ、と反論する。本質的にはユーザ企業が良くないのだが、現在の状況を考えると、ここはベンダー側がリスクをとってユーザ企業の案をきちんと精査し修正することが必要であろう。そのためには、ユーザ企業の業務を理解していることが必須である。そのシステムがどのような業務から生まれてきているものなのかを把握せずに助言はできない。ユーザ企業が必要なのは、言われたことをやる人＝プログラマー、ではなくて、言われたことをやらない人＝コンサル、である。ユーザ企業の不満の多くはこの認識の違いが出発点になることが多いのである。
2004/09/21
コメント(2)
-
IT技術者からITコンサルタントへ
IT技術者＝与えられた課題をコンピュータ上のに実装する人ITコンサルタント＝与えられた課題から真の問題を抽出し、それを解決する人と定義した場合に、IT技術者がITコンサルになる第一歩は比較的簡単である。それは、顧客に何かをやってくれと頼まれたら、なぜそれをする必要があるのか問うことである。そして逆に、別のやり方をすればよい結果が得られる方法を提案できればさらに良い。そこまではいかなくても、そのような仕様が発生した理由を顧客と議論できれば、もう立派なコンサルである。IT技術者がおちいり易いワナであるが、顧客がある仕様を伝えてきたとする。素人目にみてもおかしな仕様であるが、顧客の言うことだから間違いない、と思って実装すると実は大間違いだったりする。残念なことだが、顧客の言うことは間違いだらけである。顧客は自分たちの間違いを指摘されると非常に喜ぶ。それは当然で、ミスが早い段階で防げれば余分なコストがかからないわけであるから、そういった指摘はWELCOMEである。ところがIT技術者がそういった仕様レベルで問題点を指摘することはほとんどない。逆に顧客が、それはWindowsでもできるんじゃないの？とか指摘すると、いえ、UNIXじゃないとダメです、とか言う。どうでもよいことだけはきっちり反論する。顧客の仕様を、業務レベルで分析し、問題点を指摘すること、なぜそのシステムが必要なのか、なぜその帳票が必要なのか、なぜその項目が必要なのか、を議論すること。IT技術者がITコンサルになる重要な第一歩である。
2004/09/19
コメント(0)
-
普遍性の高い技術を学ぶ
前回の資格の話とからめて、取得すべきIT技術について書いてみたい。個人的に、技術は普遍性の高いものとそうでもないものがあると感じている。前者の例としては、・コンピュータのハードウェアアーキテクチャ・データベース・ネットワーク・セキュリティ後者の例としては、・プログラム言語・設計技法・プロジェクトマネージメントなどがあげれる。データベースは1969年に開発されてから、基本思想はまったく変わっていないし、ネットワークもいまだにTCP/IPが全盛である。コンピュータの技術は進歩が早いと言われるが、それは一部の分野であって、何十年もほとんど変化のないこういった部分も多々存在する。どうせ勉強して資格を取るのであれば、こういった普遍性の高いものを対象にするのが良いのではないか。情報処理試験のテクニカルエンジニア関連がこれに相当すると思われる。逆に普遍性の低い分野は、仕事で必要になったときに、それこそ一夜漬けで学べば良い。今まで自分がやってきたことを整理する意味で、これらの分野を勉強するのは意味があるのかも知れないが、まったく新しい知識として勉強するのであればやや疑問である。普遍性の低い分野は、勉強したことが実戦で役に立たないことが多い。ITエンジニアの教育はこのあたりをきちんと認識していないと、非常に間抜けなことになる。明日からの仕事に必要な知識を学んでいるのか、これからIT業界で食っていくための基本的な知識として勉強しているのか、その色分けが重要であろう。
2004/09/18
コメント(0)
-
資格取得のすすめ
コンピュータの知識を得るためにはどのような勉強をしたら良いか、と聞かれることが多い。その時は決まって、資格取得を目指して勉強するべき、と答えている。資格なんて．．．と敬遠する向きもあるが、個人的にはそうは思わない。逆に資格取得を目指さずに、単純に本などを読んで勉強した場合、・自分がどれだけ理解できたのかを判断できない・達成感を得にくいというデメリットがあげられる。資格を取得すれば、合否がはっきりするし、受かればうれしいので、モチベーションがあがる。また転職時などに必ず役に立つ。以前私がメーカーからコンサルファームに転職したときも、「中小企業診断士の資格があるなら経営情報システムについては理解しているよね」と聞かれ、「はい」と答えて、面接が終わってしまった。資格を持っていることによって、ある一定の知識を持っていることが保障されているのであるから、採用するほうも細かく聞かなくて良いので楽である。さて、具体的な資格であるが、個人的には公的な機関の資格が良いと思っている。ベンダーの試験も有用なのかもしれないが、バージョンアップに対応しなければならないのがめんどくさい。資格と言うものはある程度の普遍性が要求されるべきものであって、1年や2年で使えなくなってしまうものは、資格にはそぐわないと思う。技術者向けには、情報処理試験テクニカルエンジニア関連、上流志向のある人には中小企業診断士がおすすめだと思っている。
2004/09/17
コメント(0)
全111件 (111件中 1-50件目)
