目次
俺みたいになるな！入社3年目で任されたシステム開発プロジェクト推進の実態
すまいる顔がシステム開発に携わったユーザー企業の方にインタビューをして、
結果をブログに掲載するというシリーズが始まりました。
今回は第１弾として、金融系企業にお勤めのIさんの体験談です。
Iさんは入社3年目の若手社員の時に、社内システムの新規開発プロジェクトの
リーダーを任されたそうです。
紆余曲折ありながらなんとか完成したシステムでしたが、
もっとこうすれば費用や期間を無駄にかけずにできたのではないか、と仰っていました。
システム開発がうまくいかずに悩んでいる、という方はぜひ参考にしてみてください！
もっと業務経験がある人が主導となって進めていれば・・・
Iさん「当時入社3年目だったうえにシステムの専門家でもない自分がシステム開発プロジェクトのリーダーになるなんて、絶対うまくいくわけがない、と思いました。」
なぜIさんが担当することになったかというと、「他にやる人がいなかったから」だそうです。
先輩たちはシステムに全く興味がなく、事務アシスタントと新入社員と自分だけで進めていく
ことになってしまったそうです。
Iさん「システム開発はお金がかかるものだし、コストダウンだけでなく、
会社全体としてどうあるべきかを決定することにも繋がるため、若手が事務ツールを
開発するという認識ではなく、会社全体の課題と捉えてやらなければ迷走すると学びました。」
確かにシステム開発では、最初は部分的なツール程度のものを予定していても、
進めていくうちに社内システムとの連携がしたい、決済や入金も確認したいなど、
会社の基幹システムとも関連してくる部分が出てきます。
一度作ってしまったら大きく変えることは難しいため、若手社員や事務員に任せるのではなく、
経営層や部長など役職者も一丸となって取り組むべき課題ですね。
I さんも、「目の前の事務処理の効率化であれば比較的わかりやすいが、どうあるべきか
という方向性は若手や新人にはわからない。業務経験があり、こうあるべきだと語れる
先輩社員の知恵があればもっと進めやすかった。」と語っていました。
自分がシステム苦手だからという理由で、若手や新入社員に任せきりにしてしまっている
場合、システム投資の費用対効果が薄まってしまっている場合があります。
プロジェクトとしての方針や方向性を逐一確認しながら、経営層も一丸となって進めること
ができているか、今一度チェックしてみましょう。
プロジェクト推進のプロ、●●●担当者を挟んだほうがうまくいく
Iさん「外資系企業には、クオリティ担当というプロジェクト推進専門の人たちがいました。」
どうやらクオリティ担当の方々は、システム開発などプロジェクトを実行する際は、常に
リーダー役を担ってくれる人のようです。
現場と経営層の 中間の役割を担ってくれるうえに、システムに明るい優秀な人材のため、
そのような人材を抱えることは会社にとってはコストが高くつきますが、
クオリティ担当がいるプロジェクトは割とうまくいっていたイメージがある、とIさんは
仰っていました。
クオリティとは英語で「Quality Assurance」といい、品質保証を意味します。
現在では「QAエンジニア」という名称で品質を担保するための役割を担うエンジニアがいます。
しかしIさんが仰っていたクオリティ担当というのはQAエンジニアとはまた違っていて、
どちらかというとPMOのようなプロジェクト推進担当のようなニュアンスでした。
PMOはやはり必要な存在ですね。今一度現場担当者だけに任せきりになっていないか、
プロジェクトを推進する担当者はいるか、など適切な人材配置がなされているか確認
してみましょう。
仕様を確定したい開発サイドVS巻き込まれたくないユーザーサイドの実態
どんな開発プロジェクトにおいても、
ユーザーの了解をとり仕様を確定させたい開発側と、
巻き込まれたくないユーザー側の構図が見られるのではないでしょうか。
かく言う筆者自身も、開発担当者としての立場とユーザ側の立場両方経験しており、
開発者だった頃は、自分が書いた設計書をレビューしてもらう時に
「もっと自分のシステムに責任を持って設計書のレビューしてほしいな」
と思っていましたが、実際ユーザー側になってみると、
「こんな責任私がとれるわけないよ・・・」と弱気になってしまう自分がいました。
それも踏まえてIさんの体験談を聞くと頷きが止まりませんでした。
もっと評価して！協力しても評価されないユーザーたちの本音
Iさんに、「なぜユーザー側と開発側に溝が生じてしまうのでしょうか？」
と質問をぶつけてみました。
Iさんは、ユーザ側の立場でしたが、このような光景を目にしたそうです。
「仕様を確定させたい開発側と、巻き込まれたくないユーザー側の構図がある。
ユーザ側はシステム開発に協力することが仕事の一部として認識していない。
なぜなら関わっても評価される仕組みがないから。
前述のクオリティ担当がいる会社では、協力すれば評価につながる仕組みになっていた。
通常なら、いいアイデアを出して変に巻き込まれて忙しくなるのが嫌だから協力しない。
巻き込まれることがなければいいアイデアをくれたり協力してくれたりすると思う。」
これを聞いてなるほど、と思ったのは、ユーザ側にとって協力するメリットが何か？という点です。
業務を知っている現場担当者に要件定義を任せがちですが、そのやり方は正しいのでしょうか？
返って非協力的な社員から出る意見は積極的なものにならない可能性もあります。
特に営業社員は売上実績が評価の全てなので、いくら業務が効率的に変わっても、
それはシステム担当者の実績であり自分の実績にならないのであれば、協力するより
営業の仕事をしていたほうが会社のためでもあります。
会社としてシステム開発に協力した現場社員に対し、
定性的な評価しない仕組みになっている場合は、見直してみるのも良いかもしれません。
なにこの量！？見れるわけないじゃん・・・徹夜で受け入れ検証をするユーザーたち
前章で、筆者自身もユーザ側の立場としてシステムの受入れや設計書のレビューをしたことがあると
記載しました。私自身、「レビューをお願いします。」と言われて非常に困った経験があります。
なぜなら、私が作ったシステムではないので、私自身もどうあるべきかが曖昧だったからです。
私の経験不足が大いに関係しているとも言えますが、開発者からすればそんなことは関係なく、
工程を終えたという承認を得たいのです。
その気持ちも痛いほどわかりますが、やはり適当にOKを出すわけにもいかず、残業して設計書の
レビューを行った記憶があります。
Iさんも、ご自身ではないと言いますが、徹夜で受け入れテストをしている社員を見たことがあるそうです。
しかし、ユーザー側でシステムに精通した人も限られているため、
結局プロジェクト関係者にしかできず、周りの人が手伝うことすらできなかった、と語ってくださいました。
ユーザ側の意見としては、たとえ1週間の期間が与えられたとしても、
通常の業務もやりながらレビューや受け入れ検証をすることは、負担になります。
Iさん「通常の開発の打ち合わせ現場では、打ち合わせ後の開発サイドの持ち帰り期間が
1週間などかかると、ユーザー側からすると遅いなと感じる。」
それを聞いて1週間という期間の感じ方がユーザ側と開発側で違うかもしれないな、と感じました。
待たされるユーザー側からすれば長く感じるし、やらなければならない開発側からすると短く感じる
ということです。
Iさん「なので、1日でも3日でも進捗状況を共有して修正する、を繰り返した方が
ユーザーとの溝も深まらない。ユーザー側に求めることはとにかく多くない方がいい。」
ユーザ側に求めることはできるだけ少なくする。
このことがシステム開発プロジェクトを成功させる秘訣なのかもしれません。
システム外注の落とし穴・・・一本線を引くのに数百万！？
Iさんが勤めていた会社では、基幹システムから何もかも全てグループ会社に外注をしていたそうです。
そのため、ユーザー側でシステムを修正したり改善することは難しい状況でした。
例えば、「請求書に１本線を引きたい」というユーザーのオーダーに
数百万円かかると言われたので、諦めたこともあったそうです。
このように、システム開発を全て外注している場合、改修するためには、見積もりや影響調査、
実現性調査、人件費など多大なコストがかかるため、一度開発してできあがったものに対して
手を加えることは難しいのです。
このように、長期間に渡って外部ベンダーに外注し続けていることで、社内にシステムの内部が
わかる人がいなくなってしまう状況を「ベンダーロックイン」といいます。
こうなってしまうと、社内の方針転換や最新技術に追いついているのかいないのかも判断できず、
社内システムがいつの間にかブラックボックス化してしまいます。
そのような状況になっていないか、今一度確認してみましょう。
もはや業務がシステムに合わせたほうが楽だよね。
近年、システムをゼロから構築するのではなく、パッケージシステムを購入して、
自社の業務に合わせてカスタマイズする手法が主流になってきています。
ゼロから開発するよりもコストが抑えられると言われているからです。
実際に筆者が関わってきたシステムも全て、パッケージシステムでした。
しかし、パッケージシステムには仕様制限がつきものです。
Iさんも以下のような体験をしたと仰っています。
「パッケージシステムの仕様上、変則的な入力ができないものがあり、
その場合は自然とシステムに業務が合わせるようになっていきました。
例えば、システム上5年という区切りでしか入力できないが、
お客様が5年1ヶ月で契約したいと言ってもできません、となっていたのです。」
筆者はその話を聞いて、思わず「ええ！？」と驚いてしまいました。
エンジニアとして業務を変えることはあってはならない、と口すっぱく教えられてきたからです。
Iさん「それで案件を取り逃がす場合もありますが、逆に分析の観点や事務手続き面からは
効率が良い場合があります。」
筆者はその発言を聞いて「なるほどな。」と思いました。
筆者はエンジニア以外に営業企画を経験したこともあるのですが、
その際にシステムから抽出したデータをExcelで分析可能なように、
毎回関数を組んでデータを統一していたからです。
もともとシステム上分析可能な値しか入らないのであればその手間は省けますし、
契約手続きも煩雑にならなくて済みます。
考え方によっては、システム仕様上の制限が良い方向に働くこともあるのです。
まとめ
これまでの日本企業は「お客様至上主義」が当たり前でした。
例えば、取引先や元請の都合に合わせることが習慣化しており、
システム開発現場においてもお客様の業務をそのままシステムで実現することが最優先で求められてきました。
Iさん「しかし、もしもシステム側の方が現状の業務よりもより良いプロセスを提案できるならば、
ユーザー側も過去の仕事のやり方にこだわらずに、システムに合わせようという考えは
ひとつのやり方だと思う。
例えば請求書を別々の形で出しているなら統一するなど、システムに業務を合わせていく
のもありだと思います。」
パッケージにはカスタマイズがつきものですが、
「パッケージの仕様でできません」と言うのではなく、
「御社ではこのフローに変えた方がより良くなります」というような提案ができるのなら、
ユーザ側としても受け入れやすいですよね。
また、ユーザ側に元々無いものについて、「要件定義をしたいので、言語化してくれ」
というのは簡単ですが、実際にやってみるとかなり難しいことがわかります。
そのため、1日〜3日で開発を繰り返したり、試作品を試して意見を出すほうが、
システム開発が進みやすいこともあるのではないでしょうか。
そもそもユーザー側はシステムの専門家ではないため、ユーザが言っている要件が
正しいとも限りません。
システムのことを知らないから思いつかず言えなかったり、諦めたりすることもあります。
これまで当たり前と思われてきたウォーターフォール式の要件定義から始まるシステム開発を
見直して、アジャイル方式やカスタマイズなしのパッケージシステム導入に踏み出してみませんか？
まずはシステムの知見を持ったプロに相談してみることから始めましょう。
すまいる顔ではあなたからのお問合せをいつでもお待ちしております。
