三津石智巳

👦🏻👦🏻👧🏻 Father of 3 | 🗺️ Service Reliability Engineering Manager at Rakuten Travel | 📚 Avid Reader | 👍 Wagashi | 👍 Caffe Latte | 👍 Owarai

【感想】ソフトウェア工学の勧め


ISOを調べてたら見つけて買った。

ソフトウェア工学とは「間違いばかりを犯している不完全な人間が、本来は完全であるべきソフトウェアをどのようにすれば開発し、維持することができるのかを追究するもの」であると考えている。

不完全な人間というところが好き。

逆にソフトウェア工学の成果を素直に取り入れることで、インドなどは国全体でソフトウェア産業が大きく成長するという状況を作り出している6。

なるほど。

保守を含む幅広い範囲のソフトウェアの開発部門を統括し、あるいはソフトウェア開発部門の活動に何らかの責任を持っている人たちは、ソフトウェア工学の成果を充分に理解し、評価し、開発現場にその成果を積極的に取り入れて、定着させることに努める必要がある。

その通り。

6 例えばインドでは、ソフトウェアのCMMI(能力成熟度モデル統合)ですでにレベル5の段階に至っている開発組織の数がたいへんに多い。これは、インドでは一般にソフトウェア工学のレベルが、非常に高いことを示している。CMMIについては、第40章で改めて述べる。

CMMIについて知りたい。

しかし悪いのは、ユーザや経営者だけではない。最初から無理と分かっているスケジュールを受け入れてしまうソフトウェア技術者の側にも問題がある。私は、これはソフトウェア技術者が一般に持っている「特性」によるものと考えている6。

オーナーシップには、できないことをできないということも含まれると思う。

ユーザや経営者も、押しつけたスケジュール通りにシステムが開発できると本音では思っていないことがある。この場合ユーザや経営者は、開発部門にタイトな目標を与えることによって、そうではない場合よりも早くシステムを入手できるはずだとの期待を持っている。この考えが間違いであることを、プロジェクトの見積りについての章7で、改めて述べる。

興味深い。

ふと思ったが、私は人類が20世紀的知ですらまだ十分に咀嚼できていないという信念のようなものに突き動かされている。

工業製品全体を網羅した今の品質保証の考え方では、「その製品の作り方が良ければ、その結果作られる製品の品質も良い」ということになっている。この工業製品一般に適用される品質保証の考え方をソフトウェアにも適用したものが、「ソフトウェアの品質保証」4のベースにある考え方である。

なるほど。

しかし世界標準のISO規格であっても、それが本当に我々の考えている通りのことを表現してくれているのかを検証するというスタンスは必要である。その観点から、JUASのスタンスはすばらしいと評価できる。

その通り。

ソフトウェアの品質を構成する要素は第5章で述べたように、多岐にわたる。しかしその中でポイントになる要素は信頼性に関わる部分、つまりソフトウェアに欠陥が少ないことだとケイパース・ジョーンズ(Capers Jones)は述べている[JON96b]。

なるほど。

レビューの場合はそのレビューのやり方にもよるが、良いレビューでは欠陥除去率は60パーセントから80パーセントにも達するといわれている。一方テストでの欠陥除去率はだいたい30パーセント見当である。欠陥除去率の観点から見ても、レビューの方がテストより効率的である。つまり高品質のソフトウェアを開発する上で、レビューの作業は欠かせないということになる。

信頼性を考える上で、レビューの観点が欠かせない。

ISO 9001だけでなく、ISO 9001と同じようにソフトウェアの品質システムを作ることができる「開発のためのCMMI(Capability Maturity Model Integration-DEV:能力成熟度モデル統合)v-3[CMM10a]」2やISO/IEC 155043(現在の最新の版はISO/IEC 15504-1:2004)[ISO04d]などがその組織の規格であっても良いように思える。

詳しく知りたい。

ただソフトウェアの場合、最終製品が複雑な上、実態が容易に目に見えるものではなく、さらに限られた項目の測定やテストの実施だけで必要とするソフトウェアの幅広い品質全部を保証できるものではないということなどから、「製品の品質保証」より「プロセスの品質保証」の方が、ソフトウェアの品質保証として適切なように、私には思える。

なるほど。

テストやレビューなどソフトウェアの品質を高めるための直接の活動は、やはりそのソフトウェアを開発しているプロジェクトの責任である7。そのプロジェクトの活動を支援し、結果としてプロジェクトが品質の高いソフトウェアの開発を実現することが品質保証チームの役割であり、責任であると私も考えるからである。

なるほど。

ソフトウェアの構成管理はソフトウェアに関わる変更を管理し、変更に伴うトラブルを回避することを主たる目的にしている。

なるほど。

仮に1つの航空会社がいくつもの種類のジャンボ・ジェット機を所有しているとすると、次にドックに入ってくる飛行機にはどの部品や設計図が使われているかを事前に知っていなければ、このオーバーホールや部品交換が円滑には進まない。別の言い方をすると、どの飛行機にはどのタイプの部品が使われ、どの設計図に基づいて作られたか、などをしっかりと管理しておく必要がある。

ソフトウェアとは少し違うな。

ソフトウェア会社の場合はハードウェア会社の場合ほど、「本来の」構成管理を必要としていなかった。

なるほど。

ふと思ったが、私はソフトウェア工学とビジネスの橋渡しをしたいのだと思う。ソフトウェア工学のプロフェッショナルと言えるかもしれない。

国際規格群の中のISO/IEC TR 15846:1998という技術報告書があった8[ISO98]。この技術報告書によると、ソフトウェアの構成管理は以下の7つのプロセスから構成される9。 1.ソフトウェア構成管理プロセスの実現 2.ソフトウェアの構成識別 3.ソフトウェアの構成制御 4.ソフトウェアの構成状況記録 5.ソフトウェア構成評価 6.ソフトウェアリリース管理および出荷 7.インタフェース制御

以後リストを転載していきたい。

構成管理の対象物として、その変更の管理と対応を行うものをソフトウェア構成品目(Software Configuration Item:SCI)と呼ぶ11。構成識別での最初の作業は、まずこの構成品目を明確にし、それらがそれぞれ別のものとして識別できるようにするすることである。

なるほど。

インタフェースについての文書を作成する場合、それに記載する内容には以下のようなものがある。 1.インタフェースの目的 2.インタフェースにおける要求事項 3.影響を受ける組織 4.管理するべきインタフェースについての文書 5.インタフェースに影響を与える変更要求を他者に伝える手順、およびインタフェースへの影響の評価を共同または個別に行う手順 6.インタフェースの変更管理責任者を含む、インタフェース文書の承認、変更および発行の手順 7.インタフェース文書の変更を、他の構成品目に対する変更として解釈する手順 8.役割と責任

インタフェース制御。

継続的に改善を進めるためには組織内が変化していかなければならない。変化を評価するためには測定が必要である。・・・」 この文章は、このJIS規格の元になっているISO/IEC 15939:2007の冒頭の部分との断りがある。

めっちゃいい言葉だ。

ここでバシリ教授は、ソフトウェア・メトリクスの測定項目を決めるためのアプローチは、ボトム・アップではなく、トップ・ダウンでなければならないと述べている。

技術戦略を策定することと合致する。

ISO/IEC 12207:2008に準拠して作成された「共通フレーム2013」の管理プロセスの一部である「測定」のアクティビティには、ソフトウェアの測定のためのタスク(手順)として、以下の3つの作業が挙げられている3[IPA13a]。 1.測定の計画 2.測定の実施 3.測定値の評価

測定がどこのプロセスに属しているかわからなかった。

かけることになる手間や費用と比較して結果があまり有効でないと思われる場合には、その測定は見合わせた方が良い。

「測りすぎ」でほかに指摘されていたこととして、測りやすいからといって、適切な尺度であるとは限らない。

ケイパース・ジョンズ(Capers Jones)はその著書の中で、もっと明確に次の9項目を測定の対象として挙げている「JON08」。 ①運用環境 ②開発中のプロジェクト ③ソフトウェア資産とバックログ顧客満足度 ⑤完了プロジェクト6 ⑥ソフト要因 ⑦ソフトウェアの欠陥 ⑧企業内従業員統計 ⑨企業内の意識調査

「Accelerate」と比較したい。

この規格がソフトウェア構築に関わる全ての作業を網羅していることから、今ではISOのソフトウェアに関わる規格の核とでもいうような位置づけになっている。

ISO/IEC 12007に目をつけたのは自然の流れか。

CMMIのテキストで示されたプロセス定義はここまでである。しかし私はこれに、「手順書(Script)」を付け加えたい。ハンフリー博士が提唱しているPSP1(Personal Software Process)に則ってPDCAサイクルを回してプロセスを改善する時の方法として、このプロセスの内容を記述した手順書の改訂が必要になるからである。

プロセスには手順書が含まれるか。興味深い。標準の守破離の例としても分かりやすい。

ところで、運用と保守の違いがわからない。

ソフトウェア開発の手順とは、この9個の作業を、どのような順序で行うかを示すものといえる2。その主なものとして、次のものを挙げることができる。 ・ウォータフォール型開発手順 ・インクリメンタル型開発手順 ・修正ウォータフォール型開発手順 ・スパイラル型開発手順 ・進化型開発手順 ・ラショナル統一プロセス(RUP) ・イタレイティブ型開発手順 ・U字型開発手順

なるほど。

それぞれが本当に適した領域や規模では、それが適している方法で開発するのがよい。この2つが、直線上に連続して配置される一連の開発手順の両端に位置している。つまりその両者の中間に、無数の規模や領域がある。だからこの中間に位置するソフトウェアを開発する場合には、両者の方法を折衷するのが良いとする。

その通り。だから学ばなければならない。

私のソフトウェア開発方法論は、ソフトウェアを完成させるために個々のソフトウェア・プロセスをどう組み合わせるかを問題にする「開発手順」とは異なる。 現在のところ、我々が知っている開発方法論は、構造化技法、データ中心アプローチとオブジェクト指向技法の3種類である。

開発方法論と開発手順は異なる。ドメイン駆動開発やマイクロサービスはどこか?

構造化技法とは、この一般の工業製品の開発に適用されている「分割と統合」の考え方をソフトウェアに適用しようとするものである。ソフトウェアではこれを、「トップ・ダウン・アプローチ」と呼んでいる。

究極的にはこれしかないと思っていたが、違うようだ。

モジュールの強度についていえば、「機能的レベル」が最も好ましい。機能的レベルとは、例えばC言語の実行環境にある「平方根」を計算するファンクションのように、全てのステートメントが、ある単一の機能(今のファンクションの例では、「数学的に平方根を計算する」機能)を実現するためだけに存在しているような状態をいう。

関数とかFaaSの話はここから来ているのか。

余談だが、「データ中心アプローチ」という言葉は和製英語で、欧米では通用しない。欧米ではこの方式を「インフォメーション・エンジニアリング」と呼ぶが、本当のインフォメーション・エンジニアリングとデータ中心アプローチとは対象の広さや深さの面で、後述するように大きな違いがある。

インフォメーション・エンジニアリング

トップ・ダウンでこれを行うには、充分な経験を積んだスーパーSEが必要になる。彼/彼女は仕様書に目を通しただけで実体関連図を描いて、データベース化の対象物を明確にできる。この方法だと時間は少なくてすむが、スーパーSEがいなければ実施できないという難点がある。それに対してボトム・アップの方法は、時間はかかるけれど基本的には誰でも行うことができるという利点がある。

スーパーSEがいなければボトム・アップしかない。

データベースの共用は、ビジネス・アプリケーションでの必要な要件の1つである。

もともとこれは要件だったんだよな。

レビューには、いくつかの種類がある。アメリカの学会であるIEEE(The Institute of Electric and Electronic Engineers)が決めたソフトウェア・エンジニアリング関係の標準にIEEE std 1028-2008(IEEE Standard for Software Reviews and Audit)というものがあって、ここでは次の5つについてその内容やレビューの方法が取り上げられていた1[IEEE08a]。

AuditとReview