ソフトウェア開発において最も重要なメトリクスは何か?

メトリクス(評価指標) の測定は、ソフトウェア開発チームとマネージャーが製品の品質を高め作業の効率を上げるのに役立ちますが、プロジェクトや組織に合った適切なメトリクスを選択することが重要です。 この記事では、ソフトウェア開発メトリクスが重要である理由、プロジェクトとチームにとって最も効果的なメトリクスを選択する方法、そして広く採用されている代表的なメトリクスについて紹介します。 1. 適切なメトリクスを選択する方法 情報は、定量化することでより便利に使えるようになります。データを集計・測定することで、どのような時間と労力の投資が実際に成果を上げているか、そしてどのようにプロセスを改善するべきかを判断することができます。 ソフトウェア開発チームとそのマネージャーは、メトリクスを基準を用いて作業において何が重要であるかを測定し、その測定結果を基にチームの目標を設定し、メトリクスの時系列変化を観察します。ソフトウェア開発メトリクスを使って、ソフトウェア開発プロジェクトの成功に不可欠な生産性、効率、品質、およびその他のKPI(Key Performance Indicator) を測定することができます。 しかし、情報と測定量は多ければよいとは限りません。ソフトウェア開発プロジェクトによって生成されるデジタルデータの量を考えると、チームにとって情報が多すぎるという問題を抱えないようにすることが重要な課題です。どのソフトウェア開発メトリクスを使うかを慎重に検討し、チームの成功をもらたすメトリクスを選択し測定する必要があります。 また、一部のソフトウェア開発チーム、特にアジャイル方法論や他のリーン・プロセスフレームワークを採用しているチームの中には、メトリクスの使用に抵抗を感じるチームもあるでしょう。データの収集と測定というあまり生産的でない作業に多くの時間を費やしたくないためです。チームがメトリクスのための作業でつまづいたり、「バニティメトリクス(Vanity Metrics: サービス改善につながらない指標、意味のない指標)」に夢中になり時間をかけすぎるような場合、製品の質も士気も低下してしまう可能性があります。 そのため、選択したメトリクスで得た情報を理解し、それによりプロジェクトの状況を決定し、時間リソースの最適化ができるかどうかを常に確認してください。 定期的にメトリクスを見直し、チームにとって引き続き有効かどうかを判断します。もし以前選択したメトリクスが役に立たなくなっていると感じたら使うのをやめ、代わりに新しいメトリクスを試してください。 2. ソフトウェア開発メトリクスの分類 開発中の製品は、順調に完成に向かっていますか? あなたのチームはどれだけうまく仕事を進めていますか? そのような質問に答えるためのソフトウェア開発メトリクスは、大きく分けて2つのカテゴリに分類されます。 デリバリー・メトリクス:スプリントの効率、プロジェクトのデリバリーまでのリードタイム、および、チームが作業を完了するまでの時間を左右するその他の要因を測定します。 これらのメトリクスは顧客満足度に影響を与えます。また、マネージャーはこれらのメトリクスを使用して、製品のリリース時期と内容を決定することができます。 テクニカル・メトリクス:コードベースのソフトウェア開発メトリクスは、技術的な観点からのプロジェクトの堅牢性を測定するもので、製品を内部レベルで分析し、製品のパフォーマンスを把握するのに役立ちます。 バグ、セキュリティなどの要因は、このテクニカル・メトリクスを使用して測定されます。 通常これらのメトリクスは、ツール等を利用して自動的に測定されるようにします。 開発チームのリーダーと協力して、自動計測をどのように実装するのが最善か、検討してみましょう。 上記を踏まえて、どのメトリクスを選択するかはあなた次第です。 さまざまなソフトウェア開発チームのリーダーが、過去の経験則に基づいてメトリクスやその計測システムを選択しています。 選択するメトリクスは、その企業固有の価値観を反映している場合もあれば、チームが現在使用している一般的なフレームワークの一部である場合もあります。…

Continue Reading ソフトウェア開発において最も重要なメトリクスは何か?

ソフトウェアメトリクス1: 循環的複雑度

 ソフトウェアの品質を測定するためのメトリクス(指標)はいろいろありますが、本記事ではソースコードの品質を評価する指標の一つ、循環的複雑度を取り上げたいと思います。1970年代に提唱されたメトリクスであり、現在のソフトウェア開発には合わないという意見もありますが、他の指標と合わせて使うことで依然として有用なメトリクスとなります。 循環的複雑度の定義  循環的複雑度(英: Cyclomatic Complexity) は、その名称から、単にプログラム内のループの個数を数えるものであると誤解されていることも多いですが、実際にはプログラムの構造を「制御フローグラフ(英: Control flow graph)」で表した際のグラフ内部の循環の数に着目してソフトウェアプログラムの複雑性を測定する指標です。1976年にMcCabe によって提案されました。ちなみに制御フローグラフとは、プログラムの実行中にプログラムを通過する可能性のあるすべての経路を有向グラフで表現したもので、Frances E. Allen によって提唱されたものです。  Fig 1 に制御フローグラフの例を示します。ここで、プログラムの開始位置をノード a, 終了位置をノード f とします。プログラム中の反復や条件分岐が開始する位置と終了する位置もそれぞれノードとなり、図の例ではノードb からe となっています。ノード間をつなぐ逐次処理の部分はエッジとなり矢印で表現されます。ちなみに、逐次処理部分は、プログラム行数が何行であっても(0行であっても) 1つのエッジとなります。 Fig 1: 制御フローグラフの例 (McCabe 1976 より転載) 循環的複雑度の定義は以下のとおりですV(G)…

Continue Reading ソフトウェアメトリクス1: 循環的複雑度
アジャイルマニフェストは今も正しい?
Photo by Bonneval Sebastien on Unsplash

アジャイルマニフェストは今も正しい?

アジャイルマニフェストは、ソフトウェア開発に大きな影響を与えただけでなく、ビジネスの世界にも応用されています。しかし、ソフトウエア開発を取り巻く環境が大きく変わってきた今、それでもまだ有効といえるでしょうか? 1. アジャイルマニフェストの概要 アジャイルマニフェストは、2001年にユタ州のリゾート地での開発者が集まる小規模な会議で考案されました。 短いながらも非常に影響力があり、「4つの価値」と「12の原則」で構成されています。「4つの価値」は以下のとおりです。 アジャイルマニフェストの4つの価値 プロセスやツールよりも個人と対話を包括的なドキュメントよりも動くソフトウェアを契約交渉よりも顧客との協調を計画に従うことよりも変化への対応を 12の原則では、迅速性、コラボレーション、継続的な反復プロセス、および定期的な製品リリースなどを重視することが述べられています。 アジャイルがうまく機能すると、これらの要素が連携して、開発者、顧客、およびその他の利害関係者間の強力なフィードバックループが確立されます。 マニフェストがソフトウェア開発に及ぼす影響は非常に大きいと言えますが、その影響力ゆえに、ソフトウェア開発の状況が変化した現在においてもマニフェストが当てはまるかどうかについては論争の的となっています。 実際、初版のマニフェストの署名者の中にも「見直す時期だと思う」と述べている人もいます。 マニフェストの原作者の1人であるAndy Hunt は、「口先だけでアジャイルを語る熱狂的なグループがいます。熱狂的なファンというものは、目的を忘れて無駄な努力だけを続けるものです。そして最悪なことに、アジャイル "手法" 自体はアジャイルではありませんでした。これはまったく皮肉なことです。」と述べています。 ソフトウェア開発者が増加し多様化する今の時代においても、アジャイルマニフェストは役に立つのでしょうか? Photo by Bonneval Sebastien on Unsplash 2. マニフェストが今も有効であるという意見 アジャイルマニフェストが現代のソフトウェア開発においても引き続き有効であるという証拠として以下の3つをあげることができます。 多くのベストプラクティスの土台 アジャイルマニフェストは、最新のソフトウェア開発における複数のベストプラクティスのコア要素となっており、これらは広く影響力を持つようになっています。 その影響力の例は次のとおりです。 スクラム:アジャイルのアイデアに基づく小規模チーム向けのフレームワークユニファイド・プロセス:ラショナル・ユニファイド・プロセス(RUP)…

Continue Reading アジャイルマニフェストは今も正しい?
プロジェクトマイルストーンの定義
Photo by Startaê Team on Unsplash https://unsplash.com/photos/7tXA8xwe4W4

プロジェクトマイルストーンの定義

プロジェクトマイルストーンは、どのようなプロジェクトにおいても重要であり、チームメンバーには重要な日付を、利害関係者には透明性を提供し、プロジェクトマネジャーにとっては、プロジェクトの管理を容易にしてくれるものです。 プロジェクトマネージャーとして、様々な部署や個人にまたがる大規模プロジェクトの計画と実行を行う際、プロジェクトマイルストーンはタスクを時間通りに維持するために不可欠です。しかし、具体的にどのようにしてプロジェクトのマイルストーンを定義するのでしょうか? プロジェクトマイルストーンとは? プロジェクトマイルストーンとは、プロジェクトの明確な成果を表す特定の時点のことです。高速道路に沿ってマイルマーカーが設置されていることで、どこまで運転したかを知ることができるように、プロジェクトマイルストーンでプロジェクトの進捗状況を知ることができます。 プロジェクトマイルストーンには通常「幅」はありません。プロジェクトの進捗状況をチームメンバーや利害関係者に正確に伝えるためには、確定した日付が重要です。これらのマイルストーンは、長いプロジェクトや大規模なプロジェクトをより管理しやすい期間毎に分割するのに役立ちます。 幹部や上位の利害関係者は、プロジェクトの日々の活動を意識していないかもしれませんが、マイルストーンが近づくにつれて、だんだん関心を持つようになります。マイルストーンに支払いが含まれている場合は、ベンダーや業者も特別な関心を持つことがあります。プロジェクトのマイルストーンに注目が集まる中、マイルストーンを正しく定義することが重要です。 マイルストーンの設定方法は? Photo by Startaê Team on Unsplash https://unsplash.com/photos/7tXA8xwe4W4 適切なマイルストーンを決定することは、プロジェクトの健全性の維持に不可欠です。プロジェクトの進捗状況を関係者全員にわかりやすく共有してくれます。 マイルストーンは、ほとんどの場合、作業の重要なフェーズの開始または終了、締め切り、またはプロジェクトのその他の主要な分岐点を表しています。プロジェクトの開始日と終了日は重要なマイルストーンですが、プロジェクトの種類によっては、その間にも数多く設定されます。 一般的なマイルストーンには、以下のようなものがあります。 主要業務の完了Go /No Go の決定テスト段階の完了最終サインオフ 家を建てることに例えると、主な成果物は家そのものであり、あなたはプロジェクトマネージャーであり、家に住む家族は利害関係者です。 プロジェクトマイルストーンのリストには、以下のようなものがあるでしょう。 月曜日に壁が完成する水曜日に屋根を仕上げる金曜日に配管工事が完了する 家族のほとんどは、自分の家に含まれているパイプの一つ一つには興味を示さないでしょうが、配管が完成したときに知りたいと思うでしょう。ここでマイルストーンの出番です。上記のリストは、あなたが家の作成に必要な全てのタスクを把握することなく、家の現状についてどこまでできているのかを通知するのに役立ちます。また、作業者も何が期待されているかを知ることができます。マイルストーンは、プロジェクトに関わる全ての人を同じ認識に保つのに役立ちます。 もちろん、マイルストーンはプロジェクトの特定のポイントをマークするだけではありません。一工夫することで、あらゆることを「スケジュール」することに役立ちます。プロジェクトのマイルストーンを使って、重要な会議やワークショップをチームに思い出させることができます。業者への支払いや、納品を期待していることを思い出すときにも使えます。プロジェクトのマイルストーンは、プロジェクトの重要な部分を皆に思い出させるシンプルで効果的な方法です。 プロジェクトマイルストーンを使ってスケジュールを組むには? プロジェクトマイルストーンは、プロジェクトマネージャがプロジェクトの特定のフェーズを完了するのに必要な時間を正確に見積もるのに役立つだけでなく、プロジェクト自体を完成させるのにも役立ちます。 プロジェクトを開始する際には、いくつかのプロジェクトマイルストーンを設定しておくと便利です。月によっては他の月よりも活動量が多い場合もありますが、経験則としては、1ヶ月に1回以上の区切りを設けるのが良いでしょう。プロジェクトの開始時からマイルストーンを組み込むことで、スポンサー、役員、その他の利害関係者からの期待を管理することができます。また、どのタスクを完了させたか、どのタスクが遅れてしまったかを記録しておくのにも役立ちます。 そのようなプロジェクトマイルストーン前に発生する様々な問題を簡単に管理するために、Sleeek…

Continue Reading プロジェクトマイルストーンの定義
リモートワークでスクラムを効果的に運営する方法
Photo by Sincerely Media on Unsplash

リモートワークでスクラムを効果的に運営する方法

スクラムは、最も人気のあるアジャイルソフトウェア開発手法です。 Coding Sansが2019年に実施したソフトウェア開発の状態に関するレポートでは、回答者の60.58%がスクラムを使用し、35.4%がカンバンを使用し、19.71%がアジャイルモデリングを使用していると回答しました。 スクラムの人気が高まっているのと同時に、リモートで作業する開発者の数も急増しています。OWLLabsによる2019年のリモート作業の現状についてのレポートによると、米国の労働者のほぼ3分の2が少なくとも一度はリモートで働いたことがあり、ほぼ半分が週に一度以上リモートで働いています。 TecLAのリサーチでは、世界でリモート勤務する職業トップ5の中にソフトウェア開発者が入っていることが報告されています。 また、ソフトウェア開発者の仕事に従事する人は2026年までに24%増加すると見込まれています。 スクラムは本来物理的に一カ所に集まるチームのために作られた開発手法であり、毎日スタンドアップ・ミーティングを開いたり、スプリントレトロスペクティブ(振り返り)という情報共有の機会が含まれています。そのため、リモートで働くソフトウェア開発者がスクラムを使って開発するには、スクラムの方法を変えなければなりません。 ソフトウェア開発においてスクラムを導入すると、以下のような利点が得られるでしょう 製品リリースを加速させる 製品の品質とチームの生産性を向上させる コストを削減させる チームの士気を向上させる 顧客満足度を向上させる 複雑なタスクの実行を可能にする 関係者により透明性を提供する リモートワークには多くの利点がありますが、リモートチームがスクラムを行う場合、スクラムにおける各種イベントや情報伝達を効果的に実行し、リモートチームであることで生じる課題を克服するという新しいチャレンジがあります。 私たちスリークは、数カ国に分散したチームを持つソフトウェア開発企業として、リモートのスクラムチームが直面する問題を過去に経験しました。 以下に、リモートであることによって悪化しがちな問題とそれに対するアイディアをいくつか挙げていきます。 スクラムを妨げるリモート作業の5つの困難 1.フィードバックの遅れ 例えば米国の開発チームがアジアにいる開発者に何か質問をする場合、現地が朝になるまで返事を待たなければならないことがあります。 返事の遅れは、開発プロセスの遅れを引き起こします。5分のチャットで済むはずの同僚とのチャットが、現地が週末に入ってしまったために週明けまで3日待たなければならないということも起こりえます。 2.困難なスケジュール調整 各開発者が時差のある場所で勤務している場合、全員が同時に参加できる会議を開くことができる時間帯は限られます。時には片方のチームが他の開発者に合わせて、通常の勤務時間外に作業をせざるを得ないこともあるかもしれません。3つ以上のタイムゾーンがある場合、スケジューリングはさらに大きな課題となるでしょう。 リモートチームとの間に時差がない場合でも、同じオフィスにいれば数分で済むような会話をするためにスケジュール調整をしなければならないこともあります。 3.プロセス統一のためのマニュアル作成 作業プロセスを記録したマニュアルの作成は、多くのチームが苦労する課題です。 しかし、リモートチームの場合には、自分が担当した作業を他のチームに引き継いだり、他のチームから引き継いだりする際に、作業プロセスを記録したマニュアルが必須です。ドキュメントが不十分であったりコミュニケーションが不足していれば、チームが作業を進めるのは難しいでしょう。マニュアルの作成は退屈で時間がかかるのに加えて効果も見えにくいため、担当者には面倒な作業と思われがちです。 4.ツールの不備 リモートチームと一緒に仕事をするためには、さまざまなツールを活用すべきです。テレビ会議や電話、メール、コラボレーション・ツールなどは、リモートチームとのコミュニケーションと作業プロセスを容易にしてくれます。…

Continue Reading リモートワークでスクラムを効果的に運営する方法