HOME会社概況業務内容開発分野開発事例CANモジュールソフテックだよりお問い合わせ
HOME > ソフテックだより > 第27号(2006年10月4日発行) 現場の声編「ソフトウェア開発の苦労」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより(技術分野別)のページへ
ソフテックだより(シーン別)のページへ


ソフテックだより 第27号(2006年10月4日発行)

現場の声編

「ソフトウェア開発の苦労」

1.はじめに

ソフテックでは様々なソフトウェア開発を手がけています。
そのソフトウェア開発の難しさや苦労する点について、私の経験を交えて紹介します。

ソフテックの仕事の特徴として以下のような点があります。

  1. Windows用ソフト、マイコン用ソフト、PLC用ソフトなど様々なシステム開発を協力させて頂いています。
  2. 経験があるシステムや新規分野のシステム開発に協力させて頂くこともあります。
  3. 1人で開発の全てを担当する案件から、20人程度で作業を分担して開発をする場合もあります。

上記のように、開発ごとに新しい要素や環境を作る難しさもありますが、今回はソフトウェアというモノに焦点をあて紹介します。

2.ソフトウェア開発の難しさとは?

ソフトウェア開発の難しさを考えます。
新しいものを作るためには、様々な知識が必要であったり、お客様のニーズを聞いて、製品化するという難しさもありますが、これはソフトウェア開発に限ったことではありません。
では、ソフトウェア特有の難しさとはどのようなことでしょうか?

私自身も上司から数年前に「なぜソフトウェア開発は難しいのか考えてみなさい」と課題を出されたことがあります。
自分でどのように回答したか忘れましたが、その時に上司から「ソフトウェアは目に見えないから」という話をいただき納得しました。
現在でも、そのとおりだと考えています。
ソフトウェアは完成すると画面や制御対象物の動きで正しく動作するか否かの判断が出来ますが、途中段階で評価しようとした場合に一目で「良い」「悪い」という判断は出来ません。
しかし、本棚や机を作った場合には、ネジの締まり具合、色、手触り、など第三者が客観的に評価することが出来ます。
このような点が、ソフトウェア開発の難しさのひとつと言えます。

3.実際の現場では?

私は、10人以上が参入して開発するシステムのプロジェクトマネージャーという立場でした。
この開発で小規模開発時以上に「見えない」という部分の難しさを知ることになりました。
開発段階や進捗管理で実際に私が経験した一例を紹介します。

(1) イメージ合わせの難しさ

ソフトウェアを開発する場合は、各機能ごとにインターフェースを決め、担当者を割り当てます。
インターフェースを決めるということは、入力情報や出力情報であったり、通信のプロトコルであったり、「情報の流れ」を決めることになります。
開発時はインターフェース仕様書やプロトコル仕様書を作成し、「情報の流れ」の決まりを作ります。
この「情報の流れ」はツールを利用することで、可視化することもできますが、開発時は仕様書を読んで各担当者がイメージするしかありません。
しかし、文章には必ず「行間にある言葉」を読みとる必要があり、文章を読む人により、そのイメージが微妙に異なります。
このイメージの違いは複数人で開発すると、大きな問題に発展することがあります。
実際に発生した事例として以下のようなことがありました。

処理はマスタとスレーブの通信で、私が通信仕様書を作成し、事前に打ち合わせを実施したうえで開発を進めました。
通信はハンドシェーク方式を取っており、マスタがコマンドを送信すると、対応する応答コマンドをスレーブが返信します。
しかし、結合テスト段階でマスタは「送信したいタイミングで複数のコマンドを送信し、それぞれのコマンドの応答を待っている」という作りになっており、スレーブは「1つのコマンドを受信すると応答コマンドを返信するまで、新しいコマンドは受信しない」というイメージの違いがあることが分かりました。
私はスレーブ側の担当者と同じイメージで仕様書をチェックしていましたが、この問題が出てから仕様書を見直すと、「マスタは応答を受信するまで、次のコマンドを送信しない」という言葉はありません。
結果としてマスタ側を修正しましたが、マスタ側の担当者もスレーブ側の担当者も仕様書どおりに開発しており、「行間にある言葉」の認識違いでこのような問題が発生しました。

このような、同じ仕様書を読み、打ち合わせをしながらも、別々なイメージで開発が進んでしまうケースは、大なり小なり何らかの形で発生し、関係する人数が増えると、イメージを合わせることが難しくなります。
私はこの時の開発を通して、仕様書の書き方について、もっと勉強するべきだったと、反省するとともに、担当者間のコミュニケーションの重要性を再認識することになりました。

(2) 不適合対応の難しさ

開発が進むと、検証中に不適合が見つかります。
1人で開発しているシステムであれば、おおよその見当をつけながら原因究明できますが、人数が多くなると、1つの不適合の原因究明も容易ではありません。
効率を上げるために、初期調査を1人が実施して、ある程度絞り込んでから原因調査を行います。
それでも、容易に原因が見つからない不適合は、調査対象を広げて調査します。

このような場合、私は「〜のように作ってるよね」と各担当者に確認して歩きます。
この確認作業でも、ソフトウェアの内容を聞き、イメージして問題があるか否かを判断します。
このような作業も、「人の思考に合わせてイメージする」ため、容易ではありませんが、不適合が2つ以上絡んで発生しているような場合もあり、それを見極めるために必要な作業です。

(3) 進捗管理の難しさ

私が担当したシステムでは、システムAとシステムBのアプリケーションは完成しており、その通信のプロトコル部分だけが遅れてしまうという状況が発生しました。
通信プロトコル部分は、ほぼ完成していると私は認識していましたが、実は様々な問題があることが分かりました。
プロトコル部分を早急に立ち上げなければ、システムAとシステムBの担当者が待ち状態になり、それだけ工程も遅れてしまいます。
このときは、代替のテスト手段を作り、平行して遅れているプロトコル部分の作り込みを行いました。
私自身もサポートに入り、会社で1番早く出社して、1番最後に帰る生活が続きました。
このような認識と現実が違う状況は何度も経験することですが、なかなか解決できない問題でもあります。
私も、この進捗管理が一番苦労しました。

4.最後に

今までも開発の管理はしていましたが、10人以上が参入する規模の開発は初めての経験でした。
担当者が増加することでソフトウェアの「目に見えない」という難しさが表面化し、その対応に悩みました。

今回のメルマガを読んでいる方にも、同じような経験をされている方や、克服されている方がいると思います。
ソフテックでは、規模が大きなシステムの開発協力をさせて頂く機会が増え、管理強化の研修や、担当者の報告、連絡、相談の改善、ISO9001の取得など会社全体の底上げを進めています。
このような会社全体での取り組みや、進歩するソフトウェア開発技術の習得を通して、お客様が満足をして頂けるよう、努力を続けたいと考えています。

(T.O.)


関連ページへのリンク

関連するソフテックだより