こちらのイベントに登壇しました。このエントリの最後に各登壇者の発表資料へのリンクを張っています。

リクルートさんのITプランナーは、ビジネスを作り出すという大目的があるなかでのプランナーの存在が際立っていました。優秀なエンジニアがたくさんおられるなかで、何を解決したいからこうプロダクトをデザインしたというWHATを煮詰め、部門横断的、会社横断的に立ち回っていく、広範囲に動くPdMのような印象を私は持ちました。

で、私が考えるITプランナーは、ビジネスを作りだす為にあるわけではなく、ビジネステーマ・業務課題を解決する為に必要な価値・コンセプトは何だっけを考え、機能要件(外部仕様)まで落とし込む役割に特化するイメージです。

ITプランナーの守備範囲

こうしたい、こうなりたいというのが要望で、それを実現するために必要なことが要求です。請求締め処理を簡略化したい〜というのが要望で、データ化して郵送代行に頼めるようにするが要求、要求を実現するシステムがどんなUIや機能、データを保存しなければならないかを定義したものが要件です。

一般的に要件定義というと、上の絵で言うところの「要件」の話になるんですが、要求が間違ったら要件も間違えるので、要件定義をしっかりやるというのは、この絵に出てくる登場人物が「提供する価値」に対して同じレベルで理解しないと駄目という罠があります。

仕様に落とし込むプロセスは難しさを抱えたまま

仕様を見出すには、要望→要件→仕様まで「落とし込む」というプロセスが必要になるんですが、その落とし込みは常に難しいです。形を変えて落とし込んでいくので、ロジカルに詰めて詰めて詰めていかねばならない。

このプロセスは楽しいかといえば、あんまり楽しくないです。コンセプトやアプローチ、UIデザインを考えている時は楽しいですけど、理詰めで詰めていく作業は、間違い(犯人)探しをひたすらやるようなもの。

そのため、議論の枠組みや成果物のあり方を先に決めないと、絶対上手くいかない。決めてもうまくいくかは別問題だけど、空中戦からの消耗戦をさけるために、着地点を作らないとね。

システム化は専門技術

データベース設計と業務フローの見える化を行う技術と、ソフトウェアを実装する技術は、重なる部分もありますが全く別のスキル。なので、以下のようなお悩みTweetが生まれると思っています。

業務をデザインしてそれをERDに落とすのはスキルであって、業務に詳しくなくてもERDに落とすことは出来ます。どんなテーブルを作らねばならないかは、ある程度機械的に見出せます。そうでないと、当該業務のエキスパートでないとERD作れないことになるからね。

データモデリングは分かる人からすれば価値のあるスキルなのだが、触媒というかそれ単体では使えないと言うか、そういうところが難しい。

プログラミング経験が乏しくてもSQLを学びさえすれば、データベース設計(論理設計)をやりきることは出来ると考えています。実際に、僕が教えた新人がやりきってくれた。40テーブルぐらい。以下、参考情報。

ビジネスサイドとITサイドの両方の立場に立って、共に課題解決に必要なITシステムのコンセプトを決め提供する価値をデザインし、要件へと落とし込むプロセスを並走するプロの存在が、ITプロジェクトの成否に影響すると考えています。

発表資料