マガジンのカバー画像

ITトラブルの本を書いてます。

8
本
いつまで経ってもなくならないシステム開発のトラブルを裁判事例をもとに避けていこうという本をいくつか。あと、きまぐれにAIの本も書いてみました。
運営しているクリエイター
Yoshihiro Hosokawa

その仕様凍結、守られてますか？

拙著「エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと」のご紹介がてら、システム開発を成功させるためのポイントをご紹介する本連載、第四回も要件定義の続きです。 要件の追加・変更がひどすぎると裁判に・・・前回、要件定義について少しお話をしました。 私は以前に10年間ほど前まで裁判所でITに関するトラブルの調停や裁判の支援などを行なっていましたが、やはり裁判になるような大トラブルでも、その原因の多くは要件定義工程の不備にあるなあというのが率直な思いで、やはり何を

Yoshihiro H…

ユーザが行うべき業務要件定義

拙著「エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと」のご紹介がてら、システム開発を成功させるためのポイントをご紹介する本連載、第三回は要件定義についてです。 要件定義はシステム開発のキモシステムにどんな機能や性能を持たせるか、使い勝手やセキュリティをどうするかということを決めるのがこの要件定義という工程です。この工程は通常、システム開発の一番最初の方に行いますので、ここで誤った要件を決め、それが後になって分かってしまうとプロジェクトは大打撃を受けます。そ

Yoshihiro H…

業務フローってどう描くの？

拙著「エンジニアじゃない人が欲しいシステムを手に入れるためにするべきこと」のご紹介第２回です。まだ第１回をご欄になっていない方はこちらからご一読ください。 新システムの企画は業務フローからさて、DX室に "無理矢理" 配属された主人公のマサト君は、ある新システム企画の一環として業務フローを書くように命じられます。業務フローはシステム化対象となる業務の流れ、誰が何をして、次には誰が何をするかといったことを図示したもので、大体、以下のようなものが書かれます。 AS-ISのフロ

Yoshihiro H…

嫌いなIT部門へ異動！さあ、どうする？

はじめに先ごろ出版した自著のまとめを章ごとに８回ほどつづります。 タイトルは「エンジニアじゃない人が欲しいシステムを手に入れる為にすべきこと」・・・長い！でも、だいたいこんな内容を小説風に書いてます。 心ならずもDX室に異動となったIT素人の主人公が、どのように覚悟を決め、システム企画やプロジェクト計画を行い、欠落したシステム化要件への対応ややる気のないベンダー、大幅な手戻りなどにどう対応するか、そんなことを追体験しながら、ＩＴ素人の方がＤＸに取り組む上でのポイントをまとめて

Yoshihiro H…