ITのソムリエ・デジタリアン

ITのソムリエ・デジタリアンは、IT(情報技術)による経営革新、業務改革を支援するITプロジェクト管理の専門家です。

メルマガ

[ リスト | 詳細 ]

記事検索
検索

全10ページ

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

[ 次のページ ]

┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
    ITを経営に活かす
                    最終回 第52号(2006/7/3)

情報技術を使って経営革新や業務改革を最高に成功させる実践的な知恵を紹介

             ITのソムリエ・デジタリアン 馬場 文康
┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
目次:
  1.失敗は成功のもと
  2.コラム:グループコーチング
         「未来質問&肯定質問」の巻
  3.編集後記
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
☆☆★1.失敗は成功のもと
☆★

「ITを経営に活かす」は今回をもって最終回となります。
最後ですから、お気楽に失敗にまつわる話をお送り致します。

最近、「失敗学」なるものをマスコミで良く見聞きしますが、
失敗から学ぶことも多いと思います。

今回は情報システムの何たるかも知らない頃の失敗談から話を紐解きます。

それは、あるメーカーの設計部門でのことでした。

設計部門から製造部門へ設計図と共に製造指図書と部品表を送付していました。
設計図は毎回、ほぼ同じものが使用されるので、指示する側の設計部門も、
受け取る製造部門も阿吽の呼吸で流れ作業のごとく進んでいきます。

ただ、製造指図書と部品表は納品物によって若干内容が異なっていました。

製造指図書と部品表には設計上の様々な決りや注意事項があり、
部品どうしで使えない組み合わせがあったり、予め在庫を確認しなければ
ならない部品もありました。

問題は、この製造指図書と部品表に、ときどき間違いがあったり、
変更や追加が日常茶飯事の如く、数多く発生していたことでした。

その度に、現場の流れが狂い、納期に影響を与えたり、品質の悪化を
招いていました。


この状況を改善しようと情報システムを作ることになりました。

設計部門で製造指図書と部品表を入力すると必要なチェックが行われ、
間違いを排除した上で製造部門へ送る仕組みを作ることが狙いでした。


この要件定義を手伝った私は、製造指図書と部品表を書くのに必要な
様々な決りや注意事項を現場で聞き取りながら仕様化していきました。

しかし、調べていくとキリがないほどのルールがあることが分かってきました。

同じ様な部品表でも顧客ごとに少しずつ仕様の違いがあったり、
他の納品物との関連を考慮する必要があったりと大層複雑でした。

また、中には特殊な部品が使われ、設計者が自分で部品を保管しているような
ものまでありました。

要するに例外事項が多すぎて、仕様にまとめるのは一筋縄ではなかったのです。

結局、ルールの大部分は入力者にチェックしてもらうことなりました。

また、製造部門への自動転送に関しても誰が承認するかで一悶着ありました。

正規のワークフローは決まっていましたが、飛び込み対応や代行入力のルールは
部署ごとに若干の違いがあり、ここでも「割り切り」が必要になりました。

結局、部品表を紙に出して、従来通りに印を押して提出することにしました。


完成した情報システムは当初、好奇心も手伝って、使う人もいましたが、
入力が面倒なのと、使うメリットが少ないので、徐々に使われなくなりました。

ルール自体も新しい製品が出る度に、どんどん変わっていきます。
そして、最後には情報システムの存在自体が忘れ去られました。

昔のほろ苦い経験ですが、今にして思えば間違いだらけのプロジェクトでした。


まず、情報システム以前に仕事のやり方そのものに問題があったのです。
例外だらけの設計をそのままにして、いくら情報システムでチェックしても
限界があったのです。

またワークフローを標準化せず、現状のまま認めるという割り切りをしたために
従来通りの個別最適が生き残ってしまいました。

ここでの教訓は情報システムは万能ではなく、情報システムだけで解決しない
問題があるということでした。


◆失敗から学べば、それは成功です
失敗から得る教訓があります。

その教訓を次に活かすことができれば、その失敗は失敗ではなく、
成功であると言えます。

(「失敗は失敗さ」と批評する人もいるでしょうが。)

最近良く聞く「失敗学」で気付いたことは、
大きな事故は小さな事故を重ねるうちに発生するということです。

つまり、大きな失敗というものは失敗全体の氷山の一角にすぎず、
小さな失敗が繰り返されていると、そのうちに大きな失敗が発現する、
ということです。

逆に言えば、小さな失敗は放置せず、早めに対処することで
大きな失敗を回避できるということでもあります。

成功したプロジェクトと言えども、その中には小さな失敗が隠れています。
小さな失敗は早めに見つけ出し、大きな失敗へ発展する前に、
その芽を摘み取ってしまうことが大事であると言えます。



◆失敗の積み重ねはシングルヒット、成功の積み重ねはホームラン

失敗から教訓を得ることは大事ですが、失敗で学ぶことができる教訓は、
「次回、やってはいけない」ことを一つ学んだに過ぎません。

つまり、多くの「やってはいけないこと」の集合体の中の、ほんの一つである、
ということです。

厳密に言えば、「やってはいけないこと」をいくら集めても、
成功する道は見えてはきません。

(実際には、それ程ひどい状況にはなりませんが、...)


一方、成功体験は丸ごと、成功への道であり、次回もそのまま実行すれば
成功する確率が高いということです。

たとえ、どんなに小さな成功であっても、それは貴重な成功体験ですから、
大切にしなければなりません。

失敗したプロジェクトであっても、その中から成功した経験を探し出して、
共有しておくことが大事です。

前述の失敗事例では、大胆な割り切りによって情報システムを完成するところ
まではできた、という一点では成功体験を勝ち得たと言えます。

多くのプロジェクトが日の目を見ることもなく消えてしまうことを考えると
小さいながらも貴重な経験でした。


◆小さな成功を勝ち取る
業務改革はアイデア勝負でもなく、地道な改善活動でもありません。

また前述の事例のように単に情報システムを作れば実現できるほど簡単なもの
でもありません。

たとえ小さくても成功体験を積み重ねることで、ノウハウが蓄積でき、
自信がついて、着実に目標を達成することができるようになります。

そして、やがて大胆で抜本的な業務改革や経営革新ができるようになり、
自らの実力で競争優位を獲得できるまでになるでしょう。

それにはプロジェクトチームが一丸となって持続的に仮説検証を重ね、
継続的に小さな成功を勝ち取っていく過程こそが大事なのです。



━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□□■2.コラム:グループコーチング
□■       「未来質問&肯定質問」の巻

人は失敗すると「どうして失敗したんだろう?」と後ろ向き、否定的な質問を
やってしまいます。

過去の行動を振り返り、反省することも大事ですが、それだけでは
前向きで元気な「やる気」は出てきません。

コーチングでは、将来に向かって何をすべきか?
どうすれば成功できるか?、を考えます。

このときの質問が未来質問と肯定質問です。

これは文字通り、未来に向けて肯定的に問う質問です。

目的を達成するために「何をするか?」、「何ができるか?」を
考えることで、創造的な創意工夫が生まれてきます。

様々なアイデアを考える中から、大きなブレイクスルーが生まれることも
あります。


ただし、最初から最後まで未来質問&肯定質問だと、受ける側も変に
気負ってしまい、疲れてしまいます。

(それだけ、脳が刺激され、活性化されているということですが、...)


現状を冷静に見つめ、取りうるオプションを洗い出してから、
未来を肯定的に捉え、自らの可能性を探求することで、
内に秘めている「やる気」を前面に出すことができるのです。



━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○○●3.編集後記
○●

情報システム開発のライフサイクルに従って、ITを経営に活かす方策を
私自身の棚卸しを兼ねて綴ってまいりました。

この1年もの長い間、私の拙い文章をお読み頂き、心から感謝致します。

ひとまず「ITを経営に活かす」は本号を持って最終回とさせて頂きます。

今後は私の雑多な経験をご紹介しながら、プロジェクト管理や情報システム開発
に関する話題をお送りしたいと思います。


かって、ドイツ帝国を創建したビスマルクは
「賢者は歴史に学び、愚者は経験に学ぶ」と言ったそうですが、
他人の経験を知ることは、歴史に学ぶことと同義だと思います。

また、ハーバード・ビジネス・スクールのライリング教授は
「賢者は経験から学ぶが、真の賢者は他人の経験から学ぶ」
と述べています。

賢明な読者の皆さんには、ぜひ、私の稚拙な成功事例や失敗事例から
教訓を見つけ出して頂きたいと思います。


ただ、このメルマガのタイトル「ITを経営に活かす」のままでは
失敗談を述べるには少々窮屈ですので、このメルマガも当分、休刊と
させて頂き、流行りのブログで公開していきたいと存じます。

次回以降は以下のブログで続けていきます。
http://blogs.yahoo.co.jp/digitalians_biz

どうぞ、今後もご贔屓にして頂ければ幸いです。
さて、最後になりましたが、ご購読頂き、
ほんとうにありがとうございました。

====================================
◆メールマガジン: ITを経営に活かす
◆発行日:週刊(月曜日発行)
◆配信システム:購読、解除は以下のURLをご利用下さい。(無料)
  「まぐまぐ」http://www.mag2.com/m/0000163400.html
  「メルマガ天国」http://melten.com/m/21282.html
  「melma!」http://www.melma.com/mag/35/m00142935/
  「めろんぱん」http://www.melonpan.net/mag.php?008367
◆ブログ:http://blogs.yahoo.co.jp/digitalians_biz
◆発行元:ITのソムリエ・(有)デジタリアン
◆発行者:馬場 文康
◆URL: http://www.digitalians.biz 
◆ご意見、ご要望はinfo@digitalians.bizまで
Copyright(C)Digitalians 2006 All Rights Reserved.

┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
    ITを経営に活かす
                        第51号(2006/6/26)

情報技術を使って経営革新や業務改革を最高に成功させる実践的な知恵を紹介

             ITのソムリエ・デジタリアン 馬場 文康
┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
目次:
  1.プロジェクト後の展開
  2.コラム:グループコーチング
         「タイプ別コーチング」の巻
  3.編集後記
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
★★☆1.プロジェクト後の展開
☆★

今回は情報システムの開発プロジェクトの「その後」についてお話します。

プロジェクトの評価が終わると、プロジェクトは解散することになりますが、
ほんとうは、ここで終わりにしてはいけないのです。

せっかく、育った若い人たちの力を、次の発展段階へ導くことを忘れてはいけません。

良いプロジェクト計画書には、常にプロジェクトが終わった「その後の展開」まで
シナリオに入れてあるものです。


◆継続的に仮説・検証を続けていくことが大事

業務改革を実現し、現場に定着させるためには、仮説と、その検証を繰り返していく
ことが大事です。

この仮説・検証の繰り返しで気をつけなければならないのは、
目指す方向性を失わないように、目標をきちんと持って、継続的な活動にすること
です。

仮説・検証を行うにしても、毎回違った視点や目標で仮説を立てていては、
向かう方向がブレて、仮説・検証の努力も単発で終わってしまいます。

これでは検証結果を十分に活かしているとは言えません。

一つの開発プロジェクトが終わっても業務改革の流れを消してはいけません。

継続的な活動こそが、真の力を獲得することにつながります。


◆もう一度、企画を繰り返そう

その後の展開を確実にするために、プロジェクトの最後に、もう一度、
メンバー、特に若い人たちを集めて、企画を練ってみましょう。

小さな成功体験を共有してきた仲間ですから、より大きくて、しっかりした
業務改革案ができると思います。

可能ならば、今度は若い人たちに任せて、挑戦させてみましょう。

いったん点いた改革への情熱という炎は、若い人々の勇気を引き出し、
職場を変える大きな「改革へのうねり」を作り出すことでしょう。



━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■■□2.コラム:グループコーチング
□■       「タイプ別コーチング」の巻

コーチングでは人を行動スタイルのタイプ別に分けて、コミュニケーションを
適切に工夫することが行われています。

人の性格や置かれて環境、目指すところは、人それぞれで微妙に違いますから、
タイプによって、絶対的な指導方法が決まるわけではありません。

まあ、しかし、タイプによって、同じ言葉でも、受け止め方が違うことがあると
認識しておくのも大事ですから、今回は簡単にご紹介いたします。


コーチングで良く使われているものではDiSC理論とMyProfileがあります。

DiSC理論は人を2種類の指標を使って4つのタイプに分類します。
指標としては仕事指向か人間指向か、ペースが速いか、遅いかで判断します。

D:主導型は仕事指向でペースが速い人
i:感化型は人間指向でペースが速い人
S:安定型は人間指向でペースが遅い人
C:慎重型は仕事指向でペースが遅い人

タイプ別の性格を解説しますと、以下のようになります。
D(Dominance):
 主導型は自己主張が強く、成果を上げることに集中するクールなタイプです。
 自由を束縛されたり、利用されることが最も嫌なことです。

i(Influence):
 感化型は感受性が強く、楽天的ですが、常に認められていないと気がすみません。
 周りから拒絶されたり、反対されることを嫌います。

S(Steadiness):
 安定型は我慢強い性格で他人と協調することに専念します。
 暖かい温厚な性格ですが、逆に急激な状況変化を好みません。

C(Conscientiousness):
 慎重型は仕事の質を着実に向上させていくことを好みます。
 じっくり自信を持って仕事を進めていきますから、外部の批判には敏感です。


さて、このように人をタイプで分けたあと、タイプ別に接し方を選びます。
D:主導型には単刀直入に話した方が効果があります。
 目標設定と具体的な成果を確認しながら、自らの意思を大事にします。

i:感化型にはじっくり話し合いながら、共感と対話を重視し会話を進めます。
 同意と認知を行いながら、コーチとの共同作業を基本とします。

S:安定型にはチームメンバーといかに協調していくかに重点を置きます。
 長期的な視野で目標設定を行い、一旦決めたことは安易に変えてはいけません。

C:慎重型には責任範囲を明確にし、十分な事前準備しながら一歩一歩進めます。
 後ろ向きの議論は避け、成果を一つ一つ確認しながら手順を大切に進めます。


以上がDiSC理論ですが、一方のMyProfileによるタイプ分けは感情表現と自己主張の
強さで、次の4つのタイプに分類します。

プロモータータイプ:感情表現が強く、自己主張も強い
サポータータイプ :感情表現が強く、自己主張は弱い
ドライバータイプ :感情表現は弱く、自己主張は強い
アナライザータイプ:感情表現は弱く、自己主張も弱い


DiSC理論の判断軸とは微妙に異なりますが、
あえて類似点を探して整理すると以下のようになります。

プロモータータイプ=企業家  ≒i:感化型
サポータータイプ =実務者  ≒S:安定型
ドライバータイプ =個人主義者≒D:主導型
アナライザータイプ=完全論者 ≒C:慎重型


ただ冒頭にも述べた様に人の性格は4つのタイプに類型化できるほど単純ではなく
異なるタイプが複合化しています。
人のタイプを軽々と決め付けることはできません。

それが人間の面白いところでもあり、難しいところでもあります。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
●●○3.編集後記
○●

成功したプロジェクトで一緒になったメンバーの信頼関係は一生ものと
言われています。

共に成功を勝ち取った貴重な経験は、更に険しい山を乗り越える勇気と自信を
与えてくれます。

プロジェクトの成功体験は単に成功したノウハウの蓄積以上の価値を提供して
くれるものです。

ですから、プロジェクトは必ず成功しなければなりませんし、
必ず成功させるのだ、という信念を持って臨まないといけないと思います。

さて、この連載も次回で最終回となります。
次回は一年間の総集編としてお送りする予定です。


====================================
◆メールマガジン: ITを経営に活かす
◆発行日:週刊(月曜日発行)
◆配信システム:購読、解除は以下のURLをご利用下さい。(無料)
  「まぐまぐ」http://www.mag2.com/m/0000163400.html
  「メルマガ天国」http://melten.com/m/21282.html
  「melma!」http://www.melma.com/mag/35/m00142935/
  「めろんぱん」http://www.melonpan.net/mag.php?008367
◆ブログ:http://blogs.yahoo.co.jp/digitalians_biz
◆発行元:ITのソムリエ・(有)デジタリアン
◆発行者:馬場 文康
◆URL: http://www.digitalians.biz 
◆ご意見、ご要望はinfo@digitalians.bizまで
Copyright(C)Digitalians2006AllRightsReserved.

┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
    ITを経営に活かす
                        第50号(2006/6/19)

情報技術を使って経営革新や業務改革を最高に成功させる実践的な知恵を紹介

             ITのソムリエ・デジタリアン 馬場 文康
┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
目次:
  1.チームの評価
  2.コラム:グループコーチング
         「コーチの資質」の巻
  3.編集後記
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
☆★☆1.チームの評価
☆★

情報システムの評価は予め設定した効果目標を達成しているかどうかが
問われます。

プロジェクトチーム自身の評価は、その目標を納期通りに、そして
許された費用の範囲でできたかどうかで見られると思われますが、
実際にチームの評価をきちんと行っている例は少ないようです。


◆人事考課としての目標達成度評価とは別に「良いところ」に注目する
チーム自体の評価を正確に行おうとすれば、評価の指標や、評価の基準を
予め定義しておく必要があります。

でもプロジェクト毎にそのような評価基準を定義することは非常に稀です。

あっても、会社全体の社員を対象とした人事考課の一つとして目標管理する
程度だと思います。

人事考課による目標管理はプロジェクトの成果に直接には関係なく、
個人の目標達成度で測られます。

ややもするとプロジェクト全体の評価が個人の成績に微妙に影を落とす
ことになりますから、個人の評価をプロジェクトの評価とは独立して行う
ことは、これはこれで健全だと思います。

個人の人事考課は厳粛にプロジェクトを離れて行われるべきでしょう。

では、プロジェクトにおける純粋にチームやプロジェクトメンバーの
立ち位置や振る舞いに関しては、どのように評価してあげれば良いでしょうか?


◆チームの評価を行い、プロジェクト管理の教訓を残しておく
プロジェクトが終わった段階でプロジェクト管理の評価を行うときに
チームの評価も含めて行っておくべきでしょう。

プロジェクト管理におけるコミュニケーションやリソース管理は
直接、チームの力量が問われる課題です。

プロジェクトの中でチームやメンバーの効果的な行為や貢献を
きちんと拾い上げ、今後のプロジェクト運営に活かせる教訓を残すことが
大事です。

成功したプロジェクトでは当然ですが、失敗に終わったプロジェクトにおいても
学ぶべきことが、たくさんあります。

できれば、そのような小さな功績にも注目して、何かの形で表彰してあげると
チームや個人の自信につながります。


◆成功体験の積み重ねが、より力強い成功するチームを作る
人は成功する体験を経て、勝つ自信を獲得し、より確実にプロジェクトを成功へ
導くことが出来ます。

プロジェクトの中にあって、効果を上げたことを丹念に見つけ出し、
何が良かったのかを貴重なノウハウとして共有していくことが大事です。

失敗したプロジェクトや、あるいは十分に成功を納めたとは言えない
プロジェクトにおいても、個々のアクションにおいては色々な工夫や成果が
あった点もあると思います。

むしろ問題プロジェクトほど、多くの工夫が編み出されているはずです。

例えば、会議の進め方とか、情報共有のやりかたとか、遅れた進捗の回復とか、
そういう工夫や成果を成功体験として見つけ出し、正しく認識することが、
次のプロジェクトで活きてくると思います。

そして、それを個人のノウハウの範囲に留めておくだけではなく、
プロジェクトを成功へ導く有益な知恵としてメンバー全員の共有財産にします。

一つ一つのノウハウが自信を持ってプロジェクトに挑戦するための
心の糧になると信じます。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□■□2.コラム:グループコーチング
□■       「コーチの資質」の巻

今回はコーチングの対象者から見た望ましいコーチとは、どんな人か?
考えてみましょう。

ひと昔のコーチのイメージは指導力があって、優れた技能の持ち主ということ
になるでしょう。

でも今のコーチングにおけるコーチのイメージはずいぶん違っています。

コーチング対象者のやる気を引き出すのがコーチの役目ですから、コーチに
高い技能は必ずしも必要ではありません。

優れたコーチの資質をあげると以下のようになります。
・良いところを見つける
・前向きな発想ができる
・相手を尊敬する
・満足感を共有できる
・相手にとって相談しやすい

以上はコーチング相手の本音を引き出すために必要なことですが、
相手に迎合するばかりでは駄目です。

・NOも言える
 コーチング相手の認識が甘いところや弱いところがあれば、
 しっかり批評し、時には相手の意見にノーが言えることが大事です。

・目標をしっかり共有できる
 何が目標で、現在の状況はどうか、どういう行動が必要かを
 分析し、相手がしっかり認識できるように説明することが大事です。


また、次のような態度はコーチの陥りやすい問題です。
・教条主義にならない
 目標や状況は常に同じということはなく、個別の事情で違っていますし、
 変化していくものです。
 何でもかんでも、いつも同じやり方を押し付けても、うまくいきません。

・失敗は認め、素直に誤りを認める
 コーチも人間で、神ではありませんから、ときには失敗もあります。
 そのときは素直に失敗を認め、謝る態度が必要です。

大事なことは、押し付けではなく、コーチング対象者の「やる気」を
引き出すことです。

コーチは指導者というより、伴走者として、時々の状況に応じて
共に考える姿勢が求められます。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○●○3.編集後記
○●

プロジェクトをうまく成功させるためのコツは、成功した手法を確実に
実行していくことです。

毎回、毎回、試行錯誤していてはダッチロールするばかりです。

そのためには「成功した手法」を着実に貯めるいくことが大事ですが、
でも「成功した手法」にはたまたま、ある状況で成功した場合も含まれています。

どんな状況でも「成功する手法」にするには「なぜ成功したか」を良く分析して
おくことが大切です。


====================================
◆メールマガジン: ITを経営に活かす
◆発行日:週刊(月曜日発行)
◆配信システム:購読、解除は以下のURLをご利用下さい。(無料)
  「まぐまぐ」http://www.mag2.com/m/0000163400.html
  「メルマガ天国」http://melten.com/m/21282.html
  「melma!」http://www.melma.com/mag/35/m00142935/
  「めろんぱん」http://www.melonpan.net/mag.php?008367
◆ブログ:http://blogs.yahoo.co.jp/digitalians_biz
◆発行元:ITのソムリエ・(有)デジタリアン
◆発行者:馬場 文康
◆URL: http://www.digitalians.biz 
◆ご意見、ご要望はinfo@digitalians.bizまで
Copyright(C)Digitalians2006AllRightsReserved.

┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
    ITを経営に活かす
                        第49号(2006/6/12)

情報技術を使って経営革新や業務改革を最高に成功させる実践的な知恵を紹介

             ITのソムリエ・デジタリアン 馬場 文康
┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
目次:
  1.繰り返し開発
  2.コラム:グループコーチング
         「パワープレイ」の巻
  3.編集後記
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
★☆☆1.繰り返し開発
☆★

情報システムの開発ではウォーターフォール型と呼ばれる開発手順が
採用されることが多く、通常は要件定義・設計・実装・ テスト・運用の順に
実施します。

これに対して、最近は繰り返し型、反復型と呼ばれる新しい開発方法が提唱され、
採用実績が出てきました。


◆業務改革や経営革新には従来の開発手順は適していない
ウォーターフォール型は要件定義で一旦、仕様を決めたあと、一気呵成に開発を
行っていきますから、途中で仕様変更などの手戻りを前提としていません。

最初に固めた仕様は運用に入るまで変えることができないのです。


情報システムの目的が業務の合理化など、単純明確な場合は、
開発全体の見通しが良いウォーターフォール型が適していました。

ところが、情報システムの目的が業務改革や経営革新になってくると
情報システムの要件や仕様がどんどん変化してきます。

業務改革や経営革新のやり方、業務仕様は最初から完全に固定できるものではなく
仮設検証や試行錯誤を繰り返しながら、徐々に仕様が固まってきます。


また競争が激化している現代においては、外部要因によっても情報システム要件が
変化してきます。


業務改革や経営革新を狙う情報システムの開発ではウォーターフォール型開発は
適していません。


◆最低1度、できれば2度の改善工程を予め想定しておく
ウォーターフォール型に代わって繰り返し型、または反復型と呼ばれる開発手順を
採用する事例が増えてきました。

繰り返し型は要件定義・設計・実装・ テスト・運用の工程を複数回繰り返し
ながら開発していきます。

また繰り返し型は短期間に1サイクルを実行しますから、経営変化へすばやく
対応することができます。


ただ繰り返し型開発はまだまだ普及しているとはいえない状況です。


そこで、ウォーターフォール型で開発する場合においても開発後の改善工程を
予め想定しておくことをお勧めします。


従来からも、開発が一旦終わったあとで仕様追加や改善のための追加工程を
予め見込んでいるプロジェクトがありました。


今後はこのような追加工程が必ず必要になると思います。

開発工程の考え方としては例えば以下のように考えます。

(1)初回の開発では機能限定、基本機能の確認を行います。
(2)2度目の開発では全て機能を追加、使い勝手の修正、
   一部の利用者への展開を行います。
(3)3度目の開発で、仕様の見直し修正、全利用者への展開を行います。

予算配分は(1)と(2)の機能分割によって違いますが、
例えば、全体の開発費用を100%とすると、
(1)に30%
(2)に40%
(3)に30%
の比率で配分しておきます。

もし事情があって、(1)と(2)を一つで行わなければならない場合でも、
必ず(3)の追加予算30%は確保しておくべきだと思います。



━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■□□2.コラム:グループコーチング
□■       「パワープレイ」の巻

パワープレイとはアイスホッケーでは、選手が反則などによって退場し、
一方のチームの人数が相手チームの選手数より多い状態を指します。

つまり相手より有利な立場にたって試合をすることです。

会話や交渉においても心理的に、一方の立場が勝っている場合には
パワープレイになります。

例えば、たった一人を大勢で取り囲めば、多勢に無勢で文字通りの
パワープレイになります。
また、上司と部下とでは、当然ながら上司の方が優位な立場です。

上司が部下をコーチングすれば、部下の自発的な意思よりも、上からの
強制的な指導が強くなります。


コーチングによって「やる気」を引き出すには、このようなパワープレイ
は好ましくありません。

コーチは、このような心理に配慮して、コーチングにふさわしい環境を作ること
が必要です。


パワープレイを避けるには以下のようなことに気を付けます。
・相手のホームグラウンド(場所)で話す。
・質問攻めにしたり、威圧感を与えない。
・相手のリズムに合わせ、話の腰を折らない。
・明るい話題で、好ましい世間話、雑談をしておく。
・相手の姿勢を真似する。同じ姿勢を取ることで協調感が生まれる。
・会話の最後では次回の話題を決め、相手のペースで進める。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
●○○3.編集後記
○●

パワープレイはコーチングにおいて悪影響を与えますが、
討論や交渉を優位に進めるためのテクニックとして
特に米国では盛んに研究されています。

相手の空間と時間を占有することで有利な立場を勝ち取ります。

空間を占有するとは、相手の場所をできるだけ狭くすることです。
時間を占有するとは、相手の時間をできるだけ拘束することです。

こうすることで、相手は心理的に追い込まれた状態になってきます。

パワープレイは奥の深い、決して侮れないテクニックですね。


====================================
◆メールマガジン: ITを経営に活かす
◆発行日:週刊(月曜日発行)
◆配信システム:購読、解除は以下のURLをご利用下さい。(無料)
  「まぐまぐ」http://www.mag2.com/m/0000163400.html
  「メルマガ天国」http://melten.com/m/21282.html
  「melma!」http://www.melma.com/mag/35/m00142935/
  「めろんぱん」http://www.melonpan.net/mag.php?008367
◆ブログ:http://blogs.yahoo.co.jp/digitalians_biz
◆発行元:ITのソムリエ・(有)デジタリアン
◆発行者:馬場 文康
◆URL: http://www.digitalians.biz 
◆ご意見、ご要望はinfo@digitalians.bizまで
Copyright(C)Digitalians2006AllRightsReserved.

┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
    ITを経営に活かす
                        第48号(2006/6/5)

情報技術を使って経営革新や業務改革を最高に成功させる実践的な知恵を紹介

             ITのソムリエ・デジタリアン 馬場 文康
┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏
目次:
  1.現場の知恵を活かす
  2.コラム:グループコーチング
         「ステレオタイプ」の巻
  3.編集後記
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
☆☆☆1.現場の知恵を活かす
☆★

稼動したシステムが全く使われない、ということが時々あります。

決して安くない費用と時間を掛けて作ったのに、
完成して運用に入って、
最初のうちは物珍しさもあって、少しは使われますが、
徐々に利用者が減り、最後には誰も見向きもしなくなった。

というような情報システムが実際にあるのです。

基幹系の情報システムで、それがないと業務が回らないということなら、
どんなに使いにくいものでも、使われないというこは起こらないでしょう。
(そんな事態になるのは、よっぽどの場合です。)


問題になるのは主に情報照会系の業務支援を行うような情報システムです。

業務分析や情報共有のための情報システムは業務上、必ずしも必須では
ありませんから、使わなくても直接困りません。

利用者にとってメリットがない情報システムは使われなくなって当たり前です。

じゃ、何の為に作ったのか?

やはり経営上、必要があったから開発したわけですから、
使われないと困ることがあるはずです。

情報システムの評価では、その辺りをきちっと評価すべきでしょう。


◆使われる現場の理解が不十分
なぜ、使われない情報システムができてしまうのでしょうか?

それは、
・機能が貧弱
・欲しい情報がない
・使い勝手が悪い
・情報が古い
・反応が遅い
など様々な理由があると思います。

開発する側にしても最初から「使われない」ことを目指して作っているわけ
ではないでしょうから、どこかに思い違いがあったということでしょう。


ここで問題になるのは、情報システムが使われる現場の事情を、
開発者が十分に理解していない場合です。

開発者の力量不足や、「便利だから使われるはず」と言った独りよがり
の意識によって、理解不足が起こります。


更に、このような場合には現場ではほとんど使わないような過剰な機能が
盛り込まれたりします。

これは過剰仕様(オーバースペック)と呼ばれますが、
かって「花魁の厚化粧」と呼んでいた人がいました。


◆現場の知恵を活かす
このような使われない情報システムを作らないようにするには、
何より開発時に使用現場を十分に理解することです。

要件定義の段階から利用者の声を聴き、利用する場面を想定して、
情報システムの仕様に反映することが大事です。


もし仮に「使われない情報システム」になってしまったら、
どうすれば良いでしょうか。


現場の声を聴くのに「遅すぎる」ということはありません。
情報システムを評価段階で「使われない」ということが判明したら、
現場へ行って、事情を調査することから始めましょう。


使用現場には使用現場なりの生活の知恵がありますから、
必ず打開策が見つかるはずです。

大事なことは開発者が使用現場の目線に立って共に解決策を思案することです。



◆誰がどのように使っているかがわかれば、成功事例も見えてくる

情報システムを評価する際には必ず使用現場まで出向いて、
実際にどのように使われているかを見てみましょう。

使用現場の創意工夫や知恵を学べば、必ず成功事例が見えてきます。

それを広めて行けば良いのです。

ただ、気を付けなくてはいけないのは、成功事例をそのまま移しても、
同じように成功するとは限らないということです。

使用現場の状況によって成功要因は違ってきます。

ですから、成功事例をそのまま移すのではなく、
各々の使用現場に合った活用方法を見つけることです。

得られた成功事例はあくまで参考情報であることに考慮して、
その考え方をヒントにして、それぞれの使用現場での状況を理解し、
それぞれの仮説を立てることが大事です。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□□□2.コラム:グループコーチング
□■       「ステレオタイプ」の巻

ステレオタイプとは、心理学の用語で、
型にはまった考え方とか、固定観念的、画一的な見かたを指します。

コーチングをしていて、人の話を聞くときに、先入観があると、
「ああ、それはこういうことだ」とか、「よくある話だ」と
早合点してしまうことがあります。


会議をしていても、人の話を最後まで聞かないで、
決め付けで判断し、口を挟む人がいたりします。

コーチングにおいてはステレオタイプな考えは極力排除しなければなりません。
けれども相手の話を聞きながら解決策を探そうとすると、
どうしても過去の事例に当てはめようとしてしまいます。


一方で、こちらの先入観は相手にとっては「どうせ、分かってもらえない」
とか、「言われることは最初から分かっている」というような、
逆の先入観を増長してしまうことになります。


人それぞれの課題や背景、状況は皆それぞれ違うわけで
即断即決は決して「やる気」を引き出すことにはつながりません。


純粋に心を開放して、相手の言葉に意識を集中し、
相手の気持ちを読むことに専念することが大切です。


そうすることで、相手の状況も十分に理解できるし、
相手にとっても、また話し甲斐のある会話ができるようになります。



━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
○○○3.編集後記
○●

人は成功しているときは、どうしても慢心から独善的で傲慢になりがちです。

独善的になると、人から学ぶ姿勢がなくなり、ステレオタイプな考え方に
支配されてしまいます。


「勝って兜の緒を締めよ」と言うように、成功を収めたときこそ、
謙虚に周りの声を聴く必要があります。

コーチングは相手のやる気を引き出すために指導することですが、
真剣に取り組めば取り組むほど、相手から「学ぶ」ことが多くなります。

そこが、コーチングの面白さでもあります。


====================================
◆メールマガジン: ITを経営に活かす
◆発行日:週刊(月曜日発行)
◆配信システム:購読、解除は以下のURLをご利用下さい。(無料)
  「まぐまぐ」http://www.mag2.com/m/0000163400.html
  「メルマガ天国」http://melten.com/m/21282.html
  「melma!」http://www.melma.com/mag/35/m00142935/
  「めろんぱん」http://www.melonpan.net/mag.php?008367
◆ブログ:http://blogs.yahoo.co.jp/digitalians_biz
◆発行元:ITのソムリエ・(有)デジタリアン
◆発行者:馬場 文康
◆URL: http://www.digitalians.biz 
◆ご意見、ご要望はinfo@digitalians.bizまで
Copyright(C)Digitalians2006AllRightsReserved.

全10ページ

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

[ 次のページ ]


よしもとブログランキング

もっと見る

プライバシー -  利用規約 -  メディアステートメント -  ガイドライン -  順守事項 -  ご意見・ご要望 -  ヘルプ・お問い合わせ

Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

みんなの更新記事