先日のDXの時代に関する記事を書いている中で特に感じていたのは、コーディングではなくプランニングに比重を起きつつエンジニアと議論できる人材が必要だということ。プロダクトマネージャというわけでもなく、もう少し守備範囲が広い人。そういった職種を定義したいなと思っており、IT企画というテーマで勉強会をやったりしたんですけど、既に職種化されている記事があって興奮しました。
ITプランナーの仕事内容メモ
上記の記事を読んだ私のメモです。
- ITプランナーは、エンジニアのチームとともにプロダクトを企画開発し、リクルートの商品として世の中に出していくのが仕事
- 「What（何をやるか）」を重点的に考えるが、エンジニアと同じ土俵で議論をすることが求められる
- ワイヤーフレームまではITプランナー側で作り、ER図はエンジニアが作る
- ITプランナーでSQLを書けない人はいない
- クライアントの業務の課題などから一歩引いて抽象化したプロダクトを作り何が「提供価値」で、どうやったら儲かるかを考える
僕が考えているIT企画を行うポジションの仕事内容に極めて近い。やはり先駆者はいた。
リクルート社の場合は売上拡大がミッションでのITプランナーなので、儲かるサービスをどう作るかになるけれど、業務改善・効率化・コスト削減・事業開発など、色んな背景が本来あると思う。が、「一歩引いて抽象化したプロダクトをデザインする」という、ITプランナーのミッションは変わらないはず。
ITプランナーは複数のロールを持っている
上記記事のこちらの画像が極めてわかりやすいので、貼らせて頂きます。
技術とビジネスのハブになる！ プロダクト開発のためにエンジニアとガチで議論するリクルートコミュニケーションズのITプランナーの役割とは - はてなニュースより
- 事業開発及びプロダクトマネジメントとしてのロール
- どうやってプロジェクトを進めるかというロール
これらが絡み合うのが難しいけど面白いのが、ITプランナーという職種だと思います。全部に秀でるのは無理ゲーですけど、どれもこれもバランスよくスキルを併せ持つのは、これはこれで価値がある。このプランニングを行う人は、受託開発の現場でも、事業会社の現場でも、絶対に必要だと思う。経営と開発現場とユーザーの間に立てるのは、このITプランナーという人たちしかいないはずなので。
ITプランナーという職種を確立したい
ユーザーとシステム屋の間に立って、適切なITシステムのプランニングやプロジェクト立ち上げを専門にやっていくプロを新しい職種として定義したい。
ITコンサルタントだと、抽象的な言葉が続きすぎてよくわからない。「先生」的な立ち位置のイメージが強いのも好きじゃなかった。IT企画って要はITプロジェクトの立ち上げだから、専門性を生かして企画立案を行う職種であるプランナーが最もイメージに合うし、プランナーという言葉は市民権を得ている。我が意を得たり、という感じです。
ちなみに、上記の記事でも私と同様に「以前はコードを書いていたが、エンジニアリングの道では大成できないと認識してITプランナーになった」という方がいらして、非常によく分かる次第でございます。
私は今でもコードを書いています。主には昔作った販売管理システムのリプレイスをするためですが、それがなくても何かしらはやります。プログラミングは筋トレと一緒なので、やらないと維持できない。ただ、これ以上に技術の筋肉がつくかといえば無理だし、選手として1軍でプレーできる自信はないが、プログラムを書くための脳内筋肉がダルンダルンにはしたくなくて...。ふつーのコードが書ける人間ではありたい。
ITプランナーって要件定義を行う人と何が違うのって話は、守備範囲の違い。要件定義というのはあくまでHowを決めるもの。どうやってソフトウェアを作ろうかという話。でも、プランニングというのは何を何のためにどういう手段で作るのかを検討するWhatとWhyの話。ただ、WhatとHowが分断すると誰一人幸せにならないので、ITプランナーがそこをつなぐ。
WhatとHowは車の両輪で、特にソフトウェアはHowの比重がとても高い。無形の成果物だから。ツール買えばOKという話でもない上に、一般の方から見れば「どんだけ細かいんだよ」ってうんざりするような細部の詰めを綿密にやらないといけない。綿密さをどこまでITプランナーに求めるべきかという議論はあるんですけど、プログラマのキャリアチェンジの方向性としても親和性が高いはず。全員が全員、テックリードというポジションに就けるとは思えなくて。
ITプランナーのスキルセット
ビジネス寄りのスキルセットを上げるとキリがないと思うので、IT技術のスキルだけ。プランナーとして必須なのはSQLが書けること及びER図を読んで理解できること、だと思う。データモデリングができればなおよし。仕様を作るのはエンジニアとしても、UIから送られてきたデータをどうやって保存するかの議論が出来ないと困る。
ちなみに、SQLはある意味で最もわかりやすいプログラミング言語。宣言型だから。プログラムを読み解く難しさは処理内容をつなげていってストーリーを把握して業務仕様を把握することだけど、SQLは宣言文そのものが仕様で実行結果も2次元表しか返さない。全体を俯瞰するコストが低い上に、文章としてなんとな〜く意味が通るから覚えやすいと思います。
ITエンジニアがITプランナーになるパスもあれば、ビジネス側がITプランナーになるパスもあって然るべきで。でも、後者はどこまでIT武装できればいいのかという程度問題があると思っています。どうなんでしょう？
勢いでITプランナーのSlack作りました
こんな感じの議論がしたくて、ITプランナーに興味がある人集まれ的なSlack作りました。
上記のURLを踏んで頂ければ。ITプランナーSlackへの招待リンクです。
今の所メリットとしては、僕の書いたIT企画方法論の草稿(DropboxPaperで書きました)が読めることぐらいですが、ITプランナーという職種に興味のある方で、雑談でもしましょう。20人ぐらい集まったら、4月の何処かで飲み会でもしましょう。お待ちしておりますー。
