« タコヤキ業務にタコヤキテーブルは必要か | トップページ | ALTER文の自動生成機能 »

2016.11.04

開発手法と「クリティカル・スキル」

 開発プロジェクトというものは、常に何かが足りないものだ。それは予算だったり時間だったり要員だったりするが、それでも粛々と進めていかねばならない。そのときに大事なことは「限られたリソースをどんな優先順位で何に割り振るか」である。開発手法はその判断をガイドしてくれるものでなければならない。

 その意味で、出来の悪い手法は「このプロジェクトを成功させるためにやるべきことは、アレとコレとアレとコレとアレとコレとアレとコレである」と、出来の悪いコンサルタントのように饒舌である。クライアントとしては「それを全部やれるなら苦労はない。この制約された状況で我々が優先的に進めるべきことは何なのか」を知りたいのであって、「アレもコレも」としかガイドできないのでは困る。むしろ、「重要でないこと」をその根拠とともに示してくれるようであってほしい。

 業務システム開発向けの手法にはいろいろあるが、いくつかの手法ごとの「最優先されるべきモノ(作業成果物)」を整理すると次のようになる。

開発手法 最優先されるべきモノ クリティカル・スキル
アジャイル手法 動くソフトウエア プログラミングスキル
データ中心手法 データモデル データモデリングスキル
ウォーターフォール 包括的ドキュメント ドキュメンテーションスキル
ドメイン駆動 ドメインモデル ドメインモデリングスキル

 「最優先されるべきモノ」を明確にすれば、それを生み出すためにボトルネックとなるスキルもわかる(これを「クリティカル・スキル」と呼んでおく)。さまざまな制約があっても、優れたクリティカル・スキルを確保することが優先されなければいけない。そのためには、クリティカル・スキル以外については優れていなくてもいいということでもある。その価値観が、選定される開発手法毎に異なるということだ。

 たとえばアジャイル手法では、「動くソフトウエア」を早期にプログラミングして、それを動かしながら仕様の的確さを高めることを是とする。したがって、クリティカル・スキルは「優れたプログラミングスキル」である。

 「そんな極端なことを主張しているのではない。アジャイルは今やさまざまな概念が統合されたものに成長しており、チームビルディングもドキュメンテーションもモデリングも、プログラミングと同じように重要だ」という反論は的外れだ。それこそ「アレもコレも」と語るのと同じである。まともな手法であればその背景に独自のシステム観があるもので、そこから最優先事項も「最優先でない事項」も導ける。それらを明確にすることで、プロジェクトの特性に合わせた手法も選定しやすくなるし、制約されたリソースを生かしやすくもなる。

 他の手法ではどうか。データ中心手法(DOA)では「データモデル」の確立が重要視される。効果的なデータベース構造を生み出すことが、他の何よりも優先される。したがって、クリティカル・スキルは「優れたデータモデリングスキル」である。

 ウォーターフォール手法(局面開発法)ではどうか。この手法において、次の局面に進んでよいと判断するための根拠は、「前局面でまとめられたExcel文書の充実具合」である。「充実具合」であって、「設計の妥当性」ではない点に注意してほしい。本来であれば後者がテーマになるべきなのだが、ドキュメントがExcelで書かれている限り、設計の妥当性を検証することがものすごく難しい。遅かれ早かれ、「大量のExcel文書が規定どおり揃えてあれば、しっかり設計されているに違いない」とみなされるようになる。

 したがって、ウォーターフォール手法で求められるスキルは「大量のExcel文書を文句も言わずに作れる能力」である。このスキルは比較的調達しやすいが、プロジェクトはデスマーチに陥りやすい。大量のExcel文書を文句を言わずに作れるとしても、設計スキルがあるとは限らないからだ。なぜか。Excel上で仕様をまとめている限り、その妥当性に対する組織的なフィードバックが起こらないからだ。

 ドメイン駆動では、ドメイン(問題領域)に対する効果的なモデル(ドメインモデル)の確立が最優先課題である。経営上の計数管理のドメインモデルである「複式簿記」をゼロから考案することの難しさを想像してもらえばわかるが、的確なドメインモデルを生み出すことは簡単ではない。必然的にクリティカル・スキルは、豊かなドメイン知識と創造性に裏打ちされたモデリングスキルである。そのようなスキルを調達することは、データモデリングスキルと同様に簡単ではない。

 なによりも重要なことは、プロジェクトの特性を正しく認識し、それに見合うような開発手法を選定することだ。スキルの調達しやすさなどで「臨機応変」に選定すべきではないし、要員のクリティカル・スキルについては十分に値踏みされなければいけない。そんな当たり前の配慮が足りなかったゆえに失敗している事例が、そこらじゅうにある。企画担当やPMの責任は重大である。

 当然ながら、「コレさえあればうまくいく(十分条件)」が明確なプロジェクトなど例外的だ。しかし、「コレがなければ先に進みようがない(必要条件)」を手当することで救われるプロジェクトはずいぶんある。しかもそれは、開発手法の選定と、それが要請するクリティカル・スキルの調達という基本レベルの問題だったりする――そういう話だ。あなたのプロジェクトの特性は正しく認識され、的確な手法が選定されているだろうか。そしてそれに必要なクリティカル・スキルは潤沢に確保されているだろうか。そうでなければ文字通り話が始まらないし、始めるべきではない。

|

« タコヤキ業務にタコヤキテーブルは必要か | トップページ | ALTER文の自動生成機能 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 開発手法と「クリティカル・スキル」:

« タコヤキ業務にタコヤキテーブルは必要か | トップページ | ALTER文の自動生成機能 »