概要表示の使い方

Sider Labs の解析結果の画面(ダッシュボード)では、様々な方法でコードクローンの分析を行うことができますが、この記事では「概要」タブにおけるコードクローンの可視化機能について使い方を説明します。 概要タブにはクローンの可視化パネルがあります。ホイール表示は、プロジェクトの全ファイルのうち、コードクローンが存在するファイルのみを抽出し、同一のクローンを持つファイル間の関係を図示したものです。プロジェクトのファイルが円環に沿って表示されています。円環を繋ぐように飛んでいる円弧が2つのファイル間に存在するクローンになります。円弧の幅がクローンのステートメント数に対応しており、円弧をクリックすると、実際のクローンのコードを閲覧できます。一方で、同一ファイル内部のクローンは円環のうえの「コブ」として表現されています。もし、ある程度大きな幅で、異なる2つのファイル間にまたがる円弧が表示されていたら、クローンの内容を確認することをお薦めします。ユーティリティ関数やクラスとしてまとめることで、コード品質をあげられるかもしれません。 ホイール表示の例 例えば上図はある3D画像処理のオープンソースソフトウェアのレポジトリを分析したものですが、"vmStackedVolume.cpp"(黄色)と、"vmBlockVolume.cpp"(ピンク)との間には、ステートメント数が30 から150程度のクローンペアが10個以上検出されており(図中右下の赤い点線部)、ファイルの名称も近いことから何らかの形で共通化できる余地がありそうです。 非常に大規模なプロジェクトの場合、ファイル相関図のファイル名や表示がほとんど見えなくなってしまうことがあります。今後、UI/UXの改善を行っていく予定ですが、ホイール表示の円環にマウスオーバーすると全ファイル名が表示されます。また、図の右上の「拡大」ボタンで図を拡大することもできます。「重要度トップ10」や「クローン数トップ10」のファイルのみで描画することもできます。ご活用下さい。

Continue Reading 概要表示の使い方

成功への分岐点 — ソフトウェアブランチのベストプラクティス —

ソフトウェア開発チームは、迅速に行動しなければなりません。予算はますます厳しくなっています。タイムラインも短くなってきています。そして、クライアントは常により多くの機能を求めてきます。もしあなたのチームが最大限の能力を発揮できるようにしたいのであれば、可能な限り効率的に仕事をする必要があります。 ソフトウェア開発チームにとって、ブランチの作成方法は生産性に関わる一要素ですが、いわゆるベストプラクティスを採用してないケースも多いようです。結果として、多くの問題や余計な労力が発生している可能性があります。この記事では、生産性を向上させる9つの方法を紹介します。 0.ブランチとは何ですか? ブランチとは、バージョン管理システム(Version Control System: VCS)で管理されているオブジェクトのコピーのことです。VCS内のコードベースは別名トランク(幹) とも呼ばれ、そこから異なる「ブランチ(枝)」が分岐しています。これらのブランチによって、ソフトウェア開発者は、コードベースを不安定化させることなく、分離して実験することができます。大規模なプロジェクトでは、開発者や品質保証など、多くの異なる役割が必要になります。ブランチを使うことで、これらの異なる役割を満たし、並行して開発することができます。一人の人間がブランチに変更を加えても、他のチームメンバーに影響を与えることはありません。 ブランチの利点は、多くの異なる人々が同時にプロジェクトに取り組むことができるということですが、ソフトウェアのブランチ化のベストプラクティスを持っていない場合、これは大きな頭痛の種になる可能性があります。 以下では、9つのベストプラクティスを紹介します。 1.ブランチング戦略をチームに伝える まず、どのようなブランチング戦略を採用するかを決める必要があります。ソフトウェアチームが利用するブランチング戦略で、広く採用されているものは以下の3つです。 Git Flow はおそらく最もよく知られている戦略です。2010年に策定されたこの戦略では、master が本番用ブランチであり、develop がベースブランチとして扱われるとしています。feature-*、hotfix-*、release-*など、さまざまなサポートブランチを使用することもできます。Git Flow は非常に厳格なプロセスを作成しますが、これはマージやリリースにおける心理的な不安を和らげるのに役立つかもしれません。もしあなたのQAプロセスが厳格なものであれば、Git Flowはあなたにとって最高のブランチング戦略となるかもしれません。 コインの裏返しになりますが、Git Flowは開発が本番と同等ではないため、環境間の移行が必須になります。そのため、頻繁なリリースを行う継続的デリバリー(CD)や継続的インテグレーション(CI)は、Git Flowの下では困難になる可能性があります。また、Gitの履歴が読めなくなることもしばしばあります。 https://www.nicoespeon.com/en/2013/08/which-git-workflow-for-my-project/ より転載 GitHub Flowは、Git Flowに比べてプロセスがはるかに簡素化されており、複数の異なる環境や同時バージョンの管理を必要としない小規模なチームにとっては、優れた選択肢となります。GitHub Flowでは、まずマスターブランチから始めます。作業が必要になるたびに、新しいブランチをチェックアウトします。作業内容を確認してマージする準備ができたら、master へのプルリクエストを開くだけです。マージされてmasterにプッシュされたら、理想的にはすぐにデプロイするべきです。…

Continue Reading 成功への分岐点 — ソフトウェアブランチのベストプラクティス —
ソフトウェアメトリクス2:ソースコードの規模
Carpenter holding a measure tape on the work bench

ソフトウェアメトリクス2:ソースコードの規模

いまさら Lines-of-code?   ソースコードの規模を測定する際に、最もよく使われるメトリクスはコード行数、いわゆるLines-of-code (LOC) でしょう。古くからあるメトリクスである上に、計測も簡単にできます。Linux 環境であれば、wc -l コマンド一発ですし、エディタで常時表示させることもできます。  ただし、ご存知とおりLOC は取り扱いが難しいメトリクスでもあります。特に、LOC を作業量の見積もりや、開発チームのパフォーマンスの計測に使う場合は、使い方を誤ると批判が生まれます。例えば、2つの異なるチームが「オンラインでの支払いシステム」を開発した時に、同じ期間で1000行のコードで開発したのと、100行のコードで開発したのでは、どちらのチームがパフォーマンスがよいと言えるでしょうか。ほぼ同じ機能であるならば、開発時のコストはもちろん、その後の保守メンテナンスのことも考えれば、より少ない行数で実現できた方がよいことは疑いようがありません。最近のNo Code の流行にもあるように、全くコードを書かずに実現できれば、それが最も効率が良いとも言えます。  LOC の問題点の一つは、単純な変数の代入も、複雑な算術演算ステートメントも、同じ1行でカウントされてしまうことにあります。この問題点を解決する一つのアイディアは、行の複雑度に応じて重み付けをすることですが、「17行目のステートメントが45行目のステートメントよりも2倍の重みを持っている」などと定量的に表現することは容易ではありません。LOC は、その名の通り単位「コードの行数」を数えただけのものであり、開発時間や、生産性や、コストに直接変換できるものではありません。  このように、様々な問題をもつメトリクスではありますが、それでもなおLOC が有用な場面は多数あります。例えば、LOCの絶対量ではなく相対的な変化に注目してチームの開発フェーズの変化を知ることができます。前述の通り、LOCの値そのものはチームの生産性と必ずしも関連性があるとは言えませんが、同じプロジェクト、同じチームにおいて、チームの先週のLOCと今週のLOC を比較することで、増加傾向であれば「設計フェーズから実装フェーズに入った」とか、減少傾向であれば「実装が一段落してテストフェーズに入った」などと類推することができます。  他には、LOC はテストや保守の基準値として使われることもあります。10万行のソフトウェアは、1万行のソフトウェアよりも保守やテストのコストがかかるのは同意できるところだと思います。バグの数をLOC で割ったものを「バグ密度」と定義し、ソフトウェア品質の基準値として使っているチームもあります。  LOCの計測方法にはいくつかの定義があり、チームや組織で採用する場合は同じ定義を一貫して使うことが重要です。単純にテキストファイルとしての行数(Physical LOC)を使うこともありますが、多くの場合、空行とコメント行を除いた行数(Non-comment LOC: NLOC)や、NLOCからさらに、「2つの命令が書かれた行は2行と数える」、「括弧だけの行を除く」などの換算をした行数(Logical LOC: LLOC)を用いることが多いでしょう。コメントの行数をComment lines of…

Continue Reading ソフトウェアメトリクス2:ソースコードの規模
ソースコードレビューツールとは?代表的ツール7種をご紹介
Software engineers people working on project and programming in company

ソースコードレビューツールとは?代表的ツール7種をご紹介

 ソースコードレビューは、近年のソフトウェア開発プロセスに不可欠な要素ですが、リリース時期が迫りメンバーが多忙になると、十分にコードの確認ができなかったり、レビュー自体がスキップされてしまうことも起こりがちです。そのような忙しい場合でも品質を一定に保つためには、レビューの効率を上げる必要があります。この記事では、コードレビューの効率を上げるために、現在(2020年)広く導入されているコードレビューツールを7つご紹介します。 ソースコードレビューとは?  ソースコードレビューが行われるタイミングは様々です。ソースコードマネージメントツールとしてGitHubやGitLab を利用している場合は、最も一般的なコードレビューのタイミングはPull Request (GitLab の場合Mearge Request) のタイミングでしょう。組み込み系開発などでは、ある程度まとまった単位でのコードを、メンバー全員で時間をかけてレビューするやり方もあります。コードレビューを行う主たる目的は以下のとおりです。 不具合の発見: マルウェア、バグ、パフォーマンスの問題、セキュリティホールなど、コードの欠陥を見つけることは、コードレビューの最もな重要な要素です。 コード品質の向上: ソースコード単体の不具合を見つけるだけではなく、プロジェクト全体の品質を改善します。「機能している」からといって、改善する箇所がないわけではありません。コードレビューによってリファクタリングが必要な箇所がみつかることもあるでしょう。 学習・ナレッジシェア:  新人開発者や品質保証エンジニアは、コードレビュープロセスを導入することで、開発者の意図を学ぶことができ、スキルアップにもつながります。また、チームの誰かがなんらかの理由で抜けることになっても、他のメンバーがバックアップ可能になります。 連帯感の向上: コードレビューは、チームワーク、責任感、コミュニティの形成に役立ちます。 コードレビューツール7選  今日の市場には数十種類ものコードレビューツールが存在し、その中から組織のニーズに最適なものを選ぶのは難しいでしょう。以下では、汎用性が高くかつ堅牢なコードレビューツールを紹介します。 GitHub GitHubはプルリクエストの画面にコードレビューツールが付属しています。すでにGitHubを使ってGitレポジトリをクラウドで管理している場合、プルリクエストを使ってコードをレビューするのはもはやあたりまえになっているかもしれません。無料でも利用可能ですが、保持できるデータ量や月ごとに行えるアクション数に制限があるため、チームや企業で利用する場合は有料のオプションを選択することになるでしょう。 GitHubでは、レポジトリへのアクセス権を持つメンバーをプルリクエスト毎にレビュアーとして割り当てることができます。プルリクエストを提出した開発者は、管理者にコードレビューを依頼することもできます。変更履歴の確認だけでなく、プルリクエストの議論やdiffの分析、インラインでのコメントも可能です。コードレビューツールでは、GitにおけるコンフリクトをWebインターフェイスで解決することもできます。さらに、マーケットプレイスを通じて追加のレビューツールと統合することで、レビュープロセスの機能を拡張することもできます。 GitHub付属のコードレビューツールは、あなたの組織がすでにGitHubを利用している場合には最適なツールです。すべてが組み込まれているので、追加のインストールや設定は必要ありません。 Review Board Review Board は、このWebベースのオープンソースのコードレビューツールです。コードレビューとドキュメントレビューの両方が利用可能で、コード比較をグラフィカルに表示することができます。ウェブサイトでデモ版を試すこともできるし、ソフトウェアをダウンロードして自分のサーバーにセットアップすることもできます。Review Board の初期バージョンはかなり前にリリースされたものですが、依然として活発な開発が行われています。…

Continue Reading ソースコードレビューツールとは?代表的ツール7種をご紹介
リファクタリングはじめの1歩 — 手法や注意点を初心者向けに解説 —
Group of young programmers developing data code, working together in modern office, panorama with free space

リファクタリングはじめの1歩 — 手法や注意点を初心者向けに解説 —

リファクタリングとは?  プロのソフトウェア開発者はほぼ全員知っているが、学生やアマチュアの開発者はあまり知らない用語として、真っ先に思いつくものの一つが「リファクタリング」ではないでしょうか。  アマチュアの開発者は、多くの場合自分のためだけにコードを書きます。コードは論文発表のためだったり、自分の作りたい実験的なシステムのためだったり、目的は様々ですが、基本的には期限付きのもので必要な時にある程度動作すればそれでよく、目的を果たした後はそのまま放置されることがほとんどでしょう。一方、プロの開発者は、チームで作業を行うことがほとんどです。プロジェクトの存続期間も長く、製品を完成させた後も、機能追加・機能改善など引き続き作業が発生します。そのため、 他人が読んで理解しやすい変更がしやすいバグが生まれにくい など、いわゆる「品質の高い」コードであるかどうかは非常に重要なポイントになります。  リファクタリングは、ソースコードの品質を向上させる手法の一つです。リファクタリングの教科書ともいえる名著「リファクタリング(第2版): 既存のコードを安全に改善する」での定義を引用すれば、 リファクタリングとは、ソフトウェアの外部の振る舞いを保ったままで、内部の構造を改善していく作業 を指します。具体的には、様々な理由で設計が劣化し、可読性が低下してしまったソースコードを、機能毎に切り分けてクラス化・関数化したり、逆に同じ処理をまとめてクラス化・関数化したり、変数や関数名をわかりやすいものに変えたり、様々な手法を用いて人間にとって理解しやすいコードに置き換えます。この際、ソフトウェアを使うユーザー側から見える挙動は変わっていません(厳密には、処理速度が速くなったり遅くなったりすることがあるかもしれませんが、それが許容できるか、あるいは思わぬプラスの効果になるかはシステムによります)。 リファクタリングにより、以下のようなメリットが得られます。 全体的な開発スピードの向上リファクタリングにより設計が改善されると、各モジュールの影響範囲が明確になります。これにより、例えば新規機能開発の際に、どこをどのように変更すればいいか、容易に理解することができ、開発スピードが上がります。 潜在的なバグの顕在化リファクタリングの作業にはバク修正は含まれていませんが、リファクタリング作業自体を通して、そのソースコードの深く理解することができます。最終的に設計やコードをわかりやすくした結果として、いままで気が付かなかったバグが発見されることがあります。 チームとしてのパフォーマンス向上前述のとおり、多くのソフトウェア開発プロジェクトはチーム戦です。自分の書いたコードを他のメンバーがデバックすることもあるでしょう。リファクタリングを行い定常的に可読性を高めておくことは、むしろ自分以外の各メンバーにとってメリットが大きいといえます。また、新しく加わるメンバーにとっても、コードの理解が容易であれば、戦力になるまでのキャッチアップの時間を最小限にできます。 逆にデメリットとしては、リファクタリングをしている間はユーザーが受ける価値は全く変わらない、ということが挙げられます。もっと悪いケースとして、リファクタリングのやり方によっては、せっかく正常に動作しているソフトウェアに手を加えることで、動作がおかしくなってしまうこともありえます。リファクタリングは、ある意味で将来への投資であり、今、ソースコードの品質を上げるコストを支払うことで、上に挙げた将来の開発上の様々なメリットを享受する行為と言えます。つまり、リファクタリングを行うか否かは、 現在の製品がユーザーに与えている価値製品の将来ロードマップリファクタリングにかかるコストリファクタリングにより、動作している製品を改修するリスク逆にリファクタリングしない場合の、将来のバグやトラブルのリスク などを総合的に分析して決断すべきでしょう。そのような決断をする際の判断材料のひとつととして、Sider Labs を使用いただければ幸いです。 リファクタリングの方法 この章ではリファクタリングの具体的なやり方について説明します。まず最初に準備することは、リファクタリング対象となるコードについての十分なテストコードを用意することです。「動いているものには触るな」という格言があるように、正常に動いているものに手を入れるのは怖いものです。加えた変更の影響範囲が把握できずに、意図せず別の箇所でバグを生んでしまうことは十分ありえます。そのため、テストコードを用意して動作を確認をしながら安全にリファクタリングを行うことが重要になります。  テストの作成には時間がかかりますが、コードとテストと、自分の実現したいことを2度書くこと自体が、バグを減らすことにつながります。また、GitHub, GitLab などのバージョン管理ツールを導入していない場合は必ず導入しましょう。もしなんらかの問題で、動作がおかしくなってしまっても、バージョン管理ツールで正常な状態にいつでも戻すことができます。  テストコードの準備ができたら、いよいよリファクタリングを行います。コードの可読性を上げる手法はいろいろあります。先に紹介した、「リファクタリング(第2版): 既存のコードを安全に改善する」では、リファクタリングの手法(How) が78種類ものパターンに分類されて、それぞれの典型的な手順がまとめられています。また、リファクタリングを始めるトリガー(When) となる「コードの不吉な臭い(英: Code Smell)」についても、24種類のパターンを示しています。ここでは、我々のSider Labs…

Continue Reading リファクタリングはじめの1歩 — 手法や注意点を初心者向けに解説 —

GitとGitプラットフォームについてと、GitHubかGitLabかBitBucketの3大Gitプラットフォーム紹介

Gitについて 2020年現在、ソースコード管理システムとしてはおそらく最も使われているのはGitです。GitはLinuxの開発者でもあるLinus Benedict Torvalds氏により開発され2005年に登場しました。当時はCVSやSVNやが主流でしたが、開発者個々人が細かな変更履歴も含めて管理(記録・追跡)が行えるバージョン管理システムとしてGitが使われるようになってきました。 その後、Gitのプラットフォーム、特にGitHub.comの登場とオープンソースソフトウェアの開発コミュニティのGitHubへの移行に伴いGitの普及速度がますます伸び、現在ではデファクトのバージョン管理システムであると言っても過言ではない普及率になっているかと思います。 Gitプラットフォームのメリット 2010年頃の日本では公式(標準)のGit を自社のサーバー上で稼働させているケースも多くありました。一方で、Gitサーバーの運用コストも低くはなく、より利便性の高い、クラウドで動作するGitプラットフォームサービス、GitHubやBitBucket、GitLabなどがその後大きく普及し、2020年現在では、Gitサーバー単体の利用や運用ではなく上述のものを利用しているチームが殆どを占めているように思います。 Gitサーバー単体ではソースコードを管理することが出来るのみで、UIなどはなく、コードレビューの機能なども備えていません。コマンドラインからGitサーバーのURLに対してブランチ(メインブランチから派生したトピックブランチ、もしくはメインブランチのソースコード)をPushして保管することが出来るのみです。 Gitサーバーの運用を簡単にするのに加えて、UIなどの様々な機能を追加したものがGitプラットフォームです。 プラットフォームを利用するメリットとして特に次の3つがどのプラットフォームでも共通して言えるものであり、大きいメリットでしょう。 ソースコードのコラボレーション開発・コードレビュー機能(Pull Request、Merge Request) WebUIで様々ながことが行える高いユーザビリティ チケット管理機能などの開発に関わる重要な付随機能やそういった機能・サードパティサービスとの連携機能 ソースコードのコラボレーション開発・コードレビュー機能(Pull Request、Merge Request) Gitではメインブランチとは別にトピックブランチなどで開発をし、メインブランチにPull Request(or Merge Request)を作成、トピックブランチでの開発内容をメインブランチに取り込むことによって、ノンリニア開発(数千の並列ブランチでの開発)を実現します。 それに伴い非常に重要な役割を果たすのがにPull Request(or Merge Request)といった機能で、メインブランチとサブブランチの差分を表示し、また、それについて開発者同士でコメント等によりコミュニケーションを行いマージするかどうかの可否判断をすることができます。 業務でのソフトウェア開発やオープンソースソフトウェアの開発など、あらゆる種類のソフトウェアの開発でこの機能は利用されています。 WebUIで様々ながことが行える高いユーザビリティ Gitサーバー単体ではすべての操作がコマンドライン経由であり多くの方にとって難しい、利便性が低い、とっつきづらいものでしょう。その点、先述のGitプラットフォームはいずれもソースコードを簡単にに閲覧する事ができる、ファイルや行ごとにいつ誰がどのような理由(コミットメッセージ)でコミットしたか、などを容易に閲覧や検索が出来るなどの強力な機能、ユーザビリティが備わっています。…

Continue Reading GitとGitプラットフォームについてと、GitHubかGitLabかBitBucketの3大Gitプラットフォーム紹介
SVNからGitへの移行 ~ SVNからGitLab CE(Self-hosted)への移行ステップガイド
SVNからGitLabへの移行の手順です

SVNからGitへの移行 ~ SVNからGitLab CE(Self-hosted)への移行ステップガイド

はじめに 近年ではバージョン管理システムのディファクトスタンダードといっても過言ではないGitですが、実際にはまだまだSubversion(以下、SVN)で管理をしている現場も多いと思われます。 また、「GitやGitlabの名前は聞いたことがあるけど、SVNとの違いがよくわからない」「SVNの管理から移行するメリットはなんなのか?」 「今のプロジェクトを移行してみたいけど、どうすればいいのか?安全に移行できる?」といった疑問をお持ちの方も多いのではないでしょうか。 確かに、使い慣れたツールや管理方法を変更するのであれば、相応のメリットが欲しいところです。また、実際に移行する作業も わかりやすく、かつ安全に実行できることが望ましいです。 そこで本記事では、前半で「SVNとGitの違いはなにか」「バージョン管理をGit(GitLab)で行うメリット」について紹介をし、 後半でSVN管理のプロジェクトをGit/GitLab管理のプロジェクトに移行する移行する手順を紹介します。 SVNとGitについて ここでは、SVNとGitの違いや、Git・GitLabを導入するメリットについて紹介をしていきます。 SVNとGit・GitLab まずはSVNとGitについて述べていきます。大前提として、SVNもGitも同じ「バージョン管理システム」です。 つまり、ソースコードをはじめとした様々なファイルの変更履歴を「リポジトリ(= 書庫)」に記録し、管理・追跡するためのシステムです。しかし、 SVNとGitは構造的な違いを持っています。 SVN : 集中型バージョン管理システム SVNは、集中型バージョン管理システムです。SVNの場合は、リモート環境にインストールしたリモートリポジトリだけが、ソースコードのバージョンを管理しています。 開発に参加するメンバーは、各自がこの中央リポジトリにアクセスして、ローカル環境にあるファイルをコミット(新バージョンとしてファイルを保存)したり、 ローカル環境へチェックアウト(特定のバージョンのファイルを取得)したりします。 このように、SVNはバージョン管理を行うリポジトリが、リモート環境にのみ存在するという構造を持っています。 Git : 分散型バージョン管理システム Gitは分散型バージョン管理システムです。Gitの場合は、リモート環境にあるリモートリポジトリだけでなく、各開発メンバーのローカル環境にも リポジトリ(ローカルリポジトリ)が存在します。開発メンバーはこのローカルリポジトリに対して修正や追加したファイルをコミットしていきます。 このローカルリポジトリは、リモートリポジトリの完全なコピー(クローン)として作成されます。ローカルリポジトリにコミットされた変更内容は、 リモートリポジトリへプッシュすることで、リモート側へ反映されます。また、リモートリポジトリからプルをすることで、ローカルリポジトリの 内容をリモートリポジトリとあわせることができます。…

Continue Reading SVNからGitへの移行 ~ SVNからGitLab CE(Self-hosted)への移行ステップガイド

スクラムマスター 成功のポイント

自分自身の開発経験から、もっと早くからスクラムとスクラムマスターを経験しておけばよかったと思っています。スクラム未経験の方には、この記事がスクラム導入のきっかけとなればば幸いです。また、スクラム経験者の方にとっては、より良いスクラム開発プロセスを考えるきっかけになることを願っています。 --- 私たちは長いソフトウェア開発プロセスの終盤をむかえ、ようやくお客様に製品を届けることができて興奮していました。開発開始時に受け取ったお客様からの要件使用書を元に、何ヶ月もかけて熱心に作業した結果、お客様が求めていたものをすべて実現した素晴らしい製品ができあがりました。 少なくとも私たちはそう考えていました。 残念ながら、それはお客様の求めていたものではありませんでした。私たちの理解に誤解があったようです。いくつかは明確に私たちのせいでした。しかし、いくつかはお客様側に原因があるように感じることもありました。お客様から受け取った要件仕様書を見直してみると、ある事項については仕様に曖昧な部分があることがわかりました。いずれにせよ、ソフトウェアはお客様の要望に応えられず、その場の誰も満足できない結果になってしまいました。 このとき、私は明らかにチームリーダーとして失敗しました。しかし、もし私がスクラムマスターとしてスクラムプロセスで開発していたら、物事は違った方向に進んでいたでしょう。 スクラムやアジャイル開発プロセスを導入したのは、その苦い経験があったためです。いま、私はスクラムの熱狂的なファンになっています。 私がスクラムを好きな理由の一つは、途中でチェックイベントがあるため、間違った機能の開発に何ヶ月も無駄にすることなく、プロセスの非常に早い段階で問題や誤解を発見することができるためです。もしスクラムをずっと使っていたら、何ヶ月もかけて間違った開発をすることはなかったと思います。 スクラムとは? スクラムは、アジャイル開発のために最も広く使われているプロセス/プロジェクト管理フレームワークであり、チームワークを使って迅速な反復サイクルで製品をリリースすることを重視したソフトウェア開発アプローチです。 Photo by: Smart Works for Upsplash スクラムマスターとは? スクラムでは、小さなチームで協力して仕事を進めていきます。スクラムマスターは、スクラム開発チームの「サーバントリーダー」(奉仕型リーダー)です。 「サーバントリーダー」とはどういうことなのでしょうか?従来のリーダーは組織の頂点に立ち、上から指示を出してメンバーにタスクを割り振るのに対し、スクラムマスターはメンバーを下から支える立場です。従来のリーダーと同じように、チームに方向性を示してプロセスをスムーズに進行させていきます。しかし従来のリーダーとは異なり、スクラムマスターは自分の仕事をメンバーに割り振ることはありません。そうではなく、スクラムチームの生産性を向上させるために、全力でサポートすることが仕事です。 スクラムチームには誰がいるのか? スクラムの教科書によると、スクラムチームは、開発のあらゆる側面に対応できる3人から9人の自己完結型のユニットであるべきだとされています。つまり、あなたのチームはスクラムマスターに加えて、デザインスキル、エンジニアリングスキル、品質保証スキルなどすべてのスキルを一通り備えている必要があります。各機能の専門家が一人ずついる必要はありません。チームのフロントエンド開発者が同時に熟練したデザイナーであったり、プログラマーがテスターを兼務することもあります。 現実のプロジェクトは、教科書に載っているような完璧な世界とは限りません。スクラムチームの中には、10人以上のメンバーがいるチームもあります。会社によってはフロントエンド開発のみに特化したスクラムチームと、バックエンド開発作業のみに特化したスクラムチームがあるかもしれません。しかし、これらは理想的なスクラムチームとはいえません。 スクラムマスターの仕事内容は? スクラムマスターには3つの大きな責任があります。成功するためには、すべてを上手くこなさないといけません。 1.      スクラムチームのミーティングを促進するスクラムのフレームワークでは、プロジェクトは「スプリント」と呼ばれる1週間から4週間程度の短い期間に分割されます。各スプリント期間中はミーティングが何度も行われます。 スプリントの最初で、スクラムマスターは「スプリント計画」会議をリードします。このミーティングでは、プロダクトオーナーが顧客のニーズを説明し、タスクの優先順位を決めます。その後、あなたのスクラムチームは、各タスクを完了するために必要な難易度と時間を議論し、このスプリント中に実施する項目を選択します。 スプリント期間中、チームは毎朝集まって、各チームメンバーのタスクの状況を確認するための短いスタンドアップミーティングを行います。ここでのスクラムマスターの仕事は、全員がスケジュール通りに進んでいることを確認し、タスクに遅れが生じているメンバーがいる場合には、軌道に乗るようにサポートすることです。…

Continue Reading スクラムマスター 成功のポイント
ゼロから10分で出来る!オンプレ版GitLab導入クイックスタートガイド
GitLab CE(OSS版) とEEの違いです。

ゼロから10分で出来る!オンプレ版GitLab導入クイックスタートガイド

はじめに 本記事では、Ubuntu 16.04 LTS に GitLab Enterprise Edition (以下、EE) を導入する手順を示します。Enterprise という名前ではありますが、基本機能のみの Core プランの利用はなんと 無料(Free)で使うことが出来ます。Core プランでもチーム開発に必要な機能のほとんどにアクセスできるので、まずはここからお試ししてみましょう。インストールパッケージが非常によく出来ているので、導入はとても簡単です。 最短5行、10分程度で終わります。 GitLab には EE の他に CE (Community Edition) というバージョンがありますが、こちらは MIT License の下で開発されているオープンソースソフトウェアという位置づけであり、機能的には EE の Core…

Continue Reading ゼロから10分で出来る!オンプレ版GitLab導入クイックスタートガイド
アジャイル手法について知っておくべき3つのこと
Photo by İrfan Simsar on Unsplash

アジャイル手法について知っておくべき3つのこと

アジャイル手法は、絶えず変化する市場のニーズに素早く対応したいと考える技術系企業に適した手法であり、近年、規模を問わず様々なソフトウェア開発に活用されています。アジャイル開発を採用することで、開発チームは迅速な反復サイクルで製品を作り、テクノロジー業界の変化に容易に適応することができます。 VersionOne 社のState of Agile Report 2018年版によれば、「何らかの形でアジャイル手法を実践している」と回答した組織はアンケート対象の97%にのぼりました。 しかし、アジャイル手法が広く受け入れられる一方で、アジャイルの概念については間違った解釈をされることも少なくありません。そもそも「アジャイル」とは、手法やプロセスを指すものではなく、アジャイルによってもたらされる価値や実践すべき原則を示したものです。 1. アジャイルの歴史 Photo by İrfan Simsar on Unsplash 1970年代から2000年頃までの間に、従来の製品開発プロセスがソフトウェア開発においては機能しないことが明らかになりました。 ソフトウェアプロジェクトが完了する頃にはビジネスニーズがすでに変化していた、ということが頻発し、いわゆる「アプリケーション開発の危機」あるいは「アプリケーションの完成までのずれ」などと言われました。プロジェクトが途中でキャンセルされり変更を求められることが続き、開発者たちはもっと良いやり方を探す必要に迫られました。 その後、業界が市場に適応できないことに不満を抱いた17人の思想的リーダーが集まり、ソフトウェアを開発するより良い方法について議論し、2001年に「アジャイルマニフェスト」をまとめました。彼らの定義した以下の4つの価値と12の原則は、多くのソフトウェアチームに採用され、製品を常に最新の需要にキャッチアップさせるために役立っています。以下に引用しましょう。 4つの価値 プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。 12 の原則 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。動くソフトウェアこそが進捗の最も重要な尺度です。アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。シンプルさ(ムダなく作れる量を最大限にすること)が本質です。最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。 © 2001 Kent Beck, Mike Beedle,…

Continue Reading アジャイル手法について知っておくべき3つのこと