気が付けば前回の投稿から随分と時間が経ってしまいました。 仕事の方がなかなかにスパイシーな状況であったため、平日は殆ど何もできず、休日は家の中のことや、各種手続き、そして何より疲労の回復が最優先となり、ブログ記事を書く余裕を持つことができなかった次第。 しかし、それらのゴタゴタもようやく一段落し、気力・体力ともに以前の水準まで復旧しつつあります。 そんなわけで、文章作成のリハビリも兼ね、以前より構想していた「業務管理システムの内製」について、思うところを書いてみたいと思います。

私はこれまでに幾つかのお客様のオフィスに入って仕事をさせて頂いてきました。 その際、どこの現場でも共通して感じるのは、製品として提供されるソフトウェアシステムの開発技術と比較して、社内の業務を管理・支援するシステムが圧倒的に貧弱である、ということ。 顧客向けのプロダクトして創意と工夫を凝らしたソフトウェアを生み出す一方で、勤怠・スケジュール管理, 内部レビュー, インシデント報告, 各種申請・稟議といった社内業務は市販のグループウェアや、Excel などによって賄われている場合が殆どです。 もちろん、それで業務が効率的に回っているのであれば問題はないのですが、実際のところ、そうした本質的でない作業 (およびそれらが正しく行われているかのチェック) にかなりの時間と労力が費やされています。 ひとつひとつの手間は些細なものでも、職場全体で1日あるいは1ヶ月あたりにこうした作業に浪費されるコストを見積もってみると、「必要経費」として簡単に割り切ることが難しいほどに大きくなるのではないでしょうか。

私は以前、自分の勤務時間を毎日4ヶ所に入力しなければならない現場に入ったことがありましたが、それぞれの入力ファイル/画面上での配置や書式が異なっていたため、食い違いなくデータを記入するために (それなりに) 神経を使いました。 各作業員が留意に努めて、1日あたりの記入ミス発生率を0.5%まで抑えたとしても、20人がいれば、そのうちの誰かが間違える確率はおよそ1割。(1 - 0.995²⁰ ≅ 0.095) 平均すれば10日に一度は集計にエラーが紛れ込む計算になります。

flint blog: Less Chance to Make Mistakes

とは言え、こうした社内業務のためのシステムを自分たちの手で作るとなれば、やはりかなりのコストが掛かることは想像に難くありません。 しかしながら、システムの内製は、適切な管理・運用を行うことさえできれば、それを補って余りあるメリットを生み出すことができる、というのがこのエントリにおける私の主張です。

市販のグループウェア、あるいは Excel ワークブックなどを使用してデータ入力を行う際に、以下のような事象に遭遇することはないでしょうか。

- 空欄のままにしておかなければならない項目

(例: 報告者は「承認日」の欄に記入してはならない。)

- 決まった値を入力しなければならない項目

(例: 「該当部署」の選択は必ず自分が所属する部署とする。)

- 使用されることのない選択肢

(例: 「設計書の種類」の "詳細設計書" は、該当する業務フローがないため使用されない。)

- まとめて行うことのできない操作

(例: 入力画面からは直接提出することはできず、一度保存した上で「状態変更」画面を開き、"作成" から "提出"へ変更する必要がある。)

- 必要な情報を入力する欄がない

不具合が発生した機器のシリアルコードは「備考」欄に所見とともに括弧書きで記入する。

空欄のままにしておかなければならない項目にユーザが入力できてしまうというのは、ユーザインターフェイスの設計として落第。 入力不可 (非活性) の状態にしておくか、そもそも表示されないようにしておかなければなりません。 定められた値を指定しなければならない項目であれば、その入力は自動で行われるようにするべきでしょう。 「部署」の入力値 (あるいは規定値) はログオン中のユーザの情報を参照して決定、「申請日」は (特別な事情がない限り) 現在の日付を採用するのが一般的です。

汎用的に設計されたツールやフレームワークは、当然のことながら特定の業務形態に当てはめたときに、沿わない部分が出てくることは避けられません。 そして、その部分を「運用でカバー」するとなれば畢竟、入力時の妥当性検証や、集計時の整合性確認はすべて人の目、そして頭脳を使って行われることに。 なんという無駄。 なんという非効率。 人間の知力, 集中力, そしてなにより貴重な時間を、プログラムで自動化することができるような作業に投入するというのは、労働力の価値と本質を見失った行為と言えます。

自社で内製したシステムであれば、少なくともこうした問題は起こらないはず。 必要な機能だけを搭載した、自社業務にぴったりと沿ったシステムが作られるでしょう。

とは言え、内製をすれば無条件に自社の業務に適合するシステムができあがるというわけではありません。 システム化にあたってまず必要となるのは、業務内容をソフトウェアで処理することができる形式で記述し直す、所謂「モデル化」の作業。 以下に挙げるような要素をひとつずつ客観的に検証していくこととなり、その正確な理解へと繋がります。

• 取り扱われる情報の形式 (フォーマット)
• 業務に携わる人間の権限と役割 (ロール)
• 処理が行われる順番とタイミング (フロー)

また、その過程において次のような現行業務の「穴」が判明することもしばしば。

• 各担当者ごとに異なるやり方で行われている作業 (手順が明確に規定されていない)
• まったく必要がないにも関わらず行われている作業 (手順書改定時の削除漏れ)
• 複数の担当者によって重複して行われている作業 (情報共有の不足)

そのような場合には、作業の責任者・担当者と話し合って問題点を整理して新しいルールを設定することも必要となります。

そうして設計されたシステムが使いづらく、評判が悪いとすれば、それは業務に関して本質的な何かを見落としているか、あるいは規定の仕方に何らかの「ねじれ」が存在する証拠。 業務をモデル化することは、それ自体の妥当性を見直す絶好の機会でもあります。

製品として開発されるソフトウェアに求められるものは、他の何を措いてもまず「安定」。 どんなに優れた点があっても、頻繁にエラーを発生したり、ダウンしたりするようでは使い物になりません。 しかしながら、この「安定志向」が技術の停滞を招く大きな要因となっていることもまた事実です。

• 既に稼動しているプログラムには、多少効率や可読性に問題があっても手を付けない。
• 追加機能は可能な限り既存コードのコピーを元に作成する。
• 新しいコンポーネントやライブラリの導入は慎重に。

新規に開発されたにも関わらず一昔前どころか数世代古い技術によって組み立てられている、あるいは、コード全体が非常に「雑」に書かれており、ブラックボックステストによってかろうじて動作が保証されているシステムというのは頻繁に眼にするところ。 そうしたシステムのプログラムが低品質のままに肥大化してく傾向があるのはひとえに、ここで述べたような「安定志向」に由来する進歩に対して消極的な姿勢が根本的な改善の実施を妨げるからです。

多くの企業は「新しい技術の習得に努めよ」との訓を掲げており、また、大半のエンジニアもできれば勉強をしたいと考えているはず。 けれども、実際問題として、それを行うことが可能なのか。 勤務中は顧客向けに安定第一のシステムを組むことにすべての時間を費やさなければならないとなれば、残るは休日か夜間ということになります。 あまり現実的でない選択肢ですが、そこは体力と情熱と家庭を顧みないことで乗り切るとして、次の問題は、その習得した技術を業務に適用することが妥当かどうかをどのように実証あるいは検証するのか、ということ。 個人が趣味的に作成するソフトウェアは、業務として開発されるシステムと比較して、どうしても小規模かつ単純なものにならざるを得ません。 そのため、ある技術が前者に対して有効・妥当であっても、後者に対しても同様に作用するという確証とは言いがたいわけです。

この問題に対しても「システムの内製」が一定の解決となり得る、というのが私の考え。 社内のシステムであれば、多少チャレンジングな機能であっても、試験的な導入を行うための障壁は低く設定されます。 もちろん、現行の機能が阻害されないよう十分に配慮することが求められますが、不具合が発生した場合でも、利用者からのフィードバックが開発者に届きやすいため、迅速な対応が可能でしょう。 ユーザ数および利用頻度も製品に近いものが得られるため、新しい技術を「試す」には格好の場。 さらにチームで作業を行うとなれば、社内での検討・議論および情報共有を促進する効果も期待できます。

また、先に述べた「業務モデル化」と併せて、社内システムの設計開発と保守運用は新人エンジニアのトレーニングにも最適です。 と言うのは、ヒアリングやトラブル対応など利用者とのコミュニケーションが必要となるを含めた業務全般を、対顧客のそれと限りなく近いスケールで経験することができるため。 「OJTだ」としていきなり現場に放り込まれるよりも、社内で業務に慣れていく方が、最初は誰もがやらかす失敗を、本人にとっても会社にとっても小さいダメージで、そして結果的にはより多く、経験として蓄積できるでしょう。

私が観察した範囲の話ではありますが、IT業界においては、技術的なスキルの程度およびその向上はほぼ完全にエンジニア個人の資質に依存しており、企業の存在はほぼこれに直接的な関与をしていません。 その原因は、従業員に対して業務としての「学習」が認められにくいということと共に、職能として有用なレベルのノウハウは、業務かそれに近い規模での開発の中でしか培われない、ということにあります。 製品に対して開発効率 (工数の削減・縮小) と安定が (そして、ともすればそれのみが) 厳しく求められる現状では、業務の中に「学習」の機会・余地を確保することは至難であり、そうであれば、技術面において従業員を育てる術を企業が持たないのも無理からぬことかも知れません。 しかし、そうした無為が「技術者を使い捨てにする」という業界の評判に繋がっている面もあるのではないかと思っています。

そんな中で、業務システムの内製は、効率化と技術育成を両立させることのできる数少ない、かつ比較的簡易な手段のひとつ。 明日からいきなり業務のすべてを賄うシステムを自前で、というのは無理があるかもしれませんが、手の届く範囲、例えば、勤務時間や弁当注文の管理から初めてみるのはどうでしょうか。

Every adventure requires a first step. Trite, but true even here.
(どんな冒険にも最初の一歩が必要だ。陳腐な言い方だが、けだし明言だね。)

American McGee's ALICE