ソフトウェア技術者としての責務に関する考察

Facebook にシェア
このエントリーをはてなブックマークに追加
[`livedoor` not found]
Delicious にシェア

大学院のソフトウェア工学で、「ソフトウェア開発の専門家としてのソフトウェア技術者は、雇用主によって明示的に要求されていない場合であっても、保守と変更が容易なプログラムを作成する責務がある。」に対する考察を行ったので、今後の備忘のために残します。

考察があっているかは分かりませんが、心に留めながら仕事していきたいと思います。

 

1. 「ソフトウェア開発の専門家としてのソフトウェア技術者は、雇用主によって明示的に要求されていない場合であっても、保守と変更が容易なプログラムを作成する責務がある。」に対する考察をせよ。

結論から述べると、ソフトウェア技術者は成果物リリース後の運用フェーズを常に意識しながらソフトウェア開発を行う必要がある。また、常にそのソフトウェアを使用するユーザの立場に立ち、ソフトウェア開発を行う事も重要である。理由として、一度リリースしたシステムやソフトウェアは7~10年間程使用される為、この長いソフトウェアライフサイクルの中で、どのような事が起きる・行われるかを意識するかしないかにより、ソフトウェア本体や各種ドキュメント等の成果物の優劣が大きく変わってくるからである。この結論に至るまでの過程を次項以降で詳細に分析を行う。

2. 「ソフトウェア技術者の職業倫理」による分析

ソフトウェア技術者の職業倫理として常に心掛ける事として、「ユーザ志向であること」を挙げる。ユーザとは、ソフトウェアの発注元(顧客)やそのソフトウェアを実際に使用する使用者を指す。私達ソフトウェア技術者は誰の為に何の為にこのソフトウェアを開発しているかを考えると、最終的にユーザ志向に行き着くと考えている。また、再発注を受ける為には、顧客満足度を上げる必要もある。ユーザ志向を持つと、ユーザインタフェースが格段に良くなる。開発者としては工数の掛かる機能であっても、その機能を10年間使用するユーザにとっては、その一瞬の不都合な機能が積み重なる事により、大きな対応工数になる事が多い。例えば、1機能毎に開発担当者が別であったとする。それぞれの開発担当者が実現し切れない部分を安易に”ユーザによるマニュアル対応”と位置付けて処理した場合、何が起きるか。対象機能が100あれば、100のマニュアル対応が発生する事になる。マニュアル対応によるヒューマンエラーを無くし、極力システム化する事が私達の使命である事が念頭にあれば、安易な仕様決定とはならないはずである。次の職業倫理として、「保守性を意識すること」がある。ソフトウェアはリリース後に必ず機能追加やバグが発生する。その際に、保守性が高いソフトウェアは機能追加やバグ修正が容易である。保守性が低い場合、対応時の工数が大きく異なる。1機能毎の対応工数に差がある場合、ソフトウェアが使用される10年間ではどの程度差が開くかを考えると、保守性を意識することの重要性は理解出来る。また、対応工数差の比率は常に同じではない。保守性が低いながらも、機能追加を行い続けたソフトウェアは、後続の機能追加が非常に難しくなる。難しくなると、設計、実装、テスト等の各工程で工数を大きく取られる為、対応工数差の比率は更に広がる。よって、保守性を意識することは、対価を支払う顧客の為でもあり、運用保守を行う仲間の為にもなる。

3. 「ソフトウェアの品質」による分析

ソフトウェアの品質とは人により捉え方が異なるものである。例えば、ソフトウェア技術者にとっては、ソースコードの品質であり、そのレベル感も個々に異なる。ユーザにとっては、システム(ソフトウェア)の品質であり、同様に個々に使用感や、ビジネスプロセスの効率化に品質を感じるかもしれない。よって、ソフトウェア技術者として大事な事は、誰の為のソフトウェアであるかを意識することである。個人的にはソースコードの品質が大事なのは当然の事として、よりユーザの立場に立ち、分析・設計・実装等を行って行く事が、ソフトウェアの価値向上に繋がり、ソフトウェア品質が向上する。ユーザの立場に立ったのと同様に運用保守担当者の立場に立った場合はどのように振舞うべきか。意識をしていなければ、成果物には反映されない事は明白である。

4. 「ソフトウェアプロセス」による分析

ウォーターフォールモデルのような規範的なプロセスモデルとアジャイル開発のようなアジャイルプロセスモデルを比較すると、どちらも一長一短があり、どちらが優れているということは言えない。よって、必ずどちらかのプロセスモデルで実施するのではなく、状況により選択していく柔軟性が大事である。例えば、運用保守フェーズであれば、アジャイルプロセスモデルが適している。顧客もチームメンバとして迎え、設計→プロト実装→本実装→テスト→リリースのイテレーションを行う。これにより保守運用フェーズのスピード感を出し易い。一方、規範的なプロセスモデルでは、開発フェーズの前にプロトタイプフェーズを行うのが良い。プロトタイプを行う事で余分な工数が掛かるが、顧客やユーザとの仕様のズレが解消され、顧客満足度を上げやすい。また、プロトタイプを実装するにあたり、調査等も行う為、設計・実装工程以降のインプットともなり易く、結果として工数短縮に繋がりやすい。設計・実装の前にある程度詳細に把握出来ていると、後工程の成果物精度が上がり、結果より良いソフトウェアライフサイクルに繋がるのではないだろうか。

5. 「ソフトウェアの分析、設計、実装、テスト」による分析

本項ではソフトウェアの分析、設計、実装、テストの各工程における分析を行う。

 
5.1. 分析

分析工程ではオブジェクト指向分析、構造化分析等の分析方法があるが、最終的な成果物は、顧客のようなソフトウェア技術者以外の人が確認し易い記法で書かなければならない。例えば、オブジェクト指向分析であれば、UMLを使用し、ユースケース図やユースケース記述、アクティビティ図等であり、構造化分析であれば、DFD等である。これらの成果物は設計工程以降のインプット情報となり、運用保守にも読まれる成果物となる。また、要求仕様化をするにあたり、As-Isモデル、To-Beモデルを定義すると良い。これらは顧客側や開発側の漏れを無くし、ビジネスプロセスの再構築に役立つ。同様に運用保守時の理解促進に役立つ。

 
5.2. 設計

設計書は何の為にあるか。私は運用保守フェーズ以降の為にあると考える。運用保守フェーズでは、新しいベンダーや担当者が入ってくる事が多いが、分析工程の成果物と一緒に参照されるのは設計書類となる。よって、設計書は実装の為に書くのではなく、保守対応者へのメッセージとして書く必要がある。但し、注意点として、設計書が必ず正しいわけではない。結局真実はソースコードそのものである。また、設計と言っても、基本設計、概要設計、詳細設計と複数あるが、実装をする為の詳細設計は必要ないと考えている。必要があれば、後追いで作成が可能である。実装中に詳細設計に記述している内容とズレが出てくる事は普通であるし、運用保守において詳細設計書を確認する事は少ないはずだからである。前述しているが、詳細設計書を参照するのであれば、ソースコードを確認したほうが良い。詳細設計が無い事により、設計書の作成や修正といった無駄な工数削減が可能である。注意点として、その前工程にあたる概要設計の記述レベルとして詳細に記述する事は極力避けるべきである。特に大規模開発で開発工程を開発パートナーへ依頼する場合は、ある程度の仕様に揺れ(不明点や考慮が必要だと感じてもらう)を持たせ、開発工程で検討を行ってもらう事が大事である。理由として、請け負った時点である程度詳細に決まっていると、更なる詳細部分(例えば、頻度の低いエラーケース等)を考慮しなくなる恐れがあるからである。よって、各設計書の記述レベルを事前に定義し、周知徹底する事が結果的に品質のよいソフトウェアが完成する。

 
5.3. 実装

シンプルなソースコードは、可読性・保守性・開発効率、そして美がある。言い換えると美しいソースコードは結局シンプルである。シンプルなコードを実装する事は、ソフトウェアライフサイクルが上手く循環する為の根幹となる。シンプルなコード→可読性が良い→保守性が良い→開発効率が上がる→機能毎の工数が減る→他機能に工数を掛ける→→→……(循環する)また、最低限の処理効率化は必要あるが、過度な効率化やテクニカルな記述は避けるべきである。個々の要件にもよるが、以前と比較し、CPUやメモリ等のハードウェア性能も上がっている為、過度な効率化を進めるよりも、多少の緩みを持たせ可読性を上げるべきである。必要であれば、スケールアウト・スケールアップや他技術の併用によりパフォーマンス改善は可能である。

 
5.4. テスト

テストの無いソフトウェア開発は有り得ない。これは誰もが共通の認識であると思うが、テストにたいする意識レベルの差により出来は全く違うものになる。まず、ソフトウェアのテストは何の為にあるのかを考えると、テストケースやテストデータ作成に対して、気を抜けなくなるはずである。私にとってテストケース・データの作成タスクは楽しい作業ではないが、ケースやデータがソフトウェアの仕様を網羅しているかを常に意識している。テスト方法としては、ホワイトボックステストよりもブラックボックステストの方が大事である。ソフトウェアが持つ本来の仕様を満たしているかどうかは、ブラックボックスでないと分からないからである。また、後工程で発覚したテスト不足は前工程に逆戻りするだけでなく、コストに大きなインパクトを与える事が多い。テスト工程は時間が掛かるが、やはり大事な工程である。以上のような意識を持ながらテストを行う事で、運用保守フェーズにおけるバグ発覚は非常に少なくなる。

6. まとめ

以上の事から、保守と変更が容易なプログラムを作成する為には、ソフトウェア技術者がどの立ち位置で振舞うかによって、結果は全く異なる。ソフトウェア構築サービスを請け負う以上、当然これらの責務を負い、遂行しなければならないと考える。

以上