2006年10月15日

続・QMSについて

 お待たせしました、QMSの続きです。

前回は、ルールを作るには前提があるという所で終わりました。
そう、「前提」があるんです。わーい(嬉しい顔)

ひとつは、「現場主導でルールが検討される事」。

トップダウンで指示されるルールは、現場にフィットしません。
トップダウンで指示して効果があるのは、短期的なやっつけ指示。
いわゆる「力技」です。

問題が発生して、なんとしてもやりきる必要がある時、こんな
場面では有効です。大きな問題対処の前では些細な問題は放置
されます。これは、放置されるべき状況でもあり、現場も目を
つぶれます。

しかし、通常のルールとなると細部まで理解していない人が
決めたルールにはいろいろな課題や問題が潜在的にも残る確立が
高くなります。要するに現場でないと的確なルールの作成が
困難だということです。

さらに、現場が関わっていないと「やらされている」という
意識が残りうまく機能しません。

極めつけは、本当のルールの主旨が現場に伝わりにくくなる事
です。主旨が十分理解されていれば、ルールのほころびは
現場が補っていきますが、押し付けのルールは記述されている
事どおりにしか運用されません。俗に言う「マニュアルの弊害」
が起こりやすくなるんです。

もうひとつは...





続きを読む
posted by 三十郎 at 21:03| 大連 🌁| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2006年10月08日

QMSについて

この「プロジェクトマネジメント」というカテゴリを
このブログのメインテーマにする予定でした。

実際には、あまり記事も増えていませんが、もう少し
いろいろな観点で書いていこうと思います。

そんな訳で、今回はQMS(品質管理システム)について
です。

先日QMS(品質管理システム)関連の会議があったのですが、
「当たり前の事を確実に実施できるようにQMSを改定しよう!」
なんて話がありました。

簡単に言えば、「仕事の進め方のルール化」です。

どうでしょうか。

私はこの考え方に、諸手をあげて賛成ができません。信号

−−CMです−−−−−−−−−−−−−−−−−−−−−−−−−−−−

「起業したい!…無理だよなぁ」そんな風に、あきらめないで!あなたの夢をかなえる方法があります。会社を辞めず、元手をかけず、自分のビジネスを持ちたい人が集う会員組織。それが「週末起業フォーラム」です。

【無料】メールマガジン「会社を辞めずに起業する!by週末起業フォーラム」では、
藤井孝一による「週末起業入門」、森英樹による「週末起業クリニック」
など公式メルマガならではの、質の高いコンテンツが、あなたの起業意欲を
高め、実践的なノウハウを提供!
書籍「週末起業」で語られていない情報が満載!



−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

続きを読む
posted by 三十郎 at 20:03| 大連 | Comment(1) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2006年04月04日

パッケージシステム導入の落とし穴

あー、なんて久しぶりなんだろう。このカテゴリ。

記事を書くのも久しぶりだ。

「SE」という仕事も20年を超えたけれど2連徹は初めてでした。

この年齢での徹夜仕事はさすがにこたえます。もうやだ〜(悲しい顔)

導入するシステムのタイプには、新規構築とパッケージの2つが
あります。一般的には、パッケージを採用しカストマイズして
自社仕様にして導入する方が経費が少なくできます。

しかしこのPKG(パッケージ)、SEにとっては落とし穴が
いっぱいです。

いくつか経験していれば、とても便利でSEもユーザーも
楽ができるのですが、経験の少ないSEが担当すると地獄を見ます。



「落とし穴」って???   続きを読む
posted by 三十郎 at 00:36| 大連 🌁| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年11月26日

ミスの重さ

 若い頃、よく先輩に「人の生き死にに関係ない仕事だからまだ良いよな。」って
言われました。

つらい時のなぐさめです。

しかし、情報化が進み、これだけ生活や社会の奥深くまでコンピュータが
入り込んでいる現在、IT業界では「ちょっとしたミス」が企業の存続を
脅かす時代になりました。

IT業界では、技術の進歩が異常に早く、1年現場を離れると
置いて行かれる時代です。

「ちょっとしたミス」は、結局「ちょっとしたミス」で、個人の技術的な
スキルだけではなく注意力、緻密性等のベーシックなスキルも要求されます。

こんな中、個人の責任は増大し、企業は個人のスキルを今まで以上に重要視し
社員の差別化を評価という名前で実施しています。
少し表現は、極端で、もっと複雑ですがIT企業は厳しい状況です。

情報化社会が進むのとあわせて企業の責任が重くなっていく。
こんな中、最終的に頼るのは「個人」。

そして「個人」の「ちょっとしたミス」を企業がフォローしきれなくなって
いるような気がします。

仕事を自宅に持ち帰り、個人情報が漏洩、結果として減俸や懲戒免職なんて事も
起きかねません。忙しくて、時間が無くてやむなくやっているはずなのに。

人の生き死にには直結していなくても、人生を左右する「ちょっとしたミス」の
プレッシャーには晒される仕事になってしまいました。

厳しいーーーーー。モータースポーツ

posted by 三十郎 at 19:10| 大連 ☀| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年10月22日

ザ・ゴール考察6

 今回で、ザ・ゴール考察シリーズは終了です。

前回以降、またまた大幅に間があいてしまいました。

この本の内容を簡単に言うと、利益を生みだす為には、複数の工程が必要となる。
そしてこれらの工程をうまくコントロールすることは非常に難しい。

ボーイスカウトの隊列の話である。

又、本当に利益を引き出す為には何をするべきか、いま目標としている「ゴール」は
正しいのか。

これを「ものさし」の正当性も含め検討する。

部分最適と全体最適の話である。

最後に、この複数の工程をコントロールするには、ボトルネックを明確にし
これを利用すれば良い。ボトルネックと非ボトルネックを区別する事で
無駄な作業を軽減することもできるという結論に達する。

が、ボトルネックは生き物で、状況の変化に伴い替わっていってしまう。

その為、常に一定のサイクルでボトルネックを捕まえ続けなければならない。

非常に理にかなった理論で、おもしろい。

この理論の事を「TOC(Theory of Constraints)」(制約条件の理論)と言う。

この理論をシステム開発に利用できるだろうか。

続きを読む
posted by 三十郎 at 22:41| 大連 | Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年07月29日

ザ・ゴール考察5

 いやー、間が空きすぎて思い出せません。 わーい(嬉しい顔)

少しづつ、本の内容から外れていたりして。
多少のことは、ご勘弁を。

ストーリーの中では、ボトルネックか非ボトルネックかを非常に
意識して展開されていきます。

今回は、非ボトルネックにスポットを当ててみましょう。

「非ボトルネック」とは、生産能力に余裕があり、スループットを
考えた場合、それほど重要視、重点コントロールしないくも良いところです。

ここが、目一杯がんばると、この工程で作成される部品だけが大量に生産
されることになり、不良在庫が増え、非効率になります。

ようするに、ボトルネックの状況を横目で見ながら、ほどほどに仕事を
するのがベストなわけです。

では、システム開発における「非ボトルネック」とは、なんでしょうか?

手(パー)

続きを読む
posted by 三十郎 at 01:18| 大連 ☀| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年06月29日

ザ・ゴール考察4

 少しあいだが空きましたが、前回は「スループット」の重要性を
記述しました。

話が少しずれるかもしれませんが、スループットの大きさは、クリティカルパスの
長さによって決まります。
そして、このクリティカルパスの中でも重要なのが、「ボトルネック」です。

ストーリーの中では、この「ボトルネック」をいかにして有効に機能させるか
という事が記述されています。
その手法のひとつに、「ボトルネック」工程より後で発生する不良(エラー)を
減らして、「ボトルネック」の効率を向上させるという記述があります。

もしも、問題が潜在しているのであれば、「ボトルネック」を通す前にチェック
して、無駄になる可能性のあるもの(エラーがあるもの)は、「ボトルネック」を
通さないという考え方です。

非常に合理的な考え方です。

システム開発でも、同じような考え方は取り入れられており、いかに早い工程で
バグ(エラー)を取り除くかが、作業効率に大きく影響します。

その中で、かなり以前から実施すべきとされながら、実施されてこなかったものに
CDI(コードインスペクション)があります。

「CDI」、プログラムを記述した後に、実行してエラーを検出するのではなく
記述内容を机上でチェックして、エラーを検出するというものです。
もちろん、CDIの後に、実際に実行してテストは実施します。

この「CDI」が最近、実施されるようになりました。
なぜでしょうか。

続きを読む
posted by 三十郎 at 23:46| 大連 | Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年06月15日

ザ・ゴール考察3

 少し、おさらいをします。

考察1では、目標の明確化と目標に対する正しい評価指標について述べました。

会社の目標と、自分が意識している目標のズレについてです。
これは、「部分最適と全体最適のギャップ」として考える事もできます。
大企業になると、ありがちだと言われています。

まずは、具体的で正しい目標を明確に意識しましょう。
そして、現在の位置を正しく評価できる「ものさし」を持ちましょう。
システム開発でも、進捗状況を何で図るかという事は、非常に重要な要素になります。


考察2では、スループットの重要性を記述しました。

いかに早く、結果(利益)に結びつけるか。
システム開発でも同様で、生産性や効率が多少悪くても、早く完成させて
売上げることができれば、早く利益を確定でき会社にも貢献できるという話でした。

もうひとつは、「統計的変動と従属事象」。
個々に変動があるケースで、従属関係がある場合、進捗の遅れだけが後工程に
伝達されるという法則。
システム開発は、マシンが中心ではない為、遅れに対するリカバリーが、後工程で
なくなる事はあまりありません。全体を把握できる為、それなりの行動ができるはずです。
しかし、工場の場合は機械が主体の為、前工程で遅れをリカバリーする為に、作業を
圧縮しても、次工程に一度に渡される量がキャパを超えてしまうと、そこで足踏みして
しまいリカバリー分がなくなってしまいます。
システム開発でも、同じことですが、工場ほど明確ではないというだけです。

他の指標については、あまりふれませんでしたが、スループットが大きくなると
在庫(仕掛り)が増加し、利益を圧迫する事になります。
又、在庫の増加は、保管スペース(倉庫)の問題等で経費の増加にもつながります。

posted by 三十郎 at 02:01| 大連 🌁| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年06月12日

ザ・ゴール考察2

 早速、昨日書いた記事を読み返し、一部修正をしました。
思ったままを書いているため、内容が理解しにくい部分が多々あると思います。(^^;

読み返しては、手を入れますので不明点はコメントしてください。

さて、評価指標が間違っている事に気づいた所まで書きました。
物語では、3つの指標のうち、「スループット」にスポットをあてた展開になります。

「スループット」、システム開発では「開発期間」に該当しそうです。

ロゴの工場では、納期が遅れているオーダーが多数存在します。その遅れも
4ヶ月遅れとか、大きな遅れです。
まず、受注したオーダーを何とか納期どおりに納品できるようにしなければ
なりません。
資材を投入してから、各工程を通過し完成品となるまでのコントロールを
して、この期間(スループット)を短くしなければなりません。
いくら各工程がフル稼働しても、完成品が出荷できなければ、利益は上がらないのです。

ロゴの工場では、完成品を出荷するために、いくつもの工程を通過しなければ
なりません。又、完成品の種類により、通過する工程が違います。
工程(ワークセンター)から見ると、色々なオーダーを常時対応することになり
まわされてきた製品をどんどん加工するイメージになります。
ワークセンターでは、自分の工程がすべての為、オーダー単位での一連の流れが
把握できず、スループットを意識できません。
この辺の事情を、物語ではハイキングの隊列を使ってうまく説明しています。

同時に、この辺の事情がシステム開発とは違ってきます。

続きを読む
posted by 三十郎 at 16:21| 大連 🌁| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年06月11日

ザ・ゴール考察1

 少し前に、レビューのカテゴリで紹介した「ザ・ゴール」をほぼ読み終えたので
システム開発と比較した考察を記事にしようと思います。

2回目ということもあり、前回読んだときよりは理解できたつもりですが
「おかしい!」「どういう意味?」と思われる方、遠慮せずコメントを
お願いします。

こま切れで、書き終える迄しばらくかかると思いますが、ご勘弁を。わーい(嬉しい顔)

主人公の「ロゴ」は、とある工場の所長。

自分の工場は、そこそこの業績だと思っていたところに、突然上司から
業績低迷を理由に3ヵ月後の工場閉鎖を宣告されます。

工場を存続させ、我が身を守る為には3ヶ月以内に業績を飛躍的に好転させなければ
なりません。

さー、困った。

というところからストーリーが始まります。

ここで、ふと以前に空港で会った学生時代の恩師「ジョナ」の事を思い出します。

この恩師、なんだか、スターウォーズの「ヨーダ」のようーだ。なんてね。わーい(嬉しい顔)

まだ、工場が順調だと信じていたロゴに対し、今の最悪の状況を見透かしていたような事を
言うジョナ。

「君の会社の目標とは、何だね」(ジョナ)
「できるだけ効率的に製品を作る事です。」(ロゴ)
「違う、そんなのは目標じゃない、本当の目標はなんだかわかるかね」(ジョナ)
−p55−

質問を残し立ち去るジョナ。がく〜(落胆した顔)

続きを読む
posted by 三十郎 at 02:23| 大連 🌁| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年04月09日

映画とプロマネ

プロジェクトマネジメントの講習をいくつか受講しましたが、その中に映画を
題材として、ディスカションや検討をするものがありました。

映画の主人公をPJマネージャー、主人公の仲間をPJメンバーに見立て
ストーリーを分析する。

すこし、型破りな講習です。 たらーっ(汗)

主人公が、ここで単独行動をしたから、犠牲者が増えたんだ、
これはPJマネージャーとして、とってはならない行動なんです。

ってなディスカッションをする訳です。

でももし、主人公が完璧なPJマネージャーを演じきってしまったら、どうでしょう。

たぶん、映画は映画として成り立たなくなるのではないでしょうか。

アンバランスなところ、うまくいかないところがあってこその映画なんです。
観客としては、問題が起きないと面白くないんです。
でも、主人公はきっと、問題なんてない方が良い筈。

観客と当事者では、視点が全く違うのです。exclamation

これ、上司と担当者の視点の違いに似ていませんか?
特に直属上司ではなくて、もう少し上の現場から離れた上司と現場担当者に。

上司からすると、トラブルが発生して、苦労しながらも、なんとかシューティング
した部下の方が、問題なく完了してしまう部下よりも、印象に残っちゃうんじゃない?

ここら辺りが、難しいところですよね。 雪

posted by 三十郎 at 01:17| 大連 🌁| Comment(2) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年03月21日

プロジェクトが遅れる理由

しばらく、間(あいだ)が空いてしまいました。

仕事が忙しくなると、どうしても時間が取れなくなるし、仕事に関連した事は
書きたくなくなります。 ふらふら

ゴールドラット博士の本は、大好きで「ザ・ゴール」から「クリティカル・チェーン」
まで全て読みました。

その「クリティカルチェーン」の中にプロジェクトが遅れる理由として、
以下の3点があげられています。

1.統計的変動による遅れ
2.学生シンドロームによる遅れ
3.マルチタスクによる遅れ

「統計的変動による遅れ」は、一連の作業の中で、早い工程と遅い工程があることに
より、早い工程が遅い工程にぶつかって結果的に遅れていくというものです。
又、遅れないように納期は意識してキープしようとしますが、早く終わっても
次の工程を早く始めない傾向にあるという心理的な側面も指摘されています。

「学生シンドロームによる遅れ」は、試験直前にならないと勉強しないという事が
仕事においても発生するという事です。
試験は、点数が悪くなるだけですが、常に100点をとる事が要求される仕事では
うまくいきません。

「マルチタスクによる遅れ」は、仕事を掛け持ちする事による効率の低下です。

最初と最後は、わかりますが、真ん中のやつが、どうもシックリきませんでした。

「仕事」と「学生の試験」は違うでしょ!!

学生は、遊んでりゃいいけど会社で遊ぶわけにはいきませんから。

ここはやはり、ほかの事に時間がとられると考えるほうが自然だと思います。
確かに納期が先だと、切迫した緊張感が無いので、「残業までしなくても」と
いう意識は働くと思います。
そして、それ以上に、突発的な別の仕事が入って時間がとられてしまう事が
多いのではないでしょうか。

又、当初の計画時に、この「突発的な別件」を考慮していない事が真の原因では
ないでしょうか。

いわゆる「計画の精度」と「リスク管理」の話だと思います。

続きを読む
posted by 三十郎 at 02:38| 大連 | Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年02月27日

SEという職業について

SEとは、システムエンジニアのことです。

以前は、SEと言えば、何をする仕事かよくわからないけれどコンピュータに関した
仕事ですごい仕事なんだというイメージで世間から思われていました。

今は、IT産業という言葉と共に最先端をいく花形産業というイメージをもっている方も
いらっしゃるかもしれません。
反面、SEに関した書籍も、最近はよく目にするようになり、イメージとは違った実態を
垣間見ることもできるようになりました。

みなさんは、どんなイメージをお持ちでしょうか。

続きを読む
posted by 三十郎 at 23:22| 大連 | Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年02月16日

あなたは何を売りますか

私が就職した頃は、まだFORTRANでのシステム開発案件があり、紙テープを業務で
利用していました。
鉄人28号なんかに、コンピュータとセットで出てきそうなやつです。わーい(嬉しい顔)

そして、この頃のシステムは、省力化が売りでした。

システム導入によって、転記、集計、計算、作表が簡単にできます。
要員を2人分削減できます。 ってな具合です。

しかし、今はこの段階は通り越して、システム導入によってどれだけ利益が
増えるのかを売りにしないと満足して貰えなくなりました。

続きを読む
posted by 三十郎 at 00:36| 大連 🌁| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年02月11日

プロジェクトマネジメントとは?

 基本に戻って、「プロジェクトマネジメント」とは何なのかを整理しようと
思います。

用語辞典を調べると、

「チームに与えられた目標を達成するために、人材・資金・設備・物資・スケジュールなど
をバランスよく調整し、全体の進捗状況を管理する手法。」とあります。

要するに、人、物、金などの資源を使って、与えられた目標を達成する技術の事です。
但し、ただ達成するのではなく、品質、コスト、納期を守らなければなりません。
そして、与えられる目標についても、いろいろな面があり、それほど単純ではありません。

続きを読む
posted by 三十郎 at 15:27| 大連 | Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年02月03日

もうひとつのファクター

前回までの記事は、システム開発が内容的にうまくいくという視点からの提言
でしたが、システム開発としては、「コスト」という非常に重要なファクター
があります。

このファクターについては、最近「オフシェア開発」を採用するケースが増えて
います。

私も、ある程度の開発規模がある場合は、先の記事で紹介した体制に「オフシェア
開発」を取り入れます。

それほど、経験が多いわけではありませんが、ある程度のノウハウは蓄積できたと
思います。

「オフシェア開発」については、以下のページにいろいろな事が紹介されています。
興味のある方は、参考にしてきださい。

http://aicoach.tea-nifty.com/offshore/cat1266789/index.html

                               iモード続きを読む
posted by 三十郎 at 20:43| 大連 ☁| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

テクニカルSE専任化の工夫

前の記事で、テクニカルSEを専任化するためには、ある程度の開発規模が必要だと
書きました。

私の場合、ほとんどがそういった物件の為、ユーザー要望に左右されにくい制御系の
仕組み、たとえば、ユーザー認証、メニュー管理、印刷制御といった部分を、テクニ
カルSEの分担として、専任化のためのボリュームを確保しています。
posted by 三十郎 at 20:09| 大連 ☁| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年01月29日

プロジェクト体制について

私の理想とするPJ(プロジェクト)体制で、重要な役割を担うのはPJマネジャー、
PJリーダー、テクニカルSEと言いました。

PJマネージャーは、あまり専任にはこだわりませんが、他の2つはこだわりたい
ポストです。

<私のイメージするPJリーダーとは>
 ・システム全体の機能、ロジックに責任を持つ人。
 ・チームの中で、業務知識が一番豊富でシステム全体を一番把握している人。
 ・ユーザーをリードできる人。

<私のイメージするテクニカルSEとは>
 ・採用技術の専門家。
 ・設計書ドキュメントの様式、記入サンプルを検討・作成する人。
 ・設計標準、プログラミング標準等、テクニカル面の標準類を作成する人。
 ・機能部品、サンプルプログラム、制御系プログラム等を作成する人。
 ・開発環境を構築する人。
 ・上記内容が、機能とコストの両面でバランス良く検討できる人。

これらのポストを専任にする為には、ある程度の開発ボリュームが必要になります。
通常、1.5千万程度の開発案件では、専任のテクニカルSEを確保することは
難しいと思います。

PJリーダーが重要なことは、誰でも容易にわかると思いますが、専任の
テクニカルSEにこだわる理由は、何だと思いますか?

三日月 半月 やや欠け月 ひらめき

続きを読む
posted by 三十郎 at 01:41| 大連 🌁| Comment(0) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする

2005年01月28日

アーキテクト

ビジネスカテゴリ初投稿です。

ガンダムSEED Destiny、大好きです。
今までのシリーズは、出し惜しみの傾向がありましたが、今回はそれもなく
毎週楽しみにしています。

そんな訳で、記事の内容をあれこれ考えていましたが、出し惜しみ無く考えて
いることを、どんどんUPしようと思います。

まとまりに欠ける可能性もありますが、ご容赦ください。

さて、本題です。

私の職業は、IT企業のプロジェクトマネージャーです。ライン管理も実施しています。
今、「プログラマの本懐」(山本啓二著)という書籍を読んでいます。

この中に「アーキテクト」という役割が出てきます。
本書では、プロジェクトリーダーとテクニカルSEをあわせたような役割として
紹介されています。
続きを読む
posted by 三十郎 at 01:35| 大連 🌁| Comment(1) | TrackBack(0) | 20 プロジェクトマネジメント | このブログの読者になる | 更新情報をチェックする