要件定義

今日のテーマは要件定義について。四字熟語ではカッコよく(?)見えるのですが、実際はかなり奥が深いものだと改めて思い知らされました。
現在はなぜかインフラ構築系のエンジニアになってしまいましたが、基本的にはインフラの運用エンジニアです。(主にメンテナンスや日々の監視、維持のための管理がお仕事になります。)
したがって、依頼元よりヒアリングを行う機会というのはこれまで限られていました。で、配置転換とともにそういう機会も増えてきまして、当然のことながら、経験不足によりことごとく失敗しているというのが現状です。
もともと、あまり要件定義っていうのをしっかりやっていなかったような感じがあるので、ノウハウも少ないため改善していくのが難しいのですが、このところヒントみたいなものをつかんだような気がします。
まず、プロジェクトの概要を把握する。仕様固めとインフラ構築が同時に走るのがうちの会社のやり方のようですので、サービス的にどういうものなのかをしっかり把握しておかないと、仕様も適当で納期は明日までとかっていう状況下に陥るような気がします。
次に、技術的な細部(当然ポイントを押さえてということになりますが)を、詰めていくことになるのですが、「なにがしたい」→「こうすればよい」までのプロセスには相当量の情報が必要となります。この情報の引き出し方がとっても難しい。きちんと仕様書を作って、ほとんど固まってからインフラ構築の依頼をしてきてくれればいいのですが、そうじゃない場合が9割。で、ここでのポイントは、少しずつ(人間心理的にたくさん質問されると後回しにしたくなるので)、分かりやすい形式(選択式など)でということなのかなぁ・・・。
ここで行き詰まるのが、これだと機材の購入が発生する場合の動きが遅くなるということ。うちの上司は「モノは圧力をかければ手に入る」という訳の分からん持論の持ち主なので、それでもオッケーになってしまうんですよね。だからトラブルが絶えない。ある程度まで、「無理を聞く」のはありだと思いますが、万事それではいけないでしょう。デリバリーの時期が延期できないという事情もよく分かりますが、万事が万事ではありえないでしょう。

で、今やっているプロジェクトも当然その危険性が高いわけでして。以前、ソフトウェア工学とか学んでましたが、開発中の仕様変更で一番避けるべきところじゃないのかなぁ。というか、ソフトウェア開発の現場からは大分遠ざかったので、現状どんな手法が流行っているかはよく分からないのですけど、もうちょっとなんとかならないのかなぁというのが正直な感想。スピード勝負だとどうしようもないのかな。

最近思うのは、どうしようもなくなってから降ってくる仕事ばっかりだなぁということ。やれやれ・・・たまにはゆとりのある進行をして欲しいものです。