記事

予算ブレの原因

開発の変動要因

システム開発は長期にわたることが多く、また未来の不確実性の中で予算を策定しなくてはいけないことがある。セキュリティーをはじめ動作環境の変化や人員の欠如、予期していなかった仕様の発覚などが原因だ。

目標変化と予算

進捗率は目的地が明確に設定されていれば数字を負うことで予算達成率を算出することができる。しかし、目的地が近い遠いのは無しではなく、根本的な目的地がなくなったり、複数になったりすることがシステム予算の策定の難しいところである。

計画型開発法

システムに未来を見ることができればブレない、見えないことをすべて調査の上で着手できれば確実な予算と実行が可能である。進捗率の報告が可能になる。フォーターフォールモデルなのでコストがかかることと時間がかかることの覚悟が必要だ。途中での方向修正は原則できない。

柔軟な開発手法

逆に低予算で早く導入するなら、見えにくくなるデメリットがある。状況によって対応を素早く変化させる必要があるため進捗率を算出しにくい。アジャイル開発と呼ばれるものであり、社内開発であることが理想である。途中で出てくる条件に対しても柔軟に方向性を変化させることが可能である。

まとめ

アジャイル開発で予算を立てるときは、1.5-2.5倍くらいを目安に余裕を持って設定することを推奨する。

ローコード開発≠安い 前の記事 内製化の成功術 次の記事

関連記事

記事

相場の不在

開発の相場観

相場とは、一般的に市場で競争売買によって決まる商品の価格とされているが、ことシステム開発においては、相場というものが存在しない。

比較の難しさ

比較できる同じものであれば競争原理が働き相場が構築されるが、フルスクラッチされるシステム開発においては全く同じものができることはない。しかも、出来上がるものはパッケージシステムやSaaSの利用以外は、未来にしか完成しないので当然比較もできないものとなる。

将来要件判断

比較的ないからこそ、しっかりと吟味する必要があるが、吟味する材料や条件などは現時点で明確になるものが元となる。未来に発生する追加条件や変更される環境などはジャッジする時点にはすべて出そろわないという難しさがある。

変化への対応

システム開発は未来にどのような条件変更やルール変更が行われるかわからないものであるという認識を持つことが大切である。その上で最善のジャッジを行うべきである。その判断は過去を遡って正解か間違いかを評価すべきではない。

まとめ

日本では原点方式の人事評価が行われるため、イノベーションは起こりにくい本質的な問題がある。これを無視して「DXだ」といっている組織があるとすれば、それは本質を見誤っているといえる。

続きを見る >
記事

内製化の成功術

IT報酬の実態

海外と比べて日本のITエンジニアの報酬が低いという記事をよく目にする。それもそのはずで、ハイクラスIT人材は都合のいい「何でも屋」にはならないからである。

導入時の誤解

ユーザー企業やシステムのユーザーは、IT化を行うことで業務が減るという先入観を持っていることがある。システム導入を着手したときの目的を忘れて、その時、その場の課題を優先して都合よくITエンジニアを動かしてしまう。また動くITエンジニアもそこにいたりする。

システムと医療

たとえば、「お腹が痛い」と病院にいって「すぐに切開しよう」とはならないはずだ。このようにシステムにもその他にも色々な条件が絡まり合っている。システムは取り扱う情報量や関連する業務が多く導入に時間がかかる。時間がかかる結果、最初の導入目的を忘れてしまうのである。

真のIT人材価値

ハイクラスIT人材はユーザー側の状況と心理を配慮しつつ、現場のプログラマーの状況と心理を考慮して陣頭指揮できる人材といってもよいだろう。心理というのは物の言い方だけではなく、無形の財産を構築したり業務にフィットさせたりするので、プロジェクトの円滑さが変わるのだ。

まとめ

小手先だけでシステムに関するプロジェクトを推進しようとすると、「言われた通りにやった」という受動的な参加者が増えてしまう。情シスのSIer化を回避するにはITエンジニアを「何でも屋」にさせて疲弊させないことも大切である。開発チームの雰囲気作りも非常に効果がある。

続きを見る >
記事

野良アプリは排除すべきか？

「便利」の裏にある現場IT

シャドーITとは、企業の情報システム部門が認知・管理していない状態で、現場の判断によって導入・利用されるIT資源を指す。具体例としては、LINEやGoogleドライブ、Excelマクロなど、日常業務の中で自然発生的に使われるツールが挙げられる。これは企業としての統制外にある一方、現場の即応性や利便性を追求した工夫の結果でもあり、単なるルール違反と一括りにはできない。ゆえに、これを「排除すべき野良アプリ」として扱うことが妥当かどうか、慎重な見極めが必要である。

IT部門を飛び越える理由

現場がシャドーITを使う背景には、既存システムの使い勝手の悪さや、IT部門の対応の遅さといった事情がある。業務は待ってくれない以上、迅速な判断や情報共有のために、現場が自ら使いやすいツールを選ぶのは自然な流れである。たとえば、社内の共有フォルダではなくGoogleドライブを使ったり、煩雑な申請フローをExcelマクロで簡素化したりといった工夫は、業務効率の向上に寄与している。現場がスピードと柔軟性を求める限り、IT部門の枠組みに収まらないツール活用は今後も続くはずだ。

シャドーITのリスク

便利な一方で、シャドーITには深刻なリスクも存在する。まず、セキュリティが担保されていないツールの使用は、情報漏洩やマルウェア感染といったリスクを高める。また、IT部門の管理外にあるため、データの一元管理ができず、連携の取れないシステムが乱立することで、かえって非効率になることもある。最悪の場合、コンプライアンス違反や内部統制の崩壊を引き起こす可能性も否定できない。利便性の裏には常にリスクが潜んでいるという現実を直視する必要がある。

市民開発と再定義

ただし、シャドーITの存在は、現場が自らITを活用しようとする前向きな姿勢の表れでもある。近年ではDXの進展に伴い、「市民開発」や「ローコード開発」など、現場主導のIT活用が注目を集めている。従来は否定されてきたシャドーITも、企業変革の一端を担う可能性を秘めている。IT部門がすべてを統制するのではなく、現場と協力しつつガバナンスを効かせる視点に立てば、シャドーITは排除すべき“野良”ではなく、むしろ育てるべき“創造”として再定義できるはずだ。

まとめ

現場の柔軟性と全社最適を両立させるには、両者を理解した経営の舵取りが欠かせない。「排除」ではなく「共存」の設計に踏み出すことこそが、企業のDXを推進するための鍵となる。

続きを見る >