ソフトウェア開発」カテゴリーアーカイブ

開発チームを強くするプロジェクト管理とは

 

「開発チームの生産性を上げたい」「チームの情報共有化したい」「サービスの品質を上げたい」
プロジェクト管理ツールが解決すると謳っている課題である。ツールを導入したからといって生産性や情報共有化などの数値化しにくい点が改善した、と証明することは難しい。チーム全体が変わった気がする、前よりスケジュール遅延が少なくなったなどの感覚値で語られることが多い。

 

それなりの費用をかけてプロジェクト管理ツールを導入したけど、一部の人たちしか使っていない。数字をいじる仕事の人だけー管理者やリーダーのみーという声を聞く。

 

これまでいろいろな開発チームを見てきて、開発ツール等の選定、導入をサポートしてきた立場から
うまくいっている状態(チーム)に見られる特長として、チームのボトムアップでの盛り上がりとチーム全員がそれなりに使うことができる共通言語になる場(ツール)になれるかどうかだと思った。

 

ツールはあくまでもチームを成長させるためのきっかけにすぎないのではないかと思う。

 

医療業界向け業務サービスを提供している会社の話

 

医療業界向けに業務サービスを提供している約60名ほどの企業(エンド企業)でのこと。社内の基幹システム運用やホームページ、ウェブシステムの管理、運用まで4,5名の情報システム部が担当をしている。ただし、システム開発ができる技術者はおらず、外部にアウトソースしていた。開発会社として2社(A社、B社)といつくかのプロジェクトを進めていた。

2013110601

エンド企業ではSI企業で開発経験があり、システムに詳しく業務知識に明るい担当者が管理者(リーダー)として、すべての開発プロジェクトのとりまとめを行っていた。情報システム部門メンバーの進捗管理から外部の協力会社との仕様取り纏めなども管理しなければならず、いつも忙しい状態が続きそれが普通になっていた。

このまま何事も無くリーダーの管理で仕事はスムーズに進めばよいのだが、、、これまで体調不良で数日休むことがあり、業務に致命的な穴が空くことが何度か発生したらしい。

1人の優秀な人のスキルに頼り切った状態で運用されていたため、その人がいないというだけで情報システムメンバーは穴を埋めることが出来なかった。メンバーからするといきなりリーダーがやっていた作業を引き継いで進捗管理から外注管理まで・・・無理な相談である。

 

よし、ツールを導入しよう

 

開発チームの生産性向上、チームの情報共有に効果があると思われるツールを入れて試用版をいくつか試してみた。約1ヶ月試用してみたけど、メンバーは最初ちょっと使うだけ、いつのまにか見向きもされなくなってしまった。

ツールが役に立たない訳ではない。ちょっとしたリーダーの作業とチーム体制を変えたことでこの後、ーチームに導入、浸透するまで2,3ヶ月の時間が必要だったー一気にツールのメリットが享受されるようになった。

 

エンド企業の情報システム部門に必要だったこと

 

2013110602

新しい体制図では、これまで利用するツールが決められていなかったーメールに記載したり、Wordで書いたり、電話だったり..ーがツールを一元化しクラウドサービスに統一したことである。

外部の協力会社と一緒にプロジェクトの情報共有ができ、だれが、何をしているのかを見ることが出来る。

プロジェクトを進めるときに関係者が共有ツールを手に入れることでコミュニケーションコストの削減が実現ーコミュニケーションコストの削減は効率化に直結するーした。

これは、関係者で共通言語「今週中に対処が必要なレポートで進捗確認しよう」「#441 チケットにコメント書いたので、内容チェック後、コメントください。」「A社の提示した資料のチェックがまだです。いつまで?」が自然にできあがったためである。

もう一つ、重要な点はエンド企業の大きなシステム毎に専任の担当者を任命したことである。
社内の業務システム担当者とホームページやウェブシステムの担当者の2名である。

これによって、プロジェクトチームに推進力が生まれ数ヶ月後に多くの課題が解決されることになった。

まだまだたくさんの課題は残っており、体制とツールですべてが解決できたわけではない。

しかし、2,3ヶ月という期間でチームの風通しが良くなりプロジェクトが前に進んでいるという実感をチーム全員が感じていることはとても意義がある。

 

銀の弾丸はない、でもちょっとした改善で変わる

 

小さなチームのちょっとした改革によって前より少しだけよいチームになった。

この小さな改善のサイクルを繰り返すことがとても重要である。

アプリのテスト管理に不可欠となったバグ追跡システムとは

はじめに

みなさんは、トラブルチケットという言葉をお聞きになったことはあるでしょうか。トラブルチケットは、問題発生時に発行される言わば受付票のようなもので、IT業界では障害管理を始めさまざまな用途で使われています。ここでは、アプリケーションのテストに不可欠な存在となったバグ追跡システムについて紹介するとともに、バグ追跡システムのユースケースについて紹介します。

バグ追跡システムとは

バグ追跡システム(BTS:Bug Tracking System)は、アプリケーションのテスト時や利用開始後に発生した障害を管理するシステムです。アプリケーションのリリース前に行われるテストは、アプリケーションの開発などに関わった関係者だけで行われますが、一度リリースしたアプリケーションが、数千から数万人規模で利用される場合、障害だけでなく、その他の問い合わせも利用者の増加とともに増えてくる事が予想されます。これらを人手を使って処理することも可能ですが、障害報告や問い合わせの件数が増えて来ると、人が対応していたのでは、対応や回答までのレスポンスが速くなったり、遅くなったりなど担当者の業務負荷に左右されることになります。しかし、バグ追跡システムを使うことで、利用者から受けたバグ報告や問い合わせ内容をシステムに登録し、受付番号(トラブルチケット)を発行することで、受け付けたチケットの受付日、受付時間、受付内容、完了日、担当者などの対応状況を一元管理できます。このように、バグ追跡システムでは、報告された内容をシステムに登録することで、未対応のチケットや解決に時間が掛かっているチケットなどチケットの状況をさまざまな角度から分析し、障害報告や問い合わせへの対応を通して、アプリケーションの品質改善などに役立てています。以下では、バグ追跡システムのユースケースについて紹介します。

2000-02

代表的なバグ追跡システム

フリーのバグ管理システムには、Tracや影舞のようにPythonやRubyで実装されたシステムの他に、BugzillaのようにPerlで実装されたシステムもあり、さまざまなシステムが公開されています。以下に、代表的なオープンソースソフトウエア(OSS)のバグ追跡システムを簡単に紹介します。

Trac(トラック)

Tracは、スウェーデンのEdgewall Software社が開発するプロジェクト管理システムです。プログラミング言語Pythonで実装されており、プロジェクト管理システムのサブ機能として、バグ管理システムが搭載されています。Wiki(ウィキ)などの情報共有ポータルサイトも構築できるため、プロジェクト関係者間で資料やさまざまな情報を共有できるため、大規模なプロジェクト管理に適しています。Tracは、LAMP(Linix,Apache,MySQL,PostgreSQL)環境だけで無く、殆どのUNIXマシンで動作します。

2000-03

Bugzilla(ばぐじら)

ウエブブラウザFirefoxで有名なMozilla Foundationが開発しているバグ管理システムです。プログラミング言語Perlで実装されており、日本語化も可能です。元々Netscape Communications社のウエブブラウザNetscapeのバグ管理のために作られたシステムのため、安定して利用できるシステムだと言えます。Tracと同様に、殆どのUNIXマシンで動作します。

2000-04

影舞(かげまい)

影舞は、Fukuoka Tomoyuki氏が開発したバグ管理システムです。プログラミング言語Rubyで実装されており、データベースが無くても動作する手軽さとソースコードの少なさが特徴です。2008年3月にリリースされたバージョン0.8.8が最新のバージョンであり、現在は開発を終了していますが、Bugzillaと同様に安定して利用でき、カスタマイズしやすいシステムだと言えます。Tracと同様に、殆どのUNIXマシンで動作します。

2000-05

ユースケース1:ソフトウエアの障害管理

ケース1は、ソフトウエアの障害管理です。バグ追跡システムは、ソフトウエアのバグを追跡するシステムですから、バグ管理に利用されるケースが最も多くなっています。フリーのUNIXであるFreeBSD Projectでは、1994年以降GNATS(GNU BUG TRACKING SYSTEM)というバグ追跡システムを利用しており、FreeBSDのユーザーは、send-prコマンドを利用して、FreeBSDのGNATSシステムに問題報告を送信できるようになっています。また、ウエブインタフェースを利用したバグ報告も利用できるようになっています。

ユースケース2:営業支援システム

ケース2は、営業支援システム(SFA:Sales Force Assist)への適用です。バグ追跡システムでは、報告日、報告者、報告内容、優先度、添付ファイル、プラットフォーム、バージョン、再現性などの項目を使ってバグ管理に必要な情報を登録します。この機能を営業管理システム用にカスタマイズすることで、訪問日、営業担当者、同行者、訪問先、営業内容、案件確度、添付ファイルなどを管理することができます。そのためには、バグ管理システムのカスタマイズが必要となりますが、今回紹介した影舞は、ソースコードの少なさからカスタマイズに適しています。

ユースケース3:QA管理システム

ケース3は、QA管理システムへの適用です。QA管理は、Yahoo知恵袋やOK Waveなどのように掲示板方式で実装されることが多いのですが、バグ管理システムをカスタマイズして利用することで、例えば登録された情報をCSV形式で出力したり、出力する項目もカスタマイズによって追加することができるため、掲示板方式のQ&Aシステムよりも柔軟なシステムを構築できます。

まとめ

ここまで、バグ追跡システムについて紹介するとともに、ユースケースについて紹介しました。オープンソースソフトウエアのバグ管理システムは、さまざまなプログラミング言語で実装されており、カスタマイズが必要になった場合でも、開発しやすい言語のシステムを選定することで、既存のシステムの機能拡張を行うことができます。今回紹介したユースケースをヒントに、新たなユースケースを検討してバグ管理システムを活用してみませんか。

[git] クローンからプルしてマージ、コミットしてプッシュする

 

こんにちは、最近流行の git(ギット)。
分散バージョン管理の概要を理解するためのコンテンツを公開しました。

 はじめてバージョン管理システムを利用する人、初学の人から、すでに開発に使っている人までこれまでのバージョン管理に比べ圧倒的に便利だ。という反面、「バージョン管理の利点と使い方はなんとなくわかる。が、分散バージョン管理はよくわからない」という声があります。私自身も git の利用を開始した当初は、「Index? HEAD? なにそれ? 」状態でした。

社内メンバー向けに作成し、お客様にも利用して頂いた資料をもとに新たに編集し直して公開します。(画像なども新たに編集)

この「git 基礎勉強」を読めば、
「クローンからプルしてマージ、コミットしてプッシュする」

の意味が理解できるようになります。

ぜひご覧下さい。

 


手書き風の画像は、だものメーカーを使っています。

[book][bts] 組込みソフトウェア開発における品質向上の勧め(バグ管理手法)本の紹介

 

バグ管理のやり方や運用ルールは開発チームや会社によっていろいろな方法があります。
専用のバグ管理システムを利用したり、表計算ソフトを利用したり、ワープロで作成した紙もあるかもしれません。

バグ管理の大きな目的は「バグを見つけたら速やかに、かつ確実に正しく修正し、その再発を防ぐこと」です。そのために必要な考え方を体系立てて説明している無料の書籍をご紹介します。

 

IPA(情報処理推進機構):組込みソフトウェア開発における品質向上の勧め[バグ管理手法編]
PDF版のダウンロードはこちら
(書籍で欲しい場合は Amazon.co.jp で購入することができます。)

 

tracpath を利用している企業へのヒアリングで

  • 業務アプリケーションの受託開発
  • 組込みシステムの開発
  • クラウドサービス・ASPサービスの開発
  • コンシューマ向けゲーム・ソーシャルゲーム開発
  • スマートフォン・モバイル開発

多くのソフトウェア開発に携わる方に利用頂いております。
バグ管理方法や tracpath の使い方についてヒアリングし、多くの人がバグ管理のルール決めとバグ管理のプロセス(ワークフロー)を自分たちにあったやり方にしなければうまくいかない。と言われます。

これは、どのようなツールを使うのか、オープンソースの無料ソフトウェアを利用するのか、商用サービスを購入するのかは重要ではないことを言っています。また、ワークフローは極力シンプルにする必要がある。とも言われます。

ソフトウェア開発に携わるすべての開発者に言えることですが、バグ管理の目的や管理プロセスを理解し、自分たちのチームに最適な方式(運用ルール)を決めることがとても重要になります。

IPAの組込みソフトウェア開発における品質向上の勧め[バグ管理手法編]はバグ管理やプロセスの標準的な方法を体系立てて説明しています。

組込みソフトウェア開発向けだけではなく、他多くのソフトウェア開発の現場で役立つ情報だと思います。

PDF版は無料で読むことができますのでぜひ皆様の現場で活用されることをオススメします。

 

Git のリポジトリを履歴保持したまま ciklone に移行する方法

 

Suvbersion / Git / Mercurial のリポジトリを tracpath にインポートする機能がリリースされております。外部リポジトリをサイクロンに移行(Git / Subversion / Mercurial) をご確認ください。
以下のエントリーは古い情報となります。


Subversion のリポジトリを履歴保持したまま ciklone に移行する方法の Git 編です。
Git/Mercurialのリポジトリ移行はユーザの操作で可能です。

GIt の移行

はじめに

Gitは分散バージョン管理システムのためリポジトリが変更履歴を保持しています。Gitリポジトリを別サーバから移行する方法を説明します。

注意すべき点は、サイクロンのGitはチケット管理システムのコミットフック(commit-fook)が設定されているため事前にコミットフックの設定を変更する必要があります。

コミットフックを変更しない場合、インポートに時間がかかる場合があります。

手順

  1. サイクロンで新規リポジトリを作成
  2. サイクロンのコミットフック設定を無効にする
  3. Gitコマンド
  4. 移行されたデータの確認
  5. サイクロンのコミットフック設定を有効にする

1. サイクロンのプロジェクトにリポジトリを新規作成

サイクロンのプロジェクトに新規Gitリポジトリを作成します。

  1. リポジトリの追加をクリック
  2. リポジトリ名を「projectA」入力
  3. 「作成」をクリック

2. サイクロンのコミットフック設定を変更

サイクロンにログインし、管理画面のサイドナビゲーション[trac.ini] -> ticketをクリックします。
チケットの動作設定に関する設定画面が表示されます。

  • 項目名:commit_ticket_update_ignore_repositories
  • 変更時にチケットを更新させないリポジトリの名前を設定します。

テキストボックスに1)で新規作成したGitリポジトリ名を入力します。
複数入力する場合は「,(カンマ)」で区切ってください。

3. Git コマンドで移行

新規作成したサイクロン上のGitリポジトリにローカルにあるGitリポジトリを移行します。
サンプルとして Ruby の Git ライブラリである Grit をクローンして自分のサイクロンリポジトリに移行します。

リポジトリを取得します。

> git clone git://github.com/schacon/grit.git mygrit

Cloning into 'mygrit'...
remote: Counting objects: 4051, done.
remote: Compressing objects: 100% (2261/2261), done.
remote: Total 4051 (delta 1810), reused 3911 (delta 1733)
Receiving objects: 100% (4051/4051), 1.84 MiB | 636 KiB/s, done.
Resolving deltas: 100% (1810/1810), done.

取得したリポジトリのクローン元情報を削除します。

> git remote
> git remote rm origin
> cd mygrit   ... ここは利用環境によって異なります。

サイクロンにリポジトリを移行します。

> git push --all origin

Username for 'https://.ciklone.com': user-name
Password for 'https://@.ciklone.com':
Counting objects: 4021, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2179/2179), done.
Writing objects: 100% (4021/4021), 1.84 MiB | 3.11 MiB/s, done.
Total 4021 (delta 1793), reused 4011 (delta 1786)
To https://.ciklone.com/git/

他サイト(サーバ)のリポジトリをサイクロンに移行することができました。

4. リポジトリの確認

ブラウザでサイクロンにアクセスし、リポジトリを確認します。

5. コミットフックの設定を戻す

1) コミットフックの設定を無効から有効にします。

コミットフックの除外リポジトリとして登録したリポジトリ名を削除して、「変更を適用」をクリックします。

以上で他サイト・他サーバで管理している Git リポジトリを簡単にサイクロンに移行することができます。

ぜひ、お試しください。

Subversionのリポジトリを履歴保持したままcikloneに移行する方法

Suvbersion / Git / Mercurial のリポジトリを tracpath にインポートする機能がリリースされております。外部リポジトリをサイクロンに移行(Git / Subversion / Mercurial) をご確認ください。
以下のエントリーは古い情報となります。


こんにちは。

サイクロンをご利用されている皆様よりよくあるお問い合わせ内容について、これまで社内開発で利用しているリポジトリをサイクロンのリポジトリに移行したい。というお問い合わせがあります。

リポジトリには、コミットログ、ソースコードの差分、コミットしたユーザなど多くの情報が記録されており、プロジェクトの大切な資産の1つです。開発環境が変わったり、クラウドサービスを利用し始めたり、ソフトウェア開発のインフラはセキュリティが担保された上で、より便利で効率的な方法に移行することがあります。

このとき、これまで開発で利用していたリポジトリを新しい環境に移行して、開発を継続するための方法をバージョン管理システム Subversion,git,mercurialに合わせて手順を説明します。

現バージョンのサイクロンではユーザがSubversionの移行をするためには、データを当社に送付して頂く必要があります。今後のバージョンアップでユーザによるデータ移行が可能になります。ご期待ください。

Subversion の移行

はじめに

Subversionリポジトリをサイクロンに移行します。リポジトリの履歴を含めたデータの移行方法について説明します。履歴を含めない場合、エクスポート・インポートコマンドによりリポジトリの移動が可能です。

Subversionの場合、ユーザのみで移行するための機能が実装されていないため以下の手順となります。

  1. (ユーザ)のリポジトリからダンプファイルを生成
  2. ダンプファイルを当社に送付(セキュアなファイル受け渡し)
  3. ダンプファイル受領後、約1営業日内にユーザ領域にインポート
  4. あなたのアカウントでサイクロンにログインし、リポジトリを確認

1. リポジトリからダンプファイルを生成

サイクロンに移行したいリポジトリを svnadmin コマンドを使ってダンプします。

svnadmin dump  >
svnadmin dump /var/svn/project-1 > project-1.dmp

複数リポジトリがある場合、各リポジトリ毎にダンプファイルを作成してください。
ユーザの環境はWindows/Linuxどちらの環境でも問題ありません。OSに関係なく移行することができます。

2. ダンプファイルを当社に送付

ダンプファイルを当社に送付頂きます。送付前に当社にご連絡ください。
セキュアなファイル送付方法を提示いたします。

当社に送付頂くデータの扱い

にて説明しています。ご希望があればNDA(秘密保持契約)も可能です。お問い合わせください。

3. ダンプファイルのインポート

ユーザから送付されたダンプファイルを受領後、利用者のアカウントにインポートします。
これは約1営業日内の作業時間が必要となります。ご了承ください。

4. 通知とご確認

インポートが正常に完了後、ユーザに通知いたします。通知を受けましたら利用者のアカウントでサイクロンにログインしてください。
正常に移行されているか確認をお願いします。

さいごに、サイクロンのリポジトリURLからチェックアウトを行います。正常にチェックアウトされれば移行作業は完了となります。

ビギナーに伝えたいバグ管理ノウハウ 〜バグ管理の必要性〜

ソフトウェア開発に携わる人は必ず出会っているバグ。バグとはプログラムのソースコードの間違いや誤動作するコーディング上のミスのこと。設計工程で発生する仕様間違いなどもバグである。

 

このバグを効率よく管理してみんなが幸せになるためにどのような点を注意して日々の業務を進めるべきか、について考えてみる。

 

プログラマーのスキルによる成果物の品質

 

どこのチームや会社にもスーパーエンジニアと評されるスキルが高いエンジニアがいる、という話を聞く。
私の関わるプロジェクトでもあるエンジニアがいるというだけでチームにとって技術的な安心感であったり、品質面でも安心感を与えてくれることを実感している。

 

これは管理する側からみても同様に安心感を得られる場合が多い。

 

特に最近のソフトウェア開発は顧客から短納期・低予算が求められ、専門性の高いエンジニアに大きく依存しているプロジェクトばかりである。開発ではオープンソースソフトウェアやミドルウェア製品、フレームワーク、言語が多数存在しており、それらを「うまく組み合わせた総合的なソリューションを提供」する必要がある。

 

このような状況もあり、専門性の高いエンジニアに大きく依存しているプロジェクトが多いように思う。このようなプロジェクトでは経験に価値があり、技術全体を俯瞰して考えることができるエンジニアの付加価値が大きい。

 

このスキルは簡単に身につくものではないが物事の理由を考えながら高い意識で仕事することで養われていくと信じている。

 

スキルの高いエンジニアでは成果物の品質にも大きく影響し、バグの少ない、メンテナンスしやすいプログラムができる。

すべての開発をスーパーエンジニアに依頼することが理想だが、決められた予算とスケジュールを持つプロジェクトでは到底無理な話で、スキルがバラバラのチームで開発することになる。

 

スキルの異なるチームの生産性を上げるための話題や研究は考えられてきているが。。。ここではプログラマー、テスターが一番触れる機会の多いバグ管理の運用管理について書いていこうと思う。

 

バグ管理の必要性(メリット)

開発の現場でよく聞かれる管理方法として

  • Excelなどの表計算ソフトで管理
  • オープンソースのBTS
  • パッケージ製品

最近はTrac、Redmine、Mantis、BugzillaなどのBTSの利用が増えてきていると実感している。

世の中にはバグ管理だけでも多くのツールが存在しており、各製品には多くの特徴やバグ管理をサポートする機能が提供されている。これから数回に分けてビギナー向けバグ管理のノウハウをまとめていくがツールに依存した説明は避け、バグ管理の運用と考え方にフォーカスしようと思う。

バグ管理の必要性(メリット)について

 

1.バグが管理されデータベースが用意されることで、発生障害についてチーム内の意思疎通がスムーズになる

管理方法が統一されることで、電子メールによる共有や都度作成するレポートよりも正確に内容を伝えることが可能

2. DB化することで、バグの通番管理(追跡と参照)が自動化され、レポートのための分析や報告が提供できる

3. 開発チームは、プロジェクトチーム、マネージャ、顧客、ユーザのそれぞれにとって重要な観点から考え修正を進めることができる。(バグには優先順位が存在する)

優先度がないバグは「声が大きい人」の報告したバグほど早く修正されがちになる

4. 「バグの発見→レポート→担当者割当→解決」について、全てのライフサイクルを通じたバグ管理が出来る。

バグがどこかのライフサイクルに潜り込み、早期修正が必要なバグから注意がそれることがない。

5. 開発チームやプロジェクトチーム、テスターの全員が最新の状況を簡単に入手できる。解決したバグはナレッジとなる。

これらのバグ情報は、リリース製品に紛れ込み、サポート部隊のコストを上げる原因、売上の伸び悩み、使えないシステムという辛らつな評価につながる問題に対する対策が可能

 

チームにとってスキルや役割の違う人々がスムーズな意思の疎通を行うためにも、ベースとなる一元化されたバグ管理は必要である。

 

SAP:ソーシャルアプリ開発にクラウド(IaaS)を利用するメリット

「クラウドのメリットを一番享受できるのは、個人開発者、ソーシャルアプリ開発企業、IT系ベンチャー企業」

小さく・安く・始めて、成長に合わせてサービスレベルを向上させることが出来るクラウド・コンピューティングはそのような企業にとって大きなメリットがあると考えています。

クラウドは、開発環境、本番環境のインフラ、スケールアップ、運用負荷軽減を低リスクで担保できるサービスになっています。これからのアプリ開発でははじめるときにハードウェアのことをほとんど考えなくて良くなる、と言えます。

サービス提供者の役割によるメリットを簡単にまとめると、

経営者

  • システムの投資の無駄を排除 →「所有」から「利用」
  • 求めるサービス提供のためのハード購入費用がかからない
  • 素早いサービス立ち上げ

開発者

  • 開発環境の迅速な構築
  • スケールアップ・可用性向上
  • 本番リリースに向けたサーバ規模の設計を軽減
  • 負荷分散

運用者

  • 利用状況に応じた柔軟なリソース割当
  • システム運用負荷の軽減
  • ハード障害から解放(自前に比べて…

数年前まではデータセンターを借りて自前のハードを用意するか、ホスティングサービスを利用するかが一般的だったと思います。最近はクラウドを使うことで低コストでストレスなく(ハードの面倒を見る必要なく)始めることが出来る。スタートするときの敷居が低くなることはアプリケーションベンダーにとっては良いことです。
2,3年のスパンで見た場合、クラウドよりコスト面でメリットがあるサービスもありますがソーシャルアプリ・ソーシャルゲームに限ればベストなソリューションではないでしょうか。

新しいサービスをすばやく提供するために、その時、そのタイミングで最適なサービスを積極的に利用していきたいですね。

 

SAP:ソーシャルアプリ開発、インフラ構築時に使える10個のチェックリスト

ソーシャルアプリ開発者、とくにインフラを担当している技術者の方はシステム構成をどのようにしていますか。
最近の一般的だと思われるシステム構成とソーシャルアプリ開発のインフラ構築時に使える10個のチェックリストをご紹介します。
実際にソーシャルアプリやソーシャルゲームのシステム構成として稼働実績があるシステム構成になりますので参考になるかもしれません。

インフラ構築に使える10個のチェックリスト

  1. 必要なときにスケールアウト、スケールアップができるか
  2. トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか
  3. トラブル発生時に担当者に通知がされ、その障害対応フローやエスカレーションがマニュアル化されているか
  4. 性能を考慮したハードウエア、OS、ミドルウエア(Apache、MySQL)構成、設定になっているか
  5. メンテナンス時間を最小化できるか
  6. ログファイルをいつでも参照、見える化(グラフ化)できるように管理出来ているか
  7. サーバの状態を常に把握できているか(全体PV、各ページPV,日毎、時間毎)
  8. WEBサーバ、キャッシュサーバ、DBサーバ、踏み台サーバの分離、機能の明確化ができているか
  9. バックアップ・リカバリの方法は確立されているか
  10.  監視用アプリケーションは正しく、漏れなく設定されているか

 

1. 必要なときにスケールアウト、スケールアップができるか

自前でマシンを用意する場合、ある程度余裕を持ったインフラを構築しておきたいものです。しかし多くのサービスでは必要最小限ではじめたい。という声があるのも確かです。(予算もありますし)

これがクラウドサービスを利用した場合、クラウドの一番のメリットと言える内容です。それぞれの意味を把握しておくと良いことがあるかもしれません。

  • スケールアウト(Scale Out) ・・・ 稼働する仮想サーバの台数を増やす機能
  • スケールアップ (Scale Up)・・・ 稼働するサーバ1台の性能をあげる

多くのクラウドサービスではこのスケールアウト、スケールアップは対応しています。その方法については開発しているサービスに合わせて手順書化しておくことがベストです。

ref:クラウドでよく言われる「スケールアウト」の反対の言葉って何だろう?

2. トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか

障害対応やバグ対応でもっとも大切なことは「障害が発生したときの原因を突き止めること」です。

問題が分かってしまえば解決するための対策を行うことはそんなに難しいことではないですし、いつ解決するのかを見積もることも比較的容易に出来ます。インフラを構築する時は、この原因を突き止めるための材料(ログ、発生手順、システムの挙動、エビデンス)をできるだけ多く、楽に集める仕組みが必要ということを意識して、インフラを構築するべきです。

3. トラブル発生時に担当者に通知がされ、その障害対応フローやエスカレーションがマニュアル化されているか

多くのシステムでは有料、無料を問わず、使い慣れた監視システムやパッケージ等のソフトウェアを導入していると思います。監視システムにより障害を検知し、関係者にアラートできることは当たり前ですが、障害発生後の

  • 1次受付け
  • 問題の切り分け
  • 判断をする役割、管理者の判断の有無(ビジネス上の)
  • 担当者割当

が重要になります。障害が発生したときは、少なからず現場が混乱した状態になることが考えられますので落ちついて対処するためのルールやマニュアルを問題が起こる前に決めておくべきです。

4. 性能を考慮したハードウエア、OS、ミドルウエア(Apache、MySQL)構成、設定になっているか

アプリケーションの性質に合わせて、特にOS、ミドルウェアの設定は本番サービス開始までに必ず見直しをするべきです。
Apacheの設定ファイルやPHPの設定ファイルが環境によって異なっていたり、開発環境の設定になっている場合がよくありますので注意が必要です。Web#1とWeb#2は同じ役割のはずがApacheの設定やPHP.iniの設定が違う・・・は避けたいですね。

5. メンテナンス時間を最小化できるか

システムを長時間稼働させるように構成されたシステムにおいても、メンテナンスは多くのサービスで必要になります。ソーシャルゲームの場合、メンテナンス中は利用者が「アクセスすることが出来ない = 売上がない」、状態であるため可能な限りメンテナンス時間を最小化させる方法を考えるべきです。

  • メンテナンス中に実施している作業は本当に必要なのか・・・サービス停止しなくても良いのでは?
  • 夜間等のバッチ処理でできるのではないか
  • ジョブの順番や時間帯の変更は可能か

等の今より最適化することは常に考える必要があります。可能なら無停止アップデートができるのかを検討すべきです。

6. ログファイルをいつでも参照、見える化(グラフ化)できるように管理出来ているか

ウェブアプリケーションやソーシャルアプリでは、Apache、MySQL等のミドルウェアのログ、システムログ、アプリケーションログと見なければいけないログが散らばっており、さらにサーバによっても分散していると思います。開発や運用に多くの情報とヒントを提供するものがこのログファイルです。ログファイルをいつでも、すぐに参照できるように管理(集約、集計)することはとても重要です。

サービスが運用フェーズに入った段階でも、警告やエラー情報、タイムアウト等の異常をすぐに見つけ、原因を探す糸口として活用できるようになっているのかをチェックします。

7. アクセスの状態を把握できているか(全体PV、ページPV、日毎、時間毎、リソース)

サービス提供しているウェブサイトのアクセス解析を導入しているのか、また導入済みのアクセスログから自分たちに必要な数字を把握できているのかはとても重要なことです。直接利用者の動向を把握することが出来るツールになるため、自サイトのターゲットと実際の利用者の行動を把握するために活用できるような仕組みになっている必要があります。

8. WEBサーバ、キャッシュサーバ、DBサーバ、踏み台サーバの分離、機能の明確化ができているか

Webアプリケーションの場合、役割によってサーバを分けたりパフォーマンス向上のために分割したり、をよくやります。ボトルネックになりやすいDB(マスタ)やスレーブDB等、機能の明確化をメモ書きしておくことで

  • システムの全体像を把握したり、
  • 将来の拡張性を考える
  • 運用保守の補助資料として利用
  • チーム内で情報共有(どのようなインフラになっているかを説明出来る)

ができます。役割分担(機能分担)を明示することはとても重要になります。

ソーシャルアプリ開発プラットフォーム(クラウド環境)

ソーシャルアプリ開発プラットフォーム(クラウド環境)/開発・ステージング環境

9. バックアップ・リカバリの方法は確立されているか

アプリケーションやDBのバックアップを実施することは比較的容易に出来るのですが、

  • リカバリにどれくらいの時間が必要なのか、
  • 正常にリカバリできるのか

ということは問題になるのではないでしょうか。

バックアップ・リカバリについては本番機と同等のマシンでリハーサルを実施しなければ正確なリカバリ時間や問題点は見えてこない場合が多々あります。(見積だけでは理想値になりやすく、試験をしない場合、障害が起こったときに想定外のトラブルや取り返しの付かない問題が発生すると考えるべきです。)
どうしても開発中は開発が優先されるため、バックアップ・リカバリは後回しにされる場合がありますが、利用者データや自分たちのシステム保全はとても大切なことなので実際にやってみることはとても重要になります。それが運用マニュアルとして記録されているとベストです。

 

10. 監視用アプリケーションは正しく、漏れなく設定されているか

システムのリソースやサービス監視用の専用ツールはとても高機能で便利に利用しているサイトが多くあります。自分たちのアプリケーション特性にあったチューニングや設定ファイルになっているのかを確認すべきです。デフォルトのままというありがちなミスをしないように注意する必要があります。

 

ソーシャルアプリ、ソーシャルゲーム開発のプラットフォームを構築するインフラエンジニアは表に立って活躍する目立つ存在ではありませんが、縁の下の力持ちな人材です。ソフトウェア開発期間よりももっと長い期間、運用を支える大切な基盤環境を構築しなければいけません。
インフラに関する10個のチェックリストをあなたの開発チームでも確認してみてください。
これ以外にも大切なチェックはあると思いますので教えてもらえればインフラエンジニアのスキルアップに繋がりますのでご意見をお待ちしています。

 

SAP:ソーシャルアプリ開発を支える技術(バックエンド)

ソーシャルアプリ・モバイルアプリケーションの開発環境や支える技術についてご紹介。
ソーシャルアプリとは、mixi、mobageやGREEなどのSNSプラットフォーム上で動作するアプリケーションです。
2009年末頃から各SNSプラットフォームのオープン化が進められ、外部開発者でもアプリケーションを開発し、SNSに登録されている多くのユーザに対して公開できるようになっている。数千万人という会員をもつプラットフォームに公開が可能になることで、労せずに大量のユーザに利用してもらえる可能性が高い。
また、これまでのコンシューマ向けのゲームやECサイトと違い、SNSの利点を活用したコミュニケーションを重視していることが特徴の1つになっている。

ビジネスとして考えた場合、

  • 大量のユーザにリーチ
  • 少ない投資で開発が可能
  • その上で大きな成功の可能性あり

など、良いことだけを挙げると一日でもはやく始めたいと思うかもしれないが、そんなに簡単ではないことは承知の通り。
開発者から見たソーシャルアプリ開発で重要だと思われる点は

  1. 競合が多いく、早いリリースが必要 → 開発の効率化
  2. アプリがヒットするかどうか不安要素が多く、初期費用を抑える → インフラ・維持費
  3. クチコミ等、一気にユーザが増えた場合のスケールアップ → インフラ・スケールアップ
  4. 利用者に向けたイベント、日々サイト更新必須 → サービス運営・ソフトウェアライフサイクル

 

1. 競合が多く、早いリリースが必要(開発の効率化)

ciklone(サイクロン)を利用しているお客様で携帯向けやスマートフォン開発されている企業様から話を聞いたり、開発者と話をすると、数名~5,6名の開発チームで2,3ヶ月くらいの期間でリリースとなる場合が多いようです。
開発の効率化について実践していることは

  • Ruby/PHP/Python等フレームワークを利用
  • 開発環境の仮想化・チーム内で共通化
  • バージョン管理システムとバグ管理システムの利用
  • 開発拠点の分散に対応したコミュニケーションツール・情報共有ツールの利用

などがあります。ソーシャルアプリを開発している企業の傾向がベンチャーというのもあるかもしれませんが…

2. アプリがヒットするかどうか不安要素が多く、初期費用を抑える

初期費用で一番コストがかかるのがサーバ費用やデータセンター費用(人件費以外で)。この費用は売りあげゼロでも確実に必要になる費用です。多くの企業でインフラに関する部分は8,9割がクラウドサービスを利用されているようです。最近は国内クラウドサービスも増えてきており、日本語でのサポートや情報が充実しています。

  • GMOクラウド http://www.gmocloud.com/
  • ニフティクラウド http://cloud.nifty.com/
  • Amazon EC2 http://aws.amazon.com/jp/ec2/

 

3. クチコミ等、一気にユーザが増えた場合のスケールアップ

自分たちのアプリケーションのユーザが増えることはとてもうれしいことですが、不測のアクセス増加(それも何十倍)が起こった場合には

  • ハードウェアの増強 – Webサーバを増やす、キャッシュサーバを増やす、DBサーバを増やす
  • アプリケーションのチューニング

などの対応が必要になります。ここでもクラウドによる大きなメリットがあり

  • スケールアップが容易
  • 一気に増える時間帯、特定の日のみサーバ数を増やすなどの柔軟な対応

が可能です。
開発期間中に高トラフィックを発生させ負荷試験を実施したり、チューニングをすることがとても重要です。わかっていても現実のタイトなスケジュール内ではその時間と人材を確保することが難しいのが現実です。

4. 利用者に向けたイベント、日々のサイト更新必須

ソフトウェアやソーシャルアプリは開発期間よりも運用期間の方が長いことが通常だと思います。特にソーシャルアプリの場合、既存のユーザが飽きないように次から次へと新しいキャンペーンやイベントを行っています。
あるソーシャルゲームサイトでは、朝、前日のアイテム課金結果をみてよく売れている傾向から、その日の夕方には傾向に沿った新アイテムをリリースしたり。週替わり、月替わりのタイミングでイベントを実施したりしています。小さな改善だけではなく、コアなシステムに影響のある変更までユーザ動向に合わせた改善が日々くり返されています。

これは

  • 複数サーバの安定した運用
  • 複数サーバ(数台~数十台)に確実にリリースするデプロイ管理
  • 24時間のサーバ、サービス監視
  • ログの解析、ログの視覚化
  • デザイン・素材・プログラムのバージョン管理
  • 不測の事態と前兆を教えてくれるアラートシステム

 

ソーシャルアプリ開発では提供するサービスだけではなく、バックエンド側にも高度な技術力が必要とされます。
すべての環境が満足できるレベルまで整備されたプロジェクトが理想ですが、そのようにできない場合が多いのではないでしょうか。
技術者のスキルによりカバーできる部分とできない部分を見極め、あなたのチームに最適な環境を見つけてください。
そのための開発方式やインフラ技術について情報提供していきたいと考えています。