異常ケースが大切、ソフトウェア開発のポイントは普通の仕事にも通じる
こんにちは、
拙作ブログをご覧いただきありがとうございます。
今回は、
ソフトウェア開発について考えてみたいと思います。
というと、
特殊な専門分野を連想しますが、
ここで述べるポイントは、
普通の仕事でも使えます。
よって、
ソフトウェア開発に興味がなくても、
最後までお読みいただければと思っています。
ちなみに、
私は約50年、
ソフトウェアの開発に従事していました。
- 1.ソフトウェアの特徴
- 2.ソフトウェア開発の基本工程
- 3.ソフトウェア開発のポイント
- 4.異常ケースを想定する
- 5.思考過程もドキュメントに残す
- 6.正常処理より異常処理
- 7.入力データの合理性チェック
- 8.検討会(ウォークスルー)
- 9.机上デバッグ
- 10.まとめ
- 【関連記事】
- ※更新履歴※
- ※CMリンク※
1.ソフトウェアの特徴
ソフトウェアについて少し触れておきます。
ソフトウェアにお詳しい読者は、
本項は読み飛ばしてください。
1)ソフトウェアは正直。
ソフトウェアは正確かつ確実に動作します。
同じ条件であれば、同じように動作して、
同じ結果を返します。
人間のように気まぐれではありません。
2)ソフトウェアは経年変化がない。
ソフトウェアは劣化しません。
何年経っても故障したり、
動作がおかしくなることはありません。
何年経っても、
同じ条件であれば、
同じ結果を返します。
もし誤動作するとしたしたら、
原因は別なところにあります。
たとえば以下のようなのが原因です。
①ソフトウェアを動作させる環境(下記)に異変があった。
ハードウェア、OS(オペレーティングシステム)
②細部の動作条件が変わった。
「動作条件」とは、
該ソフトウェアの「動作タイミング」などです。
「動作タイミング」とは、
そのソフトウェアが動作する状況を意味しており、
動作環境の負荷や、排他制御の仕様によって変化します。
と、ここまでくると専門的になります。
同時に難しくなりますので、
このへんで止めておきましょう。
3)ソフトウェアは見えない。
ソフトウェアは電気と同じで、
目で見ることができません。
実は、ここがやっかいなのです。
この欠点を補うのが、
ドキュメントです。
しかし、
そのドキュメントでも、
不備が多いのが現実です。
「保守員」泣かせになっているのが現実です。
2.ソフトウェア開発の基本工程
次にソフトウェアの開発工程をみていきます。
2-1.私のソフトウェア経験
その前に私のソフトウェア経験をご紹介しておきます。
①経験年数:約50年
②会社:某大手鉄鋼メーカー
③分野:鉄鋼現場の制御用コンピュータシステム
※この制御用コンピュータシステムを、
我々は「プロコン」と呼んでいます。
プロセス制御用コンピュータシステムの略です。
④システム数:約500システム
1)開発工程
開発工程は、おおむね下記となっています。
工程名の呼称は、ソフトウェア業界によって、
少しずつ異なっているようです。
ですが、
大きな流れ(工程)はほぼ同じです。
①要求定義(機能仕様書)
ここでは、システムに組み込む機能を明確にします。
いわゆる「WHAT(何を)」を
定義するものです。
よって、
作業メンバーには現場(工場)の人も参画します。
②機構設計(ファイル仕様書、処理仕様書)
ここでは、①で設定した機能の実現手段を明確にします。
いわゆる「HOW(どのように)」を
定義するものです。
この工程で、
ある程度のシステムの概観が見えてきます。
ハードウェア仕様を決めるのも、
この工程です。
③プログラミング(プログラムソース)
ここでは、具体的なソフトウェアを作成します。
いわゆる「コーディング作業」です。
また、テストの一部として「単体テスト」が含まれます。
つまり、
コーディングしたプログラムの動作検証です。
ここで行う動作検証は、
「ホワイトボックステスト」です。
つまり、
全「カバレッジ」(ケース)が
検証の対象です。
3.ソフトウェア開発のポイント
以下にソフトウェア開発のポイントを列挙しておきます。
いずれも、
ソフトウェアの品質を左右するものです。
ソフトウェアは劣化しないし、正直です。
(上述)
ゆえに、
ひとたび問題のあるソフトウェアを作成すると、
とんでもない悲劇が生じます。
①ソフトウェアの暴走。
②不正データの書き出し。
銀行オンラインシステムのダウンなど、
昨今のシステムトラブルは、
ソフトウェアの品質が原因となっています。
つまり、
異常ケースの想定が網羅されていないのです。
分かりやすく言うと、
異常ケースが漏れているのです。
だから、
漏れていた異常ケースが発生した途端に、
「トラブル」です。
これでは、使い物になりません。
しかし、この使い物にならないソフトを平気で、
オンライン(本番化)しているのです。
「平気で」とまではいいませんが、
いろんな意味で質が低下しているのは事実です。
その質とはソフトウェア要員の質もあれば、
品質管理体制の質、
会社が品質よりコストを優先する
などの問題などがあります。
最悪時は、
その質の悪さに気づいていない組織や会社もあります。
困ったものです。
そこで、
理想のソフトウェアについて言及します。
理想のソフトウェアは、
異常ケースを全ケース網羅しています。
下記のような異常処理の抽出と、
適切な処理が絶対必要なのです。
それでも、異常ケースの洗い出しは無理です。
最後は、
フェイルオーバー、
フェールプルーフ、
フェイルセーフで逃げます。
◇フェイルオーバー:系全体を正常系へ切り替えること。
(ただし、
ソフトウェアに問題があると切り替えても問題は解決しない)
◇フェールプルーフ:誤操作時には機能しないようにする。
オートマの車で、
ブレーキを踏んでいないとエンジンがかからないなど。
◇フェイルセーフ:故障時には安全サイドに動作する。
転倒時に火が消えるストーブなど。
4.異常ケースを想定する
ソフトウェア開発で重要なのは異常処理です。
正常処理はもちろん大事ですが、
ソフトウェアは、
異常処理のほうがもっと大事です。
というのも、
異常処理をどこまで考えられているかで、
そのソフトウェアの品質(信頼性)が決まる
からです。(上述)
つまり、
異常処理がどこまで考えられているかで
ソフトウェアの良否が決まります。
5.思考過程もドキュメントに残す
また、ドキュメントも大事です。
前述したようにソフトウェアは目に見えません。
だから、
ソフトウェアの中身を文書化しなければなりません。
このドキュメントが大事です。
5-1.思考過程も
とくに私が重視しているのは、
その処理(仕様)に至る過程です。
どういう理由で、
最終仕様(処理)にしたのか、
その過程を残すのです。
これは保守するときに非常に役に立ちます。
また、技術伝承のうえでも大事です。
このへんの考え方は、
ソフトウェア開発に限った話ではありません。
通常の仕事でも同じです。
作業者の思考過程を文書化する。
これを是非、心がけてください。
6.正常処理より異常処理
ここで、前述した異常処理を掘り下げます。
6-1.正常処理と異常処理の比率
その前に、ここに一つのデータがあります。
私が調べたソフトウェアの実態です。
正常処理 : 全体の10~20%
異常処理 : 全体の80~90%
%:行数比(△△処理の行数÷全行数×100)
どうでしょうか。
異常処理が圧倒的に多い
ことがおわかりでしょう。
その異常処理の例を見ていきましょう。
6-2.入力データ
入力データには下記2種類があります。
①自動入力データ。
プロセス(製造ライン)から入力されるデータ。
(重量、長さ、温度など)
②手動入力データ。
端末からオペレーターが入力するデータです。
製造計画など
これらの入力データに対して、
次のような処理やチェックを行います。
6-3.入力データの上下限チェック
まず、上下限チェックです。
上下限チェックとは、
該データのレンジ(範囲)チェックのことです。
データ<下限値 ⇒ 異常(エラー)
上限値>データ ⇒ 異常(エラー)
◆異常検出時の処理。
このときの異常検出時の処理例を少し詳しく解説します。
<異常検出時の処理例>
①ログ出力。
異常を検出したことを記録に残します。
出力するのは下記です。
検出年月日時刻、生データ(異常データ)
②データの置換。
スライス処理:上下限値を仮の入力データにします。
この処理は、データ置換が可能で、
しかも処理の続行を優先するときです。
6-4.入力データの欠値処理
次に入力データが欠値時の処理です。
欠値とは入力データがないときのことです。
途中のケーブルが断線したときなどです。
◆断線の検出。
断線(欠値)の検出は、
とんでもない値が入ってくることによって、
検知します。
あるいは、あらかじめ決まった値
(ex.16進8000など)で判別します。
◆異常検出時の処理。
①ログ出力。
異常を検出したことを記録に残します。
出力するのは下記です。
検出年月日時刻、生データ(異常データ)
②データの置換。
所定のデータを仮の入力データにします。
この処理は、データ置換が可能で、
しかも、処理の続行を優先するときのみです。
7.入力データの合理性チェック
次に少し高度なチェックです。
たとえば原料の粒度分布です。
この粒度分布の%(粒度比率)は、
合計が100%でなければなりません。
Σ各粒度データ=100% ⇒ 正常
このチェックで異常判定します。
◆異常検出時の処理。
この時は、ログ出力のみです。
データの置換処理はしません。
データの精度があまりにも悪いからです。
8.検討会(ウォークスルー)
①メンバー:本人(設計者)、システム関係者(原則全員)
②開催時期:下記の最低2回は実施する。
○処理概要完成時 ○処理仕様完成時
③基本姿勢。
◇揚げ足をとらない。
個人攻撃ではありません。
◇建設的な意見に終始する。
◇感情的にならない。
◇議事録に残し、
議論した内容を出席者で共有する。
◇必ずフォロー会議を開く。
このフォロー会議で、修正内容を確認します。
◇仕様検討会にならないこと。
ここは誤解されそうですので補足しておきます。
ソフトウェア開発工程には、
WHAT(目的)とHOW(手段)があります。
ここのウォークスルーでは、
このうちのHOW(手段)に
的(まと)を絞って議論します。
ところが、
往々にしてWHAT(目的)の議論に発展することがあります。
WHAT(目的)の議論は、
ユーザーの出席が必須です。
WHAT(目的)の決定権は、
ユーザーにあるからです。
ところが、
今回のウォークスルーはシステム関係者だけです。
そのウォークスルーでWHAT(目的)の議論をしても、
何も決まりません。
というか、この段階では、
すでにWHAT(目的)は決まっているはずです。
ここで、過去のWHAT(目的)を蒸し返すのは、
ムダな議論といえます。
ただ、確認の場として、
本ウォークスルーを活用するのは意味があります。
(よくあることです)
8-1.蒸し返しはよくあること
といいましたが、
実際にはHOW(手段)の議論に、
WHAT(目的)の議論が出ることはよくあります。
しかし、そのときは、
WHAT(目的)の議論は残件として保留にしておき、
別の機会に別のメンバーで整理することにしましょう。
9.机上デバッグ
◆大事な点。
机上デバッグで大事なのは、
思い込みを廃することです。
そのためには、
頭がさえていることが大事です。
そのためには、
机上デバッグは朝一番でやりましょう。
できれば、
会議室などで、外乱のないところが良いでしょう。
【外乱例】電話、会話など
10.まとめ
どうでしたか。
ソフトウェア開発における品質管理の概要が、
ご理解いただけたと思います。
では、最後に、
普通の仕事でも応用できそうなものを、
ピックアップしておきましょう。
1)異常ケースを想定する。
普通の仕事でも、
正常ケースより、異常ケースのほうが多いと思います。
その異常ケースが、どの程度想定できるかで、
勝負(仕事の良否)が決まります。
2)ウォークスルー。
立案した計画は、関係者で検討会を開きましょう。
そのウォークスルーの基本マナーは下記です。
◇論理的な議論を。
◇立案者を攻撃したり、感情的になってはいけません。
ウォークスルーの目的は、
「いい計画」、
「いい仕事」です。
相手を丸め込めることが目的ではありません。
3)机上デバッグ。
自らの机上デバッグ(問題点の抽出)も大事です。
そのときには、
固定観念は排除してください。
思い込みは、
机上デバッグ(問題点の抽出)を阻害します。
机上デバッグ(問題点の抽出)は、
良い環境と良い時間帯で行いましょう。
4)思考過程の文書化。
思考過程の文書化(見える化)は大事です。
それは自分自身の反省や技術伝承に役立ちます。
自分自身の反省とは、
処理内容を検証することです。
なんで、こうしたのか。
どうして、こうしなかったのか。
この思考過程が大事なのです。
それは、自分のためでもあるし、
他人(後継者)のためでもあります。
この文書化がノウハウの蓄積になります。
よって、大変ではありますが、
必ず文書化を行ってください。
急がば回れ です。
技術は文書化(見える化)をして
初めて「技術」となります。
それまでは、
単なる「技(わざ)」です。
最後までお読みいただき、
ありがとうございました。
【関連記事】
※更新履歴※
【更新】2019年10月22日、2020年2月8日、24日、6月21日、11月13日、2021年8月27日、2022年10月19日
少しだけ校正させていただきました。
【更新】2019年6月25日
中身(文章)をマイナー修正しました。
「目次」を追加しました。
これで少しは読みやすくなったと思います。
※CMリンク※
CAREER SKILLS ソフトウェア開発者の完全キャリアガイド
はじめて学ぶソフトウェアのテスト技法
Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)
はじめて学ぶソフトウェアのテスト技法
ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点