これまでのキャリアで私はいくつかのシステム開発にかかわってきた。
予算を与えてもらい、時間をかけてシステム作りをする。小規模なものも、大規模なものもあった。
私に特別な経験があったわけではないのに、こういう機会を何度となく与えてもらい経験できたことは振り返ってみれば私にはキャリア運があったということだろう。
それにこの経験を買ってくれるという転職先が結構あるのだ。
システム作りの経験から共通して学んだことは、開発者側のいう事は鵜呑みにしないほうがいいということである。
私の経験にはITバックグランドはなく、いつもビジネス側としてシステム開発に関わってきた。そしてITチームに任せてしまうと、最終的にはいつも同じような苦汁をなめるのだ。
基本デザイン構想は依頼者であるビジネス側が提供する。私の提供する説明が悪いのか説明後に仕上がりを待っているだけだと、「これはなんだ？」というものが出来上がってくる。
まさによく聞く”タイヤのブランコ”なのである。(リンク先に説明あり)
開発者側は最善を考え取り組んでいるのだろうが、何でもできるのだという夢物語をちらつかせるのは止めて、現実的なアプローチに変えて頂きたい。
会社のマネージメントは、逆に夢物語に予算を払うのかもしれないが、オペレーションで効率化を計れないシステムなんて社員にとっては重荷以外のなにものでもないのだ。
ビジネス側の担当者が欲しいものは現実的で使い勝手の良いシステムである。その基盤があったうえで夢物語に繋げてほしいとつくづく思う。
開発側が理解した内容でのプランニングレビューをもっと行ったほうが良い。
開発中の中途半端なシステムも開発できた部分を実際に見て、進捗レビューをビジネスと共にしないと「これはなんだ？」という物が作られてしまう。そうなってからでは遅いのである。
だからアジャイルというスタイルができて、より現実的に必要とされているシステムへと軌道修正しながら作るという方法が出来たのだろう。
私は実際にアジャイルスタイルを使いこなす機能しているプロジェクトマネージャーに出会い一緒に仕事をする機会を得たことがある。
人生初めて私がシステム開発を心底楽しいと思えた時期である。
このプロマネに任せておけば開発するものが出来てくると必ず成果物が期待する働きをするか確認してくれと、私に責任がある部分の役割を果たすための軌道修正する余地を与えてくれるのだ。
プロジェクトマネージャーが肝になる
この先、システム開発プロジェクトについて関わるなら絶対に譲れないものがある。
それはプロジェクトマネージャーの人選である。これは間違いなくビジネスを良く知っていてシステムを良く知っている人でなければいけない。
事前に知っている必要はないがプロジェクトを進めるにあたり深い理解をしてくれる人でなくてはならないし、ビジネス寄りの人になれる人である必要がある。
システムを立ち上げるにのに本当に必要なものについての知識と装備の判断を誤らない為にも、ビジネス寄りで本当に必要なものを準備できる人をプロジェクトマネージャーに採用する必要があるのだ。
プロジェクトマネージャーを誰にするかで成功と失敗の分かれ目となる。開発者として優秀でもプロジェクトマネージャーとして優秀な結果を残すとは限らない。
開発側からプロジェクトマネージャーを採用した場合、意思疎通のズレによって本当に欲しいものが作られないなんてことが起こる。ビジネスよりもシステムの事を考えてしまい、良かれと思い確認なしに勝手に作り進んでしまうことはよくある。
そんな可能性は初めに取っ払っておかないと、取り返しのつかない事態になりかねない。
システムを開発するときの要件定義
総括的な要件定義にはマネージメントが居てもいい。マネージメントのリクエスト発言も会社の権力者の意見として聞き、最終的に盛り込むかは後で考えればいい。
ただ優先順位には気を付けなければならない。
開発者はプランニング段階で何でもできると言うのだ。そして偉い人の意見に重きを置いてしまう可能性が高いので注意が必要なのだ。
たしかにお金と時間をかければどんなものでも出来るだろう。しかし会社のプロジェクトにはタイトな期限があり、予算にも限りがあることを絶対に忘れてはいけない。
夢物語は総括的なオープニングディスカッションだけにしなければいけないのだ。
実際の要件定義は限られた人数でやるほうがいい。要件定義はセクションを分けて、かならず必要な機能から取り組もう。
どのような目的を果たす必要があるのかを中心に考える。そこで必要となる入力項目のパターン数を含めて討議する必要がある。
このパターン数というのがネックになり実運用が難しくなるようであっては根本的なデザインミスになる。しっかり運用を考慮して開発者と討議すれば運用しやすく使い勝手の良いシステムが作れるのだ。
私は開発側がビジネス側の理想を汲み取って、素晴らしいシステムを作るとといいながら、そうならなかったことを何度も経験した。
簡単に計算パターンと構想を説明しただけで、その計算機能が希望通り作成されたことは本当に一度もなかった。
説明している時、私の頭にはしっかりとした計算式が存在し、全体的な運用まで頭にある。開発で何度も痛い目を見た私は面倒でもしっかり計算式を組み込んだ仕組みのデモ版を作成し、開発者に実データを含む計算式ごと渡すようになった。
実データを格納してあるので、過去データを利用し開発をしてもらえば開発側でも開発完了前に答え合わせをして、それを洗練された形で作ってくれるのである。
計算方式が同じでなくてもよい。コードの書き方も自由でいい。やりたい事の結果が正しい数値で表され使いやすくなって完成品に反映されているのがベストなのだ。
時間を無駄にしない為にも、この程度の協力なら惜しみなく提供したほうがいいと私は少し時間をかけてでも丁寧な準備をするようになった。
こんな風に具体的に何が必要かはっきり理解できれば開発側もビジネス側の要求に答えてくれるようになる。
開発側でも回り道の時間を削減し時間を上手く使ってシステム開発できると、本当に必要なことだけでなく付加価値について討議する時間が生まれる。
「本当はこういう機能も欲しいのだ」とコミュニケーションする時間が生まれ、運が良ければそれも一緒に開発される場合もあるし、開発側にも色々と良いアイデアを提供できるチャンスが与えられる。
使うシステムによっては、既にある機能を使えばいいだけだと具体的に提案してもらえる事もある。そういう機能のアドバイスを貰いテスト運用しながらシステムを使っていければ良いシステムが作れるだろう。
開発チームだってビジネスに喜んで欲しくて仕事をしているし、感謝されたいと思っている。だからこそ他人任せにせずコミュニケーションをしっかりとり全員で成功し喜び合って士気を高めれば、開発の負のスパイラルから抜け出せる。
システム開発方式
システム開発にはウォーターフォールというやり方と、アジャイルというやり方があるらしい。そしてそれをMIXした、いいとこどりっていう方法もあるらしいが、私は断然アジャイル推しだ。
いいとこどりっていう方法も体験したが、私にとってそれは間違いなくアジャイルではなかった。どこがアジャイルだったのか説明してほしいくらいである。
開発側とビジネス側の必要の理解にはいつでも溝があることを心得よう。
「なぜこうなった？」ということは日常茶飯事だから、そのギャップを埋めるのはアジャイルしかない。
ウォーターフォールで必要ではないものが出来上がったのを見せられても後の祭りだろう。到底巻き返しが出来ないからこそ、アジャイルという方式が出来たのだと思う。
巻き返しが出来ない時にはワークアラウンドの提案を受けるのだが、ワークアラウンドが必要なシステム開発ははっきり言ってただの失敗作である。
アジャイルであれば開発側は必要なものを少しずつ作る。それに対してビジネス側も責任をもってレビューやテストを繰り返し、必要が備わっているかを確認し、開発側と調整して進める。
それで初めて必要なものが必要な時間内に出来るのだ。
システム開発テスト
システムの構築が出来ればUATが行われる。UATとはシステムを使うビジネス側による動作確認テストである。
このテストケースは必ずビジネス側が作るべきである。開発側でテストケースを作る場合もあるが、それでは本末転倒だ。誤った理解の上にシステムを作ってしまったら、テストシナリオだって誤っているのである。
このような根本ミスを防ぐためにもテストケースはビジネス側が準備する必要がある。
UATテストを進めるには、ビジネス側がデータのインプットパターンも考慮し、開発側と協力しシステムに設定する項目の準備をする必要がある。
ある程度環境を整えてテストを行わなければ最低限の必要が満たされているか確認が難しい。確実に必要なものが開発出来るようにビジネス側も開発には相当協力する必要がある。
システム開発は堅実に進めなければ悲惨なものになるのだ。
完成日を何度も延期し、一体いつ完成するかも予想できないような状況を作り出し、システムはオペレーションの効率化を図るどころか、逆にシステムを動かすためのワークアラウンドを加え効率が落ちるなんてことが起こりうる。
そんなことには成らないように、プロジェクト立ち上げ時に何をするかが大切なのだ。
「この先まだまだ時間はある。」なんて思っていてはいけない。
鉄は熱いうちに打て！
早め早めに手を打って、信頼できるプロジェクトメンバー共にとシステム開発計画を煮詰め、本当に必要なものを明確にリスト化してプロジェクトを成功させよう！
システム開発を成功させるポイント
- ビジネスとシステムをよく知る人をプロジェクトマネージャーを置く
- ビジネス運用の為に本当に譲れない機能を明確にする
- アジャイルで開発されるシステムの軌道修正を細かく行う
- システムを使わないマネージャー陣が欲しい機能は優先順位をさげる
