先日公開した、下記の資料に対する解説というか、セミナー形式での勉強会を行います。
11.25(月) 19:00〜 場所は赤坂です。
お申し込みは、下記のConnpassよりどうぞ。完全無料です、予約も要りません。入退室自由です。
色んな方にお会いできるのを楽しみにしています〜！
ITプロジェクトの歩き方という資料を作りました
おかげさまで、色んな方に読んで頂けています。参考になれば幸いです。
コーポレート・エンジニアリングに花束を
「コーポレート・エンジニアリング」という言葉があるのを知ったのは、1ヶ月ほど前のことでした。この資料を作っている時に、SpeakerDeckを漁っていたら、メルカリのsorarokさんの資料がヒットして、我が意を得たり、でした。
直訳すれば、「対象が会社のエンジニアリング」となるかと思います。その会社の事業の拡大に耐えうるプロセスを作ったり、円滑に回せるようにしたり、利用するツールやインフラを変えて会社の働き方を変えていく。そういった活動のことをコーポレート・エンジニアリングだと解釈しています。
サービス内容をパクられることは世の常ですが、オペレーションをパクることは極めて困難です。ECを始めるだけなら簡単ですが、仮に毎日のようにネットからの注文があった場合、どうやってそれの在庫を確保して・ラッピングや梱包・出荷・フォローアップ・キャンセル・欠品時の入荷案内などをしていくのかというオペレーションは、皆さんの業務インフラというベースがあり、そこからの創意工夫の結果に生み出されます。それが会社を強くする源だと、私は考えています。
良質なオペレーションを作るには、業務の現場に向き合って価値を作るロールを担うITエンジニアが必要で、先鋒となるのは情シス部門のエンジニアなのかなと思っています。ヘルプデスクで終わってはならない。
とはいっても、アイデアを形にするのは準備が必要だし、仲間を集める必要もあります。エンジニアがいない会社のほうが圧倒的に多いですし。折角立ちあがったITプロジェクトの離着陸がなるべくスムースにできるように、上記の資料を作りました。ここまで事業会社側で準備すれば、描いたToBeとのギャップを最小化できると思います。私のノウハウでよければおいておきますので、好きなようにご賞味頂ければ。1歩でも進む会社が増えたら最高です。
このリリースを見たのも、資料を作るモチベーションの1つでした。XaaSの時代こそ、システム企画のあり方が見直されてほしいです。
案件のご相談はいつでもWelcomeです
企業組織のオペレーション(働き方を)をITで変革するお手伝いをしています。SIerにいたときも、一人情シスやってたときも、独立してからも、一貫してそれをやってきました。組織構成・業務内容・IT環境をヒアリングさせて頂いて「どのような業務"システム"がこの会社にあるべきか」を、共創させて頂けたら。
お手伝いの内容については、こんな感じです。状況によって期待値も異なると思うので、まずは期待値のすり合わせができれば。
アドバイザリー系
手は動かさなくてよく、レビュー中心の立ち回りをご希望されるケース。
デリバリー系
何かしら成果物を作る or 案件やプロジェクトをデリバリーすることをご希望ケース。
- 業務設計からSaaS/システム導入まで、一貫してやってほしい
- プロジェクトを立ち上げてデリバリーまで手伝ってほしい
- システム作って欲しい(パートナーさん紹介することも
ウチじゃ出来ないケースや、より適任の会社さんがあった場合は、そちらをご紹介させて頂きます。
国内アパレルブランド「Hummingbird Project」のオウンドメディアをはじめました
前々から文章やコンテンツを作るのは好きで、それが好じて今のブログをやっている所もあります。
純粋に自分が表現してみたい世界観を実現できるWebメディアを始めてみたいとぼんやりとしていたところ、前職が立ち上げたブランドがとても良い商品を作っているので、オウンドメディアを立ち上げました。
Hummingbirdとは
国内の生産工場や職人さんと、靴下・バッグ・シューズ・帽子等を作っており、そのブランド名称です。主に女性向け。取扱商品は、こんな感じです。一般の方もお求め頂けます。
コーポレートサイトはこちらにあります。見てやってくださいませ。
この商品が埋もれて消えていく＝職人技が消えていく
きっかけは、GW頃に前職の社長と会ってじっくり話したこと、サンプルの商品（一足の靴下）をもらってその品質の良さに驚いたことです。おいおい、オレがいたころはこんな物作ってなかったじゃないか、新しいブランド立ち上げたとは聞いてはいたけどなんでこんな物が作れるようになったんだという驚きがありました。
同時に、ブランド立ち上げまでの七転八倒、疲弊した国内アパレル生産現場、凄い職人さんがあってはじめて出来た商品開発の話を改めて伺って、僕の好奇心に火が付きました。
１つは単純に布モノが好き。微妙な違いを教えてもらってから、好奇心が湧いてきました。生産現場や品質への取り組み、デザインや企画などの裏話を、脚色無く伝えていくことが布モノが好きな方には楽しいはずだと思ったこと。もう１つは、エンジニアと同様に卓越した技術が無いと出来ない商品が多くあったので、その技の凄さを伝えたいと思ったこと。話を聞くまでは機械回して作るだけと思っていたけど、そうではなかった。
人件費の安い国への生産拠点の移動（産業の空洞化）とファストファッションの台頭で、作る人は単価が下がる一方。食うために品質の良くない安物をたくさん作るのは嫌だったと、ある職人さんは言ってました。「大量生産で似たような商材を安く作ってばらまく→同質化が激しくなり消費されるスピードも上がってすぐ飽きられる→ものが売れない」という負のサイクル真っ只中で、今更になって国内の産地に目を向けようとか言っているのは草も生えない。だって捨てたのあなた達でしょう。向けたところで横に倣えでセレクトするだけのメーカーに新しい商材を作り上げる力があるとも、思えない。
職人さんの技術があってはじめて出来る仕事があるのなら、僕が出来るのはそれを伝えていくことだなと思った。国内のアパレル生産現場(アパレルは98%が輸入生産)が活性化することはもう無いでしょう。工芸品のような世界になると思います。それならそれで、自分が好きな衣料品を作ってくれる現場にスポットライトを当てていくまで。
ブログを始めた頃のような業界に対する問題提起へをやっていくアツさが、戻ってきました。
本音の情報開示の少ない企業に対する、消費者の不信
梶祐輔さんの「広告の迷走」という本に、こんな記述があるそうです。
「消費の低迷は、本音の情報開示の少ない企業に対する、消費者の不信の表れだ。企業自身の社会的存在証明のためには、自らを語り続けなければならない。」
それだけなのかと思う部分もあれば、確かにと思う部分もあります。おそらく本音とは、自分たちが目指す世界はこうで、そのためにこういう商品を作って、その品質を守るために何をしているのか、を包括的に語ったストーリーなんだと思います。
というわけで、Hummingbird Projectをどうぞよろしくお願いいたします。
ブラウザで学ぶSQL学習・研修サービス「Start-SQL」を作りました
こんな感じで、ブラウザでSQLを書いて環境構築一切不要でSQLを学べるというものです。
PyQ - 本気でプログラミングを学びたい人のPythonオンライン学習サービスで提供した教材の作成、PyQを使った研修を通じて、ブラウザで実行できる環境があると学習効率がすごく良いことを痛感したので、SQL版を用意しました。
「学習コストの少なさと実用性のバランスが最も良いのはSQL」だと考えています。Start-SQLを使えば1日でSQLの基本をマスターできます。
一般個人向けではなく、研修用途に使うサービスです
SQLは言語仕様も20年前と変わらない上にやれることは集合演算しか無いので、定期的に新たな学習コンテンツを提供できないと判断したので、Start-SQLは当社のSQL研修を実行するプラットフォームになります。私が講師をやって、生徒さんがStart-SQL使いながらSQL学ぶという格好です。
個別のRDBMSの環境構築・データベース運用みたいな所は、一切載っていません。純粋に、主要RDBMSで実行可能な標準のSQLを学ぶためのものです。
Start-SQLで学べること
これらを1日で学習できます。また、復習したい時はいつでも復習できます。当たり前ですけど。
- データの選択(SELECT, DISTINCT, CASE-WHEN)
- データの絞込(WHERE, IN, AND, OR, LIKE, NOT, BETWEEN)
- データ集計(GROUP BY、HAVING、SUM/MIN/MAX/AVG/COUNT)
- 複数テーブルの操作(JOIN、EXIST、UNION、副問合せ)
- データ登録(INSERT、SELECT〜INSERT)
- データ更新(UPDATE、JOINを伴うUPDATE、CASE-WHENを使ったUPDATE)
- データ削除(DELETE)
IT企画について「壁打ち」相手になるサービスをはじめました
noteで書いているITプランナーを増やしたいというマガジンも掲載しましたが、こちらにも掲載します。
IT企画やIT戦略立案の分野において、ご自身がお考えになっている企画を通す為に必要な相談相手・パートナーがいないので、プロジェクトを立ち上げるにあたっての準備が不足しているのではと感じています。
かと言って、案件になる(予算がつく)ようにならないと、外に正式に依頼することもできない。でも、企画を通す・プロジェクトを成功させるための武器は欲しい。社内に相談できそうな相手が見つからない。
そんな状況になっている方が多いと感じたので、時間限定(60分前後)ではありますけれど、ITプランナーである私が壁打ち相手を務めさせて頂けたらと思っています。
IT企画・システム企画のモヤっとした部分をより明確にして、解像度を上げるお手伝いをさせて頂けたら。
詳しくはこちらをご覧ください。
よろしくお願いします！
IT企画をちゃんとやりたい勉強会 Vol.3をやります
半年に1回ぐらいやらせていただいているイベントです。今回が第3回目。1年半ですか。月日が流れるのは本当に速い・・・。
元ネタはこのツイートです。
ITの上流工程勉強会とかあってもいいよな。お互いに「どうやってお客さんの課題を可視化して、要件定義やってます？」みたいな話で意見交換をビアハッシュな感じでやる。
— ちなヤクのござ先輩 (@gothedistance) May 10, 2018
ITプロジェクトの企画運営に対する問題意識を共有しよう
どんなイベントかといえば、セクションタイトルにあるように「ITプロジェクトの企画運営に対する問題意識を共有する」イベントです。
エンジニアの場合は様々な勉強会やコミュニティがありますが、ITのビジネスサイドにいらっしゃる方々はお悩みを抱え込む傾向にあり、なかなか自分の仕事内容や悩みを相談できる相手がおりません。
色んな立場の人が集まって利害関係なしでわいのわいのやる場があるだけでも、学びや気づきが得られますし、イベント開催後に分科会(反省会)を開催されてお招き頂いたこともありました。
私はアジャイルだ滝だDevOpsだという開発方法論よりも、ITプロジェクトのプランニングを適切に行う、質を上げるために何が必要で、どんなやり方や考え方を持って望めば、失敗を少なくすることができるのだろうかということに強い関心があります。エンジニアのせいでITプロジェクトがコケるケースは極めて少なく、プランニングがコケてしまうことで共倒れというケースが多いからです。
同じような領域に関心がある方、是非ざっくばらんにコミュニケーションを取りたいなと思います。
ご参加はこちらより
なぜ「ITプランナー」なる人が必要なのか、という資料を作りました
皆さんおなじみWeb技術者の為の伝統ある勉強会「BPStudy」での発表を予定しておりました。
当方の不徳の致すところで、開催日を1日勘違いしていまい、予告先発しておきながら登壇できずにぶっちぎってしまいました。人生初の登壇ぶっちです・・・。
できることといえば、資料を作ってブログで精一杯ご説明させていただくしか無いので、資料を作りました。分量少なめ、エモさ多めです。
ITプランナーなるものへの思い
なんでこんな言葉を連想したかという点については、このツイートをご参照ください。
要件定義を仕事にしてますってふつーの人から見たら意味がわからないと思うのだけど、プランナーですっていう話なら意味がわかると思う。そういうのも結構大事じゃないでしょうか。
— ちなヤクのござ先輩 (@gothedistance) 2019年3月14日
IT側の方々は要件定義が重要ってのは通じると思うんですけど、要件定義って濃ゆい業界用語にすぎず一般的には何のことだかわからない。要件ってなにっていう反応をされたこともありました。主語がないんで、確かにと思いましたけど。
要件定義の支援を仕事でやってみると、要件定義はどう作るかを決める工程なので、どう作る以外の問題は解決できないという当たり前といえば当たり前の話を痛感することもあって。解決したい課題認識のズレとか、体制がうまく作れなかったとか、手段の目的化、とか。ITって、ビジネス側が思うよりもずっと融通がきかない(複雑な仕組みでできているので、組み立て直すのが困難な場合が多い)というのが落ちるまですごく時間がかかる、とか。
エンジニアとの関わりが薄い企業さんだと、身も蓋もないけど「プログラムを作ってもらう時に、何をどう整理して頼めばよいか」という頼み方がわからないというケースもあった。やったことなければ、頼み方わからないよね。予算や納期に制限が強いと「とにかくすぐ作り始めてくれ」とか「PM削ってプログラマに発注」とかいうやり方をしたがる発注側が少なからずいらっしゃるのですが、その場合は発注側がマネジメントできないとかなり難しい。コンセプトやゴールの策定をすっ飛ばして要件定義から始めようとすると、意思決定がうまくいかない。
ま、目に見えない不確実性が高いわりに融通がきかないものを作るから、なかなか難しい。
なぜかITシステムにおいては専門の企画職がなくない？
システムを作ることへの知見を持っている人が単純に少ない。IT企業を離れていた時期があったのですが、その時の経験を振り返ると無理もないな、と。世の中の会社の多くは、ITが重要ではない。IT技術を手に入れても活用する術を見つけなければ、会社にとって価値がない。スマホを持ったから事業の売上が比例して増えるわけがないですよね、それと同じ。
一方で1990年頃に開発され、今でもそれが事業の屋台骨を支えるシステムになっている会社も知っている。でも、充分な価値を提供できているし、ビジネスの変化に追従して今がある。レガシー(遺産)が活きているのは、ユーザー目線では大勝利。ずっと動いて使われているという側面は無視できない。そこには、ITプロダクトをデザインできる人がいたわけです。
「価値のある、使いやすい、実現可能なITシステムとして作られるべき何か」
これがカチッとハマる事業会社が増えて欲しいし、そのコアの部分は外に出せない。行くべき道は自社で決めるしかないですから。その助けとしてITプロダクトのデザインと実現までのロードマップを考えられる人材が必要なはずで、個人的に言葉のイメージでITプランナーが最も近かった。ITプランナーなる名称に込める思いは、そこです。優秀なソリューション・技術ノウハウ・進め方をもっている会社と巡り合っても、ITプランナー的な仲介役がいないとコミュニケーションが取れないので、物事をドライブして進めていくことができない。このアンマッチを解消したい。
ITプランナーを増やしたいので、お仕事のご相談お待ちしてます！
(株) クオリティスタートは、現状私がワンオペで回しているため私がガッツリ入って稼働するのは厳しいです。自分のワークロード超えて仕事を取るのも難しいなと思っていたのですが、やり方はなんぼでもあるしITプランナーという仲間を増やしたいので、ご相談はいつでもWelcomeです。TwitterのDM、もしくは弊社Webサイトのお問い合わせまで。
ソフトウエアが出せる価値を根気よく考えて「価値のある、使いやすい、実現可能なもの」を作り出すパワーを、一緒に出せる関係を築けたら。
よろしくお願い致します！
ITプランナーという職種を確立させたい
先日の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月の何処かで飲み会でもしましょう。お待ちしておりますー。
DXの時代なるものは当分来ないから安心して下さい
展望2020年のIT企業というシリーズ企画の記事を、たまたまTwitterで見かけました。
この記事で語られるDX(デジタルトランスフォーメーション)ってものすごいオワコン臭で衝撃を受けました。汎用機をお守りする時代は終わった、これからはオープンなWeb技術を駆使して基幹システムではなく顧客の売上を支えるITを作るのだ、SO！それが！DX時代！ みたいなノリで書いてあって、1ミリも次世代感が無い。
生きている時間軸が違うんだなと思いました。
DXの妨げは社内システムにあるらしい
色んな定義をされているDXですが、ここでは経済産業省の提唱する「DXレポート」のサマリー版に書いてある問題点とDX推進のためのシナリオみたいなのを引き合いに出します。
DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省）
簡単に言うとこういう主張です。
- モバイルやWeb技術を駆使してサービスを作り新事業を立ち上げる。皆がこれをやる時代。それがDX！
- が、DXの足かせになっているものがある。社内システムだ。地獄でしか無い。
- 乱立するシステム群によるスパゲティ状態で、全社横断的なデータが取れない
- 高度なカスタマイズとレガシーな技術を使う為に運用コストが肥大化
- DX活用のためのデータが一切取れないじゃないか！
- 既存システムを刷新しその上でクラウドに乗っけてAIとかでいい感じに！
企業の強さはオペレーションによって決まる
この関係性が理解できないと一生DX無理なんで、マジでわかってほしい。
どんなにITに金を突っ込んだ所で、現場のオペレーションが変革できなければ意味がないのね。動かないコンピュータの本質はここ。現場が使うのは紙とペンじゃないですよね、何かしらのシステムとそれをサポートするツール。ITを入れるだけ入れてもしょうがなくて、使い方を工夫しないと何にもならない。
この手の話になると、「カスタマイズはもってのほか、色んな会社で使われている効率化がされたパッケージに業務を合わせる、これがベストプラクティス」というクソが出てくるのですが、大きな間違いです。これが出来るのは定型的な業務(総務系)だけ。いい加減に目を覚まして欲しい。
社内システムは業務内容によって決まります。業務は、自社が行う事業によって決まる。事業は需要と顧客によって決まる。つまり「顧客 >> 事業 >> 業務 >> 社内システム」という従属性があるわけ。どの会社でも。
で、事業運営上必要な業務が社内システムになかった時に、「あーうちのITシステムがアホなのはしょうがない。この顧客を取りこぼす、このニーズや売上はいらんわ、それが健全だもんな」という話になるかといえば、なるわけないでしょ。なぜExcelで頑張るのかという理由の9割ぐらいは、ここだと思うよ。
売上を上げるまでのプロセスは、非定型的な業務も多くあるし、顧客や商材によってオペレーションも変わる必要がある。時代が変われば需要が変わって顧客も変わる、それに追従するためのDXではないんですか？？
だとしたら、死ぬほど地道にオペレーション設計をするしか無いと思います。サービスや商材はパクれますけど、オペレーションはパクれないんで。自社独自のオペレーションこそ、企業の競争力を生み出す源泉だと僕は信じています。それを支えるためのITをどう作ればいいかという方向で、社内システムのあり方を考えて欲しい・・・！
本当のDXはITありき
僕がDXをやるとすれば、「IT >> 顧客 >> 事業 >> 業務」で考えます。ITありき。え、こんなふうにITを使えばこんなサービスが出来るよねで始まり、ITありきでコンセプトを作って、そのコンセプトにハマるニーズと顧客を作り出して、事業化する。これが本当のDXだと思うんだけど、どうです？
IT企画が出来る人がいないと始まらない
どんなに優秀なエンジニアを抱えていても、どんな価値を提供してかつそれが自社のリソースで実現可能なシステムの形を与えることが出来なければ、意味がない。プロダクト作るのにプロダクトの仕様が決まってなければどうしようもないのと同じで、「経営もしくは業務課題を解決するために必要な、業務や事業をより良くするためのITシステムの企画立案」ができるIT企画屋さんが、圧倒的に足りていないと思う。業務向けとか個人向けとか関係なくてさ。
その点を無視してCOBOLエンジニアをオープン系に！とか言ってる段階でDXの時代なんて来るわけないので、無関係です。安心してくれ、と。
エンジニアのキャリアチェンジの方向性としても面白いと思っているので、僕はこっち側に仕事内容をシフトしました。仲間が全然いないのでちょっと寂しいですが、この道も面白いと思うのでご一考下さい。
エンジニアがマネージャになることへの憂鬱について
既視感があったので反応しちゃう。すげー懐かしいなこの手の話題と思った。
懐かしいと言っているのは、ネット上の議論では誰も肯定的な反応をしていないと思われる「PG→SE→PM」の出世魚キャリアの憂鬱にそっくりだったこと。
技術者とマネージャって職種(ジョブ・ディスクリプション)が全く違うのに、なんでこれが技術者の出世コースになっているのか。でも、ビジネスサイドと話ができるマネージャーは価値高いけど「作りました」ほどわかりやすい評価体系がないし、陸に上がった魚は老害になるんじゃないか・・・みたいな話ですよね。
当時は今ほどITが本業の会社が多くなく、エンジニアの主たる現場は受託開発を中心に行うSIerでした。その内部でも誰もPMになりたがらないのは人材育成上の課題にあげられていた。給料大差ないのに責任は重いので単なる貧乏くじではという風潮でした。
twitter.com某ブログでみた『プログラマのキャリアパスの先にプロマネを置くのは、FFで例えたら 「戦士からナイトを経て最終的には黒魔導師を目指してください」 と言ってるようなもんだと思うんだけどな』って表現は秀逸だと思う *P3
— t_yano (@t_yano) 2008年12月20日
2008年のツイートという所に趣を感じます。
で、2019年のツイートもございます。
SIerでは今もこのジレンマが継続中。そこに転職市場の売り手市場が乗っかっていい感じに育った中堅どころが企業の大小を問わずに去っている印象 https://t.co/U4J0VMBayz
— amanojach (@amanojach) 2019年2月19日
問題の構図は変わっていないようです。打つ手が無いもんね。
マネジメントが必要だしビジネスサイドとコミュニケーションをとってチームを率いて行けるマネージャはみんな欲しい。ただ何をどう作るかを判断できる技術力がないと何も出来ないから、まずプログラミングを覚えてもらう。が、陸に上がることを好むエンジニアは非常に少ないので、絶対数が少ない。
この現状認識があっているのであれば、マネジメントを外注することを検討するしか無いのでは？ と思います。
僕が考えるマネジメントなるもの
「マネジメント」というやつは企業の中に溶け込んでいくものなで、可視化しにくいと思う。そのチームで、その会社で行っている事業やお仕事そのものが対象になる。薄暗い森のなかにいるようなもので、例えば私にやってくるIT企画的なご相談も、抽象度が高い。プロジェクトを立ち上げたいんだけどどうしていいかわからん、と。何も決めて良いかもわからん、と。
この状態では自分が前に出て手を動かすというよりも、自分の周りの人達とコミュニケーションを取ったり、課題管理をしたり、分かりやすい資料を作ったり、各々の立場に沿った方向性を導き出したりするしかなく、こういうお仕事って定型化するのが困難なので、わかりにくい。
抽象度の高いものを具体的なステップへ落とし込むアプローチを考えること、現場で起こっている不都合な事実を集めて抽象化して、それらのもつ構造や性質を考えてこのアプローチで攻めるべきではみたいな立案をする。僕はこういう事を考えるのが好きですので、苦にならないけど。
正しい方向はどっちなのかを示すのが、一言で言えばマネジメントだと思う。手取り足取りあれやれこーやれってのは、説教でしょ。
こういう仕事であれば外に出せるはず
コード書きたい人しかいないとチームとして回らない。コードの良し悪しは外注に判断ないから、仕事を円滑に回してチームで結果出す為の仕組みづくりを外注使ってサポートしていくみたいな話にすれば、マネジメント派はそっち極めたらいいし、コード派はひたすら書けば良い気がする。すげーラフだけど。
— ちなヤクのござ先輩 (@gothedistance) 2019年2月19日
ソフトウェアを育てていくプロセスは外注によろしくとは言えないから、自社でやるしかない。でも、仕事を円滑に回してチームで結果出す為の仕組みづくりという部分にフォーカスすれば、外に出せると思う。「やっぱエンジニアでよくね？」みたいになる人が多いのであれば、検討の余地はあるはず。実際、自分の周りでもエンジニアの組織づくりやマネジメント系のフリーランスを、何人か知っている。
僕はエンジニアで一本立ちするのはとっくに諦めたので、「エンジニアとしては極めて普通だが、文章を書くのと説明が得意で、企画の立案やロードマップを作ってマネジメントもいける」人材になろうと決めて、その最短ルートが独立だった、という感じです。元々SI時代からPMとかやってて、昔懐かしい「スーツ」の仕事は嫌いじゃないです。やりがいも知ってるし。
まずはディスカッションでもしましょうか
もし「フリーランスだけの会社」を作ったらどうなるのか - GoTheDistanceの記事を書いた時に、ディスカッションでもしましょうと言ったら結構人が集まった。なので、「受託開発だろうがサービス系だろうが、出世魚のジレンマを解消してエンジニアリングを適切に行うための仕組みづくり」について興味のある人で、意見交換でもやりましょうか。5人ぐらい集まればやるので、Twitterでお気軽にどうぞ。