アイスブレイク

最近玄関の照明をセンサー付きに変えたらQOLが爆上がりしました。
両手に荷物抱えてても勝手に明るい、すばらしい。
これなら一人暮らしで「ただいま」って言ってもそれっぽいですね！（言わないけど）

最近プロダクティビティ向上担当みたいなことを始めました、DX事業部の安宅です。
システム開発いい感じで回るにはどうしたら良いかな、お菓子配れば良いんじゃないですかね、みたいなことを日々考えています。

PM

「PM」って存在、いるじゃないですか？
日本のシステム開発の現場に生息している生物らしいです。

この「P」ってプロジェクトなの？プロダクトなの？って思いません？
そんなのどっちでもええやん、とか言われるとこの話が終わってしまうので禁止です。
（まあたぶんプロジェクトです、プロダクトの方はプロダクトオーナーとか言っててもう少し強い種族感ある）

プロジェクト思考

ではプロジェクトってなんなの？というところ
一般的にシステム開発ってプロジェクトから始まります。

プロジェクトとは

• 目的があって
• 予算があって
• 納期がある

みたいな

そしてプロジェクトの最大のリスクは「プロジェクトが終わらないこと」
始まりがあって終りがある、諸行無常、それがプロジェクト。（※盛者必衰です）

なのでプロジェクト思考ではそのリスクを全力で回避します。

• 仕様変更は受け付けない
• 正解は使いやすさではなく、仕様と合っているか
• 計画どおり終わらせたい

そう、プロジェクト思考のゴールは「プロジェクトを計画通り終わらせること」なのです。

プロダクト思考

いっぽうプロダクト思考とは、良いプロダクト（製品、サービス）を作る。
それが

• ユーザビリティを向上し
• 利用者を増やし
• 会社の利益となる

という考え方
プロダクトの最大のリスクは「プロダクトが終わること」
それを避けるために

• やりたいことは0にしない（それはサービスが死ぬとき）
• ビジネス的な価値が向上するならやるべき
• 全てに優先度があり状況によって入れ替わる
• 終わりなんてない

プロダクト思考のゴールは「プロダクトを未来永劫続けること」です。
もっと言うとそれでビジネスが成功すること（ぶっちゃけると儲かることです）。

そう考えるとシステム開発って本来「プロダクト思考」であるべきなんです。
良いプロダクトを作る → 使われる → 儲かる。とてもシンプルわかりやすい。

それに比べてプロジェクト思考の
言われたとおり作る → 使いやすさとか知らない → さっさと終わらせたい。
ぱっと見これで良いものを生まれそうな気がしない。。。

なんでそうなん？

この辺はどこまで「自分ごと」として捉えるかの違いです。
プロダクト思考の方がスコープが広い。（視座が高いとも言います）

プロジェクト思考の方は限定条件の中で最高の結果を目指すので、、、部分最適になりがちですかね。
色々組み合わせた結果、、、あれ？これが欲しかったんでしたっけ？みたいな

これは個人の意識の問題でもありますが、根本的にはチームの開発方針次第です。
チームがゾーンディフェンス戦略なのに、1人だけマンマークなんてできないですよ、監督にしばかれますやん。
なのでチーム戦略、とても大事です。
このあたりは「心理的安全性」という文脈で語られたりしますね、機会があればその話もしたいですね。

そうなるとやはり決定階層が多い開発スタイルはプロダクト思考に向いていないのですね。
ということで最近の流れビジネスコアな部分は内製化しようという風潮です。

そう流行りのデジタルトランスフォーメーション（DX）ですよ！
ということでIPAからも「アジャイル開発版の「情報システム・モデル取引・契約書」」が公開されています。

https://www.ipa.go.jp/about/press/20200331.html

ユーザ企業、ベンダー企業で一緒に1つのゴールを目指しましょう！
初めは外注しつつ、ゆくゆくは自社開発に移行したい、そんなビジネスをお手伝いする部署、それがDX事業部！

らしいですよ、今日知りました（笑）