2008年6月アーカイブ

インドや中国でのオフショア開発はIT業界の大きな流れです。

特にパッケージなど製品開発に関してはオフショア開発は一般的とも言えるような

状況ではないでしょうか

オフショア開発はなんといってもコスト面で魅力が大きいのですが、

英語を母国語にする国がインド人開発者を使いこなすのに比べ、

日本は言語の壁など不利な点がまだまだあり、

ブリッジSEの力量にかなり依存するのが現実です。

 

数年前に中国のIT企業を視察に行きましたが、大連は日本語教育とIT教育に非常に熱心でした。

大連の市長と面会した際に通訳をしていただいた方が日本に来た事が無いのに流暢な

日本語を話されていて、本当に感心しました。

 

中国でお会いする大学や政府の関係者はほとんど英語が流暢であったので、

本当に驚きます。

日本がソフトウェア産業を戦略的に考える上で、言語教育も戦略的に行わないと実感しました。

 

ところで、中国は契約社会です。

仕様がどんどん変更していくようなプロジェクトで中国に開発委託をしていると、

かえってお金がかかるというケースもあったりします。

 

 

ITプロジェクトの計画づくりから実行まで、様々なシーンでヒアリングを行います。

ヒアリングを行う際には事前に想像力を働かせる事が重要です。

例えば、システム化計画において、ある部門にヒアリングを行う際に、

「この部門が困っていることはこんな事ではないか、こんな事が実現できたら、どうだろう?」

といった事を想像しておくと、深いレベルで理解ができます。

 

ヒアリングされる人は、たいがい構えるものです

自分がヒアリングされる立場になったつもりで、一度想像するのも良いヒアリングをするのに

効果的です。

「あなたたち、誰?」「何しに来たの?」

「システムの不満なんて、いつも聞くだけで実現してくれない。時間の無駄だ」

「自分の言ったこと、評価につながったりしないよね?」

こういう気持ちをいかに取り除いてヒアリングを行うかと同時に

場合によっては期待値コントロールもヒアリングの際に出来ると良いでしょう

 

システム開発を行う前にすでにバグがあるって事実、なんだか変ですよね

でも事実、要件変更に伴い影響範囲の検証が不十分なために発生する仕様障害、

業務パターンの考慮漏れによる仕様障害など、システム開発に着手する前にすでにバグは

誕生しているのです。

あるリサーチによるとITプロジェクトの失敗要因の4割近くが要件定義フェーズに起因するそうです。

 

プロジェクト規模が大きくなるほど、各要件の変更に関する情報共有や経緯の把握、影響範囲を

確認するのが容易でなくなっていきます。

要件定義を支援する市販のツールもあるので、プロジェクト品質向上のために活用するのも

良いかと思います。

 

 

プロジェクトの初期段階では、決まっていない事が多く、予算化する上でのひとつのコツが

「バッファ」です。

 

予算が大きくぶれるような要件が新たに出てくる事もあれば、想定外の出来事が起こるのが

ITプロジェクトです。

 

この事をあらかじめ前提として進めるのですが、プロジェクトのフェーズ、要件の明確さ、難易度など

を考慮し、バッファを決めます。

 

重要なのは、予算に対するバッファをプロジェクトでオープンにしておくという事です。

追加の要件が出た場合、バッファの中で対応していくという事で、顧客側も予算の追加を

社内で獲得するという作業を行わなくてすみます。

バッファをマネジメントする事は、すなわち予算を管理するという意識が共通意識となります。

これはプロジェクト予算をいたずらに増加させかねない、重要度の低い要求へのけん制にもなります。

 

バッファを示す場合には、後日、バッファの中で対応するものかどうかという議論にも

なりえるので、見積り根拠を明確にする事は重要です。

 

ITプロジェクトでは、非常に重要な割に主役になる事は無い「データ移行」

プロジェクトによっては百人月を超える、データ移行だけでも一大プロジェクトになる

システム化のスコープが決められていない場合はデータ移行の範囲も決められないですが、

場合により、データ移行の複雑さ、データ精度などがシステム化のスコープを決めるケースがあります。

プロジェクトを立ち上げたばかりで、業務の変革をどのように実現するかという熱い議論をしている際

にデータ移行についての調査というのは意図して行わない限り後回しにされてしまいがちです。

データ移行は企業規模によっては、かなりやっかいなものです。

少しでもいいので、プロジェクトの初期段階で移行データの調査をしておいて、感触をつかんでおく

事が重要だと思います。

 

業務アプリケーションを導入するにあたり、現場の業務担当者

あるいは責任者にプロジェクトへ参画してもらうのは、とても重要です。

 

場合によっては「現場の意見は聞かない」というプロジェクトも存在しますが、

よほど業務に精通している方が主導している場合でないと、

「使われない」「業務負荷の高い」システムになるリスクを高めてしまいます。

 

現場の方はたいてい、自分の利用しているシステムが改善されるなら

積極的に時間を作っていきたいと考えています。

しかし、単純に時間が無い、評価の対象外、過去のITプロジェクトへのネガティブなイメージなど

様々な理由から業務側の主体的な参加を求めるのが難しい場合があります。

 

このような場合、ひとつのテクニックとして、業務側の責任者を明確にし、

プロジェクトの全体スケジュールの中で業務側のタスクを明示的に示し、他タスクとの関連を明確にする事です。

 

プロジェクトの進捗を業務責任者と共有し、業務側の遅延がプロジェクトの遅延理由になりそうな場合に、業務責任者にとってのプロジェクト関連のタスク重要度が自然と上がるはずです。

 

 

今更ですが、このタイトルが適切なのか、ちょっと悩みます。。。

 

さて、予算設定時の前提となる軸の話ですが、まず受注側も発注側も何を前提とした金額なのか明確にするということです。

これは仕様を詳細に決めるという話ではなく、大きな要件を明確にし、受注金額の前提となるものは何かを共有する事です。

例えばユーザ要求の定義を行う必要がある場合、実際にかかる工数はユーザが打ちあわせ等の時間をとれるかどうかでスケジュールに大きな影響を受けます。

また、企業によっては要件を決めるのに様々な承認行為が必要となり、企業体質がスケジュールに大きな影響を与えます。

これらの事に対しても前提として、どのようなスピード感や現場の協力を得られるかを明示的にする事は大事なことです。

 

また、後々、このあたりの事は書いていきたいと思います

 

どんなプロジェクトでもシステム導入に関連した予算枠というのは、ありますよね

システム要件も決まらないまま、一括請負をして、要件が増えて受注金額をめぐって交渉、なんて事になったら、発注者側も受注者側も気分が良いわけありませんし、たいがいプロジェクトは赤字になり、予算をけずられ、プロジェクトに関わるエンジニアが苦労するという図式ができあがります。

かといって、プロジェクトの実行判断を行う上で想定予算を出さないことには経営判断はできません。

そして一度、出た予算は一人歩きし、その予算をさらに拡大させるというのは、大抵の場合、大変なことです。社内でのプロジェクト責任者の責任問題になりかねません。

システムの要件は現場の担当者に聞くと様々な新要件があります。

これを要件の重要度を判断せずにシステム要件にすべて反映させれば、当然、予算を大幅にオーバーします。

これをコントロールするには、予算設定時の前提となる軸が必要です。

 

(続く)

どんな組織でも、あたりまえですがコミュニケーションは重要です。

ITプロジェクトでは当然のごとく、メールで情報のやりとりを行いますが、人数の多いプロジェクトで情報共有のためにメールのCCに全メンバを入れて情報発信をするというケースがありました。

情報発信しているんだから、見ていないのはあなたの責任でしょ、という雰囲気さえ感じます。

 

プロジェクトマネジメントを行う上でコミュニケーション環境を構築するのは非常に大事です。

メールで情報をやりとりするだけでなく、定期的に情報や課題を共有し、知恵を出し合うことによりコミュニケーションが円滑になり、チームとしての一体感も生まれます。

ミーティングだけでなく、コミュニケーションを活性化するために座席位置やメールの件名ルール、等様々に工夫するべき点があります。

 

アナログなコミュニケーションを日頃から行うのが何よりも重要です。

昔のお客様先の社訓にありました。

「あいさつをしよう」

大事です。

「おはようございます」言えてますか?

 

 

簡単すぎる目標も、無理だと思うようなスケジュールも人間にとってはモチベーションを高くする要素にはなりません。

がんばったらなんとかなりそう、よし、がんばろう!

くらいのスケジュールがベストです。(モチベーションを高めるという観点だけで述べると)

 

ITプロジェクトにおいて、ゆるいスケジュールというのは、あまり経験がありませんが、無理と思われるスケジュールは良く目にします。

これはプロジェクトの実行計画が法律改正、企業計画、あるいは予算等様々なプレッシャーにさらされ、決定されるからでしょう。

プロジェクトリーダーは、スケジュールを実行するための策を練り、メンバが実行可能だと信じ込ませなければなりません。リーダーについていけば、何とかなると。

実行可能だと思いこませられれば、本当に実行可能になります。

それがモチベーションの力です。

 

ITプロジェクトはフェーズが進むにつれ、新しくメンバが加わるのが常です。


新しく加わったメンバが速やかにプロジェクトの内容を理解し、パフォーマンスを発揮できるように
環境を整えるのも重要なマネジメント事項です。

プロジェクトの実行背景や経緯がわかるようにドキュメント体系、用語集を用意しておく事が大切です。
ドキュメントは共有サーバに保管し、仕掛用の個人フォルダとプロジェクトで共有するフォルダを分けるべきで、プロジェクト共有フォルダは体系だった管理を行い、何がどこに配置されているのか、アクセス権どう設定されているか等、しっかり管理を行うべきです。(特に大規模なプロジェクトでは)

初めに決めておかないと、プロジェクトがある程度進捗してからドキュメント体系を整理すると、かなり無駄な労力が必要となります。

 

いわゆる、プロジェクトを進めるための方法論

大きなシステム会社になれば、大抵独自の方法論を持っていたりするのです。

私も前に社内のメソッドづくりに参加していた事があります。

おかざりになるメソッドは意味がなく、実際にプロジェクト品質の向上や管理に活用されるものでなくてはなりません。

メソッドを創る際に良く危惧された意見は「方法論どおりやって、なぜそれをやるのか、なぜこの順番でやるのか理解しないでプロジェクトを進めるというリーダーが出てしまうのではないか」というものでした。

実際、方法論があると、プロジェクトにはそぐわない無駄な作業をスケジュール化してしまう新米リーダーがいたりします。

メソッドはGood To Have ですが、頼りすぎるのも危険です。

 

ITプロジェクトは多様な企業からの人材から構成される事が多いので、まずは「用語の定義」が最低限欲しいところですね。

 

 

システム要件・機能を決めるスピードは企業によって、まちまちです。

システム要件や機能を決めるまでに、何人もの承認が必要となったり、業務やシステムがはっきり判る人材がいなくて
はっきり決められないといった状況が発生し、要件が決まらないという状況になると、あっという間に何か月も経ってしまいます。

このような状況を避けるために、システムの要件の重要度を業務インパクトやシステム化のインパクトから判断し、
決定者、決定プロセスを明確にする事です。

どのような事項を決定するべきか、重要度はどうであるかはコンサルタントにまかせて良いと思います。
しかし、ITコンサルタントはあくまで社外の人間です。
ITコンサルタントを雇う側が、どういった事項を決めるには、どのような体制・人材が適切であるかを
決定し、調整できるとITプロジェクトは非常にスムーズな運営が可能になります。
そのため、プロジェクト内に社内人脈があり広く業務を理解している方がいると良いでしょう。


(続く)

ITコンサルタントと付き合うにあたり、何を求めているのか、明確であればあるほど、自分のニーズにあったコンサルタントと出会える可能性が高まります。

何もかも、コンサルタントまかせという姿勢ではなく、自社に足りないものが何で、何を手伝ってもらいたいのか。

 

もちろん、何から手をつけるべきか判らないというケースもあるでしょう。

だからこそ、コンサルタントを雇うのだと。

ごもっともです。

このような場合でも、経営者が何を目指しているのか、予算はどの程度なのか、許容できるリスクは?等、できる範囲で明確に伝えることです。

もちろん、優秀なコンサルタントであれば、きちっと確認すると思いますが、最初のボタンのかけ違いが、大きな無駄を生む可能性があります。

 

(続く)

 

ITコンサルタントといっても様々です。

テクノロジー面に強くアーキテクチャ設計に強いコンサルタントもいれば
業務に強くアプリケーション設計が強いコンサルタントもいます。
経営課題から経営変革とシステム化のスコープを決め、組織変革を伴う
システム導入を実行できるコンサルタントもいれば、既存のパッケージを
導入する事を主業務とするコンサルタントもいます。
近年ではホームページを作成するコンサルティングを行う人もITコンサルタントと
名乗る場合があるようです。

このように、「ITコンサルタント」は資格があるわけでもなく、名乗ったもの勝ち、
といったところも否めません。

さて、企業統合やビジネスプロセスの変革など、様々な理由から企業システムの刷新
が行われますが、このようなケースでITコンサルタントを雇われる事が多いかと思います。
プロジェクトの成果はコンサルタントによって大きく影響を受けるケースがありますが、
コンサルタントと上手の上手な付き合い方を知っておくと、プロジェクトの成功率も高くなります。

 

(続く)

リーダーに求められる、最も重要な役割のひとつは、「決定する」という事です。
決定できないリーダーの下で組織は機能しません。
ただ決定すれば良いのでなく、必要に応じて迅速に決断するのが重要です。


すべての情報が揃った後で結論を下すのは、誰でもできること。
先の見えない状況でいかに決断を行い、組織を導いていくかがリーダーに問われます。

 

私は駆け出しのプロジェクトリーダーだった頃に、様々な不確定要素の中でどうしたら良いのかわからない事がありました。
いくら考えても「正しい決断」という確信は持てない状況でしたが、その際に上司に言われた事が、私の中でずっと残っています。


「考えて決断が下せるなら一生懸命考えなさい。大事な決断は考えても結論は出ないから、そういう場合は直観で決めなさい。」

論理的であるべきコンサルタントが直観で決断を!?と思われるかもしれませんが、実はこれが非常に重要である事を今の私は理解しています。
リーダーにとって最も避けるべきは「決定しない事」です。

迷ったら、直観に頼れ!です

 


モチベーションと組織体制というのは、けっこう密接な関係があります。
プロジェクトにおいて、どのような体制をデザインするのか、プロジェクトの特徴や人材によって様々ですが、忘れずに行いたいのが各サブ組織のミッション定義です。
タスクの定義でなく、ミッションの定義というのが重要です。
プロジェクトは生き物ですから、タスクはいくらでも変化します。
人に与えられたタスクをこなすのと、ミッションを与えられて何をすべきか考え行動するのでは、おのずとモチベーションが異なります。
また、タスクが頻繁に変わることを他者の問題であるとしてしまい、モチベーションの低下を招きかねません。

ミッション定義はマトリクスな組織においては特に重要です。
ITプロジェクトでは業務単位、技術要素単位、地域単位などで組織分けが行われますが、プロジェクト規模が大きくなるとマトリクス的な組織設計をせざるをえません。
このような場合に指示系統が煩雑だとプロジェクトメンバのモチベーションは著しく低下します。
ひとりの人間が複数の人からタスクを指示するような状況でタスクのボリュームや優先度を決めてあげないと最悪です。
(よく、プロジェクトの雑務をお手伝いするヘルパーさんにありがちな状況ですが。。。)

まぁ、そこまでのケースはあまり無いでしょうが、マトリクス組織になると、お互いのチームのタスクだと思ってタスクが漏れる、もめる、等がありますが、
チームミッションを定義しておくと比較的に責任範囲、指示系統などが整理されます。

前にテレビ東京の番組「カンブリア宮殿」で見た2人の兄弟実業家

兄は小笹芳央氏(リンクアンドモチベーション 社長)
弟は小笹公也氏(オンテックス 会長)

2人とも起業し、ともに成功を収めている。

兄はモチベーションを切り口とした企業組織・採用などのコンサルティングを手掛ける企業であり、自社の社員には褒めあうカルチャーを浸透させている。

一方の弟はリフォームを行う会社でバリバリの体育会系。成果主義で社員の努力に報いる。

番組で印象的だったのが、弟の公也氏の「子供じゃないんだし、大人にモチベーション管理が必要なんて、気持ち悪い。仕事人として、あってあたりまえ」といった趣旨の発言。

そう
仕事のプロとして、モチベーションはあって、あたりまえ。

しかしながら、ITプロジェクトではモチベーション管理って必要なのが実際のところ。
特に大規模なプロジェクトになると特に重要で、パフォーマンスに大きく影響する。

P=MA なのである。

(P=Performance M=Motivation A=Ability)


モチベーションというのは個々人で異なるのはあたりまえで、そもそも「何のために仕事をするのか?」といったところから影響を受ける。
自分のキャリアパスと合わない仕事に対して前向きに捉えられるかどうか、かなり個人によって差があるが、といってマネージメントの役割がまったくないかというと、そういうわけではない

(続く)

 


 

ダメなマスタスケジュールの作り方について今日は書いてみたいと思います。

ITプロジェクトの開発フェーズで意外に良くあるパターンですが、プロジェクトリーダーがサブチームのリーダーに個々にスケジュールを作成させ、それを寄せ集めてマスタスケジュールを作ってしまう事があります。

 

このようなスケジュールの作り方をすると、各サブチームで影響しあうタスクの優先度がコントロールされずに無駄が発生する。特に大規模なプロジェクトになり、余裕のない状況になってくると個々のサブチームのリーダーが自チームの個別最適に集中してしまい、プロジェクト全体が非効率な状況に陥る事になります。

 

よく言うのですが、スケジュールには魂をこめなければなりません。

スケジュールの背景にあるシナリオ、具体的な実行イメージがあってこそ、マスタスケジュールは価値あるものとなります。

 

 

久しぶりに秋葉原に行ってきました

新人(10数年前)の頃、会社のPCのハードディスクやメモリを増設するために買い物しに来た頃とは大違いです。

今では会員登録すればタダでディスク容量がもらえる時代です。

昔は高いリーソース(メモリ、ディスク等)をいかに上手に使えるかで、ITコンサルティングの付加価値を出すことも可能だった時代でしたが、今ではメモリの使い方がわからなくてもプログラムは書けますし、時代は大きく変わってきています。

メモリなどのリソースを気にしないエンジニアが増えた(?)のか、

「これ、データ量増えたらパフォーマンスやばいんじゃない?」

という設計が実はけっこうあったりします。

そういう意味では、リソースを意識した設計は今でも非常に重要ですね。

 

このアーカイブについて

このページには、2008年6月に書かれたブログ記事が新しい順に公開されています。

次のアーカイブは2008年7月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1