業務を改善する情報共有の仕掛け~DevOpsの実現,RPAの導入に向けて~

第3回 ツール活用で文化(カルチャー)・習慣を変えてみよう(前編)

この記事を読むのに必要な時間:およそ 1.5 分

第1回第2回では,DevOpsの概要と,DevOpsの実現にはツールの連携と活用が欠かせないことを説明しました。DevOpsを実現するには,⁠文化(カルチャー)を変えなければならない」とよく言われます。私自身は「長年の文化はそう簡単に変えられない」と感じていますが,開発チームだけであれば,なんとか変えられるのではないかと思うこともあります。そこで今回は,ツールを活用して「開発チームの文化=習慣を変える」というテーマで,DevOpsの実現に不可欠な「アジャイル開発」に注目していきます。

目的は顧客に価値を提供すること

顧客やユーザの要望は多様化しており,かつ変化し続けます。そのような背景の中,製品やサービスのベンダが価値を提供していくには「継続的な改善」が不可欠です。⁠継続的な改善」には,繰り返し作り替えることと価値を見つけることが重要だと考えますので,この2点をキーに実践的な例を紹介します。

繰り返し作り替える

みなさんの製品やサービスは,要件が確定してからリリースするまで,次のような工程で作られると思います。

  • 【機能設計】【詳細設計】【コーディング】【コードレビュー】【単体テスト】【結合テスト】【ビルド】【総合テスト】

この工程を繰り返すことで製品やサービスを作り替えますので,作業効率の改善から考えてみます。

単体テスト/結合テスト

単体テストや結合テストのテストケースは「決められた手順や入力に対して期待する結果が得られること」といった定常的なチェックが多く,コードで表現できます。テストケースをテストコードで書き,JUnitやSeleniumなどのテスティングフレームワークで自動化します。

コードレビュー

レビューの目的の1つである「コードの正しさ」は,ツールでチェックを自動化できます。コード規約などのルールチェックは静的解析ツール,コードが仕様を満たすかどうかはテストコードでチェックできます。

ビルド

プログラムをコンパイルし成果物を生成するビルドでは,MavenやGradleなどのビルドツールを利用して一連の流れを管理できます。ビルドツールでは,自動テストや静的解析ツールの実行も管理できます。

ビルドツールの実行を管理する

ここではビルドツールの実行にBambooを利用して自動化してみます図1)⁠

図1 Bambooを利用した自動化

図1 Bambooを利用した自動化

Bambooのビルド処理は,⁠ステージ】【ジョブ】【タスク】といったパイプライン構造となっています。

Mavenでソースコードをビルドしjarファイルを出力する場合,⁠ソースコードをチェックアウトするタスク」「Mavenを実行するタスク」を実行するジョブを持つビルドプランを作成します。このビルドプランは,ソースコードをリポジトリにコミットしたときに実行するようにトリガを設定します。

継続的なビルドを導入する利点

これで,コーディングしたコードをリポジトリにコミットするたびに,Bambooが最新のソースコードでMavenを実行し,⁠静的解析】【テスト】【コンパイル】【jarの生成】を自動で処理するようになります。

コミットしたソースコードにバグがあり,テストがエラーになると,Bambooは処理を中断して結果を記録するので,チームはエラーの原因を調査できます。すべてのコーディングが終わったあとに実施する従来のテストでは,問題の発見が遅れることもありましたが,このしくみによって問題の早期発見にもつながります。

BambooやMavenなどのツールを活用して,製品やサービスを繰り返し作り替える土台が整いましたので,前後の工程についても効率化を進めます。

小さなタスクで管理する

製品やサービスを改善するために,作り替える回数を増やすことを検討してみます。つまり,ビルドの回数を増やすためにソースコードのコミット回数を増やすということです。それには,小さなタスクで管理してタスクの数を増やす方法があります。ここではJira Softwareを利用してタスクを管理します。

小さなタスクで作業するメリットには,次のようなものがあります。

1.作業の目的が明確になる

目的が明確になるので,不確実性が減ります。また,シンプルな目的はシンプルなテストコードを書くことにもつながります。

2.日々の進捗がわかりやすい

1日で完了する内容でタスクを作ると,タスクの状態が日々更新されるので,問題が発生し停滞しているタスクも特定しやすくなります。

3.コードのコンフリクトが減る

タスクで修正するコードの量が少なく範囲も狭まるので,ほかのタスクのコードとのコンフリクトによるマージ問題が起こりづらくなります。

後編では,タスクを小さく分割していく作業例を紹介します。さらに,テストを管理する方針,コーディング文化の考察をし,繰り返し作り替える体制づくりをまとめます。

Software Design

本誌最新号をチェック!
Software Design 2018年11月号

2018年10月18日発売
B5判/184ページ
定価(本体1,220円+税)

  • 第1特集
    その知識古くなってない? 新サービスを適材適所で使えてる?
    あなたの知識をアップデート AWS再入門
  • 第2特集
    よい機器はエンジニアを鍛える
    ヤマハルーターをお勧めする理由
  • 一般記事
    [特別企画]量子コンピュータ〈超〉入門
    【後編】量子プログラミングと量子チップ開発の実際

著者プロフィール

奥村和彦(おくむらかずひこ)

プリセールスエンジニア

前職でシステム開発の難しさを知って,開発プロセスをカイゼンするための技術を求めてリックソフトへ。

開発を楽しく面白くするための情報を発信していきます!

コメント

コメントの記入