研究といいつつ、客観的評価が無いのはBlogだからさ。
少しずつ、Blogの書き方に慣れてきたよワタシ。
さて、また以下の参考図書を利用しながら、考えてみんとす。
SIと呼ばれるサービスの分解
サービスを知るには、サービスのプロセスを分解する必要があるそうな。というわけで、SIの中でも分解しやすいウォーターフォールモデルでやってみた。
- 基礎検討・要件定義
- 基本設計
- 詳細設計
- コーディング
- 単体テスト
- 自システム内連携テスト
- EndToEndテスト＋ユーザテスト
- 本番環境を利用したテスト
- 移行作業
- サービスイン
すると、いわゆるV字モデルでいう下層部については、コモディティ化されやすい箇所となる。
レベル分けしてみるとこんな感じ。
- レベル１：３，４、（５）
- レベル２：２，（６、７）
- レベル３：１、（８、９、１０）
で、ここで前回学んだサービスの特性を踏まえて、考えてみると重要な箇所が見えてくる。
- サービスにはカタチがない → 見えない → 可視化（成果物）による価値提供が必要
- サービスは生産と消費が同時 → 在庫できない → メンバのスキル重要（※1)
- サービスは個別化 → お客様合わせ → 要件定義で、いかにお客様に役立てるか
- サービスはお客様と役割分担 → 共同作業 → SIerは御用聞きでは駄目。
※1、メンバのスキルは結構、現状の課題のような気がするので、重要な課題があるという仮説に基づいて、考えてみんとす。
要件定義の現状
というわけで、お客様に対するサービスとして重要なのは「１．要件定義」になってきます。ある意味、当たり前の話。
ところが、要件定義の開発プロセスは後続作業に対して、イマイチ標準化しきれていないように見える。個人的に感じる問題点を以下のとおり。
- 要件定義のプロセスの書物や資料はあるが、プロセスが重い
- ユースケースとか、書きにくすぎ。表形式でとレーザビリティマトリクスの要件定義項目に記載すればいいやん。
- ビジネスフローを描けるユーザーなんて、そんなにいない
- ついでにいうと、システム化要件をあるべき論でまとめらられない
- 要件定義のWBSを描けるスキルを持った人材がシステム部にいない
- システム部に、そんなスキルフルな中の人なんていない。
ついでに言うと、ベンダが参加するにしても要件定義にかけるコストが少なくて、基礎検討不足のまま突き進み、本開発の案件で高リスクの課題が残ったままのところが多い。いわゆる、安物買いの銭失い状態。アフォですか。
そんな状況だから、
- システムの要件定義について知識不足なユーザー部
- そんなユーザー部に振り回されるシステム部
- なんとかしようと思っても、あるべき論が重すぎて成果物・WBS未定義のまま進んでしまう
- ユーザーより弱い立場といった体制なので、要件が収束に対して強権を発動できない
- そして、（崩壊したという悪い噂という意味で）伝説へ
ちなみに、筆者は要件定義をシステム部に作らせておいて、作成者だけユーザー部にするという恐ろしい政治の現場を見たことがある。くわばら、くわばら。
要件定義局面での生産性を上げる方法
で、愚痴を言っても仕方が無いので、解決案として今考えていることをつらつらと。まずは現状の課題を、少しまとめてみた。
- 要件定義に対してまとめるフレームワークがない/有効活用できていない
- 要件定義に対して、あるべき論はわかるが実施できるメンバーがいない
- メンバーがいないのは、スキルが無い、時間が足りない、コストが足りないなどによる
この課題に対してできること（=我々のサービス）は、
- お客様に合わせて、要件定義のあるべき論をもっと、簡素化する（フレームワーク化）
とりわけ、「お客様に合わせて」というのがミソで、お客さまごとに案件規模や求められる品質レベルなど要件の品質特性みたいなものが変わると思っていて、それによって、要件定義の成果物として必要最小限なものが選ばれるんじゃないかな、と思うわけです。
この辺はリスク予測における「隕石が振ってきたら問題」と似ていて、「役立つ可能性の低いもの」を含めた全成果物をつくるのは現実的じゃないよねー、という話。
余談
あれ、フレームワーク作成とか簡素化って、コンサルタントがやっているサービスじゃなかったっけ？
じゃぁ、なんでコンサルタントって雇われてないんだ、私の現場？
しかも、コンサルタントの業界は飽和状態とか聞いたことあるし、なんでだ？
現状分析してもいいんだけど、これはBlogで書きづらいので、個人的なメモとして残しておこう。
ではまた。
