エッセイ(1)
スポンサーリンク

すずき
この記事を読んで、現役SEである僕が思ったこと・感想を書いてみました。「なぜ日本政府が作るソフトウェアは使えないモノばかりなのか?」という題名ですが、何も日本政府に限った話ではなく、民間企業の業務で利用している業務システムにも当てはまることではないか?と思うような内容でした。これからエンジニアになりたいという方(特に受託開発の企業に就職したい方)は、今のソフトウェア開発の多くはこういう状態なんだ、と頭に入れておくためにも見て頂きたい内容ですね!

この記事で見解を主張している中嶋聡さんって?

ソフトウェアエンジニア・起業家。1960年東京生まれ。早稲田大学大学院理工学研究科卒業。NTT電気通信研究所を経て、1986年マイクロソフト日本法人に転職。米Microsoft本社に日本人として初めて移籍し、Windows 95/98、Internet Explorer 3.0/4.0のチーフアーキテクトを務めた。その後、ソフトウェア開発のUIEvolution(現・Xevo)をアメリカで創業。現在は一般社団法人シンギュラリティ・ソサエティで、AI時代のテクノロジーと社会の在り方を考えるオンラインサロンを主宰する。2011年に始めた有料メルマガ「週刊 Life is beautiful」は現在も継続中。

この記事を見かけたとき、「あっ、この人見たことある!」と思いました。

それはなぜかというと、中嶋さんが執筆した「なぜ、あなたの仕事は終わらないのか」を1年前くらいに読んだからです。

書評記事ではないので軽く述べるだけに留めますが、その本の中で中嶋さんが提唱している「ロケットスタート時間術」という手法は、今の僕の仕事に間違いなく活かされています。

ざっくり言うと、例えば「ある仕事を1週間で終わらせてくれ」という依頼があったときに、徹夜してでも2日程度で8割方終わらせてしまうというものです。

この本を読む前は、その仕事のタスクばらし⇒1週間で完了させる計画を策定する、という方法をしていました。

しかし、計画通りに進むわけもなく、色々やっていく内にやらなきゃいけないことが浮き彫りになっていき、結果納期間近にバタバタしてギリギリ終わらせるということが多々。。

(さすがに徹夜まではしてないですけど)ロケットスタート時間術を知ってからは、計画をすぐに策定するのではなく、1~2日かけてとりあえずタスクに着手し、4~5割方出来てから計画立てることにしました。

そうすることで、後々浮き彫りになることをできるだけ先に検知して、計画に盛り込むことが可能になりました。

また、最初に結構進めることで期間的な余裕ができ、不測の事態を考慮したバッファ(猶予期間)を設けることが可能になります。計画より早めに終わってしまったら、その成果物の見直しや改善をするなど品質向上にもつながりました。

と、まあ本の紹介はこの辺にして、これから記事に対して私の感想などを述べていきたいと思います!

スポンサーリンク

現状のIT調達方式そのものが「使えないソフトウェア」の原因

政府のIT調達というと、大抵は「ITゼネコン」と呼ばれるような大手システムインテグレーター(SIer)に対して発注しますが、
(省略)
IT業界に限らず、日本の多くの業界では政府が絡む案件について、まず政府から元請けである大手企業に調達がかかります。そこから「下請け」「孫請け」といった構造でお金の流れが生まれます。孫請けの段階では、ほとんどの人が非正規雇用の派遣として働いているケースが少なくないと思います。
(省略)
この構造の中で、上流にいる、それなりに能力のあるITエンジニアは何をしているのかというと、発注元である政府に向けた企画書や仕様書の作成です。一方、下流でコーディングを担当するのは、人材派遣会社が雇った派遣社員であることが多い。派遣会社がそうした人たちをどうやって集めているかというと、個人の能力に関係なく、1カ月ほど基本的なトレーニングを行うのみ。後は現場に派遣して「OJTで覚えろ」といった状況です。こんなやり方をしていて、良いソフトウェアなど作れるわけがありません。

政府のIT調達に関わらず、民間企業のIT調達においても多くはこの方式だと思っています。

まさに僕が現在担当しているシステム開発もこのような形になっており、コーディングを担当していただいている方の多くはそのシステム開発に携わって半年未満の方たちばかりです。不具合も沢山出ており、まさに良いソフトウェアが作れるわけがないですね(笑)

また別の話にはなりますが、受託側が発注元向けに作成した企画書や仕様書は、日本政府側でどれくらい精査したのでしょうか。それとも、そもそも作っているのでしょうか?

民間企業であれば、少なからず業務で利用するユーザの意見をある程度反映させた仕様書が出来上がるので、業務で使えないレベルのソフトウェアはあまりないです。(経験上)

そういう点から、日本政府が作るソフトウェアは、想定ユーザが誰なのかを決めていたのか?

決めていたとしたら、その想定ユーザの意見が吸い上げられていたのか?

吸い上げていたとしても、近しい人間の意見のみで偏りが出ていないか?

など色々疑問はありますね。

”発注側にもソフトウェアについて正しく理解している人材が必要”は、ごもっとも!

日本政府が作るソフトウェアは使えないものばかりなのか、に対する中嶋さんの見解の1つとして、「発注側にもソフトウェアについて正しく理解している人材が必要」という主張がありますね。

ソフトウェアを注文する側にも、ソフトウェアのことをきちんと理解している人がいる必要がある。この状況を変えるためには、教育などを通じて、時間をかけて社会そのものを変えていくしかないのでしょうね。

これは政府に限った話ではなく、受託開発における発注者にも大いに当てはまることだと思います。

発注者はソフトウェア開発の全体像、開発プロセスなどを理解していないためか、ソフトウェア開発を軽視している節があります。(すぐできるんでしょ?のスタンスが時々あります)

実際に僕が働いている会社でも、発注者がいつまでも仕様を確定せず、単体テスト工程(※)になっても仕様を変更し続けることがありました。

※ソフトウェア開発のプロセスについては以下記事を参考にしてください。基本的には後続工程になればなるほど、仕様が覆ったときの影響は大きいのです。

結果、変更管理が疎かになり、不具合(バグ)が止めどなく出てしまうシステムとなってしまいました。(赤字プロジェクトです)

「ある時点で仕様凍結する動きをして、それ以上の変更は契約変更で追加費用をもらうぞ。と宣言していれば良かったじゃないか!」という主張はあると思いますが、もちろんその動きはしていました。

しかし、発注者が断固、仕様凍結を拒否したんです。というのも、根底には「変更くらいすぐできるでしょ?」というソフトウェア開発を理解していないスタンスから来たものだと見受けられました。

受託開発が成功するかどうかは、受注者(ソフトウェア開発業者)の力量はもちろんありますが、発注者の協力もとても必要になります。

このサイトに来訪してくださっている方は、主にエンジニアを目指す方だとは思いますが、学んだ知識はエンジニアでしか活かされない訳ではないんです。

ソフトウェア開発に詳しいシステム開発の発注者という道も少なからずあると思っています。受注者側である僕とすると、そういう方が発注者側にいるのはとても心強いですね。

余談。オンライン申請とは、、、?

国民1人当たり10万円の特別定額給付金を支給する「申請システム」などをリリースしたが、その品質や使い勝手、システム利用後の業務プロセスなどに多くの問題が指摘されたことは記憶に新しい。

これについてですが、特別定額給付金のオンライン申請をした方の体験談を聞きました。

オンライン申請したのに、郵送で送った人より振込されるのが遅かったそうです。

「なんで?」と思って、市役所に連絡したところ、「オンライン申請頂いたものはデータを印刷して順次処理しているので時間がかかっています」という回答が来たそうです。

めちゃくちゃアホらしくて笑ってしまいましたね(笑)

こういうところからも、発注者が実際の業務プロセスをしっかりと考えてシステム発注していないのが分かりますね。

スポンサーリンク

Twitterでフォローしよう

おすすめの記事