GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

突撃! 隣のコーポレート・エンジニアリングっていう連載企画、どうでしょう。

あるWebメディアさんに「色んな会社がどうやって組織を円滑回すためのITを組んで会社を回しているのか、総務的かつ技術的な視点で刺激を与えるシブ知な連載どうですか」と持ちかけたんですが、まずは取材先や読者層がどれだけいてくれるのかってのが知りたくて、このブログで取材先を公募をすることにしました。

コーポレート・エンジニアリング is 何

非常に簡単に言えば、会社の運営上の問題をITを使ってどうやって解決して、組織の運営を最適化していくのか、それを支えるエンジニアリング組織をどう作るか、という活動です。私は、そのように定義しています。プロダクト開発のあり方を考えるのではなく、組織運営のオペレーション設計やあり方を考えるのが主眼です。

で、まぁ結局すべきことって1つしか無くて「オペレーションの改善と改革」です。自分達がやっているタスクを、正しいやり方に再定義して、みんなが働きやすい環境を作り、会社の運営をヘルシーにする。こういう流れというかサイクルを作って回す仕組みを、ITで用意する。そのITがハックする対象が、コーポレート(会社組織)になるわけです。

IT技術を使って、人に依存することなく働き方を変えて、会社を変える・良くする仕組みを考えて、実行に移すこと」

自分がずっとご業務システム畑にいたこともあってか、こういうITの使い方をもっとやりたいな、知りたいなっていう思いが、とても強いです。

業務のDXと事業のDX

ITを手の内に入れる(企画から運用改善までのサイクルを、自社で管理できるような体制をつくる)のが、DXなるものを実現するための骨子。これは及川さんの著書「ソフトウェア・ファースト」で書かれていた定義です。

ただ、私の中では「事業やプロダクトを開発するDX」と「業務やオペレーションを改善し、組織運営のインフラを開発するDX」の2つがあると思っています。前者と後者は、どこかで融合するといいますか、結節するポイントがあると思ってて。ラグビーでいうとフォワードとバックスのような、そんなイメージを持っています。バックスがトライを上げるために、コーポレートが前でスクラムを組むわけですわ。プロダクトが生み出す価値と、組織改革として生み出す価値が交差する議論をしていく中で、エンジニアリングの幅を広げていける刺激を提供したい、そんな風に思っています。

取材先の会社さんを募集します

取材させて頂きたい内容としては、以下の通りです。

  • 事業内容
  • 総務部門の体制
  • コーポレート系のエンジニアの主な業務内容・キャリアパス
  • 会社運営上、特にITで解決したいと思っているエリア
  • バックオフィス運営のやりがい
  • 業務運営でウチはここを工夫しているぜ!っていうアピールポイント
  • コーポレート・エンジニアリングに期待すること
  • 今後の抱負

これがテンプレになっていて、これをベースに1時間〜1.5時間枠程度で、いろんな議論が取り交わせればと思っています。私が話し手となって、ショーンKのごとく色んな話を引き出させて頂ければと思います。コーポレート部門でエンジニアを活用している会社さんが最も関心が高いと思いつつも、ウチの創意工夫を聞いてもらって手伝ってくれる人を探したい方、一緒にこの企画を運営したい方からのお声がけをお待ち申し上げております。

来週以降、私から個別にDMが飛ぶこともあるかと思いますので、引き続きよろしくおねがいします...!!

掲載先

企業メディアさんが当該企画にJOINしていただけるのであれば、そちらに掲載しようと思っています。特にいらっしゃらない場合は、私が運営しているnoteに掲載します。

ご連絡先

twitter.com
quality-start.in

Facebookでご友人の方は、そちらからぜひぜひ。

プロフィール

note.mu

「ITプロジェクトの歩き方」の勉強会をやります

先日公開した、下記の資料に対する解説というか、セミナー形式での勉強会を行います。

speakerdeck.com

11.25(月) 19:00〜 場所は赤坂です。

お申し込みは、下記のConnpassよりどうぞ。完全無料です、予約も要りません。入退室自由です。

connpass.com

色んな方にお会いできるのを楽しみにしています〜!

ITプロジェクトの歩き方という資料を作りました

おかげさまで、色んな方に読んで頂けています。参考になれば幸いです。

speakerdeck.com

コーポレート・エンジニアリングに花束を

「コーポレート・エンジニアリング」という言葉があるのを知ったのは、1ヶ月ほど前のことでした。この資料を作っている時に、SpeakerDeckを漁っていたら、メルカリのsorarokさんの資料がヒットして、我が意を得たり、でした。

speakerdeck.com

直訳すれば、「対象が会社のエンジニアリング」となるかと思います。その会社の事業の拡大に耐えうるプロセスを作ったり、円滑に回せるようにしたり、利用するツールやインフラを変えて会社の働き方を変えていく。そういった活動のことをコーポレート・エンジニアリングだと解釈しています。

サービス内容をパクられることは世の常ですが、オペレーションをパクることは極めて困難です。ECを始めるだけなら簡単ですが、仮に毎日のようにネットからの注文があった場合、どうやってそれの在庫を確保して・ラッピングや梱包・出荷・フォローアップ・キャンセル・欠品時の入荷案内などをしていくのかというオペレーションは、皆さんの業務インフラというベースがあり、そこからの創意工夫の結果に生み出されます。それが会社を強くする源だと、私は考えています。

良質なオペレーションを作るには、業務の現場に向き合って価値を作るロールを担うITエンジニアが必要で、先鋒となるのは情シス部門のエンジニアなのかなと思っています。ヘルプデスクで終わってはならない。

とはいっても、アイデアを形にするのは準備が必要だし、仲間を集める必要もあります。エンジニアがいない会社のほうが圧倒的に多いですし。折角立ちあがったITプロジェクトの離着陸がなるべくスムースにできるように、上記の資料を作りました。ここまで事業会社側で準備すれば、描いたToBeとのギャップを最小化できると思います。私のノウハウでよければおいておきますので、好きなようにご賞味頂ければ。1歩でも進む会社が増えたら最高です。

このリリースを見たのも、資料を作るモチベーションの1つでした。XaaSの時代こそ、システム企画のあり方が見直されてほしいです。

prtimes.jp

案件のご相談はいつでもWelcomeです

企業組織のオペレーション(働き方を)をITで変革するお手伝いをしています。SIerにいたときも、一人情シスやってたときも、独立してからも、一貫してそれをやってきました。組織構成・業務内容・IT環境をヒアリングさせて頂いて「どのような業務"システム"がこの会社にあるべきか」を、共創させて頂けたら。

お手伝いの内容については、こんな感じです。状況によって期待値も異なると思うので、まずは期待値のすり合わせができれば。

アドバイザリー系

手は動かさなくてよく、レビュー中心の立ち回りをご希望されるケース。

  • どんな成果物を作ればよいかのアドバイスがほしい
  • メンバーに適宜スキルトランスファーしてほしい
  • 進め方について気になる点があれば適宜指摘してほしい
デリバリー系

何かしら成果物を作る or 案件やプロジェクトをデリバリーすることをご希望ケース。

  • 業務設計からSaaS/システム導入まで、一貫してやってほしい
  • プロジェクトを立ち上げてデリバリーまで手伝ってほしい
  • システム作って欲しい(パートナーさん紹介することも

ウチじゃ出来ないケースや、より適任の会社さんがあった場合は、そちらをご紹介させて頂きます。

国内アパレルブランド「Hummingbird Project」のオウンドメディアをはじめました

前々から文章やコンテンツを作るのは好きで、それが好じて今のブログをやっている所もあります。

純粋に自分が表現してみたい世界観を実現できるWebメディアを始めてみたいとぼんやりとしていたところ、前職が立ち上げたブランドがとても良い商品を作っているので、オウンドメディアを立ち上げました。

note.mu

Hummingbirdとは

国内の生産工場や職人さんと、靴下・バッグ・シューズ・帽子等を作っており、そのブランド名称です。主に女性向け。取扱商品は、こんな感じです。一般の方もお求め頂けます。

f:id:gothedistance:20191001111454p:plain

コーポレートサイトはこちらにあります。見てやってくださいませ。

hummingbird-project.com

この商品が埋もれて消えていく=職人技が消えていく

きっかけは、GW頃に前職の社長と会ってじっくり話したこと、サンプルの商品(一足の靴下)をもらってその品質の良さに驚いたことです。おいおい、オレがいたころはこんな物作ってなかったじゃないか、新しいブランド立ち上げたとは聞いてはいたけどなんでこんな物が作れるようになったんだという驚きがありました。

同時に、ブランド立ち上げまでの七転八倒、疲弊した国内アパレル生産現場、凄い職人さんがあってはじめて出来た商品開発の話を改めて伺って、僕の好奇心に火が付きました。

1つは単純に布モノが好き。微妙な違いを教えてもらってから、好奇心が湧いてきました。生産現場や品質への取り組み、デザインや企画などの裏話を、脚色無く伝えていくことが布モノが好きな方には楽しいはずだと思ったこと。もう1つは、エンジニアと同様に卓越した技術が無いと出来ない商品が多くあったので、その技の凄さを伝えたいと思ったこと。話を聞くまでは機械回して作るだけと思っていたけど、そうではなかった。

人件費の安い国への生産拠点の移動(産業の空洞化)とファストファッションの台頭で、作る人は単価が下がる一方。食うために品質の良くない安物をたくさん作るのは嫌だったと、ある職人さんは言ってました。「大量生産で似たような商材を安く作ってばらまく→同質化が激しくなり消費されるスピードも上がってすぐ飽きられる→ものが売れない」という負のサイクル真っ只中で、今更になって国内の産地に目を向けようとか言っているのは草も生えない。だって捨てたのあなた達でしょう。向けたところで横に倣えでセレクトするだけのメーカーに新しい商材を作り上げる力があるとも、思えない。

職人さんの技術があってはじめて出来る仕事があるのなら、僕が出来るのはそれを伝えていくことだなと思った。国内のアパレル生産現場(アパレルは98%が輸入生産)が活性化することはもう無いでしょう。工芸品のような世界になると思います。それならそれで、自分が好きな衣料品を作ってくれる現場にスポットライトを当てていくまで。

ブログを始めた頃のような業界に対する問題提起へをやっていくアツさが、戻ってきました。

本音の情報開示の少ない企業に対する、消費者の不信

梶祐輔さんの「広告の迷走」という本に、こんな記述があるそうです。

「消費の低迷は、本音の情報開示の少ない企業に対する、消費者の不信の表れだ。企業自身の社会的存在証明のためには、自らを語り続けなければならない。」

それだけなのかと思う部分もあれば、確かにと思う部分もあります。おそらく本音とは、自分たちが目指す世界はこうで、そのためにこういう商品を作って、その品質を守るために何をしているのか、を包括的に語ったストーリーなんだと思います。

というわけで、Hummingbird Projectをどうぞよろしくお願いいたします。

note.mu

ブラウザで学ぶSQL学習・研修サービス「Start-SQL」を作りました

Image from Gyazo

こんな感じで、ブラウザで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)

ストアカウント用意できます

1つのセクションだけ遊べるゲストアカウントを用意できますので、ご希望の方はお問い合わせください。アカウントの発行は私共でないと出来ない仕組みなので。あしからず。

ご連絡先など

quality-start.in

お問い合わせは、会社のお問い合わせもしくは私のTwitterまでお気軽にどうぞ。

twitter.com

IT企画について「壁打ち」相手になるサービスをはじめました

noteで書いているITプランナーを増やしたいというマガジンも掲載しましたが、こちらにも掲載します。

note.mu


IT企画やIT戦略立案の分野において、ご自身がお考えになっている企画を通す為に必要な相談相手・パートナーがいないので、プロジェクトを立ち上げるにあたっての準備が不足しているのではと感じています。

かと言って、案件になる(予算がつく)ようにならないと、外に正式に依頼することもできない。でも、企画を通す・プロジェクトを成功させるための武器は欲しい。社内に相談できそうな相手が見つからない。

そんな状況になっている方が多いと感じたので、時間限定(60分前後)ではありますけれど、ITプランナーである私が壁打ち相手を務めさせて頂けたらと思っています。

IT企画・システム企画のモヤっとした部分をより明確にして、解像度を上げるお手伝いをさせて頂けたら。

詳しくはこちらをご覧ください。

quality-start.in

よろしくお願いします!

IT企画をちゃんとやりたい勉強会 Vol.3をやります

半年に1回ぐらいやらせていただいているイベントです。今回が第3回目。1年半ですか。月日が流れるのは本当に速い・・・。

元ネタはこのツイートです。


ITプロジェクトの企画運営に対する問題意識を共有しよう

どんなイベントかといえば、セクションタイトルにあるように「ITプロジェクトの企画運営に対する問題意識を共有する」イベントです。

エンジニアの場合は様々な勉強会やコミュニティがありますが、ITのビジネスサイドにいらっしゃる方々はお悩みを抱え込む傾向にあり、なかなか自分の仕事内容や悩みを相談できる相手がおりません。

色んな立場の人が集まって利害関係なしでわいのわいのやる場があるだけでも、学びや気づきが得られますし、イベント開催後に分科会(反省会)を開催されてお招き頂いたこともありました。

私はアジャイルだ滝だDevOpsだという開発方法論よりも、ITプロジェクトのプランニングを適切に行う、質を上げるために何が必要で、どんなやり方や考え方を持って望めば、失敗を少なくすることができるのだろうかということに強い関心があります。エンジニアのせいでITプロジェクトがコケるケースは極めて少なく、プランニングがコケてしまうことで共倒れというケースが多いからです。

同じような領域に関心がある方、是非ざっくばらんにコミュニケーションを取りたいなと思います。

ご参加はこちらより

connpass.com

なぜ「ITプランナー」なる人が必要なのか、という資料を作りました

皆さんおなじみWeb技術者の為の伝統ある勉強会「BPStudy」での発表を予定しておりました。

bpstudy.connpass.com

当方の不徳の致すところで、開催日を1日勘違いしていまい、予告先発しておきながら登壇できずにぶっちぎってしまいました。人生初の登壇ぶっちです・・・。

できることといえば、資料を作ってブログで精一杯ご説明させていただくしか無いので、資料を作りました。分量少なめ、エモさ多めです。

speakerdeck.com

ITプランナーなるものへの思い

なんでこんな言葉を連想したかという点については、このツイートをご参照ください。

IT側の方々は要件定義が重要ってのは通じると思うんですけど、要件定義って濃ゆい業界用語にすぎず一般的には何のことだかわからない。要件ってなにっていう反応をされたこともありました。主語がないんで、確かにと思いましたけど。

要件定義の支援を仕事でやってみると、要件定義はどう作るかを決める工程なので、どう作る以外の問題は解決できないという当たり前といえば当たり前の話を痛感することもあって。解決したい課題認識のズレとか、体制がうまく作れなかったとか、手段の目的化、とか。ITって、ビジネス側が思うよりもずっと融通がきかない(複雑な仕組みでできているので、組み立て直すのが困難な場合が多い)というのが落ちるまですごく時間がかかる、とか。

エンジニアとの関わりが薄い企業さんだと、身も蓋もないけど「プログラムを作ってもらう時に、何をどう整理して頼めばよいか」という頼み方がわからないというケースもあった。やったことなければ、頼み方わからないよね。予算や納期に制限が強いと「とにかくすぐ作り始めてくれ」とか「PM削ってプログラマに発注」とかいうやり方をしたがる発注側が少なからずいらっしゃるのですが、その場合は発注側がマネジメントできないとかなり難しい。コンセプトやゴールの策定をすっ飛ばして要件定義から始めようとすると、意思決定がうまくいかない。

ま、目に見えない不確実性が高いわりに融通がきかないものを作るから、なかなか難しい。

なぜかITシステムにおいては専門の企画職がなくない?

システムを作ることへの知見を持っている人が単純に少ない。IT企業を離れていた時期があったのですが、その時の経験を振り返ると無理もないな、と。世の中の会社の多くは、ITが重要ではない。IT技術を手に入れても活用する術を見つけなければ、会社にとって価値がない。スマホを持ったから事業の売上が比例して増えるわけがないですよね、それと同じ。

一方で1990年頃に開発され、今でもそれが事業の屋台骨を支えるシステムになっている会社も知っている。でも、充分な価値を提供できているし、ビジネスの変化に追従して今がある。レガシー(遺産)が活きているのは、ユーザー目線では大勝利。ずっと動いて使われているという側面は無視できない。そこには、ITプロダクトをデザインできる人がいたわけです。

「価値のある、使いやすい、実現可能なITシステムとして作られるべき何か」

これがカチッとハマる事業会社が増えて欲しいし、そのコアの部分は外に出せない。行くべき道は自社で決めるしかないですから。その助けとしてITプロダクトのデザインと実現までのロードマップを考えられる人材が必要なはずで、個人的に言葉のイメージでITプランナーが最も近かった。ITプランナーなる名称に込める思いは、そこです。優秀なソリューション・技術ノウハウ・進め方をもっている会社と巡り合っても、ITプランナー的な仲介役がいないとコミュニケーションが取れないので、物事をドライブして進めていくことができない。このアンマッチを解消したい。

ITプランナーに関する記事を集めたnote、やってます

週1〜2回は更新しますので!よろしくおねがいします!

note.mu

ITプランナーを増やしたいので、お仕事のご相談お待ちしてます!

(株) クオリティスタートは、現状私がワンオペで回しているため私がガッツリ入って稼働するのは厳しいです。自分のワークロード超えて仕事を取るのも難しいなと思っていたのですが、やり方はなんぼでもあるしITプランナーという仲間を増やしたいので、ご相談はいつでもWelcomeです。TwitterのDM、もしくは弊社Webサイトのお問い合わせまで。

ソフトウエアが出せる価値を根気よく考えて「価値のある、使いやすい、実現可能なもの」を作り出すパワーを、一緒に出せる関係を築けたら。

よろしくお願い致します!

twitter.com

quality-start.in

ITプランナーという職種を確立させたい

先日のDXの時代に関する記事を書いている中で特に感じていたのは、コーディングではなくプランニングに比重を起きつつエンジニアと議論できる人材が必要だということ。プロダクトマネージャというわけでもなく、もう少し守備範囲が広い人。そういった職種を定義したいなと思っており、IT企画というテーマで勉強会をやったりしたんですけど、既に職種化されている記事があって興奮しました。

hatenanews.com

ITプランナーの仕事内容メモ

上記の記事を読んだ私のメモです。

  • ITプランナーは、エンジニアのチームとともにプロダクトを企画開発し、リクルートの商品として世の中に出していくのが仕事
  • 「What(何をやるか)」を重点的に考えるが、エンジニアと同じ土俵で議論をすることが求められる
  • ワイヤーフレームまではITプランナー側で作り、ER図はエンジニアが作る
  • ITプランナーでSQLを書けない人はいない
  • クライアントの業務の課題などから一歩引いて抽象化したプロダクトを作り何が「提供価値」で、どうやったら儲かるかを考える

僕が考えているIT企画を行うポジションの仕事内容に極めて近い。やはり先駆者はいた。

リクルート社の場合は売上拡大がミッションでのITプランナーなので、儲かるサービスをどう作るかになるけれど、業務改善・効率化・コスト削減・事業開発など、色んな背景が本来あると思う。が、「一歩引いて抽象化したプロダクトをデザインする」という、ITプランナーのミッションは変わらないはず。

ITプランナーは複数のロールを持っている

上記記事のこちらの画像が極めてわかりやすいので、貼らせて頂きます。

https://cdn-ak.f.st-hatena.com/images/fotolife/h/hatenanews/20180914/20180914170119.jpg
技術とビジネスのハブになる! プロダクト開発のためにエンジニアとガチで議論するリクルートコミュニケーションズのITプランナーの役割とは - はてなニュースより

これらが絡み合うのが難しいけど面白いのが、ITプランナーという職種だと思います。全部に秀でるのは無理ゲーですけど、どれもこれもバランスよくスキルを併せ持つのは、これはこれで価値がある。このプランニングを行う人は、受託開発の現場でも、事業会社の現場でも、絶対に必要だと思う。経営と開発現場とユーザーの間に立てるのは、このITプランナーという人たちしかいないはずなので。

ITプランナーという職種を確立したい

f:id:gothedistance:20190311174429p:plain

ユーザーとシステム屋の間に立って、適切な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作りました。

https://join.slack.com/t/it-planner/shared_invite/enQtNTc5NjcyODM0Njc2LTJlZmVkOWU2NzU2ZDgxNjA1MWUxMTFkZDRmNzk4Y2ZlYjRiOGRhYTY3ZTVlMDZhNTU3Y2JlZmY0ZDYyYTlmOWI

上記のURLを踏んで頂ければ。ITプランナーSlackへの招待リンクです。

今の所メリットとしては、僕の書いたIT企画方法論の草稿(DropboxPaperで書きました)が読めることぐらいですが、ITプランナーという職種に興味のある方で、雑談でもしましょう。20人ぐらい集まったら、4月の何処かで飲み会でもしましょう。お待ちしておりますー。

DXの時代なるものは当分来ないから安心して下さい

展望2020年のIT企業というシリーズ企画の記事を、たまたまTwitterで見かけました。

japan.zdnet.com

この記事で語られるDX(デジタルトランスフォーメーション)ってものすごいオワコン臭で衝撃を受けました。汎用機をお守りする時代は終わった、これからはオープンなWeb技術を駆使して基幹システムではなく顧客の売上を支えるITを作るのだ、SO!それが!DX時代! みたいなノリで書いてあって、1ミリも次世代感が無い。

生きている時間軸が違うんだなと思いました。

DXの妨げは社内システムにあるらしい

色んな定義をされているDXですが、ここでは経済産業省の提唱する「DXレポート」のサマリー版に書いてある問題点とDX推進のためのシナリオみたいなのを引き合いに出します。

DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~(METI/経済産業省)

簡単に言うとこういう主張です。

  • モバイルやWeb技術を駆使してサービスを作り新事業を立ち上げる。皆がこれをやる時代。それがDX!
  • が、DXの足かせになっているものがある。社内システムだ。地獄でしか無い。
    • 乱立するシステム群によるスパゲティ状態で、全社横断的なデータが取れない
    • 高度なカスタマイズとレガシーな技術を使う為に運用コストが肥大化
    • DX活用のためのデータが一切取れないじゃないか!
  • 既存システムを刷新しその上でクラウドに乗っけてAIとかでいい感じに!

企業の強さはオペレーションによって決まる

この関係性が理解できないと一生DX無理なんで、マジでわかってほしい。

f:id:gothedistance:20190307122855p:plain

どんなにITに金を突っ込んだ所で、現場のオペレーションが変革できなければ意味がないのね。動かないコンピュータの本質はここ。現場が使うのは紙とペンじゃないですよね、何かしらのシステムとそれをサポートするツール。ITを入れるだけ入れてもしょうがなくて、使い方を工夫しないと何にもならない。

この手の話になると、「カスタマイズはもってのほか、色んな会社で使われている効率化がされたパッケージに業務を合わせる、これがベストプラクティス」というクソが出てくるのですが、大きな間違いです。これが出来るのは定型的な業務(総務系)だけ。いい加減に目を覚まして欲しい。

社内システムは業務内容によって決まります。業務は、自社が行う事業によって決まる。事業は需要と顧客によって決まる。つまり「顧客 >> 事業 >> 業務 >> 社内システム」という従属性があるわけ。どの会社でも。

で、事業運営上必要な業務が社内システムになかった時に、「あーうちのITシステムがアホなのはしょうがない。この顧客を取りこぼす、このニーズや売上はいらんわ、それが健全だもんな」という話になるかといえば、なるわけないでしょ。なぜExcelで頑張るのかという理由の9割ぐらいは、ここだと思うよ。

売上を上げるまでのプロセスは、非定型的な業務も多くあるし、顧客や商材によってオペレーションも変わる必要がある。時代が変われば需要が変わって顧客も変わる、それに追従するためのDXではないんですか??

だとしたら、死ぬほど地道にオペレーション設計をするしか無いと思います。サービスや商材はパクれますけど、オペレーションはパクれないんで。自社独自のオペレーションこそ、企業の競争力を生み出す源泉だと僕は信じています。それを支えるためのITをどう作ればいいかという方向で、社内システムのあり方を考えて欲しい・・・!

本当のDXはITありき

僕がDXをやるとすれば、「IT >> 顧客 >> 事業 >> 業務」で考えます。ITありき。え、こんなふうにITを使えばこんなサービスが出来るよねで始まり、ITありきでコンセプトを作って、そのコンセプトにハマるニーズと顧客を作り出して、事業化する。これが本当のDXだと思うんだけど、どうです?

IT企画が出来る人がいないと始まらない

どんなに優秀なエンジニアを抱えていても、どんな価値を提供してかつそれが自社のリソースで実現可能なシステムの形を与えることが出来なければ、意味がない。プロダクト作るのにプロダクトの仕様が決まってなければどうしようもないのと同じで、「経営もしくは業務課題を解決するために必要な、業務や事業をより良くするためのITシステムの企画立案」ができるIT企画屋さんが、圧倒的に足りていないと思う。業務向けとか個人向けとか関係なくてさ。

その点を無視してCOBOLエンジニアをオープン系に!とか言ってる段階でDXの時代なんて来るわけないので、無関係です。安心してくれ、と。

エンジニアのキャリアチェンジの方向性としても面白いと思っているので、僕はこっち側に仕事内容をシフトしました。仲間が全然いないのでちょっと寂しいですが、この道も面白いと思うのでご一考下さい。