ITプランナーの必要性を小一時間問い詰めたい / Why We need IT-Planner.

Transcript

1. 1.

   ITプランナーの必要性を 小一時間問い詰めたい YUMOTO Michitaka(a.k.a ござ先輩) @gothedistance BPStudy#140

2. 2.

   自己紹介 n 1979.11.12 東京⽣まれ ちなヤク育ち n マイメンは館⼭昌平 n (株)クオリティスタートの代表 n

   ござ先輩とも呼ばれる n GoTheDistanceというブログの中の⼈ n ツイートの99%は野球の話 2
3. 3.

   BPStudy登板履歴(11登板8野球) n BPStudy#79(野球) n BPStudy#91(野球) n BPStudy#92(エンジニアの経営学) n BPStudy#100(野球) n

   BPStudy#103(野球) n BPStudy#108(⾃社紹介) n BPStudy#112(野球) n BPStudy#115(野球) n BPStudy#122(プログラミング教育) n BPStudy#124(野球) n BPStudy#127(野球) 3
4. 4.

   4 2019年4月24日開催を完全 に勘違いし、25日開催だと 信じていました。 どう見ても、予告先発回避 です。本当にありがとうご ざいました。

5. 5.

   5 主催のビープラウド社代表の治夫さん、 及び私なぞのお話を聞くためにお時間を 割いて頂いた方々に、深くお詫び 申し上げます。

6. 6.

   6 これで終わりというわけにも行か ないので、資料を公開致します。 登壇はできませんでしたが、可能 な限り文脈が伝わるように作って みました。 ご高覧ください。

7. 7.

   わたくしの⼤まかなキャリア 7 n 2003年 商社系SIer 新卒⼊社 n コードを書きまくる部署に運よく配属され、出世⿂キャリア に乗っかる n

   2009年 雑貨製造・輸⼊卸の会社に単⾝⾶び込む n 家庭の事情とアナログな会社を変えてみたくて n ⼀⼈で業務システムを内製し、今もなおメンテ中 n 2016年 独⽴ n IT企画屋で⾏けるところまで⾏こうと決めた n やっていきだー
8. 8.

   IT企画屋になろうとした理由(１) 8 1 すげ〜できるエンジニアがアサインできなかったので、 プロジェクト失敗・・・というケースは未体験 2 エンジニアのスキル不⾜で動くシステムが作れなくて、 プロジェクト失敗・・・も経験したことがない 3 ITプロジェクトの成否はエンジニアの

   能⼒と、全然関係がないから エンジニア以外の企画側の⾊んな要因でプロジェクトが ⽴ち⾏かなくなかった・・・あ(察し
9. 9.

   IT企画屋になろうとした理由(２) 9 1 まわりにはできるエンジニアしかいないので、彼らとの レベルの差を痛感したから。 2 レベルの差というのは、発想の差。やり⽅ではない。 同じ問題を解決するにも考え⽅やアプローチが全然 違うのが、レベルの差。 3

   エンジニアでは⼤成できそうにない ごくふつうのエンジニアリングしかできないけれど、 いわゆる「T字」になって、守備範囲を広げて抽象度 ⾼めの仕事で価値を出そうという⾃分なりの⽣存戦略。
10. 10.

    10 ITプロジェクトの成否を決めるのはいつ だって、企画側。戦略のミスは取り返せ ない。 自分が得意なのはメッセージを発信して、 まわりを動かして物事を決めていくこと。 企画を立てて物事をドライブして組織を 変えるのが好きなんだ、と。 なので、プログラミングで食っていく事 へのこだわりが消えました。

11. 11.

    ITプランナーという⾔葉への思い 11 Busi ness User IT この円を描く⼈が いないとまずい 誰か! アイデアをITに変える専⾨家がいても

    いいはず。そう簡単にできないから。
12. 12.

    要望を要件まで落としこむ難しさよ 12 要望 システムによって叶えたい物事、享受したい成果やメリット 要求 要望を実現させるために必要な前提条件 要件 要求をITシステムで実現させる為のレシピ(UI/データ/機能) 要望 要求

    要件 UI σʔλ ػೳ 開発 テスト 稼働 システム開発の流れ 要望が最も⼤切なんだけど、⼀番むずかしいのは 要件を決めること。この意味をわかれ〜 頼む〜
13. 13.

    13 その会社が成り立っている事業があり、 その先にはお客さん(ユーザーが)いる。 事業の価値を高めるために、ユーザーに 選んでもらうために、ITでUXを設計し、 サービスレベルを上げていく。 そのスコープは、プロダクトデザインに 閉じた話ではなく、業務システムだろう が同じはず！

14. 14.

    14 ITプロジェクトは発注側にも色んなこと をご理解頂く必要があります。 お金で解決できるものでもなく、エンジ ニアの能力で解決できるものでもない。 開発側が出せるバリューに耐えうるだけ のパワーを、事業会社に持って欲しい。 そのために、ITプランナーが必要です。

15. 15.

    15 END