ワークフロー アクセス管理の落とし穴
IT統制ではアクセス管理が重要である。システムオーナー部門の承認を得たうえで、情報システム部門がアクセス権の設定作業を行うのが正しいコントロールである。しかし、情報システム部門が管理者権限を持つためにシステムオーナー部門の承認を得ずにアクセス権を設定しまうことが発生するという落とし穴がある。
ワークフロー 
兵法 プロジェクトの立ち上げで考えるべき５つのこと
プロジェクトを立ち上げるときには、どのようなことを考えるべきか。 孫子は始計篇で５つのこと「道・天・地・将・法」を考えよと言います。道は道理、大義名分。天は天の時、タイミング。地は地の利、ポジショニング。将は将軍、リーダ。法は組織管理、統制。
兵法 プロジェクトを立ち上げるときの心構え
プロジェクトを立ち上げるときには、どのような心構えで臨むべきか。孫子は始計篇の冒頭で次のように言います。戦争は国家の重大事であり、国民の生死、国家の存亡にかかわるものである。良く良く、考えなければならない。
ソフトウェア 要件の裏を取れ！
刑事ドラマで事情聴収した内容の事実確認を「裏を取れ！」という。同様にヒアリングを主体としてシステム技術者が要件定義を行う場合、要件の事実確認を怠るべきではない。「裏を取れ！」はやはり重要である。運用試験以降にあるはずのデータが無いことが発覚すれば、大きな手戻りが発生する。それを思えば「裏を取る」手間を惜しんではならない。
RPA 他人任せDXのツケ
業務部門が自らRPAを活用してDXを推進すれば要件の不備に早く気が付き軌道修正ができる。しかし、IT部門などがロボットの開発を引き受け、従来のシステム開発と同じようにヒアリングにより要件定義をする場合、思わぬ事態になることがある。つまり、従来のシステム開発と同じように要件定義を失敗する。RPAのようなノーコード開発によるDXでも、要件の事実確認は重要だ！
レガシシステム そうだ！夜間バッチにしよう
メインフレームのレガシで実施していた製品構成展開の夜間バッチを、オープン系のPLMで昼間実行するようになりビジネスのアジリティが向上した。しかし、PLMで部品情報を更新する設計者が増えたためデッドロックが発生。解決策として製品構成展開をRPAを活用して夜間バッチに戻すことになった。
ワークフロー ノーコード開発の大義
なぜ、DXではノーコード開発が有効なのか。そこには業務部門がDXを推進するという大義があるはず。ならば、例え簡単なコードであっても安易に開発者が手を出すべきではありません。
RPA ロボット育成計画
人を育てるには人材教育計画が必要であるのと同じように、ロボットを育てるにも教育計画が必要である。それは、自分の仕事を整理し、ロボットの開発能力を高める結果にもなる。最初から高度なことをロボットにやらせようとして時間ばかりを費やすのは得策ではない。
ワークフロー 誰にでもできる！微コード開発
DXの推進に有効とされるノーコード開発。しかし、微量のコードを書くことでやりたいことができることがある。そのために大上段にプログラミングを学ぶ必要は無い。ノーコード開発に拘ったり、コードを書くことを最初からあきらめないほうがよい。それをワークフローシステムの簡単な事例で示す。
ソフトウェア 無欠陥より価値創出を！
日本のものつくりは高品質。これと同じようにソフトウェアにも求めすぎていないだろうか。無欠陥なソフトウェアを作ることは難しいのも事実。それより新しい価値を創造することを主眼にアジャイルに作るのが得策ではないだろうか。完璧を求めすぎず固執せず、８０点の完成をめざそう。