何か分かっていない感じがする。一体何をしているのだろうという気持ちがたまってくる。そうなったら「なぜだ」と考え、自分なりの仮説や対策を立てて取り組む。こういうやり方を長年してきた。
その結果、通算22年の社会人活動において2回ほど立場を大きく変えた。1回目は仕事の範囲を詳細設計、実装、テストから、要件定義や業務設計といった上流工程に移したこと。顧客としっかり話がしたいと考え、中小企業診断士の資格を2008年にとった。
2回目は2014年に起業し、業務システム開発ツールメーカーの経営者になったこと。最近ではローコード開発ツールと呼ばれるジャンルの製品TALONを仲間と開発し、販売している。
2度の転機は私個人の話だが、その時「なぜだ」と考えた問題は「ITの技術者が真面目に開発したシステムが顧客の経営や現場でうまく使えない」と「バラバラのスキルの技術者をかき集める人海戦術がまかり通る」の2点だった。いずれも企業の情報システム部門の方、IT企業で働いている方、双方にかかわる問題である。
そこで業務システム開発のあり方と技術者として付加価値を出していくやり方を再考するきっかけになれば幸いと思い、個人的にではあるが、考え、行動し続けた末にたどり着いた結論とそこに至った道筋をお伝えする。今回は「開発したシステムが現場でうまく使えない」問題の解決策を書いてみる。
顧客の要求に合っていないシステムに価値無し
社会人の第一歩を私は1999年に踏み出した。システム開発企業に入り、主に製造業向けの基幹業務システムの開発に携わり複数のプロジェクトにおいて開発や稼働後の保守まで担当した。
2000年ごろにはJavaによるMVCフレームワークを自作し、これを使って顧客の業務システムを開発した。プログラミングで色々な物を作ることが楽しくて仕方なかった。
しかしある時、頑張って作った業務システムで利用者が操作ミスを連発する事態が起きた。非常に凝ったユーザーインターフェース（UI）により1枚の画面で多くの処理を実行できたものの、無駄に複雑で使いにくかった。
システム設計に私は関与しておらず1人のプログラマーとして渡された設計書通りに開発したが「ずいぶん凝ったUIだなあ」とは思っていた。顧客から「欲しい」と言われた機能をそのまま盛り込み、要件の整理や抽象化による再構成をしなかったのだろう。
操作ミスが多くて顧客が困っているという話は当時の上長から聞かされた。この件は私のものの考え方を変えた。開発技術への造詣を深めていくことで素晴らしいシステムを作れると信じ、プログラミング言語への理解、デザインパターンの使いこなし、データベースとインフラ技術の知見を深めてきた。ところがどれほど素晴らしい技術を組み合わせてシステムを作っても顧客の要求とマッチしていなければ社会的な価値は無いことに気付かされた。
業務システムは「誰のために」「何のために」存在するのかといったことに興味がわいた。所属先の社長に「プロジェクトに入るなら最初のところからやりたい」と直訴し、要件定義や業務設計など上流工程を担当させてもらうことになった。
