保守開発の人員固定化のメリット／デメリット

最近、久しぶりにある保守開発に係わりました。

保守開発は、新規サブシステムの開発、システムの刷新や大規模リニューアル等とは異なり、相当に短期間での対応になります。
また、その短期間であるという特徴などから、意図的か否かにかかわらず、そのメンバー構成が固定化する場合が多くあります。


この「固定化する／しない」については、双方にメリット／デメリットがあると思われます。


固定化の期待メリットとしては、

①　開発のＱＣＤが一定の範囲に収まる可能性が高い。

②　お客様に安心感を与えることができる。

③　開発組織（情報システム部門、構築ベンダー）側の管理コストが低減できる。

などがあげられるでしょうか？


しかし、このメリットは、（当然のことですが）担当者の状態が良いことが前提条件になると思われます。

例えば、そもそもお客様のウケが良くない、他開発案件と兼務すなければならない、などなどの場合、それらの期待メリットが得られず、逆にデメリットとなることもあるようです。


よって、やはり目指すべきは、固定化しなくても良い体制・仕組みを持つことだと、私は考えます。


固定化しない場合のメリットとしては、

①　開発組織（情報システム部門、構築ベンダー）側の負荷平準化が図られる

②　お客様に対して、新たな視点を与える機会となる。

③　開発者の成長につながる。

などがあげられるでしょうか？


そこで、課題となるのが、

開発のＱＣＤを担保するための管理体制・仕組みなどを、高コストにならないように構築・運用することだと考えられます。


そのための方策としては、保守開発独自の標準プロセス構築が必須であると、私は思っています。

既に取り組み済で効果を上げている組織も多いと思われますが、中小レベルのＳＩｅｒの場合には、まだ場当たり的な対応が多いと思います。

そのあたりの取り組みを実施しようと、今、思っているところです。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項

利用ユーザーへの教育・サポートの重要性

ごく稀に、システム利用ユーザーの認識誤りにより、大量の誤ったデーターの登録がなされてしまった、という状況に遭遇してしまう場合があります。
そのリカバリーはたいへんな場合が多く、お客様ご自身で実施される場合があれば、情報システム部門、保守サポートベンダーなどが対応する場合もあります。


利用ミスを招く原因には、何があるでしょうか？

① システムの操作が分かりにくい
② 入力・登録内容をチェックする仕組みが不足している
③ システム利用者への教育やサポートが不足している。

概ね、このようなところでしょうか？


①の「システムの操作が分かりにくい」については、
ユーザーの慣れに期待し過ぎず、やはり親切なユーザーインターフェースが求められと思います。

ただし、全ての利用者に「馴染む」には、ある程度の時間と改修等が必要となる場合もあります。


②の「入力・登録内容をチェックする仕組みが不足している」については、
設計フェーズにおいて、利用シーンをイメージしながら、お客様と十分に認識合わせすることが必要です。

ただし、あまりチェックをキツくし過ぎますと、運用の柔軟性や操作のスピード感などが悪くなるため、そのバランスを考慮することも大切になります。


③の「システム利用者への教育やサポートが不足している」については、
これは私は大切だと思っています。
なぜならば、これを軽視される場合があるからです。

私は、システムを導入または刷新する場合、利用者へのシステム説明会、操作説明会などは極力実施すべきだと考えています。
その説明会等で、参加者から貴重な意見が出される場合もあり、それにより、ユーザーインターフェースや入力チェックの仕組みに関する軽微な改修の必要性が明らかになる場合もあります。

そして、利用開後のフォロー体制も重要です。
サポート体制を明確に構築・案内することが大切ですし、また、インバウンドのみならず、積極的に利用状況をモニタリングして早期に問題を発見することが大切と思います。


利用ユーザーへの教育・サポートは、システムへの満足度に影響する重要事項であり、
それを省略したり、手を抜いたりすることは止めるべきであると、私は考えます。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項

　システム操作研修を定義する
　ユーザーインターフェースの重要性

仕様凍結と仕様変更のバランス

「仕様凍結」という言葉があります。
これは、発注者とシステム開発者と間で、システム仕様を確定させることです。

仕様凍結は、とても大切であると言われます。
仕様が確定しないまま開発が進むと、深刻な手戻り等が発生し易く、それによりシステム開発のＱＣＤが悪化するからであると、私は認識しています。

そのような考え方に、私も基本的には同感であり、同調しています。


私は、ユーザー部門・お客様と構築ベンダーとの間で、仕様凍結を２回設けます。

１回目は、要求仕様の凍結。

２回目は、基本設計の凍結。

この仕様凍結があることをご認識いただくことで、特にユーザー部門やお客様が、要求定義フェーズと基本設計フェーズに真剣に取り組んでいただくことが期待できます。
よって、システム開発終盤での大幅な認識の相違等の発生リスクが低減されます。
また、もう少し前向きな表現で言いますと、ＱＣＤのバランスのとれたシステム開発が実施され、プロジェクトの成功確率が向上するものと考えられます。

よって仕様凍結は、システム構築プロジェクトにおいて、欠くことができない実施事項と言えます。



それを前提とした上でですが、

一方では、仕様変更が必要な時には、柔軟に対応していくことも必要です。

例えば、ユーザー部門やお客様の環境の変化に極力対応していくことは大切なことと考えられます。
凍結された仕様どおりに開発しても、業務要求に変化が生じてしまっているため、使えないシステムになってしまう、という事態も（当然のことですが）避けなければなりません。

また、凍結された仕様に誤りがある場合もあります。
ユーザー部門・お客様の受入テスト時または運用テスト時にそれが明らかになり、残り期間の無い中でお客様の感情も高まり易く、激しいやり取りの末、仕様変更せざるを得ない状況になる場合もあります。
このとき、ユーザー部門・お客様側とシステム開発側とも、不満を抱くことになります。


それらの問題を解決するためには、

プロジェクトの予備（期間、コスト）を保持しておくことと、
テスト期間前半でのユーザー部門・お客様の確認機会を設けることが有効だと、私は考えています。


予備の保持については、言うまでもないと思います。
しかし、ユーザー部門・お客様からの短期開発要請、低価格要請は強まるばかりで、十分な事前検討もできず、予備もほとんど確保できない、という状況が増えているような印象を受けています。

私は、ある程度の予備を保持することは、ユーザー部門やお客様にとって、必ずメリットがあることと思っています。


また、テスト期間前半におけるユーザー部門・お客様の確認機会についてですが、
いろいろ難しい場合も多々ありますが、
私は、ソフトウェア結合テストまたはソフトウェア総合テストの終盤において、ユーザー部門・お客様に出来上がりのソフトウェアをご確認いただくことがたいへん有効であると考えています。

これにより、仕様凍結時点までに発生した、発見し辛いミスや認識の相違が明らかになる場合がありますし、また、環境変化により、このままの仕様では問題があること等も早めに気づき易くなります。

それらの課題について、データーベース構造に影響を与えない範囲での解決策を提示し、早めのタイミングで予備を利用して対応していくことで、プロジェクトのＱＣＤが維持でき、お客様満足の向上にもつながると、私は考えています。


とても一般的で当然のことを記載していると思われるかもしれませんが、
仕様凍結と仕様変更の両方に対応していくことはとても重要であり、その実施を確保する仕組みをプロジェクト計画に盛り込み実践することはプロジェクトの成功要因の一つであると、私は最近、再認識したところです。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項

文書化の精度とコミュニケーション

最近、
例えば、要求定義書、基本設計書などは、それそのものの内容はもちろん大切ですが、
文書化された記載内容や記載内容のフォローが大切であると、あらためて感じているところです。


これは、文書化技法など高度？な話ではありません。

例えば、ある情報項目に（注１）と文書に記載した際、
そのまま（注１）と記載された画面が作成されたり、注意書きのコメントがそのまま画面内に記載されたりと、あまりレベルの高くない分類の問題についてです。


開発規模と人員、組織階層との関係で、プロジェクトリーダー自身が、プロジェクトメンバーに要求仕様書や設計書に記載されている内容の意図や詳細を説明できない場合が多くります。

プログラマーは、与えられた文書をインプット情報の中心としてプログラムを製造します。
その文書に分かりづらい記載があったり、また他ページとは異なるルールで記載されている箇所があれば、その意図は伝わらないようです。


ただし、私としては、それら文書の精度を上げることに更に注力するというより、それらを補うためのタスクやコミニュケーションをしっかりと計画し実行することが大切であるように感じます。

具体的には、ドキュメントのレビュー、定例ミーティングなどが該当します。


これ以上の記載は省略しますが、
開発期間が短期であるほど、作成可能な文書類のボリュームと精度には限界があるため、それを補う仕組みをプロジェクト計画に組み込む必要性が高まると、私はあらためて思っているところです。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項

チームワークを高める

最近、あるプロジェクトの「チームワーク」が良くなってきたと感じています。
今まで悪かったというわけではなく、そのチームワークの良さが体感できるようになってきた、という状況です。

システム構築プロジェクトには、さまざまな立場・役割の方々が関係します。

お客様、そしてそのお客様の中にも、いろいろな役割の方がいます。
そして構築ベンダーやその協力会社なども同じで、いろいろな役割のメンバーがいます。


この「チームワーク」が良い状態について、今まで考えたことが無かったのですが、
今、メンバーの行動を見て感じていることは、

・プロジェクトの目標や特徴を常に意識しながら判断できている。
・自分の業務範囲に責任感とやる気を抱いている。
・役割分担のグレーゾーンについても、指示された仕事を積極的にこなしている。
・認識の相違があった事項に解決に対しても、積極的に対応している。
・コミュニケーションがスムーズにとれている。

という特徴でしょうか？

いずれにしても、責任回避のために見て見ぬふりをしたり、責任の擦り付け合いをするような状況は見受けられません。


それについて、私が気をつけていることも少し影響しているのかな？と感じています。

その気をつけていることとは、あらためて考えて見ますと、

・プロジェクトリーダー自身が最終的に責任があることを明言する。
・メンバーからの積極的な提案を歓迎する。
・失敗に怒らない。責任追求をしない。（そうすると悪い情報が正確に把握できない）
・メンバーが期待以上の行動をしてくれた場合、素直に「ありがとう」という。
・また、タスクのＱＣＤを守った場合にも、素直に「ありがとう」という。

などでしょうか？


過去の「協力会社を信頼する」という記事でも類似のことを記載しましたが、
（お客様や協力会社を含めたプロジェクトメンバーとの役割分担が契約・計画に記述され、且つ、認識合わせがなされていることは大前提ですが。）

プロジェクトは「協働」の場であり「信頼」がないと成功は無い、と私は思っています。
そのような思いでプロジェクトをマネジメントしていけば、さまざまな問題発生時にメンバーがベストを尽くし、要求以上の成果を上げてくれることを、私は今までの経験から信じています。


今、「今回のプロジェクトが成功する」と確信をしつつ、
そのプロジェクトを必ず成功させなければならないという責任をあらためて感じ、
そして、その責任を果たすことができた時に「あなたのおかげでプロジェクトが成功で終わりました。ありがとう。」と、プロジェクトメンバーに声をかけることを楽しみにしています。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項

　協力会社を信頼する
　効果的に組織が機能する（協働システム化する）条件