開発者体験＜Developer Experience＞

「開発者体験」という言葉を耳にする機会があり、英語でDeveloper Experience表記するのを略して「DX」と呼ぶと知りました。今まで聞いていた「DX」はDigital Transformationの略でしたので、全く別の考え方のようです。

システム開発の効率化を促進するツールとサービスを提供している弊社OpenTextとしましては見逃せない内容のようでしたのでどのようなものか確認してみました。

“システム開発を行っている会社において、開発者の幸福度、満足度に注目し改善することでハイパフォーマンスな組織にする”

ということのようですが、どういうものかまだ良くわかりません。

システム開発現場の状況

私がシステム開発系の会社でSEをしていたころも現場の状況は厳しいものでしたが、現在も大変な状況であることに変わりはないようです。

開発に関連した作業を効率化するツールの導入がなされていないところも多く、日々の作業の忙しさから最新テクノロジの勉強が困難であり、更に日本ではIT技術者の不足がこれから更に加速すると言われています。

以下の図にあります通り30%のプロジェクトにおいてプロジェクト管理ツールを導入していないとなっていますし、2030年には80万人のIT人材不足になると言われています。

開発者にとっては非常に厳しい現状と、将来性への不安が重くのしかかっている形であり、その問題に取り組み解決を図るのが「開発者経験（Developer Experience）」と言えるようです。

システム開発を行っている会社では、社員であるIT技術者が有能でパフォーマンスを発揮してくれる環境が安定して長く続いてくれることを期待するでしょう。そのために人材の採用や育成に力を入れているはずであり、その人材が実力を発揮できる環境を整える必要があることも十分理解されているはずかと思います。

可能であれば社内のIT技術者全員がいわゆる“ハイパフォーマー”になってくれれば会社全体のパフォーマンスも向上すると期待されます。

しかし、「ハイパフォーマー」「ミドルパフォーマー」などの分類は相対的なものであり、「働きアリの法則」でも知られている通り、組織の中でハイパフォーマー：ミドルパフォーマー：ローパフォーマーの割合は

２ ： ６ ： ２

と一定に保たれると言われています。

会社全体のパフォーマンスを向上させるには全てのIT技術者層の底上げを行い、個々の力を発揮してモチベーション高く作業が出来る環境の構築が必要だと言えるかと思います。

開発者体験の向上に必要なこと

人材育成のためのトレーニングや最新技術の習得、システム品質の向上に必要となるものが「工数」です。

システム開発において工数が足りなければ必要なテストや確認作業が出来ず、品質の低いものを納品してしまうと後で問題が発見され、発見されるまでにかかった期間に比例して修正にかかる工数が増大するという悪循環に陥ります。

将来のための投資として最新技術の勉強のための工数を確保するには、現状を分析して「ムリ」「ムラ」「ムダ」を見つけて作業の自動化を行い、AI機能の導入によって改善を図っていくことが重要と考えます。

とはいえ、運用方法や組織というものは全体的にを変更することが非常に困難なものですので、取り組みが可能な小さな課題を見つけて改善を行い、それを広げている活動を継続することが大切です。

いきなり「AIを会社全体で活用する仕組みを作る」ということは出来ないと思いますので、まずは日常の業務においてAIで効率化できることを探して、AIの活用方法や効果を学ぶところから始めるのが良いのではないでしょうか。

そこから徐々にAIのしくみを理解していき、自分の組織・会社にカスタマイズしたAIサービスに取り組んでいけるように進めているという流れです。

（特にハイパフォーマーな）技術者は最新技術に対する学習意欲やチャレンジ精神が高いはずなので、日々の業務を行いながらも、効率化によって捻出した工数を有効に使って新たな分野を切り開き、更にはそれを周囲の人たちに広げて行ってくれるでしょう。

AI によるシステムDevOpsの効率化

DevOpsはそれだけでも開発プロジェクトの効率化を目指すことが出来ますが、最近ではDevOpsの各活動にもAIの活用が広がっています。

例えばOpenText™ Core Software Delivery Platformでは、以下の図にあるような機能でこれまで以上の作業効率化を図ることが可能になるものです。（※この図には将来的な実装予定も含んでいます）

• 蓄積されたプロジェクトデータから現在のプロジェクトを分析し、アラートなどを表示
• 要件、バックログからテストケースを自動生成（現在は英語のみ対応）
• 自動テストのスクリプトで、テスト対象のオブジェクトを画像からAIによって識別

OpenText™ Core Software Delivery Platformソリューション

Software Delivery PlatformはOpenTextが提供しているSaaSソリューションであり、システム開発の各工程をトータルで支える機能を持っています。UFT OneやLoadRunner、ALMなどの製品で培ってきたテスト自動化やプロジェクト品質管理の機能をクラウド上に集約し、小規模から大規模な開発プロジェクトまで広範囲に使用することが可能となっています。

Software Delivery Platformは多くのCI/CDサーバ等の環境とインテグレーションすることが出来るため、既存の環境を生かしたまま開発の効率化を機能テスト／パフォーマンステスト、監視やリリースの自動化に取り組むことが可能となります。

Developer Experienceの効果

書籍「LeanとDevOpsの科学（インプレス社）」では、約23,000件のアンケートデータから実際のアジャイル開発やDevOpsに現場においてツールやプロセスの導入が企業のパフォーマンス向上に大きく貢献しているということを筋道たてて紹介されています。

この書籍ではアンケートと調査の結果から、アーキテクチャのキーポイントとして以下の点などが挙げられています。

• システムのタイプとデリバリーのパフォーマンス

調査結果から、システムのタイプがSOEであってもSORであってもデリバリーのパフォーマンスを向上させることは可能だが、次のキーポイントである容易性が需要であるとされています。

• 注力すべきはデプロイとテストの容易性

特に疎結合のアーキテクチャにおいては、「テスト容易性」と「デリバリー容易性」によってパフォーマンスを向上させることが出来るとされています。

• 必要なツールをチーム自らが選択できる

ツールをチームが選択できる場合、ソフトウェアデリバリのパフォーマンスが向上し、それが組織全体のパフォーマンスにも好影響を与えるとされています。

最後の「ツールがチーム自ら選択する」という点は、開発者が好むOSSを推奨しているように思われるかもしれませんが、実際の開発現場ではツールに予算を使わない傾向が強くOSSを使用するしかないという状況が多いのではないでしょうか。

便利なツールをチームが選択できる機会を奪っているのであれば、それはパフォーマンスの向上を妨げる要因となりますので、企業としてはツールの選択肢を広く持つべきだと思います。 殆どの企業において、ツールの導入は効率化に大きく貢献しており、開発者のモチベーション向上に役立っていると記載されていますので、興味がありましたら書籍を参照下さい。

今回のまとめ

IT技術者の不足が問題になっている今、作業の自動化や効率化によって技術者のモチベーションを高く保ち、より一層活躍出来る環境を整えることが重要だと考えます。

そのためにDeveloper Experience（開発者体験）という考え方を参考にし、開発者の活躍できる場を整えることが企業の競争力強化に繋がっていきます。

The post ◆◆DevOpsあれもこれも＜第四回＞◆◆ appeared first on OpenText Blogs.

Value Streamの見える化と最適化＜Value Stream Mapping＞

第一回、第二回でのValue Stream Managementのお話においては、システム開発における工数と品質の数値化に関して説明しました。

Value Stream Managementでは数値として「リードタイム」を重要視しており、その分析を行うことも出来る方法が今回の主題であるValue Stream Mappingです。

～ Value Stream Mappingとは ～

Value Stream Mappingは以下のように説明されています。

“Value Stream Management の中でも、業務プロセスを「物と情報の流れ」の図によって表すことで価値を効率よく生み出す部分と無駄の多い部分を明確にし、システム開発においてはリードタイムを短くすることに大きな効果を発揮する” 以下のような図を作成してボトルネックや問題点、リスクなどの分析使用出来ます。

システム開発においてリードタイムを短くすることが可能になるものだと分かりますが、そもそもリードタイムとは何でしょうか。

リードタイムを説明すると “工程や作業の最初から最後までにかかる時間”となりますので、例えば開発したシステムのアプリをテストするためのモバイルデバイスを調達にかかる時間で考えてみます。

リードタイム　＝　‘デバイスを入手した時間‘　－　‘デバイス調達を開始した時間’

処理全体では以下のような様々な工程が必要となるかと思います。

• 必要な機種を選定する
• 価格を調査する
• 業者を選定する
• 業者から見積りを入手する
• 予算申請を行う
• 予算許可を入手する
• 購入処理を行う
• デバイスを受け取る

この工程全体にかかる時間（期間）ですが、実際には“機種選定で議論する時間”、“業者に依頼してから見積りが来るまでの時間”、“購入してからデバイスが届くまでの時間”などのタイトルからは見えない作業や待ち時間が含まれているはずです。

このように工程を洗い出し、かかっている時間を細かい単位で分析したのち、作業の時間短縮や待ち時間の解消など改善ポイントを探すことでリードタイムの削減を進めます。

実際にはどのようにして分析を行うのか見てみましょう。

Value Stream Mappingの事前準備

Value Stream　Mappingは各チーム、部署の代表者が同じ場所に集まって行います。

開発するシステムが複数のサブシステム／サービスに分かれている場合はそれぞれの代表、またセキュリティやネットワーク、データベースなどそれぞれのチームの代表およびマネージャも参加して進めます。

このため、事前の連絡やスケジュール調整が大変重要になりますので、組織を横断して声がけが可能な方の協力を得て進めて下さい。

集まってからValue Stream Mapを完成させるまで短くても半日以上の時間がかかりますので、参加者には目的と時間、当日の作業内容を伝え、事前に理解してもう必要があると思います。

Value Stream Mapping当日は参加者全員が収容可能な部屋と１０枚ほどの大きな紙、３色以上のペン（マジック）を数セット用意しておきます。

準備が整ったら、ファシリテータ（あなた）がValue Stream Mappingの概要を説明し、壁に貼った紙に対してどのようにValue Stream Mapを記入していくのか方法を説明します。

記入は参加者自身にやっていただきます。

Value Stream Mappingの分析の流れ

Value Stream Mappingは以下のような流れで実施します。

1. アーキテクチャ全体象の共有
2. プロセスに関するディスカッション
3. プロセスの詳細を記述
4. 最終確認
5. 「ムダ」および「リスク」の場所や理由を記入
6. 改善方法のディスカッション

アーキテクチャ全体像の共有 ： 代表者が対象システムの全体像を説明し、各チームの代表から不足点を補足説明してもらうことで、全体像を共有します。

プロセスに関するディスカッション ： システムのプロセス（流れ）を紙に書き出す前にディスカッションし、抜け漏れが無いかおおまかに確認します。

プロセスの詳細を記述 ： 壁に貼った紙の一番右にゴールを記述し、そこから左に向かって順番にプロセスを記述していきます。複数のプロセスを纏めて扱える場合は、枠で囲って分かりやすくしておきます。

また、プロセスの下にはその工程で必要な（かかった）時間を記入しておきます。

最終確認 ： 記入したプロセスを全員で確認し、間違いや漏れをチェックします。

「ムダ」や「リスク」が発生している場所や理由を記入 ： 各プロセスにおいて無駄な時間が発生していると考えている個所、問題が起こるリスクがある箇所に、その時間や理由と思われるもの（返信待ち、リソース的なボトルネック、環境やシステムのスケジュール調整不足、など）を記入していく。

改善方法のディスカッション ：  「ムダ」と思われる箇所に対して、どのようにすれば「ムダ」を減らすことが出来るのかをディスカッションします。

Value Stream Mappingのサンプル

例えば、モバイルアプリを開発しており、そのテストに非常に多くの工数がかかっているとします。そのシステムの開発にかかわるマネージャ、各開発チーム、テストチームが集まってテストに関連したプロセスをValue Stream Mappingで書き出したとします。

このサンプルでは３つの問題点でテスト作業が遅延しており、セキュリティリスクも存在していたと判明しました。

• テスト用デバイスを準備する際、他のチームが既に同じものを持っているか、自分たちがテストしたい時期にそのデバイスを借りられるかの確認に時間がかかっていた。
• テスト作業を社外で行う場合があり、開発中のモバイルアプリを社外に持ち出す必要があったため情報漏洩のリスクがあった。
• 実際にデバイスを使用してテストを行う際に、誰かが使用中の場合や故障で使用出来ないなどのケースがあり、テストが遅延する場合があった。

これらの問題点を確認し、以下のような解決策を検討することになると思います。

• テスト用モバイルデバイスを社内で一元管理し、どのようなデバイスがあり、いつテストに使用出来るのかスケジュール管理も行える環境を用意する。
• デバイスはVPNのネットワークアクセスで外部からもリモート操作可能にし、デバイスやアプリを外部に持ち出す必要が無いようにした。
• デバイスを集中管理することで重複を減らし、削減出来た分を予備のデバイス準備に回すことで故障などによる突発的な原因によるテスト遅延を防ぐことにした。

Value Stream Mappingの代表的な表記

Value Stream Mappingの表記には様々なパターンがありますので、ネットで検索して自分の担当しているシステムに合ったものを見つけていただくのが良いかと思います。

今回のサンプルは、Microsoft Power Point用に配布されていた表記パターンを使用しており、以下のような意味で使用しています。

Value Stream Mappingの体験例

参考までに私が最初にValue Stream Mappingのファシリテータを行った際の情報を記載します。

会社 ： IT系システム開発会社

対象プロジェクト ： 社内のシステム開発プロジェクト

参加者 ： 同プロジェクト内のチーム毎の代表の方々

実施時間 ： 約半日

本来は複数の部署の代表に集まっていただくべきですが、初回ということもあり普段からお付き合いのあった部署の複数チームの方に集まっていただき、気兼ねなく現状や問題点に関してディスカッションいただく場としました。

“Agile開発とそれに伴うCI/CDに取り組みたいが普段の業務が忙しくて難しい”との悩みをお持ちでしたが、開発プロセスをValue Stream Mapに書き出しビルドプロセスを見直すことで、単体テストの実施を自動化できるかもしれないと改善ポイントを見出されていました。

それぞれのチームで分かれて作業していると開発プロセスを見直すということは合意を得るのが難しいですが、集まって問題点を全員で見つけて行くと自然な形で次に取り組むべき作業を認識することが出来、モチベーション高く自主的に作業を行っていけるようでした。

Value Stream Mappingの効果

実際にValue Stream Mappingを実施した結果、以下の効果を実感することが出来ました。

• 各部署・チームの代表者が参加することで、情報共有と合意形成が可能
• それぞれが課題や解決策を考えることで、自分自身の考えで改善を進めることが可能＝＞上層部からの指示やベンダー主導のPOCよりも、自主的な活動としての認識が強く生まれる
• 上層部もオブザーバとして参加することで課題や改善必要性への理解が得られる＝＞活動の予算や工数の確保への承認が比較的容易

今回のまとめ

システム開発のプロセスを分析・改善する方法として、Value Stream Mappingが使用可能であることを説明しました。

Value Stream Mappingによって「ムダ」を見つけて改善し、リードタイムを短くすることで短期間でのシステム更新を可能にし、企業としてのDevOps導入と促進を

次回は、開発プロセスにおいて改善を進める意味・目的を改めて考える、Developer Experience（開発者体験）に関してお話いたします。

The post ◆◆DevOpsあれもこれも＜第三回＞◆◆ appeared first on OpenText Blogs.

みずほリサーチ&テクノロジーズ株式会社は、みずほ銀行の勘定系システム「MINORI」の開発における業務効率化と品質向上を目的に、3,500画面/60万項目に及ぶUIテストの自動化に取り組みました。OpenText Functional Testingを活用してテスト打鍵自動化ツール「MIBOT」を開発し、従来8日間かかっていたテスト作業を3時間に短縮。大量の打鍵テストに必要な要員数も85名から9名まで削減するなど、大幅な効率化を実現しています。
 
詳細はこちら
https://www.microfocus-enterprise.co.jp/casestudies/pdfs/mizuho.pdf
 
この製品の詳細はこちらをご覧ください
https://www.opentext.com/ja-jp/products/functional-testing

The post みずほ銀行の勘定系システム「MINORI」のUIテストをOpenText™  Functional Testing で自動化しテスト工数を大幅削減 appeared first on OpenText Blogs.

Value Stream ManagementとDevOpsの実現～後編～

前回（第一回）では、Value Streamという考え方に関して説明を行い、そこで使用される品質の数値化に関してご紹介しました。今回は工数の可視化に使用される数値と、工数見積もりに使用される手法をお話します。

～ システム開発における数値化 ～

前回も使用した以下の図において、システム開発における数値化の代表的なものを示してあります。今回は【工数の可視化】に関してお話していきます。

～工数目線での数値化～

プロジェクトマネージャは、プロジェクト開始時に要件を分析してシステム開発の工数を概算します。システム開発を計画期間内に終了させるために、作業要員のスキルや必要な作業工数を見極める必要があるためです。

現実問題として、例えば私がSEとして働いていたころは開発プロジェクトの予算、納期が既に決められた状態で開発チームに話が来ることが多く、納期に間に合わせる形で逆算してスケジュールを設定していました。

逆算で作成したスケジュールは予定通りにいかず、恥ずかしながらプロジェクト後半は残業の山ということが非常に多い状態でした。

私の苦い経験談はさておき、要件から開発要員の工数を見積もるためには経験を元にしたおおよその数値化とスケジューリングが行われますが、根拠の少ない数値化では最終的に工数がオーバーしてしまうことが少なくありません。その見積りの失敗を防ぐため、要件の複雑度を数値化して工数にあてはめるFunction Point法（FP法）を使用することが可能です。 これは機能要件のデータとトランザクションを分析して数値化するものであり、すなわちデータファイルや項目の数や外部入出力のトランザクション数などから機能の作成にかかる数字を計算させることで、開発に必要な工数をなるべく現実に近い形で事前に算出しようとするものです。

要件の優先度付け

要件を数値化出来たとしても、開発プロジェクトにはスケジュール管理が必要ですので、同じくらいの数値の要件が複数ある場合などには優先度をつけて作業する必要があり、いわゆる要件の順位付けとスコーピングが重要になってきます。 たとえば、優先度を決めるには以下のような方法も存在します。

◆$100テスト

以下の5つの要件があったとします

1. 都心に緑を増やす
2. 少子化対策
3. 犯罪を減らし安全な街を作る
4. 減税
5. 地震（防災）対策

関係者が各自で＄１００ドルずつ持っており、その全てを使いきる形で５つの要件に異なる金額を割り振ります。

全員の割り振った金額を要件ごとに集計し、合計金額が多い順から優先度が高いものとします。

実際のプロジェクトでこのような方法で見積もるのは難しいかもしれませんが、練習としてチーム内で行うことで見積りの経験を積みながらプロジェクトの理解も進み、認識を共有できるというメリットはあるはずです。

バックログの優先度づけ

FP法はウォーターフォール型の開発で良く使用されていましたが、Agile開発においてはまた別のアプローチが存在します。チームでバックログの比重を数値化するために使用する「ストーリーポイント」と呼ばれる数値があり、以下のように使用されます。

• バックログ毎のストーリーポイントを設定
• スプリントのベロシティを確認、調整
• 振り返りによる再調整
• ダッシュボードによるプロジェクト状況確認

Agile開発においては、プロダクトバックログの複雑度や必要な工数を見極めるのは責任者だけの役割ではなく、プロダクトチームの全員が参加してストーリーポイントを決めていきます。 ストーリーポイントの値を決めるための「プランニングポーカー」というものが存在しますのでご紹介します。

Planning Pokerには１、２、３、５、８、１３、２０、４０、１００ の数字`などが書かれたものが、赤、黄色など複数の色のセットで用意されています。ストーリーポイントを見積もる人（グループ）毎に色を決めて配って使用します。

◆Planning Pokerの手順

• プロダクトバックログを選択
• 基準となるバックログを選択
• Planning Pokerを配る
• Planning Pokerを使用してポイントを決める
• チームで話し合ってストーリーポイントを修正する

例えば、以下のバックログ（機能要件）があったとします

タイトル：目玉焼きを作る

• 卵を用意する
• フライパンに油をひく
• 卵を割ってフライパンで焼く
• 目玉焼きを器に盛る

上記の目玉焼きバックログのストーリーポイントを１とした場合に、以下のバックログのストーリーポイントはどれくらいになるか各自（各チーム）でポイントを考えてみましょう。

タイトル：カルボナーラを作る

• パスタ、ベーコン、卵、チーズ、塩、オリーブオイルを用意する
• パスタを茹でる
• チーズをすり下ろす
• フライパンでベーコンをオリーブオイルで炒め、ベーコンは取り除く
• フライパンにパスタを入れ卵黄とチーズを混ぜる
• パスタとベーコンを器に盛る

各自が数値を選んだら、全員の数字を見せ合ってそれぞれの数値の根拠を聞きながら調整を行い、全員の合意を得ることが出来る数字が出たら決定とします。

実際にカルボナーラを作ったことがある人がいたら、“卵を入れたらソースが固まってしまった”などの失敗談から注意点を指摘し、問題を回避するための手順を提示できるかもしれません。

イテレーション単位のバックログのストーリーポイントでベロシティを調整するには、チームバックログ画面においてスプリントのチームとそのキャパシティを確認し、担当者アサインの可否判断やスプリントの見直しを行います。

Value Stream Managementではプロジェクトの価値を考えるため、価値とはどういうものを指すのかを以下のように定義しています。

～Value Stream ManagementのValue～

これらの数値はOpenText™ Core Software Delivery PlatformというAgileプロジェクト管理のトータルソリューションサーバに登録することが出来るもので、Value Streamにおける品質の管理が可能となります。この詳細はまた後日のこのブログでご紹介させていただきます。

今回のまとめ

プロジェクトの管理には数値による見える化が重要であり、そのために使用する品質と工数の面での様々な数値化の方法に関して代表的なものを紹介しました。

次回は、Value Stream Managementで使用するもう一つの重要な数値であるリードタイムに関してお話します。

The post ◆◆DevOpsあれもこれも＜第二回＞◆◆ appeared first on OpenText Blogs.

Value Stream ManagementとDevOpsの実現 ～前編～

Value Streamという言葉はトヨタ生産方式で提唱された考え方で、システム開発においても　Lean開発手法に引き継がれて現在でも活用されています。

システム開発の方式がウォーターフォール型からAgile型へ変化し、そして開発と運用が連動するDevOpsが求められる現在、Value Streamの重要性は更に大きくなっていると感じています。

～ Value Stream Managementとは ～

VSM Consortium(https://www.vsmconsortium.org/)によると

”バリューストリームマネジメントは、アイデアから開発、生産に至る異種ソフトウェアデリバリーパイプラインにおけるビジネスバリューの流れをマッピングし、可視化、測定、最適化、管理する人、プロセス、テクノロジーの組み合わせである。”

とされています。

IT系の会社であってもそれ以外の業種であっても、課題を持つユーザに価値（Value）を届けることを目的としている訳ですから、その流れをしっかりと把握して正しくかつ効率よく流れるようにすることが出来れば関係者全てが幸せになることが出来る、という意味だと捉えて良いのではないでしょうか。

Value Stream（価値の流れ）を分析するために、Value Stream Mappingという手法を用いて図を作成する場合もあります。

Value Stream Mapping手法の詳細に関しては、このブログの第三回でとりあげる予定ですので、そちらを参照下さい。

ここで注意が必要なのは、トヨタ生産方式から始まるValue Streamの考え方は工場などでの生産や関連した物流に注目して作られており、我々が扱っているソフトウェアシステムの開発とは同じようには扱えない点です。

車にももちろん設計書が必要であり、構想から設計や実験の工程で多くの努力がなされていることと思いますが、設計書が完成してからはその関連する部品を集めて組み立て完成品を納品する作業が長期間にわたって繰り返されるものであり、トヨタ生産方式ではその生産ラインでのムリ、ムダ、ムラを減らしていこうという取り組みになっています。

対して、システム開発プロジェクトにおいては毎回その要件は異なります。そのため、工程の前半では要件分析から要件定義などシステム設計に多くの工数が必要となります。

このブログで取り上げるのは、システム開発における Digital Value Stream の分析と改善を行う流れの部分です。

～ Value Stream Managementにおける数値化と測定 ～

“If you can’t measure it, you can’t manage it.”

“計測出来ないものは、管理出来ない”

というのは有名なピーター・ドラッカー（Peter Drucker）の言葉です。

ビジネスバリュー（価値）を測定／最適化するにはバリュー（価値）を数値化／可視化する必要がありますので、まずはその数値化の方法を確認してみましょう。

～品質目線での数値化～

～これまでの開発プロジェクトにおける数値化～

コード行数（LOC : Lines Of Code)はシステム・プログラムの規模を図るために使用されていた歴史があり、現在でもニュース等で“数百万行のコードで作成された大規模システム”という表現がされる場合があるくらい、規模の大きさを表すものとして多くの場面で使用されています。

コード行数は単純にソースコードの行を数えただけであり、言ってしまえばコピー＆ペーストで同じような機能を複製して作っていった場合にいくらでも数が増えてしまい、たいして複雑ではないシステムでもLOCの数はやたら大きいものとなってしまう可能性もあります。

類似性チェックツールを使用してコピーされた無駄なソースコードを減らすのも有効であり、ソースコードの複雑さを数値化して一定の値以下に保つことで、システムのメンテナンス性を向上させることも可能です。
ソースコードの複雑さを構造から測るため考え出されたサイクロマティック複雑度は以下のように計算され、関数・メソッド単位での分岐の数からソースコードの複雑度、メンテナンス性などを図る目安にすることが出来ます。

オブジェクト指向言語が主流の現在では、コード行数やサイクロマティック複雑度ではなく「継承の深さ」や「クラス結合、戻り値やインターフェースなどによる結合度計測」によってクラス設計が適切かどうかを判断されているケースも多いかと思います。

また、「カバレッジ率」、「パフォーマンス解析ツール」などの品質基準は、ソースコードやプログラムがあればツールを使って分析することで数値として結果が出ることもあり、明確な指標として使用されている方も多いでしょう。

カバレッジ率にはソースコードの行単位でテスト網羅性を図る「コードカバレッジ」と、テストの件数によってその実行率を図る「テストカバレッジ」があります。

コードカバレッジは更にソースコードのどのレベルでの網羅率を図るかによって「C0（シーゼロ）」「C1（シーワン）」などの計測方法があります。

ツールで最も対応が多いのが「C0（シーゼロ）」カバレッジで、ソースコードの行単位でテストによってどの部分が実行されたのか計測出来るようになっており、「ステートメントカバレッジ」とも呼ばれます。

以下の図では、テストで実行されたステートメントと実行されていないステートメントを色分けして分かりやすく表示しています。また、図の下部ではメソッド単位でのカバレッジ率を表示することでテストの網羅率、進捗率を確認することが出来るようになっています。

以下の図では、要件に紐づいたテストケースが何件あり、その何件がテストに成功しているかを数値によって確認するテストカバレッジによって、要件の完了を確認することが出来るようになっています。

以下の図では、実際にアプリケーションを実行してパフォーマンスを計測し、どのクラスのどのメソッドで一番時間がかかっているのかを分析することが出来るようになっています。

テストに関連した数値の殆どのものは閾値を設けて品質判定基準として使用することも可能なはずです。

今回のまとめ

プロジェクトの管理には数値による見える化が重要であり、そのために使用する品質管理の面での様々な数値化の方法に関して代表的なものを紹介しました。

次回は、システム開発において進捗を管理するための工数の数値化と、Value Stream Managementで使用される価値の数値化に関してお話します。

The post ◆◆DevOpsあれもこれも＜第一回＞◆◆　　 appeared first on OpenText Blogs.

マツダ株式会社、テスト自動化ソリューションOpenText Functional Testingを活用し、グローバル基幹システムの運用効率向上とセキュリティ強化を推進

「走る歓び」を追求し、MAZDAブランドの自動車を世界に展開するマツダ株式会社。同社はデジタル活用とセキュリティ強化の一環として、Oracle EBS環境のテスト自動化ソリューションとしてOpenText Functional Testingを採用。11インスタンス/複数の国にまたがるマルチベンダー体制の大規模なアップデートプロジェクトの実施に続き、さらにテスト工程全体で67%の工数削減を目指し、システムのセキュリティ強化と運用効率化の両立を図っています。

マツダ株式会社の事例詳細はこちら

https://www.microfocus-enterprise.co.jp/casestudies/pdfs/mazda.pdf

The post OracleEBS環境に欠かせない、テスト自動化ソリューションのMAZDA事例 appeared first on OpenText Blogs.