システム開発成功へのセカンドオピニオン

万一のことも考えておかなければならない。サービスインしたのであるが、箸にも棒にも引っかからないような状態でのサービスインになってしまった時のことである。サービスイン完了と判断するのの全く逆さのことである。特に、システムの乗換え、リニューアルの時にはより気をつけて条件を設定する必要がある。
続きを読む

実はこれが出来ていないことが多いと思う。実際、私もシステム企画、設計側にいた時には、これが漏れていたことが多いと思う。

サービスイン日を迎えて、ユーザーが動き始めると大体の場合、ヘルプデスクがパンクし、トラブルが発生し、なんとか対処しながら日々が過ぎていく。そして、いつの日かヘルプデスクも平穏になり、トラブルも収まりを見せる。で、それがサービスイン完了と言えるのか。
続きを読む

サービスイン後は、状況の確認が必要である。次のような理由からである。

• 本当にシステムが運用されているのかの確認


• トラブルが起きているのかどうかの判断材料


• パフォーマンス調整

続きを読む

前の続きである。今回はヘルプデスクである。ヘルプデスクは人数によって大掛かりにする必要がある場合もあれば、こじんまりで十分な場合もある。とはいえ、大きさに関わらず、やることは似たり寄ったりである。
コンタクトセンター（コールセンター）的なノウハウが必要に思われるが、それほど高度でなくても構わない。ＣＴＩなんて導入する必要はないのであるから、そんなに難しくはない。しかし、気付かないか、やる必要がないと思ってい
るパターンも見られる。
続きを読む

機能というのは、純粋に機能を考えてしまうものである。だから、システムがリリースになった後に、またはリリースが直前に迫り、移行が始まる際に、

「こんな機能、運用できない」

ということに陥る。そういうものである。だから、要求定義時から運用をきちんと組み込んでおく必要があるのである。

そのためには、ユースケース記述やペーパープロトタイピングが有効である。機能を文字面や口頭ベースで伝えて定義したつもりになっていると、運用が回らないのである。気をつけなければ、大変なことになる。

ここではリリースとか、GoLiveという言葉を使わず、ユーザー側の視点からシステムの使用開始をサービスインと呼ぶ。

日経コンピュータにプロジェクト管理系の連載があるのだが、2006年４月の何回かがサービスイン前後の話であった。まさにサービスイン前に考えなければならないことという回もあった。

私が普段、サービスイン前後にやっていること、支援時に指摘していることと比較してみるとカバー率が高い。私のやっていることは世間一般に照らしてほぼ正しいということがわかった。

続きを読む

痛感する。プロジェクトマネージャは人間性なんだと。
プロジェクトマネージャの仕事で最大のものは何かと考えると、それは

「メンバーのために、いかに働きやすい環境を整えるか」

ではないかと思う。そのためには、雑用のような空調の調整もあれば、叱咤激励する仕事もあれば、鼓舞する役割もあれば、、、、ほとんどその全てが人間性に通じてしまうように思う。

「これやって置けよ。納期遅れているんだから」とプロジェクトマネージャに言われて、「そうだな、やっておかなくちゃな」と思うメンバーは少ない。メンバーは忙しいのだ。

「これ、どうなってる？　ちょっと納期が遅れているみたいだね。どうしてかな。○○の作業にも影響が出そうだから、早めに片付けて欲しいんだけど、いつ頃ならできるかな。もし作業に支障が出るようなら、何をすればできそう？」などと、やさしく話しかけて欲しいものだ。

そういわれれば、「あれとこれを少し優先順位を下げもらえれば、できそうです。またはこの作業なら□□さんでもできると思うのですが、調整できませんでしょうか」とでもメンバーも言ってみたくなるものである。

どうだろうか。そういうプロジェクトマネージャを選びたいと思うのは私だけだろうか。甘い！というご意見もあろうかと思います。甘んじてお受けします。

今回はちょっと気になったことを書いておこうと思う。あるお客様で移行作業中のことである。移行作業が膨大になってしまい、大変な作業になったということである。その担当者がおっしゃるには、一番の原因は、

「旧システムのデータの整備がきちんと終わっていないままに、移行作業を始めたため」

と分析している。これはまさに旧システムの遺産である。これができずに挫折をする例というもの聞く。しかし、前向きに捉えたい。その整備ができていないからこそ、新しいシステムへ移行する際に大掃除ができるのだと。

時に、移行データそのものが決まらなかったり、本システムの仕様がころころ変更になりながらの移行作業となったり、移行する期間が非常に短かったりといろいろな移行時の問題はある。プロジェクトを進める際、どうしても開発にだけ目が行く傾向があるが、こうした移行の問題というのをクリアする担当者の縁の下の力持ちをきちんと認めてあげたい。

期間が空きましたが、まずＩについて考えましょう。

ＩはInputのＩですが、要はシステムというのは結局のところ、何か入力がないと動きません。だから、これがことの始まりなのです。これを意識せずに、処理のことやアウトプットのことばかり考えてもいけません。

一方で、欲しいアウトプットからインプットを考えるという方法もあります。これはアウトプットの時にしましょう。

さて、インプットですが、今あるものをかき集めましょう。そして、これから入力できそうなものもかき集めましょう。取捨選択は後でいいのです。まず、運用や負荷、制約条件などをすべて排除してかき集めてください。これは比較的簡単な作業でしょう。自分がどんな情報をコンピュータに提供できるのかを考えればいいだけです。

日々発生している情報を付箋紙にでも書きだしてください。そして、それらをグループ化して置いてください。模造紙か何かに貼り付けて見えるところへ貼っておいてください。これでまずはＯＫです。十分です。

要求定義って、名前も難しいですし、やることもなんだか難しそう。実際、大掛かりなシステムですとかなりの時間をかけてやることになります。
では、小さなシステムのときはやらなくて良いのかというとそうでもないと思うのです。
やはり、いったいわないの論争などを避けてきちんとビジネスを進めるために、やりましょう。
でも難しいことはしたくないですね。だって、小さなシステムなんですから。ということで、ひとつ簡単なものをおすすめします。それは「ISOP」です。

Ｉ：input　入力を明らかにする
Ｓ：stock　保存されたデータを明らかにする
Ｏ：Output 出力を明らかにする
Ｐ：Procedure　プロセスを明らかにする

この４つを調べれば良いのです。具体的なやり方はまた別途。