【C#】作業依頼書システム案件が頓挫した件
はじめに
昨年5月から、ひとりで少しずつ作っていたC#の作業依頼書システムというものがあります。
この度、その作業依頼書システム作成案件を、いったん凍結することとなりました。
ひとりで開発していくには、色々と足りないものが多かったのです。
経緯
作業依頼書システムの作成に着手して早１年が経ちました。着手当初は特に明確な納期もなく、業務の隙間時間や、片手間で少しずつ作っていました。
しかし、ついに先日の情報企画課内ミーティングの場で、明確なタイムリミットが提示されることとなりました。
「８月１日までに課内リリース・テスト検証報告が間に合わなければ、この案件は凍結する」とのこと。
もともとは６月１日にリリースする予定で課内には話をしていましたが、５月末時点で、設計の甘さ、保守性の低さが発覚したことや、システムテスト未実施などで、リリースするには至らないと判断。課内ミーティングの場で、課内レビューの中止とリリース延期を伝えました。課内４名には少なからず迷惑をかけてしまったことと思います。
最終的に、院内全体リリースを９月１日とし、先行して８月１日から課内リリースを実施ということが決まりました。課内リリースでは、４名によるテストで、バグや改善箇所の発見・報告をしてもらう予定でした。
課内リリースまでにやる予定だったもの
課内リリースまでに、「仕様書の作成」・「テスト報告書の作成（テストケースの作成と実施報告）」・「既存コードを共通ライブラリ化」を完了させる必要があります。
しかしながら、定型業務である毎月のレセプトオンライン請求業務、６月２２日締切の厚労省DPC再提出業務、７月下旬締切の厚労省DPC４・５・６月分提出業務の作業ボリュームが相当大きく、近日にはDPC業務システムのアップデート作業、７月１日のシステム委員会と８月１９日の電子カルテシステムレベルアップ等、イベントがひかえています。これに加え、毎日の問い合わせ案件の対応があり、作業依頼書システム関連の作業を業務時間内に行うのはかなり難しい状況でした。
そもそもなぜ作業依頼書をシステム化しようとしたか
①手書き作業依頼書の問題
2015年1月に、作業依頼書運用をスタートしました。当初は、紙ベースのままの運用で良いかと思われましたが、下記の問題が発生、これらの解消のために、システム化を計画することとなりました。
＜問題点＞
・手書きの依頼書をいちいちExcel台帳に入力するのが手間
・依頼者は共有フォルダの依頼書Excel原本を操作するので、意図せずレイアウトを変更されてしまう
・依頼書の記入漏れが多い
・そもそも依頼書を書くのを面倒がり、書かずに案件依頼する人が後を絶たない
②システム化によるメリット
問題点の解消だけでなく、メリットも多くあります。
＜メリット＞
・依頼者が依頼案件の作業過程・成果物を把握できる
・問い合わせ案件を公開することで、情報企画課の業務を見える化できる
・問い合わせ内容を集計し、ナレッジデータベースへ発展が可能となる
・依頼者が添付資料を紙で印刷・持参する必要がなくなる（添付ファイル保存フォルダで代用可能）
③プログラミングスキル習得
開発者である自分にとっても、プログラミングを学ぶ良い機会です。業務システム開発は全くの未経験ですが、実際に手を動かしていくことで、多くのことを学びました。
＜自分自身にとってのメリット＞
・SQL Server Management Studio で新規テーブルやフィールドを作成、データ型を決める作業を通じて、データベースの概念、構造を（おぼろげながら）理解しはじめた
・Visual Studioを使用したC#プログラム作成の初歩的な部分が（おぼろげながら）理解しはじめた
・DataGridViewを使用した表作成の基礎を（おぼろげながら）理解しはじめた
・データベース接続・テーブル操作の書き方を（おぼろげながら）理解しはじめた
・オブジェクト指向を（おぼろげながら）理解しはじめた
・関数、変数、引数の意味を（おぼろげながら）理解しはじめた
・使いやすいユーザインターフェースについて考えるようになった
など・・・
システム化が頓挫した理由
①自分自身で非現実的な納期を設定していた
納期を9月1日としていましたが、今から考えても、相当無理な設定をしてしまったなと思います。
ただでさえ、レセプト業務とDPC業務で手一杯なのに、さらにこんなカツカツな納期で仕上げようとしていたのですから…
あと二ヶ月で、既存のクラスの共通モジュール化、ゼロから仕様書を作り、各種テストを終わらせテスト報告書を作り、課内リリースをしようと意気込んでいました。
しかし、通常業務をこなすだけですぐ夕方になるような毎日です。しばらくは、業務時間外に、終電間際まで自主的にこの残案件を消化していきましたが、すぐに「これはもうダメかもわからんね」と気づいたのです。
②独りよがりな作りになっていた
最初から、ひとりでC#で作ることは課内に伝えていました。
しかし、開発手法やスケジュールなどを全く意識せず、いきなりコードを書き始め、Windowsフォームも後先考えず、なんでもとりあえずペタペタ貼り付けていきました。
それがいけなかったのです。
今回の件で、後悔したことは下記の五つ。
・もっと早期の段階から課内レビューすべきだった
・まず要件定義書や設計書を作るべきだった
・いきなりコードを書かず、フローチャート画面遷移図などを紙に描いてみるべきだった
・もっと周りに聞けばよかった
・そもそもC#の基礎的な理解が出来ていなかった
ひとまず五つを挙げましたが、実際にはもっと多く出てきます。
そんな素人が、いきあたりばったりで開発しようとしたわけですから…
それ以上にいけなかったのは、「C#の勉強が目的になっていた」ということです。
本来はユーザにとって何の必要もない機能なのに、「自分が使ってみたいから」という身勝手な理由で、どんどん追加していったのです。
その結果、ユーザにとって非常に使いづらいシステムになってしまったわけです。
課内レビューではあっという間に50箇所以上の修正箇所が見つかり、いかに自分が好き勝手に作ってきたかが分かりました…
③基本情報技術者試験に合格したことで無駄に勢いづいてしまった
基本情報技術者試験の合格によって、「自分はプログラミングができるんだ」と勘違いしてしまい、その勢いに乗って、無理な納期を乗り切ろうとしていました。
根性論や精神論を振りかざすのではなく、ロジカルに考えて計画性のある納期設定をすべきでした。
今後の展開
①作業依頼書システムのことから離れる
この案件は会社全体として引き継ぐこととなりました。おそらくいちから作り直しになることでしょう。
一年もかけてコツコツ作ってきたものを手放すのは惜しいのですが、ここでいったん線を引きます。
②既存のVBAやVB6プログラムのメンテナンスを怠らない
今回の案件にタスクを振りすぎて、今動いている既存プログラムのメンテナンス対応が遅れ気味になっていたのは、正直なところあります。
本来の業務は、既存システムの保守運用のはずです。それらを疎かにしていては院内SE失格です。
③自分用の小さなプログラムから始める
C#の基礎すら理解できていないのに、いきなり院内数百人に向けた業務システムを作ろうとした事が間違いでした。
まずは、自分自身の業務を助けるための、小さなプログラムから作ろうと思います。
自分しかユーザがいないので、いつでも好きなようにソースコードやフォームを変更できます。
勉強し、力をつけたら、いつか院内向けの業務システムにチャレンジさせてもらえるかも知れません。
今は地道にプログラミングの学習をする期間です。
