不変的な技術力を持つこと

筆者は、テレビドラマ「JIN～任～」にはまっていますが、みなさんは観たことがあるでしょうか。ドラマの内容は、主人公の医者「任」が江戸時代の幕末にタイムスリップしてしまい、その時代で色々な病気に立ち向かうといったストーリーです。まだ医療技術の発達していない時代なので、メスもなければ、点滴すらない。一人の医師が時代を変えてしまうかもしれないジレンマを持ちながら、目の前の人を救う為に様々な難病に立ち向かうのは痛快です。

このドラマを観ていて、「⁠エンジニアが過去にタイムスリップしてしまったら、何ができるのだろうか？」と思いました。

筆者が考えるに、現在のエンジニアが江戸時代の幕末はもとより昭和30年代に行っても役に立つ知識は少なく、恐らく何もできずにいるでしょう。それだけ、技術革新のスピードが速い業界であり、技術力に対する価値は陳腐化しやすいと思います。急速に発展を続けるIT業界において、「⁠いつの時代でも通用する技術力を持つ」というのは想像以上に厳しいものです。

今回は、プロである事の自負が招くジレンマについて考えたいと思います。

お客様からの期待

筆者が数年前に経験したプロジェクトは、同業他社のシステム構築経験を買われて、システム開発だけでなく、業務改善のパートナーのような位置づけを期待されました。

本来は経営コンサルタントや業務コンサルタントが行う仕事ですが、このようなケースは多くあります。

「要求したものをただ単に作るだけならソフトハウスにプログラム開発を頼む。貴方に頼むのは経験や他社事例を元にどうしたら改善できるかのリーディングを期待しているからだ」「⁠一般的にヨソはどのようにしているの？」「⁠システムエンジニアは業務まで踏み込んで考えるのが仕事だろう」等をいわれた経験をお持ちの方も多いでしょう。

またエンジニアとしては、そこまで踏み込んで提案することで「この人はすごい」と思われたいですし、業務改善に携わる事で効果を得たときの満足感や達成感（モチベーション）はより大きなものとなります。しかし、このような期待を受けて受注した案件は大変なプレッシャーを感じます。お客様の業務の無駄を発見し、的確な提案をする事は大変困難であり、間違ったことを提案し実行した責任もとれないからです。

コンサルタントとの大きな違いは、システム稼動までプロジェクトに関わることであり、理想と現実のギャップを埋めないといけません。最初の段階から理想と現実のギャップを小さくしようとするのがエンジニアの特性です（広げた風呂敷を畳むような作業です⁠）⁠。

実際、今回取り上げるプロジェクトは、予算と大まかな内容は決まった上で、設計作業で業務運用をどのようにすべきかを検討していきましたが、業務運用面での利便性について次々と課題があがっていきました。

何とかしたい

業務課題を検討していくと、様々な部署の人から不満があがります。ある部署は「それは自分の仕事ではない」といい、別の部署では「今まで通りの業務運用が良い」という。「⁠そんなのお客様で調整してよ」と思いますが、これもエンジニアの仕事です。

筆者「今回の費用と範囲では、そこまでのことはできませんよ」
お客様「ではどうやって運用すれば良いのですか？こんなのでは、今より効率が落ちてしまいます。システムを導入する意味がありません」
筆者「それでは、こんな機能をつけるので、これで何とか運用してください」
お客様「では、こんなケースはどうすればいいのですか？」
筆者「それは、どの程度の頻度で発生することなんですか？イレギュラーなことなら我慢してください」

こんなやり取りを繰り返しながら、一つずつ課題を整理していきました。「⁠それでは、このような機能を付ける」という提案[1]も、システム全体にどの程度影響を与えるのかを考えながらの発言です。

常に妥協点を探っていきましたが、筆者が考えても「お客様がおっしゃる通り！」と思う機能は、お客様からの要望を積極的に取り入れ解決しました。お客様からも上手くリーディングしているとの評価を得ることができ、この時点で、プロジェクトは80％完了したとすら思っていました。

致命的な問題が発生

しかし、システム開発の終盤に差し掛かり、大きな問題が発生しました。プロジェクトメンバーからの報告では、お客様との打ち合わせの中で、追加した機能の一部が想定以上に実現が難しいというのです。プロジェクトマネージャ及び仕様統括は筆者でしたから、すべての責任は筆者にありました。

仕様検討をしていくなかで、他の機能を諦めていただく変わりに取り込んだ機能でしたが、他の機能と矛盾が発生する可能性を見落としていたのです。今更、「⁠この機能ができません」とは、とてもじゃないがいえない…。どちらかというと設計ミスだ…。頭の中で、上手くできる方法を考えながらも、データベースの構造を大きく変えないと対応できない事は明白でした。

その後、社内で対策会議を行いましたが、営業も上長も契約範囲外だから「断ってこい」でした。納期も逼迫し、開発費用もギリギリとなっていたため、当然の結果でした。

この仕様を引き受けるのではなかったと後悔しましたが、どうすることもできませんでした。「プロ」として期待され、期待にこたえようとした結果、知らず知らずのうちに何とかしようとしすぎて難易度に気づかなかったのです。

コトの結末

結論からいうと、このプロジェクトは、失敗に終りました。設計の一部に欠陥が見つかり、対策するためにはデータベース構造の見直しを行う必要がありましたが、根幹の部分に影響を与える変更であり、多くのプログラムの仕様変更を伴ったからです。

また、お客様はシステムの事は「シロウト」でしたから内部構造や前提条件の説明をしても納得していただけませんでした。

エンジニアの立ち位置

今回は、プロジェクトマネージャの立場から事例を紹介しましたが、同様のことは様々な立場であるのではないでしょうか。

例えば、プログラム開発を行う際に、プログラム構造設計を任されたが、どうにもならない矛盾を引き起こし、プログラムコードをすべて捨ててしまった経験、システム移行の段階になって、どうやっても移行ができずに、お客様にお願いしてハンドでデータ移行を御願いした経験等をお持ちの方も多いでしょう。

お客様の立場に立ち、プロとしての自負を持って業務課題を解決していく事は理想ですし、そのようなエンジニアになりたいと思います。しかし、今回紹介したようなトラブルが多い事も事実です。プロ中のプロになるためには、「⁠お客様の立場に立ち、プロとしての自負を持って業務課題を解決していくこと」に加えて、「⁠一歩下がって客観的にモノゴトを考えること」が重要です。

いつも同じような失敗をしてしまうエンジニアが周りにはいるかもしれません。なお、お客様の立場に踏み込まずに一歩下がると、「⁠やる気が少ない」と見なされる可能性もあるので、注意が必要です。

自分自身の思考について「クセ」を分析・理解し、プロとしての立ち位置を意識してみてはいかがでしょうか。