システム開発,設計,東京,業務自動化

システム開発・設計 IMAGE画像01

企業が求めるシステムは主にWEB系開発か業務系開発に分類されます。WEB系はパソコンやスマートフォンなどに搭載されているブラウザ上で動くWEBを使ったWEBサービスを展開するものです。例えば自社が作ったBtoB又はBtoCのためのWEBシステムの中にログインパスワードを渡して入ってもらってサービスを提供する等が該当します。一方業務系開発は企業の業務を効率化・自動化するものを示します。給与システムや経理システム、勤怠管理、日報などが該当し、それぞれをさらに無駄な作業を減らして自動化するか等が主な業務の目的です。

徹底的にヒアリングする

まずシステム開発の流れの最初である上流工程(要求分析)から話し合いが始まります。クライアントが行いたいこと、なぜそれを行いたいのか?、それが実現できれば何が変わるのか?について徹底的にヒアリングをさせていただきます。同時にクライアントの元々の事業について弊社はプロではありませんので、元々の事業についてもお伺いさせていただきます。
システム開発を行う上で、なぜシステム開発を行なおうと思ったのかを様々な視点から核心部分に触れ、その意図を当社も理解し、共有した時、システム開発を当社がお手伝いできるか否か?について正直にお話させていただくようにしております。

IT知識な稚拙なクライアントにわかりやすいように伝える

とにかくIT業界やシステム開発・設計の業界は専門用語が多いです。初めての方は何を言っているのかもさっぱりわからないこともしばしば。ただ今まで世の中に存在していない概念のものが沢山出てきているので、それをIT業界に詳しくない人に言葉で説明するのは容易ではありません。ただ何を使えば、これはこうなってこういう風にアウトプットできますよ!ということは見せられるし、伝えられます。
クライアントの方もわからないから流すのではなく、お話を止めてもらってでもわかりやすく説明を聞いてみたいと思った場合は、都度遠慮なしに止めてもらってその部分を掘り下げて説明していただくことを奨励しております。
その上でできる限り具体的でわかりやすい説明を心がけております。

上流工程と要件定義で9割が決まる

システム開発は正直なところ、上流工程(要求分析)と要件定義で9割決まると認識しております。しっかりと考察された要件定義は、システム開発に携わる全てのプロジェクトの指針になります。そのしっかりと考察された要件定義を作成するためには、その川上にあります上流工程(要求分析)が大事ということになってきます。上流工程でよく考え抜かれた上で、しっかりと文面にて要件定義化されることによって、健全なプロジェクトが立ち上がると言っても過言ではありません。

パッケージかカスタムか

契約がまとまり晴れてクライアントという言い方から改めてユーザーという言い方に変更いたしましたところ、ユーザーが今から作りたいというシステムが100%ニーズ通りということはありませんがかなり類似したシステムが既に作られているということはよくあります。この既に存在しているシステムの権利を買って自社システム用にアレンジしていくのがパッケージ型開発。一から独自に作っていくのをカスタム型開発と呼びます。
いいシステムが既に存在していたのでパッケージ型を選択してあっさり目的達成ということも存在しますが、カスタム型に比べて取り掛かり費用が安いので安易にパッケージ型から開発に入ったものの、機能変更に限界があり、本来臨んだシステムのスペックに到底及ばず、計画を頓挫してしまったという例もこの世界には多く存在します。
使えそうなパッケージのシステムがあっても飛びつかず、改定が望むところまで可能かどうか?をある程度先に目処をつけて、パッケージ型で進めるのか、敢えてシステム型で進めるのかを吟味検討する必要があります。

ウォーターフォール型とアジャイル型

開発業務をどう進めていくのか?はプロジェクトの成功に大きく影響します。
開発の流れにはウォーターフォール型とアジャイル型の2つがあります。
一般的なウォーターフォール型の流れは、予め全体の機能設計を済ませておいてから機能を実装するので、開発の着手にはある程度時間が掛かってしまいます。一方アジャイル型は初めは厳密な仕様は決めず、大よその仕様だけで細かい反復開発を開始し、小さいユニットでの実装→テスト実行を行って開発を徐々に前に進めていくものです。
当社は、ある程度初期にガシッと作った方がいいなと思う場合、例えばユーザーがシステム開発が経験が少ない場合、ある程度仕様を固めてから見える姿をはっきりとイメージさせておいた方がしっくりくるだろうと考えた場合はウォーターフォール型を、またユーザーも経験を積んでいて、ある程度臨機応変に立ち回れ意思決定もスムーズな会社ならば敢えてちょっとづづでもどんどん進めていき、スピードや製作期間を短めで抑えるためにもアジャイル型を選択することが多いです。
しかしウォーターフォール型、アジャイル型いずれにせよ、最初決めたことが何も変更なくシステムが出来上がるということはまずありません。初期のスケジュールは何らかの形で必ず調整が入ることでしょう。完全な計画を立てるのがメイン業務ではありません。ユーザーの目的に対し一定の期間内で最適なものを作り上げるのがメイン業務です。ユーザー側にもベンダー側にも双方の信頼関係の下でシステム開発は進んでいくものです。

テスト期間をきっちり取る

ある機能のシステムが出来上がった等、例えば「入力フォームに数字を入れるとアウトプットの画面に正しく表示されていますよ」と言う風な部分部分の単体テストをユーザー側ベンダー側それぞれきっちり行うということ、特にユーザー側はベンダー側に任せっきりにしないことが大事です。
コンピューターというのは、人間が考える以上に杓子定規で頭が固いです。言い方を変えれば指示した通りのことは必ずやってくれますが、伝え方で一文字言葉を間違ってもエラーを起こす要因になり得ます。例えば入力フォームに名前を入れる欄があり、その名前に常用漢字に乗っていない名前の人がいた場合、返すアウトプットの画面にエラーが出たなんてことはよくあります。部分部分のシステムをテストすることを「単体テスト」と言いますが、単体テストを行うにもテストを行うための顧客リストであったり、数字のデータが事前に必要であったりします。
最終段階の結合テストや統合テストの際も同じことが言え、事前に入力するテスト用のリスト等が用意されており、それを実際に入力してみて、ありとあらゆる実験をしてみて、それで初めて何も問題が無いと判断された時、そのシステムは世に出されることになります。

長期で話し合える関係づくりを大事に

ユーザーとベンダーの関係があまりよろしくなく、システム完成と同時に関係が切れるというケースも世間ではあったりします。このようなシステムは後で必ず問題が発生します。がベンダー側も乗り気でないため、システムの修正に本腰をなかなか入れてくれないこともあります。このようなシステム開発はお互いにとって不幸です。
当社は、それぞれが持ち場をわきまえた上でユーザーとベンダーが相互に適切な距離感の上で信頼関係にあるのが望ましいと思っております。
ある程度ユーザーの方々にもIT知識をお持ちいただく、またベンダーである当社もユーザー企業の事業を学ぶ・理解する。
システムの完成度が非常に高い場合でも、着かず離れずで「何かあったらいち早く駆けつける気概」で常にいることが重要と思っています。
完成度の高いシステムの後ろにある更なる高みに向けてユーザーが再度システム開発に挑もうとする時、また当社をご指名していただけるような仕事をしていきたいと思っています。