「やりきる」を目標にする人に成功はない

100円のものを100万個売るのと
1億円のものを1つ売るのとどちらが難しいのでしょうか。
どちらも難しいと思います。

では、1億円売ってこいと言われたら、
100円のもので商売するか1億円のもので商売するか
あなたはどちらを選びますか?

1億円でも100円でもみんな真面目なので1億円に達するまで頑張ろうとします。

「やりきる」を目標にするとしんどいだけですよ?

DXの設計書⑧ – 業務フローのビフォーDX、アフターDX

業務フローの話です。
僕は現状のBPMNのみを書くことが多いです。
システム導入後のBPMNは必要に応じてですね。

設計書や資料の価値は、どれだけ見返されるかで測定できると思います。

問題や課題に関するビフォー・アフター(現状とあるべき姿)の洗い出しは困難を極めますが、
業務フローのビフォー・アフターは簡単です。

「プログラミングはセンス」とは?

プログラミングはセンスと主張する人がいます。

どんなものでも向き不向きはあります。
それはプログラミングに限ったことではありません。
どれだけ努力しても乗り越えられない壁を感じることがあります。

僕は歌や絵画など芸術系は誰よりも下手です。
リズム感が無いとか服のセンスがおかしいとかよく言われてきました。
球技やダンスも苦手な部類です。「何か変」とよく言われます。
僕は何を改善すればよいのでしょうか。

もう少し具体的に言ってもらえないものでしょうか?

DXの設計書⑦ – 無秩序な業務フローダイアグラム

システム開発で設計書を書く際、UMLやSysMLを使用します。
モデリング言語というやつですね。

業務フローをかけと言われた時にあなたは何を使いますか?
多くの人が独自モデルを使用します。
エクセルやパワーポイントを使用し、ルール無用の矩形や〇の組み合わせで記述します。
一回使用しただけで全く見返されないものや、別の人が何度も同じ内容で作り直すケースがしばしば発生します。
折角時間をかけて書いたものなのにもったいない限りです。

ところで、業務フローかけますか?

プログラマーに資格はいらない!について – 愚かですね

資格に関しては意外と否定派が多いです。
僕が以前勤めていたIT企業では何等かの情報処理資格を持っていた人は3割程度でした。
否定派の意見は「資格なんて業務の役に立たない」です。

その言い分は

  • 取れない人の負け惜しみか
  • 役に立つ資格を取れてない人の負け惜しみか
  • 得してる人のライバルを増やさないための戦略

です。

では、資格で得している僕の意見をどうぞ。
本音はライバルを増やしたくない。僕の希少性が薄れる。

DXの設計書⑥ – 自分のゴールを決めよ

前回の話
自分のゴールはイメージできましたか?
何を変えるのか、何に変えるのか、どのように変えるのか。
誰がいつどこでどうやってその仕組みを使っているのか具体的にイメージできていると良いですね。
実現するための道筋が想像つくならば尚良しです。

まだ、難しいようであればどんどん分割していきましょう。
具体的にイメージできないものは大抵うまくいきません。
人を頼ってもダメです。自分の中のイメージが大事です。

ところであなたがイメージしているゴール。
それは本当に成すべきことですか?

DXの設計書⑤ – 自分のゴールをイメージせよ

何を変えるのか、何に変えるのか、どのように変えるのか
The Goal の一文です。

前回の記事では個別の作業単位に分割することについて説明しました。

言うは易し、行うは難しです。
迷いが生じる2つの要素があります。

  • どこまで耕やせばよいのか自信がない
  • 作業の数が多すぎて正しく洗い出せる自信がない

残念ながらプロジェクトを完成させるには、ゴールの設定とすべての手順の踏破が必要です。
明文化するかしないかの違いだけで必ず実施することになります。
ゴールがふわふわしていると自分を見失います。

心を病む前に、自分の中のDXのゴールを決めましょう。
耕す畑のサイズを決めるのです。

「何を変えるのか、何に変えるのか、どのように変えるのか」を明確にし、
そこから逸脱するあるべき論やそもそも論はバッサリ切る覚悟をします。

DXの設計書④ – 食べられるサイズに分けよ

DXやれでは、パイが大きすぎます。

せめて食べられるサイズで投げてほしいものです。
これでは何をすべきかわかりません。

僕もプロジェクトマネージャーの端くれとして、
3桁以上のプロジェクトマネジメントをしてきました。

プロジェクト進行中、
プロジェクトの完成を確信する瞬間があります。
プロジェクト完成までの全ての作業内容が見えた瞬間です。

プロジェクトになる前でも、話を聞いた段階で確信するものもあります。
納品やリリース後になっても確信が得られないものもあります。

ちょっとした思考実験をしてみましょう。

DXの設計書③ – 成功はない、おおむね成功を目指せ

社長!ウチもクラウド化して生産性を向上させましょう!!

意気揚々と若い社員が社長に対してこんなセリフをいうCMを少し前に見かけました。

「クラウド化して生産性向上」は「風吹けば桶屋がもうかる」並みに、中身がブラックボックスです。

風吹けば桶屋がもうかる仕組み

- 突風で砂ぼこりが立つ
- 砂ぼこりが目に入り、視力を失う人が増える
- 三味線を買う人が増える(※江戸時代では、三味線弾きは視覚障がい者の代表的な職業でした)
- 三味線の皮の材料として猫の皮が必要になり、猫が捕獲される
- 猫が減るとねずみが増える
- ねずみが増えて、かじられる桶が増える
- 桶の修繕や買い換え需要が増え、桶屋が儲かる

参考:SAP 「なぜ“風が吹けば桶屋が儲かる”のか?「相関」と「因果」の関係を正しく理解」

DXの設計書② – DXを定義せよ

肚落ちしていないDXの理解に対し、周囲は容赦なく心を折ってきます。

「厳密には違う」と。

定義がふわっとしているDXの名の下、多くのお金が失われようとしています。
国内で回ってくれる分には良いんですけどね。

COVID-19の折、日本は大きく出遅れました。
ITの巨人、マイクロソフト様がDXで本気出すと言ってます。
国内企業はたくさん飛びつくでしょうね。

「DXはマイクロソフトの戦略そのもの」、日本MSが経営方針を説明

さて、デジタルトランスフォーメーション。
何気にネーミングセンスが良いんですよ。DXの"X"もカッコ良い。
ちょっと古い感じも良い。タカラトミーのメカのせいですね。
昭和おじさん達のDXに群がる様子が目に浮かびます。