設計の意図を残そう(なぜ残すのか編)

ワークフローを導入すると、業務は「ワークフロー図として明示される」ようになります。誰が、どの順で、何をするのか。それが図と設定として残り、担当者の頭の中から外に出ます。

これは確かな効果があります。担当者が異動しても、ケースは止まらずに流れます。次に何をすべきかはシステムが知っているからです。実行の属人化は、ワークフロー導入によって解決します。

ところが、数年運用したアプリで、こういう相談が起きます。「このアプリを直したいのですが、作った人がもういなくて、触っていいのか分からないんです」。

ワークフロー図はあります。設定もすべて見えます。それでも変更できません。何が起きているのでしょうか。

ワークフロー図が語らないこと

たとえば、購買申請のアプリに、次のような分岐があるとします。

  • 金額が 10 万円未満なら、課長承認へ
  • 金額が 10 万円以上なら、部長承認へ

設定を見れば、何が起きるかは完全に分かります。曖昧さはありません。

しかし、なぜ 10 万円なのかは、どこにも書かれていません。

  • 社内規程にそう定められているのか
  • 当時の責任者がそう決めただけなのか
  • 過去に問題があって、その再発防止で下げた数字なのか
  • 別のアプリの閾値と揃えてあるのか

後任者はこれを知りません。知らないので、判断できません。「20 万円に上げてもいいですか」と聞かれても、答えられません。触ると何が壊れるか分からないので、誰も触らないという結論に落ち着きます。

問題を隠す正常な稼働

この状態でも、アプリは正常に動き続けます。

毎日ケースが開始され、承認され、完了していきます。誰も困っていないように見えるので、問題として認識されません。

顕在化するのは、変更が必要になった瞬間です。規程が変わった、組織が変わった、新しい取引先の要件が加わった。そのとき初めて、このアプリは誰にも変更できないと分かります。数年分の実績が乗った、止められないアプリとして。

ソフトウェア開発における同じ問題

「コードはあるが、仕様書がない」。ソフトウェア開発の世界では、長く繰り返されてきた話です。

コードは、何が起きるか(what)と、どうやるか(how)を完全に記述しています。しかし、なぜそうしたのか(why)は記述しません。そして保守で必要になるのは、たいてい why のほうです。

では、なぜ仕様書は失われるのでしょうか。書かれなかったからではありません。多くの場合、最初は書かれています。問題は、別の場所に置かれたことです。

別の場所にある文書は、実装が変わっても更新されません。やがて実装とズレ、嘘をつき始めます。嘘をつく文書は読まれなくなり、読まれない文書は誰も更新しません。こうなると、文書はあっても役に立ちません。

ソフトウェア開発の世界で広く採られている対処は、文書をコードの隣に置くことです。コード内のコメント、コードと一緒に管理する説明書、変更ごとに残す変更履歴。変更する人の目に必ず入る場所に置けば、ズレたときに気づけます。

ワークフローアプリでも事情は同じです。設計意図を表計算ソフトや共有フォルダの設計書に置けば、同じことが起きます。

ワークフローアプリで起きやすい理由

しかも、専門知識なしにアプリを作れることが、この問題を悪化させる方向に働きます。

作る人が開発者ではありません。 業務部門の担当者が自分でアプリを作れることは、大きな価値です。同時に、その人は設計意図を記録するという職業的な訓練を受けていません。単に習慣がないだけです。

一人で作れてしまいます。 開発チームであれば、レビューの過程で「なぜこうしたのか」を必ず説明させられます。説明を求められることが、記録を残す動機になります。ワークフローアプリは一人で完結するので、その機会がありません。設計意図が一人の頭の中にしか存在しない期間が、そのまま何年も続きます。

変更の頻度が低いです。 毎日書き換えるコードなら、半年前の意図も覚えています。ワークフローアプリは、一度作れば年単位で放置されます。半年ぶりに開いたとき、作った本人ですら、なぜここをこうしたのかを思い出せません。

解決したものと、残ったもの

整理すると、こうなります。ワークフロー導入は、実行の属人化を多数の担当者から取り除きました。その代わり、設計の属人化をアプリ管理者一人に集中させました。

前者のほうがはるかに大きな成果です。しかし後者を放置すると、アプリの寿命がアプリ管理者の在籍期間で決まってしまいます。

幸い、対策に新しいツールは必要ありません。Questetra BPM Suite には、設計意図を書き残す欄がすでに揃っています。欄は足りています。決まっていないのは、どこに何を書くかです。

次回

次回は、その合意の作り方を扱います。アプリ名・工程名・項目名とメモの使い分け、そしてメモとバージョンメモの使い分け。2 つの軸で整理します。

設計の意図を残そう(どこに残すのか編)

Questetra Supportをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む