■Hearing – 仕事上のトラブルや問題点をお聞かせ下さい!

仕事上のトラブルや問題でお困りではありませんか? たとえば・・・

  • コンピュータシステムは導入したけれど、難しくて使えていない!
  • 実際の業務とコンピュータシステムが合わなくなってきた。
  • 改造したいけど、金額が高いから我慢して使ってる。
  • 転記作業が多くてミスがなくならない!
  • データの有効活用がしたいけど、どうしたらいいのか分からない。
  • 導入したときのソフト会社の対応が悪くて・・・
  • 今の作業をもっと楽に行えるようにしたい!
  • ミスを減らすにはどうしたらいい?
  • 今のパソコン、だんだん遅くなってきているかも?

何らかの問題点を抱えていて、コンピュータシステムの導入を検討しているのであれば、ぜひお問い合わせ下さい。まずは、ヒアリングから!

既存のコンピュータシステムのトラブルや問題点も、遠慮なくお聞かせ下さい。

 

■Concept – 知っておいて頂きたい、私たちの基本的な考え

私たちは、お客様のところで抱えていらっしゃる問題を聞かせて頂き、それを改善することが一番大切な仕事であると思っております。
お客様の置かれた状況によっては、 コンピュータシステムの導入は、必ずしもお客様の利益につながるとは限りません。

もし、お客様からコンピュータを導入したいと相談をされた場合でも、それがお客様にとって意味のあることなのかを熟考させて頂いた上で、お手伝いさせて頂きたいと考えております。
ですから、コンピュータシステムを導入しなくても改善できることであれば、それをそのまま提案させて頂きます。

そのため、場合によっては、コンピュータの導入はお断りすることもあります。
偏屈だと思われますか?

ですが、コンピュータシステムの導入は、お客様との共同作業ですし、それは運用が始まってからも続きます。
一時の利益を追求することは、お互いにとって不幸だと思うのです。

■システム開発手法

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

ウォーターフォールモデルは、システム開発プロジェクトで用いられる代表的な手法の一つです。工程や作業プロセスごとにチェック(検収)しやすいため、品質を重視する日本のシステム開発の現場、特に大規模なシステム開発プロジェクトにおいて、多く採用されてきた、なじみの開発手法です。時代の変化が激しい現代においては、開発期間中に要件が変わってしまうこともあります。最初の要件定義・設計からの変更は、すべて仕様変更として扱われ、コスト増・品質の悪化の原因となります。

インターネットが普及し、最近はWebサービスが当たり前となりました。より早くサービスを提供することが命題となり、スピードや操作感が優先のフロント側の開発と、安定と品質が重視されるバック側の開発、さらにインフラ構築といった分業が推し進められています。そういった変化に追従するための手法としてアジャイルモデルが出てきました。

アジャイルモデルは、変化に追従しるために、要件定義→設計→実装→テストという一連の流れを細かい単位で何度も回します(後述)。

Webサービスは、一回、開発したら、そのままずっとそのままということは、ほぼ無く、利用者のニーズの変化に合わせ、どんどん改良が加えられていきます。開発と運用を効率よくこなすために、DevOpsという手法が出てきました。また、それようのツールも多く出ています。

開発する対象に合わせ、手法やツールを適切に選ぶことは,とても重要です。

アジャイル

アジャイルモデルの中の1つ「スクラム開発」においては、「スプリント」と呼ばれる比較的短いスパンの中で、要件定義→設計→開発→テストを実施します。工程(要件定義,設計など)を区切って、まとめて作業を進めていくウォーターフォールモデルとは違い、スクラム開発ではスプリントを繰り返すことで要求事項を満たす製品に仕上げていきます。開発作業のアプローチ方法が違うだけのように見えますが、チームの中の役割分担、見積もり、タスクの割り当てなど、全てにおいてセルフマネジメントやコミュニケーションを重視しており、そのことが変化への追従や品質の向上に寄与しています。

V字モデル

V字モデルは、ソフトウェアの開発→テスト→リリースまでの一連の流れにおける、システム開発プロジェクトにおける開発工程とテスト工程の対応関係を表した1つのモデルです。「ウォーターフォールモデル」でも「アジャイルモデル」でも、このモデルは変わりません。

V字モデル
  • V字の左半分に、開発工程を上流工程から順番に右下がりに並べます。
  • V字の右半分に、左の開発工程に対応したテスト工程を右上がりに並べます。
  • V字の左右を見比べることで、実施されるテストがどのレベルの開発内容を検証するためのテストなのか、何に着目したテストが行われるのかを示すことができます。

開発段階とテスト段階を結びつけることで、

  • 対応する開発段階に沿った内容のテストに絞り込むことができるため、分担が容易で、各プロセスの責任者が明確。
  • システム開発プロジェクトの進行段階が把握しやすい。

分担することにより、各フェーズでの骨格部分の開発に集中できるため、不具合の発生を抑えることができます。仕様とテストの確認項目が明確であるという点が大事です。

プロジェクトの進行段階が把握しやすく、コストや人員、スケジュールの調整がしやすいというメリットもあります。

 

創屋ぷれす – システム開発