知って得・あなたの生活をもっと豊かに!

こんにちは、拙作ブログのご紹介です。このブログは河原健次がお届けしています。大分市出身、木更津市在住です。すでに半世紀以上も生存しています。その長い歴史から、日常生活や人生に参考になりそうな情報を提供しています。読者のみなさんに役立つことを願っています。

異常ケースが大切、ソフトウェア開発のポイントは普通の仕事にも通じる

f:id:kawa2496:20190213071140j:plain

こんにちは。
拙作ブログをご覧いただきありがとうございます。

 

今回は、ソフトウェア開発について
考えてみたいと思います。

 

というと、
特殊な専門分野を連想しますが、
ここで述べるポイントは、
実は、普通の仕事でも使えます。

よって、
ソフトウェア開発に興味がなくても、
最後までお読みいただければと思っています。

ちなみに、
私は約50年、
ソフトウェア開発に従事していました。

 

 

 

1.ソフトウェアの特徴

ソフトウェアについて、少し触れておきます。


ソフトウェアにお詳しい読者は、
本項を読み飛ばしてください。

 

1)ソフトウェアは正直。

ソフトウェアは正確かつ確実に動作します。


同じ条件であれば、同じように動作して、
同じ結果を返します。


人間のように気まぐれではありません。

 

2)ソフトウェアは経年変化がない。

ソフトウェアは劣化しません。
何年経っても故障したり、
動作がおかしくなることはありません。

 

何年経っても、
同じ条件であれば、
同じ結果を返します。


もし誤動作するとしたしたら、
原因は別なところにあります。

たとえば以下のようなのが原因です。


①ソフトウェアを動作させる環境(下記)に異変があった。
 ハードウェア、OS(オペレーティングシステム
②細部の動作条件が変わった。
「動作条件」とは、
該ソフトウェアの「動作タイミング」などです。


「動作タイミング」とは、
そのソフトウェアが動作する状況を意味しており、
動作環境の負荷や、排他制御の仕様によって変化します。

と、ここまでくると専門的になります。
同時に難しくなりますので、
このへんで止めておきましょう。

 

3)ソフトウェアは見えない。

ソフトウェアは電気と同じで、
目で見ることができません。


実は、ここがやっかいなのです。

この欠点を補うのがドキュメントです。

しかし、
そのドキュメントでも、
不備が多いのが現実です。


「保守員」泣かせとなっているのが現実です。

 

2.ソフトウェア開発の基本工程

次に、ソフトウェアの開発工程をみていきます。

◆私のソフトウェア経験

その前に私のソフトウェア経験をご紹介しておきます。
①経験年数:約50年
②会社:某大手鉄鋼メーカー
③分野:鉄鋼現場の制御用コンピュータシステム
※この制御用コンピュータシステムを、
我々は「プロコン」と呼んでいます。
プロセス制御用コンピュータシステムの略です。
④システム数:約500システム

 

1)開発工程

開発工程は、おおむね下記になっています。
工程名の呼称は、ソフトウェア業界によって、
少しずつ異なっているようです。


ですが、
大きな流れ(工程)はほぼ同じです。


①要求定義(機能仕様書)

ここでは、システムに組み込む機能を明確にします。


いわゆる「WHAT(何を)」
定義するものです。


よって、
作業メンバーには現場(工場)の人も参画します。

 

②機構設計(ファイル仕様書、処理仕様書)

ここでは、①で設定した機能の実現手段を明確にします。


いわゆる「HOW(どのように)」
定義するものです。


この工程で、
ある程度のシステムの概観が見えてきます。


ハードウェア仕様を決めるのも、
この工程です。

 

③プログラミング(プログラムソース)

ここでは、具体的なソフトウェアを作成します。
いわゆる「コーディング作業」です。


また、テストの一部として単体テストが含まれます。


つまり、
コーディングしたプログラムの動作検証です。


ここで行う動作検証は、

ホワイトボックステストです。


つまり、
全「カバレッジ」(ケース)が
検証の対象です。

 

3.ソフトウェア開発のポイント

以下にソフトウェア開発のポイントを列挙しておきます。

いずれも、ソフトウェアの品質を左右するものです。
ソフトウェアは劣化しないし正直です。
(上述)

ゆえに、ひとたび問題のあるソフトウェアを作成すると、
とんでもない悲劇が生じます。

①ソフトウェアの暴走。

②不正データの書き出し。

 

銀行オンラインシステムのダウンなど、
昨今のシステムトラブルは、
ソフトウェアの品質が原因となっています。

つまり、

異常ケースの想定が網羅されていないのです。


分かりやすく言うと、

異常ケースが漏れているのです。

だから、
漏れている異常ケースが発生した途端に、
「トラブル」です。

 

これでは、使い物になりません。

しかし、この使い物にならないソフトを平気で、
オンライン(本番化)しているのです。

 

「平気で」とまではいいませんが、
いろんな意味で質が低下しているのは事実です。


その質とはソフトウェア要員の質もあれば、
品質管理体制の質、
会社が品質よりコストを優先するなどの問題
などがあります。
最悪は、
その質の悪さに気づいていない組織や会社もあります。

困ったものです。

そこで、理想のソフトウェアについて言及します。

理想のソフトウェアは、
異常ケースを全ケース網羅しています。


下記のような異常処理の抽出と、
適切な処理が絶対必要なのです。

それでも、異常ケースの洗い出しは無理です。

最後は、
フェイルオーバー、
フェールプルーフ
フェイルセーフで逃げます。

 

◇フェイルオーバー:系全体を正常系へ切り替えること。
(ただし、
ソフトウェアに問題があると切り替えても問題は解決しない)

◇フェールプルーフ:誤操作時には機能しないようにする。
オートマの車で、
ブレーキを踏んでいないとエンジンがかからないなど。

◇フェイルセーフ:故障時には安全サイドに動作する。
転倒時に火が消えるストーブなど。

 

4.異常ケースを想定する

ソフトウェア開発で重要なのは異常処理です。
正常処理はもちろん大事ですが、
ソフトウェアは、異常処理のほうが、もっと大事です。

というのは、異常処理がどこまで考えられているかで、
そのソフトウェアの品質(信頼性)が決まるからです。

(上述)

だから、
ソフトウェアの品質は、

この異常処理で決まります。

 

つまり、
異常処理がどこまで考えられているかで

ソフトウェアの良否が決まります。

 

5.思考過程もドキュメントに残す

また、ドキュメントも大事です。
前述したようにソフトウェアは目に見えません。
だから、ソフトウェアの中身は文書化しなければなりません。
このドキュメントが大事です。

 

◆思考過程も。

とくに私が重視しているのは、
その処理(仕様)に至る過程です。


どういう理由で、
最終仕様(処理)にしたのか、
その過程を残すのです。

これは保守するときに非常に役に立ちます。

また、技術伝承のうえでも大事です。

このへんの考え方は、
ソフトウェア開発に限った話ではありません。

通常の仕事でも同じです。

作成者の思考過程を文書化する。

これを是非、心がけてください。

 

6.正常処理より異常処理

ここで、前述した異常処理を掘り下げます。

 

◆正常処理と異常処理の比率。

その前に、ここに一つのデータがあります。

私が調べたソフトウェアの実態です。

正常処理 : 全体の10~20%

異常処理 : 全体の80~90%

%:行数比(△△処理の行数÷全行数×100)

 

どうでしょうか。
異常処理が圧倒的に多い
ことがおわかりでしょう。

 

その異常処理の例を見ていきましょう。

 

1)入力データの種類。

入力データには下記2種類があります。

①自動入力データ。
プロセス(製造ライン)から入力されるデータ。
(重量、長さ、温度など)

 

②手動入力データ。

端末からオペレーターが入力するデータです。
製造計画など

これらの入力データに対して、
次のような処理やチェックを行います。

 

2)入力データの上下限チェック。

まず、上下限チェックです。
上下限チェックとは、
該データのレンジ(範囲)チェックのことです。

データ<下限値 ⇒ 異常(エラー)

上限値>データ ⇒ 異常(エラー)

 

◆異常検出時の処理。
このときの異常検出時の処理例を少し詳しく解説します。

 

<異常検出時の処理例>

①ログ出力。
異常を検出したことを記録に残します。
出力するのは下記です。
検出年月日時刻、生データ(異常データ)

 

②データの置換。
スライス処理:上下限値を仮の入力データにします。

この処理は、データ置換が可能で、
しかも処理の続行を優先するときです。

 

3)入力データの欠値処理。

次に入力データが欠値時の処理です。
欠値とは入力データがないときのことです。
途中のケーブルが断線したときなどです。

◆断線の検出。
断線(欠値)の検出は、
とんでもない値が入ってくることによって、
検知します。

あるいは、あらかじめ決まった値
(ex.16進8000など)で判別します。

 

◆異常検出時の処理。

①ログ出力。
異常を検出したことを記録に残します。
出力するのは下記です。
検出年月日時刻、生データ(異常データ)

②データの置換。
所定のデータを仮の入力データにします。

この処理は、データ置換が可能で、
しかも、処理の続行を優先するときのみです。

 

7.入力データの合理性チェック

次に少し高度なチェックです。
たとえば原料の粒度分布です。
この粒度分布の%(粒度比率)は、
合計が100%でなければなりません。

Σ各粒度データ=100% ⇒ 正常

このチェックで異常判定します。

 

◆異常検出時の処理。

この時は、ログ出力のみです。

データの置換処理はしません。
データの精度があまりにも悪いからです。

 

8.検討会(ウォークスルー)

f:id:kawa2496:20190213071203j:plain

①メンバー:本人(設計者)、システム関係者(原則全員)

②開催時期:下記の最低2回は実施する。
 ○処理概要完成時 ○処理仕様完成時

③基本姿勢。
◇揚げ足をとらない。
個人攻撃ではありません。
◇建設的な意見に終始する。
◇感情的にならない。
◇議事録に残し、
議論した内容を出席者で共有する。

◇必ずフォロー会議を開く。
このフォロー会議で、修正内容を確認します。
◇仕様検討会にならないこと。

ここは誤解されそうですので補足しておきます。


ソフトウェア開発工程には、
WHAT(目的)とHOW(手段)があります。


ここのウォークスルーでは、
このうちのHOW(手段)
的(まと)を絞って議論します。

 

ところが、
往々にしてWHAT(目的)の議論に発展することがあります。

 

WHAT(目的)の議論は、
ユーザーの出席が必須です。

 

WHAT(目的)の決定権は、
ユーザーにあるからです。

ところが、
今回のウォークスルーはシステム関係者だけです。


そのウォークスルーでWHAT(目的)の議論をしても、
何も決まりません。

というか、この段階では、
すでにWHAT(目的)は決まっているはずです。

ここで、過去のWHAT(目的)を蒸し返すのは、
ムダな議論といえます。

ただ、確認の場として、
本ウォークスルーを活用するのは意味があります。
(よくあることです)

 

◆蒸し返しは、よくあること。

といいましたが、
実際にはHOW(手段)の議論に、
WHAT(目的)の議論が出ることはよくあります。


しかし、そのときは、
WHAT(目的)の議論は残件として保留にしておき、
別の機会に別のメンバーで整理することにしましょう。

 

9.机上デバッグ

◆大事な点。

机上デバッグで大事なのは、
思い込みを廃することです。


そのためには、
頭がさえていることが大事です。

そのためには、
机上デバッグは朝一番でやりましょう。

できれば、
会議室などで、外乱のないところが良いでしょう。

【外乱例】電話、会話など

 

10.まとめ

f:id:kawa2496:20190127073926j:plain

どうでしたか。
ソフトウェア開発における品質管理の概要が、
ご理解いただけたと思います。

では、最後に、
普通の仕事でも応用できそうなものを、

ピックアップしておきましょう。

 

1)異常ケースを想定する。

普通の仕事でも、
正常ケースより、異常ケースのほうが多いと思います。
その異常ケースが、どの程度想定できるかで、
勝負(仕事の良否)が決まります。

 

2)ウォークスルー。

立案した計画は、関係者で検討会を開きましょう。
そのウォークスルーの基本マナーは下記です。

◇論理的な議論を。

◇立案者を攻撃したり、感情的になってはいけません。

ウォークスルーの目的は、
「いい計画」、
「いい仕事」です。


相手を落とし込めるのが
目的ではありません。

 

3)机上デバッグ

自らの机上デバッグ(問題点の抽出)も大事です。
そのときには、
固定観念は排除してください。


思い込みは、
机上デバッグ(問題点の抽出)を阻害します。

 

机上デバッグ(問題点の抽出)は、
良い環境良い時間帯で行いましょう。

 

4)思考過程の文書化。

思考過程の文書化(見える化)は大事です。

それは自分自身の反省や技術伝承に役立ちます。

自分自身の反省とは、
処理内容を検証することです。

 

なんで、こうしたのか。
どうして、こうしなかったのか。

 

この思考過程が大事なのです。

それは、自分のためでもあるし、
他人(後継者)のためでもあります。

この文書化がノウハウの蓄積になります。

よって、大変ではありますが、
必ず文書化を行ってください。

 急がば回れ です。

技術は文書化(見える化)をして
初めて「技術」となります。

それまでは、
単なる「技(わざ)」です。

最後までお読みいただき、
ありがとうございました。

【更新】2019年6月25日
中身(文章)をマイナー修正しました。
「目次」を追加しました。
これで少しは読みやすくなったと思います。

 


CAREER SKILLS ソフトウェア開発者の完全キャリアガイド

はじめて学ぶソフトウェアのテスト技法

Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

はじめて学ぶソフトウェアのテスト技法

 
ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点