若者の希望を摘み取ってはいけない②

日　本　生　涯　現　役　推　進　協　議　会　＆　　
　　　　　　NPO法人　ラ イ フ ・ ベ ン チ ャ ー ・ ク ラ ブ 　活　動　で　
　　　　　　　　　　　ご　 支　 援　 く　 だ　 さ　 る　　 会　　員　　皆　　様

どんづまりから見上げた空 ～ 我がITサバイバル年代
　　　　「私はコボラー」、 若 者 の 希 望 を 摘 み 取 っ て は い け な い ②

　　　　膨 大 な 成 果 物 が 役 に 立 っ た こ と は ほ と ん ど な い
　ベンダーは「やったことの証拠」としてドキュメントを提出し、ユーザーは「やってくれたことの証拠」としてドキュメントを受け取って安心する。検品後に行われる納品物の受け渡しはあまりにも壮大で無駄な儀式だった。

　ユーザーの立場になって改めて実感しているが、この膨大な成果物はすぐに役に立たないものになる。保守に入るとしばらくはドキュメントと実際に動いているプログラムのソースコードは１対１に対応しているが、すぐに対応関係があいまいになり、役立たずになっていく。膨大過ぎるドキュメントを維持し続けるのは難しい。

　当たり前のことだが、ベンダーは納品すれば「終了」だが、ユーザーにとっては納品後、稼働してからが「スタート」である。その「スタート」に当たり、これからシステムの成長に合わせて、きちんと「成長」し続けられるドキュメントが必要だ。分量ばかり多く、メンテナンスが不可能に近い膨大なドキュメントは必要ない。

　各工程で必要以上に作成すべき成果物を定義しても、それをきちんと作成し、維持し続けるのは難しいものだ。それに気付いた人がアジャイルを目指すのだろう。この観点は私も全面的に同意する。工程ごとのレビューを乗り越えるために作成したドキュメントを手に、次の工程に一方通行のように進み、その成果物をユーザーに提出することに疑問を感じた人もいることだろう。

　アジャイル開発では「必要なものだけを作る」という理念があり、それはとても美しいと思う。ただ、問題もある。これが通じるのは、ベンダー、ユーザー両方に「必要なもの」がきちんと分かっている人がいることが前提だ。残念ながら、そうした人はいそうでいない。

　　　　開 発 現 場 に 取 り 入 れ た い 手 法
　最近、IT業界の多重下請け制度に関する議論が活発になっている。その中で、あるSIerの偉い方の意見として面白いものがあった。

　「我々は開発プロジェクトで多重下請けを採用し、雇用の面で貢献している」。少々開き直った発言ではあるが、的を射ている。

　私自身、この業界の間口がここまで広くなければ入ることはできなかった。どんな制度でも影とともに光が差す面がある。そして私は光に導かれて、派遣SE・プログラマを経てユーザー企業のシステム担当になった。

　ここから、極めて現実的なことを書く。読む人によっては不愉快に思われる方もいるかもしれないがご勘弁を。

　IT系のマスコミに取り上げられる、輝かしいシステム構築事例は、大手のユーザー企業がほとんどである。大企業は、資金、人材とも豊富である。打つ手はいくらでもある。それでも失敗することがあるのは、私から見れば不思議でならない。

　中堅以下の企業では、当然システム開発における能力は大手ほど高くないし、SIerに対して力があるわけではない。そんな企業でシステム担当となったら、何に気を付けるべきだろうか。

　まず、優秀な技術者の確保が困難である。ほどほどの腕を持つ技術者が確保できれば上出来だろう。開発の本来の主役である業務担当者（エンドユーザー）のモチベーションも大手企業ほどには高くない。そのような状況で、自分の身を守るために、開発現場にどのような手法を取り入れるべきだろうか。

　　　　　私 の 考 え で は こ う だ
（1）経営陣に余計なクレームを入れられることなく、プロジェクトが遂行可能であること（最初からクレームを受け続けると、プロジェクトは出航した直後に難破したのも同然である）。
（2）イニシャルコストをかけることなく導入できること。
（3）ユーザーと開発者のスキルが高くなくてもなんとかプロジェクトを遂行できること。
（4）段階的に効果を実感できること（時間がたたないと効果が実感できなければ、やる気がどんどん低下していく）。
（5）最小の情報で最大の効果が得られること（なんでもかんでも管理対象にすると、当たり前であるが管理しきれなくなる）。

　このような手法が必要になる。これは、ベンダーにおいて、あまり規模は大きくないものの困難なプロジェクトのリーダーに任命されてしまった場合でも、状況はあまり変わらないかもしれない。　　　つづく