2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2004年09月の記事
全16件 (16件中 1-16件目)
1
-
情報システム部長育成派遣業－まとめ
情報システム部長育成派遣業を簡単に言えば、私と一緒にコンサルをやってくれる人や、企業に管理職として推薦できる人、こういった人さがすのはめんどくさいので育ててしまえ！ということになる。さらには、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)
-
ITの目指すもの
AD坂本さんの9/12の日記「ITの目指すもの」に触発されて同じことを考えてみました。坂本さん、タイトルまねしてごめんなさい．．．さて、一昔前のITというかコンピュータ化の目的といえば、・正確性・迅速性・低コストの3つの実現に集約されていたような気がする。人手で大量の数字を処理するのに比べれば、当然コンピュータは正確であるし、早いし、まあ人間よりは低コストだったであろう。もちろん現在でもこの3点は外れていないと思うが、これだけでは、インターネットの発達やその他いろいろな仕組みを説明することはできない。個人的には、上の3つに加えて、・距離の制限を越える・時間の制限を越える・容量の制限を越えることが、近年のコンピュータ化すなわちITの目的になっていると感じる。インターネットやDBを利用したシステムの発達により離れた場所で起こっていることが一瞬にして知覚できる。また、とても現物を保存できなくても、それが電子化されていれば、比較的容易に大量に保存することができる。しかも劣化しない。日ごろ自分が生活している中で、この時間・距離・容量の制限がなければどんなにすばらしいか、と思うことを見つけて、それをITを使って解決する。そんなことができれば、大成功できるのかも知れない。
2004/09/14
コメント(1)
-
ユーザ企業とベンダーの仲を取り持つ
ユーザ企業側にたって情報システムのコンサルティング行う場合、ベンダーの評価が必要になる場合がある。というか、ベンダーの評価そのものをミッションとして依頼されることすらある。そんな評価を行う場合に注意しなければならないことは多々あるのだが、以下の3つが重要だと考えている。1:悪いところばかりでなく良いところもあるベンダーとユーザ企業の間にコンサルが出てくる場合、普通はその仲がこじれている。最初の作業はベンダーのあら捜しなるのだが、これは実は簡単で、あらを探そうと思えばいくらでも出てくる。しかし今まで付き合ってきたのであるから、良いところも多々あるはずである。悪いところばかりに目がいきがちであるが、良いとことろも調査しないと片手落ちになり、その後の判断を間違わせることになる。2:コストの精査ベンダーとユー企業の仲が悪くなる一番の原因は、コストが不透明なことであろう。不当に高いと感ずる請求がおこなわれ、ベンダーに対する不信感を強めていく。しかしこれはベンダー側の言い分もあり、実はその前に格安で行った仕事のもとを取り返そうとしていたりする。ユーザ企業は、格安でやらせた仕事は忘れているが、高い請求には強く反応する。ベンダーの立場に立ってみるとやや不満がある。こういった不明瞭さをなくすためにはすべての作業をきちんと把握してコストとして換算する必要がある。3:ベンダーがいなくなったら困ること最終的にベンダーとユーザ企業が仲たがいする場合、そのベンダーから他のベンダーにリプレースが行われる。業務に影響を与えずにリプレースが可能かを慎重に見極めなければならない。ベンダーにおんぶに抱っこでシステムを構築していた場合、リプレースは不可能ということすらありうる。ベンダーは配偶者や恋人と一緒で、仲が悪くなるとどうしても良くないところが目立つようになる。また、違うベンダーであれば現状の問題が一掃されるという誤解もあるが、もちろんそんなことはない。コンサルは、ユーザ企業とベンダーの仲を取り持つ、というマインドで望んだ方が良い。もちろん、ユーザ企業の立場できちっと発言するが、ベンダーを育てて（おだてて）こちらの意図するように動かすように仕向けるのが得策であろう。
2004/09/13
コメント(5)
-
情報系の無駄な帳票
情報系のシステムを構築すると無駄な帳票（画面）が山盛り作られる。なので、情報系のシステムには、ユーザがどの画面を利用したかを記録する仕組みが必須である。それを作っておかないと、帳票は増えるばかりで減らすことができない。では、稼動した後でないと帳票を削減できないか、と言われると実はそんなことない。設計段階でもこれもこれもとと言ってたくさん画面が出てくる。それを削減する方法は簡単、具体的なアクションに結びつけることが可能か、と視点で選択すればよい。担当者の趣味で作ったような画面は数字を見てもアクションに結びつかない。本当に必要とされている画面であれば、数字を元に必ず何らかのアクションに結びつくはずである。情報系の画面を設計すると、必ずその企業の意思決定ルートを整理することになる。逆に、整理せずに作ると、ごみを山盛り作るだけになる。情報系の画面を設計・開発している人はすぐにコンサルになれる。この画面がなぜ必要かを顧客と話し合えば、業務改善に行き着くからである。
2004/09/08
コメント(1)
-
システムの最終形とその実現プロセス
コンサルという商売をしていると、システムの最終形よりもそこにいたるプロセスに悩むことが多い。企業情報システムにいろいろな問題が発生し、それを解決する方法を考えた場合、最適なシステムの形態を提案することは結構簡単である。しかし、その実現プロセスはそれほど簡単ではない。担当者のスキルや外注先との関係でなど、問題がいろいろ存在する。そういった場合には、どうしても最適な最終形ではなく、すこし劣るが実現が容易な解決策を提示することになる。また、実現のためのプロセスも念入りに計画して先方に伝える必要もある。はっきり言って非常にまどろっこしい。システムの構築にコンサルという立場で参画すると、どうしても現場をリードすることが難しい。やはり、担当者として現場に乗り込んで、はしの上げ下ろしまで指示をして強引に進めてしまうのが良いのだろうか。悩ましいところである。
2004/09/07
コメント(0)
-
ITスキルの向上には中小企業が最適！？
大企業関連の仕事ばかりしていると、どうしても知識が専門化してしまう。それはそれで研鑽と言う意味ではいいことなのかも知れないが、経営とITをつなぐ、という目的を持って仕事をした場合、あまりメリットにはならないように思える。それとは逆に中小企業のシステムに関与すると、驚くほど経営から雑多な事務処理の問題まで認識できることが多い。ITを使用せずに人間力で解決せよ！という結論に落ち着くことも多いのだが、それはそれでコンサルとしての役目は果たしている。報酬を度外視すれば仕事は中小企業のシステムの方が断然おもしろい。全体が見える、というメリットは非常に多い。さらに、まだ経験したことはないのだが、企業再生に関連したシステムの再構築、という仕事も非常に面白いと思う。それなりの資産もある企業に対して、ドラスティックにシステムを改良し、自分の思うシステムを構築するのは非常に楽しい仕事だと思われる。
2004/09/01
コメント(0)
全16件 (16件中 1-16件目)
1
