タグ: DXの設計書

コンサル発信のバズワードに踊らされて
やりたくもないDXに取り組まれているみなさまへ。
まず失敗します。だってゴールを決めてないのですから。

ゴールが無ければゴールテープは切れませんし成功か失敗したのかも判断もできません。肝は・・・。


  • DXの設計書㉖ – 内製でいくべきか、外製でいくべきか

    DXの設計書㉖ – 内製でいくべきか、外製でいくべきか

    社内システムを開発する際 「内製でいくべきか、外製でいくべきか」が議論になります。 うそです。議論になりません。 製造業に務めるエンジニアとして好き勝手やらせてもらってる立場から、 今回は内製でいくべきか、外製でいくべきかについてお話したいと思います。 内製という言い方には様々な捉え方があると思います。 ここでは最終成果物の形にするのは誰かという観点で内製と外製を切り分けます。 要はプログラミングするのは誰か?です。 プログラミングする人が内部の人なら内製。外部の人なら外製。 それでいきます。 では、よろしくお願いいたします。


  • DXの設計書㉕ – アジャイル方法論

    僕がアジャイルに興味を持ったのは10年ほど前でした。 受注後、どんどん変わっていくお客様の要求に何とか対応できる方法が無いかを検討したのが最初です。 しかしながら予め成果物を決めてから始める請負契約と全くマッチせず、 契約成立後、要求詰め放題プランになってしまいました。 今、転職し契約に縛られない働き方ができるようになったので改めてアジャイルについて考えてみます。 今回僕が取り組もうとしているDXにおいてアジャイルは肝になると考えています。


  • DXの設計書㉔ – パッケージという選択肢

    世の中に数多存在するパッケージソフトウェア(以下パッケージ)。 業務を包括するパッケージも存在します。 ERP(Enterprise Resources Planning)などはその最たるもので、数も多いし歴史も長い。 それなりのお値段もしますが、 スクラッチでつくるより値段も労力も抑えられるようになってきました。


  • DXの設計書㉓ – 既存システムの機能拡張

    既存システムを機能拡張する場合、 他の機能への影響を考える必要があります。 一般に「ちょこっと機能を足すだけ」と思われがちですが、 既に存在する処理に新たに処理を加えていくのは中々骨が折れます。 今回は既存システムの機能拡張についてご説明します。


  • DXの設計書㉒ – 開発者のユートピア新規開発

    新規開発はしんどさもありますが楽しいものです。 規模にもよりますが、[昨今の請負開発の状況 – ソフトウェア開発分析データ集2020](premium-tsubu-hero.net/technology/it/ukeoi-2020/)の”SLOC(コード行数) – 開発規模”の内容から推測するに、10000行以下のシステム開発が中心でしょう。クラスの数で言えば30以下。 偏りはわかりませんが、10000行以下のものも正規分布するなら10~20クラスくらいが中心ですかね。 これくらいの規模でしかも新規開発。 時間に余裕があれば非常に楽しいものです。 この楽しさはおそらく脳内の分泌物によるものでしょう。 知らんけど。


  • DXの設計書㉑ – システムリプレイスは簡単?ありえません。

    DXをやるにあたっておそらくシステムリプレイスが浮上してくるでしょう。 周りは簡単に言うかもしれません。 パッケージ入れるだけでしょ? これまでスクラッチ開発でのシステムリプレイスについては何度か述べましたが パッケージを使用したシステムリプレイスは語ってきませんでした。 今回はパッケージを使ったシステムリプレイスについてご説明します。


  • DXの設計書⑳ – クラウド?オンプレ?

    定期的にお金が出ていくクラウドの仕組みが世の中に受け入れられ始めてきました。 また、社外にデータを置くことにも抵抗がなくなってきたように感じます。 クラウドサービスの形態はさまざまです。 端末やOS管理がいらないソフトウェアだけを借りる Saas(Software as a Service)を対象にお話ししていきます。 クラウドを選ぶべきかオンプレでいくべきか


  • DXの設計書⑲ – 生産管理の仕事を楽にしてみよう

    前回の記事でコミュニケーションがコストであることをお伝えしました。 特に情報の再利用性の悪さとメールなどの生産性の低さについて述べました。 しかも、自分だけでなく相手の時間も奪うというね。 もう少し仕様を見直してほしいところです。 さて、みなさん軽視しがちのコミュニケーション。 実はこの業務、多くの方の作業見積もりに含まれていません。 **今日、結局何もやってないなぁ。一体一日何をやっていたんだろう。**とか **残業時間に入ってから何だか仕事進むんだよね。**とか 思っている人の業務のほとんどはコミュニケーションです。 しかしアウトプットが使い捨てなので何も残りません。 前回同様、生産管理の人を中心にコミュニケーションの改善を試みようと思います。 今回はパッケージのお話です。ようやくDXっぽい。


  • DXの設計書⑱ – コミュニケーションはコスト

    前回、部署間の関係図を書いて生産管理がかわいそうという話をしました。 改めて考えると「生産管理」。もう名前からかわいそうです。 生産を管理する。対象がざっくりしすぎています。 ちなみに僕は生産管理の人ではありません。 少 […]


  • DXの設計書⑰ – 会社全体を俯瞰してみる

    会社全体を俯瞰してみましょう。 言うはやすし行うは難し。 とはいえ、会社の全体像を見るのはそれほど難しくありません。 雑にまとめてみても見えてくるものは多いです。 たたき台を作れば色んな人が補ってくれます。 「厳密には違 […]