それでも開発するべきかを検討する
明らかに効果が出そうかどうかって、経験値で判断できるのは本音ではありますが、それでも開発すべきかを検討することは必要だと思っています。
私の経験から学んだ手順を紹介します。
開発期間が長い場合（１ヵ月以上）は、ほぼこの手順を踏んています。
■ 実務を大まかに可視化する
まずは、調査した実態を絵にします。
自分は、初めは、手書きが多いです。
そして、改善する範囲を決定します。
データの流れや手順、コメントを記入します。
実際は、ここにかかっている工数を記入していきます。
■ 業務を詳しく見る
改善した気持ちが先走りして失敗するケースも少なくありません。
業者にも、他部門にも、情シスにも頼めない。
故に、全部自分で完成させるしかありません。
開発時間は少ないし、「設備投資は０円」で進めなければなりません。
よって、自力で開発できるかの判断材料を揃えます。
さらに、担当者に詳しく業務をヒアリングします。
やる事は下記のようなこと。
｜最終目的を確認する
そもそも、何をして、何を目的にしているか、担当者に聞きます。
担当者に聞いても分からない場合、その責任者に聞きます。
｜インプットの資料やデータを揃える
今回の場合は、初めに紙に出力したものではないです。
荷姿情報や運賃が記入された紙になります。
また、運賃の早見表も含まれます。
｜記入された意味を質問する
この手の業務は長年引継ぎされている業務なので、書いてある記号や数値や色に重要な意味が含まれるケースは少なくありません。
記号の意味、数値の意味、色の意味を必ず担当者に聞くことです。
｜例外処置のケースを質問する
実務では色々なケースが発生します。
質問する前に、想定しうる例外ケースを質問しておきます。
例えば、
・トラブルが発生して出荷を止める時、どうするのか。
・キャンセルがあった場合、どうするのか。
・緊急で追加があった場合、どうするのか。
・出荷先変更があった場合、どうするのか。
・日程変更があって、先送りする場合、どうするのか。
・災害があって、集荷してくれない場合、どうするのか。
ま、こんな感じです。
例外なんて、発生する可能性低いから、どうでもいいじゃんって考えるのは、ダメです。トラブルがあっても、対応できるように作り込むのは必須です。トラブルがあった場合の想定もシステム作りの重要な作り込みです。
■ 集めた情報から実現性を考える
自分のプログラミングの実力から実現性を検討します。
集めた情報から改善する業務の範囲と「こうすれば自動化（改善）できる！」というアイデアを出します。
実際には、３週間くらい考えていました。
結論しては、下のようなができれば、改善できると確信しました。
｜運賃の早見表をＤＢ化
配達業者と配達先の都道府県と重量、もしくは荷姿のサイズの運賃表がＤＢ化できれば、改善は不可能と見ました。
ただ、運賃は変動したりサービス内容が変更するから、メンテナンスは直感的に変更できるようにしなければダメ。
これは Access で実現できる自信あり。
｜都道府県が未記入の場合あり
運賃計算するとき都道府県は必須。
郵便番号は必須で必ずデータがある。
ＪＰ（日本郵便）のｗｅｂから都道県が取得できるはず。
これは Selenium Basic で取得できる自信あり。
｜荷姿の入力作業
重量は手書きしてるけれど、荷姿は使った段ボールの種類を記入している。
たしかに、サイズをいちいちシステムに入力することは、作業者の負担を増やしてしまう。
カスタム段ボールは、サイズを計っているけれど、定型段ボールは、段ボールの記号を記入している。
段ボールをコード化して段ボールのコードからサイズを求めるようにするればできる。
｜荷姿や重量の転記の限界
現場は製品と伝票の山。夕方には集荷がくるので、時間との闘い。
兎に角、梱包が最優先。
よって、Accessを立ち上げながら、荷姿を入力させるのは、不可能と判断。
全部の製品の梱包が終わった段階で、荷姿や重量を入力させるしかいない。
と、他にもありますが、理想と現実のギャップをリストアップして、その対策を書いていきます。（もう、脳みそフル回転です！）
で、自力での対策が難しければ、その項目は、自動化（改善）から除外します。
そして、ここで重要なことは、大まかなシステムのアーキテクチャを絵にすることです。その後の見積計算で利用するからです。
■ 改善範囲の現状工数を測定する
まずは、現状の工数を測定します。
後々、偉い人に「こんなアプリ作るんで、いいですか？」って許可を取る時に必ず必要になります。
さらに、開発見積と比較してアプリを作る価値があるかの判断材料となります。
どんなに忙しくても測定をしましょう。
今回の場合、こんな感じです。
＜運賃を宅配指示書に転記する時間＞
４５分×１人×毎日＝４５分／日
４５分／日×２０日／月＝９００分
９００分×１２ヶ月／年＝１０，８００分／年
＜Ｒ／３に運賃を転記する時間＞
７０分×２人×毎日＝１４０分／日
１４０分／日×２０日／月＝２，８００分
２，８００分×１２ヶ月／年＝３３，６００分／年
＜合計＞
１０，８００分／年＋３３，６００分／年＝４４，４００分／年
これが実態の工数になります。物凄い工数です。
年間で算出します。
■ 改善出来た時の工数を妄想する
ま、ツールなんて完成していないので、完全に妄想になりますが、無くせる所、減らせる所、増える所を考えて、改善後の工数を妄想します。
改善後の妄想もある程度システム構想が出来ていないと出来ません。
そこで、現実と理想のギャップリストからある程度システム構想ができます。
今回の場合、こんな感じです。
＜運賃を宅配指示書に転記する時間＞
０分
＜Ｒ／３に運賃を転記する時間＞
１０分
＜Accessに荷姿情報を入力する時間＞
２５分×１人×毎日＝２５分／日
４５分／日×２０日／月＝５００分
５００分×１２ヶ月／年＝６，０００分／年
＜住所データ是正する時間＞
５分×１人×毎日＝５分／日
５分／日×２０日／月＝１００分
１００分×１２ヶ月／年＝１，２００分／年
＜合計＞
６，０００分／年＋１，２００分／年＝１，８１０分／年
ま、それなりに工数はかかりますね。
こちらも、年間で算出します。
■ 開発見積を算出する
概算の効果工数は、年間で４２，５９０分の効果が出ます。
前の記事でかいたように、自分の場合、開発期間は、１年で開発できるかが大きな目安の一つになります。
年内で刈り取りができるかを大まかに計算します。
自分の場合、下のような感じで見積を出します。
｜テーブル
テーブルは、１個に対して６０分計算です。
項目数に関係なく、６０分計算にしています。
｜印刷（レポート）
レポートは、１個に対して２００分計算です。
｜データインターフェース
データインターフェースは都度作り込みが必要な所なので、大目に見積します。１個のデータに対して、３００分計算です。もし、インプットとエクスポートで２個あれば、２倍します。
｜マスターメンテ
マスターメンテナンスの画面は、難易度によってわけます。
難しい：１画面に対して、２，０００分
中くらい：１画面に対して、２００分
簡単：１画面に対して、２０分
｜データ照会画面（フォーム）
こちらも、難易度によって変わります。
難しい：１画面に対して、２，０００分
中くらい：１画面に対して、２００分
簡単：１画面に対して、２０分
｜データ登録更新画面（フォーム）
こちらも、難易度によって変わります。
ただし、ここは、画面の数ではなく、機能の数で計算すること。
難しい：１機能、２，０００分
中くらい：１機能、２００分
簡単：１機能、２０分
｜システム内で利用する関数
こちらは、個数の算出が難しい所があるので、一律で１，０００分で計算。
ま、正直、ここの難易度は、完全に個人的感想になってしまいますが、いいんです。
で、ここで、見積工数を出す時に重要な事があります。
自分が思っている工数の倍で、見積を出す事です。
自分が思っているほど、自分は優秀じゃありませんから。
さらに、トラブルは常に考えた方が良いです。
今回の見積はこんな感じです。しかも、予測です。
＜テーブル＞
１４個×６０分＝８４０分
＜レポート＞
１個×２００分＝２００分
＜データインターフェース＞
インポート１個×３００分＝３００分
＜マスターメンテナンス＞
運賃メンテ（難易度：高い）＝２，０００分
荷姿メンテ（難易度：低い）＝２０分
その他のマスタ３個（難易度：中）＝６００分
＜データ照会画面＞
履歴の紹介（難易度：中）＝２００分
＜データ登録更新画面＞
荷姿入力（難易度：高い）＝２，０００分
荷姿補助入力（難易度：高い）＝２，０００分
ＳＡＰ操作（難易度：中）＝２００分
都道府県取得（難易度：中）＝２００分
＜システム内で利用する関数＞
一律１，０００分
＜合計＞
開発工数 約 ９，５６０分
■ 開発日程の計算
算出した開発工数から開発日程を計算させます。
個人差はあると思いますが、自分は、１日に２時間計算で行います。
９，５６０分 ÷ １８０分／日 ＝５３．１日
・・・ん、約３ヶ月ですね。（実際は、１．５ヵ月で開発しました）
■ 総合的に判断してスタートさせるか判断する
今回の場合は・・・
＜現状の実務工数＞ ４４，４００分／年
＜改善の予想工数＞ １，８１０分／年
＜予測の開発工数＞ ９，５６０分
─────────────────────────────
＜効果＞ ３３，０３０分／年
＜開発期間＞ ３ヶ月
今回は、工数ですが、実際は、金額でアピールします。
人件費は固定費なんで、分単価があるのが普通です。
仮に３０円として計算すと、年間９９０，９００円／年の効果を出す事ができます。
それだけではなく、無形効果を付加させます。
今回の事例では、下記の付与される無形効果があります。
・読み合わせ作業、ＳＡＰ手入力の廃止で、空き時間確保
・残業時間に行っている運賃入力を無くせる
・運賃の早見表をいちいち見ることが無くなる
など、人にかかるストレスが軽減されることを書きます。
と、数値以外の改善ポイントも書き留める事が重要です。
もし、見積段階で、年間の効果が少ない、出ない場合は、ツールを作成しない事が吉です。
ただし、例外あり。
組織の偉い人からの指示がある場合です。
この場合は、業務命令になりますからね。
■ 組織内でプレゼンする
感覚的に「これは、絶対に大きな効果がでる！」ってわかっていても、私の場合は、必ず見積と改善の対比をしています。
そして、これらの資料を纏めて組織内でプレゼンをします。
これは、下のようなメリットが出ます。
・上長の承認と同時に、職場の同意が同時に取れる
・自分アピール
・堂々とプログラミングできる
・自分に使命感（責任感）を強く持たせる事になる
・納期を設定して完成させ職場の信頼を高める
もし、組織内でプレゼンが難しい場合は、個人面談の時に、アピールします。そこで、承認が取れれば良いのです。
承認が取れる前に正式な開発に着手は、ご法度ですよ。
よっぱおじさんと約束です。
■ おしまいに
そんなことより、今回はこんな地味な記事で、すいません。
ま、市民開発者てこの見積や効果を計算していない人が多いと思うのです。
間違ってるよ！こんなやり方！って思う人もいるでしょうね・・・
もしかしたら、「古い！やり方が古い！」って言う人もいるかもしれませんね。
許してください。
だって、長年やってきてきた経験の自分なりの答えだから。
次回は、開発を着手する前に準備することを書きたいと思います。
ここまで、読んでくれた素敵な人、感謝感激でございます。
それでは、また次回に。
最後に
役に立つかまったく思えないけれど、今回の絵の元のスライドを置きます。
勝手に使って下さい。
この記事が気に入ったらサポートをしてみませんか？