- 歩きつづける アバラ骨 折りつづける
- 昔のほんだな
2009-06-12
■案件管理のお仕事
新入社員の技術サポートで虫の息、yuripopです。新入社員を教えることから得られた知見をまとめようかな、と思ったりもしたのですが、ちょっと離れて「管理」のお仕事を紹介したいななんて思います。
なんで管理について書きたいのか
動機です。
単純に「プログラミングだけできればいい」「SIする人は要件定義だけやれ」という声を聞くと切ないからです。
ただし、わたしは個人的に、開発というお仕事においてプログラミング技術が何を差し置いても最重要だと思っていますから、その軸は絶対にぶれない、ということを念押ししてから始めたいと思います。
あと言っておきたいのは、PMP試験っぽい話はできないということです。なんでかというと、情けない話ですが教科書的な勉強が苦手なん。
「要件定義」って何？
開発管理について書こうと思ったら、触れないわけにはいかないのがコイツです。これだけで本が何冊も出るくらいだから、当然キショい部分である。というか、開発管理の泥臭さのすべてのエッセンスは「要件定義」に詰まってるのです。
さて、じゃあ「要件定義」は何をするのか。
ウォーターフォール技法におけるいわゆる工程の話ではありません。なんちゃら分析とか何図が必要とかそんなことだけではない。何をして「要件定義」と呼ぶのか。
わたしの認識は、「開発を実際に走らせるまでの期間における、お客さまと開発チームメンバーの橋渡し」です。
チームメンバーには自分も当然含まれます。たまに自分で要件定義して自分でコーディングすることもありますし、要は「何を誰がいつまでにどうやって開発するのか」を、開発スタート前に決めておくってことです。
これが管理の始まり。終わりでもある始まり。
対お客さまのお仕事
わたしの認識からいくと、要件定義には、お客さま・橋・開発チームメンバー、の三つの要素がありまして、最初はお客さま要素に関するお仕事です。おおよそ以下のような感じです。
お客さまに「ソフトウェア開発とは何か」を伝える
相手が同じ技術屋さんではない場合、「ソフトウェア」っていうのが何なのかの説明から始まります。
お客さまに「ソフトウェアのお値段」を伝える
以前単独で製造請負っぽいことをやったんですけど、価格の説明が失敗した時点で案件全部失敗みたいになった。単独だったので被害は自分だけだったので本当によかったです。それで学んだことと言えば、一般市場のお客さまは「パソコン」より高いソフトウェアを買ったことがないってことです。
また、お値段＝ソフトウェアの価値なので、たとえポジティブな意識で超低価格を申し出たとしても、最終的に技術屋さんが低く見られるだけで終わることもあるので悲しいです。
この段階でのポイントは、単純に「ソフトウェアの値段」だけを伝えるというより、チームメンバーのリソースから判断して、最低いくらもらわないと誰かの首が飛ぶ、とかまで考えておくということです。オーダーメイドのソフトウェア開発は価格先行決定の後払いで売るので実に困りますね。
ここなんとかしたいなーっていつも思います。（そうするとBPMとかにいきつく場合もあるのですが、拡散するのでまたこんど）
お客さまに、開発するには「仕様」が必要であると伝える
たいていの場合、お客さまは「仕様」って言葉に馴染みがありません。漢字変換できずに「しよう？」って言われることもあります。先にいっぱい決めておくことがあるってことを伝えます。
ちなみにここでもポイントがあって、ひとくちに「仕様」と言っても、全部の機能を先に完璧に決めるのが大事なんじゃなく、「後からでも変更可能にしたい部分」とか、「今絶対にこうでないと困る部分」とか、とにかくあらゆる要望が明確になってないと大変なことになるよ、という、大変なことになる部分も強調しつつやっていきます。
仕様と値段を決めます
やっとここまできた。ここからはウォーターフォールのアレでいいです。ただし、お客さまは「ここの入力値はゼロを含まない整数」とか絶対に言ってくれず、ちょっとマシな場合でも「年齢です」とかそういう感じなので、「お客さまから仕様を出してもらう」って思わないほうがいいと思います。そう思っていて失敗したことが何度もあります。
要するに、ヒアリングと交渉をひたすら続けるんですね。
契約書を作ります
すなわち納品物を決めるってことでもあります。
なお、契約書を作らなくて三途の川を渡りかけた経験もあります。いやな経験ばかり豊富なダメ人間ですね。
番外編
とくに同業界に売る場合、「○○万円につきキングファイル△冊分のドキュメントを納品しなければならない」みたいな血を吐くルールが適用されていることがあるので（FUUUUCK）、値段を決める前に納品物についてもしつこく確認します。
橋
お客さまはこんな感じになっているので、次は橋部分です。
メンバーのフォロー
この間に暇になったメンバーは自主的に技術を磨きまくっていると最高なんですけど、そういう感じじゃない人のほうが実際SIerのパートナーさんでは多いので（これは嫌味じゃないです、全員が向上心旺盛なんて幸せなチームは滅多にない）、何かしら課題を見つけて伝えておきます。まあお客さまの業界やあやふやなイメージ的要望が分かっていれば、勉強しておいてください、と明確に伝えることができて少しは楽です。
ちなみに「この間」もリソースは消費され続けているので、費用を計算に入れておくこと。
仕様書の調整
次の項で書きますが、お客さまとチームメンバーの意識がズレないように気を配るってことです。で、何か変更があったらメールでも最悪メモ帳でもいいから絶対に議事録を残す。
対開発チームメンバー
仕様決定直前から立ち上げ期にやることです。
仕様書を作る準備
仕様書はお客さま向けに作る、というイメージが強いと思うのですが、ガチなソフトウェア仕様書を読めるお客さまはまずいません。お客さまには全然別のもっと単純明快な、たとえばHTMLで作ったモック画面とかを渡して説明して、仕様書は参考程度にすることすらあります。
（ちなみに、これはきっと「正しい」やり方ではないのでしょうけど、開発ワールドが一気に10年ぶん進化したりはなかなかしないので、今この時点でできる最良のことをやろうとするのがクールだと思うんです）
まあチームメンバー向けの仕様書はガチってことで、「これだけ見たら開発を始められる（気がしてくる）」的なものを作ろうとします。
アーキテクチャの選定や性能要件の整理
このブログで性能の話をしたときにもちょっと触れたのですが、フレームワークやデータベース、あるいはバージョン管理ツールまで含むアーキテクチャの選定は、管理する側がやるか、あるいは自分を含む開発チームメンバー全員でやるのが最適だと思います。これはもう一箇所に集まって何時間か議論する感じです。
性能要件についても同じで、お客さま説明と説得とあと要望の整理が終わっているはずなので、目標値を決めます。これはここでは詳しく書きませんけど「品質管理」の土台になります。
お金のことも共有する
お金っていうと生々しいですけど、要するに納期と使えるリソースの説明、情報共有を行います。期間から見てあまりにも無理なアーキテクチャを選定してた場合は待ったをかけます。
よく言われることですけど、もらったお金以上の開発をしようとしたらその先に待っているのは地獄の行進なので、お金の範囲内でできるかどうかを見極めます。
もうホント心から思う、これができない管理者と一緒に仕事はしたくない。だから、自分がそうならないように、トレンド技術とか全部100%書けるようになるかどうかはさておき、幅広く知っておくということを心がけています。
ただ、お金に見合うアーキテクチャ選定なんかは、能力の高い技術者がメンバーにいる場合、まるっと任せてしまうことももちろん可能です。これを専門にやってる人がITアーキテクトと呼ばれているとか理想ですね。ということは、チームメンバーの力量を正確に測る能力も必要で、まあそういうのが完璧にできればいいんですが、まったく難しい部分です。完璧な管理者なんかこの世にいるんかな……と思って絶望したりするのもこの時期。
スケジュールを決めて管理の仕方と併せて共有する
上と同時進行になりますが、開発スケジュールを決めます。ウォーターフォールとか言い出すのはここまで来てからじゃないかなーと最近は思っています。というより、○○技法、を完全に再現したら絶対にお客さまの納得いく価格でソフトウェアを作ることは不可能だ、とかまで思っている。
とはいえ、納品物とお金とリソース（メンバーの人数や力量など）のバランスを見ながら、わりと詳細なスケジュールをここで決めてしまいます。
で、これが重要なんだけど、「スケジュールの管理の仕方」も話し合いながら決めていきます。「ひとつの機能を『未着手』『着手○%』『完了』の3種類の段階に分け、すべての機能が『完了』になった時点で終了とします」「スケジュールの共有には残念ですが今回もExcelを使います」とかいう感じです。ここら辺のノウハウも管理者のセンスが如実に出て嫌ですね。一定以上の規模になると、どんなタスク管理ツールを試用してても結局今のところExcelに落ち着いちゃう……。
開発GOサインを出す
仕様書のバージョン管理とお客さまとの定例意識確認なんかを除けば、「要件定義」ほぼ終了。ウォーターフォールに限らず、要件定義だけは切り出してマイルストーンを置いておいたほうが楽かなーと経験上思っています。
というわけで
ここまでが「プログラミング」以前の管理者的なお仕事まとめです。この過程を「要件定義」とわたしは認識していて、今も頑張って改善方法とか探している感じ。企業の体質によってはガチで決まってたりもするけど、決まってない場合は自分なりに段取りとか考えていかないといけないので、要件定義のお仕事だけでも奥が深すぎるなと常々思っています。
ちなみに、お金の話はまだひとりでは全然決められないし（※例外的に単独製造請負をやったことがあるので一応思うところを言うくらいです……）、アーキテクチャの選定もトリッキー過ぎてたいてい却下だし、まだまだダメだなあというのが実感。努力はいつか実になるものだろうか。信じるしかない。
もし気が向いたらこの先の開発管理の仕事とか、あるいはこれより前の提案のとことかも紹介するかもしれませんが、今日はここまで!
