12月 19
syojiciklone, SAP, ソフトウェア開発
「クラウドのメリットを一番享受できるのは、個人開発者、ソーシャルアプリ開発企業、IT系ベンチャー企業」
小さく・安く・始めて、成長に合わせてサービスレベルを向上させることが出来るクラウド・コンピューティングはそのような企業にとって大きなメリットがあると考えています。
クラウドは、開発環境、本番環境のインフラ、スケールアップ、運用負荷軽減を低リスクで担保できるサービスになっています。これからのアプリ開発でははじめるときにハードウェアのことをほとんど考えなくて良くなる、と言えます。
サービス提供者の役割によるメリットを簡単にまとめると、
経営者
- システムの投資の無駄を排除 →「所有」から「利用」
- 求めるサービス提供のためのハード購入費用がかからない
- 素早いサービス立ち上げ
開発者
- 開発環境の迅速な構築
- スケールアップ・可用性向上
- 本番リリースに向けたサーバ規模の設計を軽減
- 負荷分散
運用者
- 利用状況に応じた柔軟なリソース割当
- システム運用負荷の軽減
- ハード障害から解放(自前に比べて…
数年前まではデータセンターを借りて自前のハードを用意するか、ホスティングサービスを利用するかが一般的だったと思います。最近はクラウドを使うことで低コストでストレスなく（ハードの面倒を見る必要なく）始めることが出来る。スタートするときの敷居が低くなることはアプリケーションベンダーにとっては良いことです。
2,3年のスパンで見た場合、クラウドよりコスト面でメリットがあるサービスもありますがソーシャルアプリ・ソーシャルゲームに限ればベストなソリューションではないでしょうか。
新しいサービスをすばやく提供するために、その時、そのタイミングで最適なサービスを積極的に利用していきたいですね。
12月 14
syojiciklone, SAP, ソフトウェア開発
ソーシャルアプリ開発者、とくにインフラを担当している技術者の方はシステム構成をどのようにしていますか。
最近の一般的だと思われるシステム構成とソーシャルアプリ開発のインフラ構築時に使える10個のチェックリストをご紹介します。
実際にソーシャルアプリやソーシャルゲームのシステム構成として稼働実績があるシステム構成になりますので参考になるかもしれません。
インフラ構築に使える10個のチェックリスト
- 必要なときにスケールアウト､スケールアップができるか
- トラブル発生時に問題箇所の原因特定できるか、可能ならその箇所を分離できるか
- トラブル発生時に担当者に通知がされ､その障害対応フローやエスカレーションがマニュアル化されているか
- 性能を考慮したハードウエア、OS、ミドルウエア(Apache､MySQL)構成、設定になっているか
- メンテナンス時間を最小化できるか
- ログファイルをいつでも参照、見える化（グラフ化）できるように管理出来ているか
- サーバの状態を常に把握できているか(全体PV､各ページPV,日毎､時間毎）
- WEBサーバ、キャッシュサーバ、ＤＢサーバ、踏み台サーバの分離、機能の明確化ができているか
- バックアップ・リカバリの方法は確立されているか
- 監視用アプリケーションは正しく、漏れなく設定されているか
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個のチェックリストをあなたの開発チームでも確認してみてください。
これ以外にも大切なチェックはあると思いますので教えてもらえればインフラエンジニアのスキルアップに繋がりますのでご意見をお待ちしています。
12月 12
syojiciklone, SAP, ソフトウェア開発
ソーシャルアプリ・モバイルアプリケーションの開発環境や支える技術についてご紹介。
ソーシャルアプリとは、mixi、mobageやGREEなどのSNSプラットフォーム上で動作するアプリケーションです。
2009年末頃から各SNSプラットフォームのオープン化が進められ、外部開発者でもアプリケーションを開発し、SNSに登録されている多くのユーザに対して公開できるようになっている。数千万人という会員をもつプラットフォームに公開が可能になることで、労せずに大量のユーザに利用してもらえる可能性が高い。
また、これまでのコンシューマ向けのゲームやECサイトと違い、SNSの利点を活用したコミュニケーションを重視していることが特徴の1つになっている。
ビジネスとして考えた場合、
- 大量のユーザにリーチ
- 少ない投資で開発が可能
- その上で大きな成功の可能性あり
など、良いことだけを挙げると一日でもはやく始めたいと思うかもしれないが、そんなに簡単ではないことは承知の通り。
開発者から見たソーシャルアプリ開発で重要だと思われる点は
- 競合が多いく、早いリリースが必要 → 開発の効率化
- アプリがヒットするかどうか不安要素が多く、初期費用を抑える → インフラ・維持費
- クチコミ等、一気にユーザが増えた場合のスケールアップ → インフラ・スケールアップ
- 利用者に向けたイベント、日々サイト更新必須 → サービス運営・ソフトウェアライフサイクル
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時間のサーバ、サービス監視
- ログの解析、ログの視覚化
- デザイン・素材・プログラムのバージョン管理
- 不測の事態と前兆を教えてくれるアラートシステム
ソーシャルアプリ開発では提供するサービスだけではなく、バックエンド側にも高度な技術力が必要とされます。
すべての環境が満足できるレベルまで整備されたプロジェクトが理想ですが、そのようにできない場合が多いのではないでしょうか。
技術者のスキルによりカバーできる部分とできない部分を見極め、あなたのチームに最適な環境を見つけてください。
そのための開発方式やインフラ技術について情報提供していきたいと考えています。
5月 23
hayashidaciklone, wiki, ソフトウェア開発
こんにちは。wiki.ciklone担当のhayashidaです。
何だか熱くなったり、寒くなったりで体調管理が難しい気候が続きますね。皆様お元気でお過ごしですか？
そんな今も空はどよどよ。今朝はレインコート着て出勤しました。
さて、cikloneの新バージョンが近日中にリリースされそうです。それに伴いcikloneHPもリニューアル致します。
残念ながらwikicikloneのデザインは変わらずですが・・・cikloneの新機能に付いてなど詳しく掲載していくつもりです。
※wiki.cikloneではciklone（サイクロン）のマニュアルやら便利なTipsやらFAQやらを掲載しています。
いつまでの無料のフリープランもこれまでと同様に使用頂けます。
今日はご報告までですが、次回はより詳しいバージョンアップ内容をご報告出来ると思います。
ではまた！
3月 15
adminソフトウェア開発
「インシデント管理、どうしていますか?」
ある程度の規模のエンドユーザ企業では数名～からシステム管理を専門にする、情報システム部門があります。情報システム部門の業務は多岐にわたり
- 社内システム、基幹システムの運用や保守
- 社員が利用するPCの管理
- インフラ・ネットワークの管理
- エンドユーザから要望されたソフトウェアの検証
- OSやツールのバージョンアップ作業
- ヘルプデスク
- 新システムの企画
など。他にもあるでしょうが･･･
情報システム部門の中でも、システム管理者や運用保守担当者とは
エンドユーザから見た場合、自分たちの業務を支えてくれる便利屋さん、と思っている人も多いのではないでしょうか。
エンドユーザから、「昨日までは出来たのだけれど」「ログインできません」「やり方がわからない」など、日々のサポートで昼間は自分たちの仕事が出来ない、という声も聞いたことあります。
「インシデント管理ができれていれば全てが解決」というわけではありませんが、あなたの仕事の2，3割は減らすことが出来るかもしれません。
インシデント管理とは
「インシデント」とは提供するITサービスの中断を意味する。インシデントに対して、インシデントの発生から対策、解決（クローズ）までの一連の流れを管理し、コントロールを行う。ただし、ITILは従来の運用で行われてきた管理と異なり、暫定対応と恒久対応を明確に分離し、インシデント管理では暫定対応のみを対象として管理し、恒久対応に関しては問題管理プロセスにて管理を行う。
問題管理とは異なり、一時的な対応・暫定的な対応ということになります。
日常起こるインシデントの具体例として
- メールが受信できない
- ログインできない
- アプリケーションの使い方が分らない
など、やろうとしたときにできない状況のことです。
インシデント管理に必要なこと
エンドユーザにとって、
- 目の前のできない状況を解決できればそれでOK。
- やりたいことができなくても、別の解決策があればOK。
- いつ解決するのか、今どのような状況なのか、がわかればOK。
システム管理者や保守運用担当者にとっては、インシデントを解決したからと言ってそれで終わりではありません。
- インシデントの発生した状況、「なぜ、そのようなインシデントが発生したのか?」
- インシデントに対して、具体的に「何をやったのか?」
- インシデントの再発を防ぐため、「同じ事が起こらないために何をすればよいのか?」
をナレッジとして残し、同じ問題が発生したときの事例として活用する仕組みまで考えなければいけないのではないでしょうか。
情報システムの方達はエンドユーザからの問い合せに対して、シンプルに、楽に管理出来るようなフローを自分たちで構築されていると思います。
エンドユーザが望むことは「いつものようにできること」と「できない場合は、今どうなっているのか」がわかることだと思います。
5月 10
adminソフトウェア開発 bts, ソフトウェア開発
ゴキブリを１匹見つけたらその１０倍は家に潜んでいると、誰かから聞いたことがありますが、それは本当なのでしょうか？
ソフトウェアのバグもそんなにあったら嫌だなあと最近つくづくと感じています。
バグ数の推定
そもそも、システム開発工程でバグを作りこまないようにすればいいのですが、必ずと言っていいほど作りこまれてしまいます。設計書の誤り、誤解や思い込み、錯覚あるいは検討もれなど、原因はたくさんありますが、どうやら人間の行動にはミスがつきまとうものだと理解した方がよさそうです。
設計者ならば、どれくらいバグが潜んでいるのか興味があると思いますが、信頼性予測のモデルによってソフトウェアの信頼性を数理的なモデルで計量化して予測する方法もあります。プログラム開発者が意図的にプログラム中にバグを埋め込んでおき、デバッグにより発見したバグのうち意図的に埋め込んだバグの発見率から全体のバグの数を推定するのです。
次のような式になります。（詳細はこちらを参照のこと）
（発見済み埋め込みバグ数）/（埋め込みバグ数）
＝（発見済み潜在バグ数）/（潜在バグ数）
ソフトウェア開発者の能力によりバグの作りこみ数も変わってくるような気もしますが、バグの収束を願う設計者の気持ちはひしひしと伝わってきます。
テストの達人とは
バグを見つけるためには効果的なテストが必要ですが、どんなテストをすれば重大なバグが素早く見つかるのでしょうか。一般的なテスト作業では、コンポーネントとして実装したプログラムが要求仕様とおりに動作することを単体テストで確認し、結合テストによりさらに大きなモジュール単位での動作を確認します。当然のことながら、どんなテストツールを使うか、どんな体制でテストチームがテストを進めるかが重要になってきます。テスト工程を管理するテストツールも沢山出ているので、うまく利用すれば自動テストや結果分析も効率化できると思います。
デバッグとは関係ありませんが、2つの似た絵があって右の絵と左の絵でどこが違うのか探すような、間違い探しのクイズを考えてみてください。答えを見れば、何だそんな所か、とわかるのですが、意外なところ、想定外のところに違いがあると案外と見つかりにくいものです。もちろん、得手、不得手はありますが、ちょっと見方を変えることでバグが見つかるということがあります。他の人の見方や意見を参考にするのも、新鮮な視点を持つという点で、効果的です。開発者は、失敗を繰り返しながら、テストの達人に成長していくものなのでしょう。
ある先輩が言っていた言葉を思い出します。
「バグを全部見つけるのは無理だが、事故再発防止により品質向上できる」
類似不良を出さないことが最低限必要なのだと理解しましたが、これはいつの時代も通用することだと思います。
cikloneによるバグ管理
バグ管理システムcikloneでは、チーム開発の進捗、wikiによる情報共有基盤を備えています。そのため、プロジェクトのチームメンバと情報交換をしながら、テストも進められます。バグ管理データベースで過去の類似バグも管理しているので、同じ失敗を繰り返さないようにできます。
無料版での利用が可能なので、皆さまも是非、御検討下さい。
4月 15
adminソフトウェア開発 agile
ciklone blogをご覧の皆さま、こんにちは！
cikloneは、チーム主導によるアジャイルソフトウェア開発を実現できる「ソフトウェアエンジニアのための開発プラットフォームを提供するクラウドサービス」です。この点で、管理者が進捗を管理するだけ、説明のためのWBSを作成するだけの、従来のプロジェクト管理システムとは全く異なっています。
アジャイルって何？という方もいらっしゃると思いますので、念のため、Wikipedeiaによると：
アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。
私達は、ソフトウェア開発に重要なキーワードは次の３つだと考えています。
- だれでも簡単に使える情報共有基盤
- チーム開発の進捗を管理し、課題・バグに漏れなく対応するためのシステム基盤
- ソフトウェア開発のライフサイクルで作成される成果物・ソースコードを管理するためのシステム基盤
cikloneを使って情報共有・課題管理を実現するには
ソフトウェア開発に重要な3つの要件を実現するために、cikloneは次のソリューションを提供しています。
- バージョン管理システム
- ソースコード管理と連携したバグ管理システム(BTS)
- チーム開発の進捗、wikiによる情報共有システム
cikloneを利用する事で、情報共有や課題管理を実現するシステム基盤が60秒であなたのチームに導入できます。そして、システムをあなたのチームに適用するための、ciklone導入・運用サポートが柔軟に対応します。
ciklone導入サポートで解決！
「ciklone導入サポート」を利用することで、これまでバージョン管理システムやバグ管理システム（BTS）を使ったことがないユーザに対してもスムーズに導入し、チームのため、エンドユーザのためのシステム開発が実現できます。
- cikloneプロジェクト管理システムの導入
- 管理者向け教育
- 一般ユーザ向け教育
お客様は当サービスにより
- システムをスムーズに導入できます。
- 教育コストを削減し、先進的なクラウドサービスのメリットを享受できます。
- 過去に導入がうまくいかなかった場合も、導入～運用まで十分サポートします。
チーム主導での開発が重要
さて、チーム主導での開発とは何でしょうか？
あなたのチームに、次の項目があてはまるかどうか、ちょっと考えてみて下さい。
- 管理者の効率化を優先し、進捗報告は数字だけによる管理をしている。進捗率30％は本当なのか?
- 現場のプログラマーまで、エンドユーザの声が届かない。プログラマーにとってベストな機能を開発。方向が違うのでは?
- 障害情報、クレーム情報、エンドユーザ要求・・・日々大量のメールが流れ、忘れ去られているのではないかという不安があるのでは?
もしも、上記項目のどれかに思いあたる点があれば、チーム開発の進め方、ルール、仕事のやり方に改善の余地があります。あなたのチームでも考えてみてはいかがでしょうか?
私達が理想とするのは、「エンドユーザ、管理者、開発者の情報格差を減少させ、必要な情報を必要な人に伝える」ことです。
正しい情報が伝えられて初めて、正しい答えを見つけることができます。
3月 24
adminソフトウェア開発
ciklone blogをご覧の皆さま、こんにちは！ 折角桜の花が咲き始めたのに、今日は冬のように寒いですね。
さて、ソフトウェア開発では、まずはじめに要求仕様にあったソフトウェアを実現するための設計をおこない、それをコンポーネントに細分化して実装します。階層化、モジュール化した各プログラムが要求仕様とおりに動作するかをテストし、最終的には結合テストを行って、より大きなモジュール単位での動作を確認していきます。システム開発をしているエンジニアの皆さんは、品質の良いソフトウェアをより早くお客様に提供するために、日々努力しているはずです。
私達は、ソフトウェア開発の品質管理をはじめる第一歩はバグ管理であると考え、cikloneで開発工程である、「プログラミング、変更・構成管理、テスト」の効率化を実現するためのサービスを提供しています。今回は、実際にcikloneを使ったソフトウェア開発についてご紹介いたしましょう。
cikloneを使ったソフトウェア開発
システムテスト担当のＢ君がcikloneにログインすると、B君専用のダッシュボードが表示されます。この画面では、遅延したマイルストーン（期限付の予定）、プロジェクトの進捗状況が一目でわかります。
- システムテストの状況は 233項目のタスクとバグのうち75%完了。期日まで2週間しかなく、59項目のタスクとバグがある。
- 残タスクのレポートを確認し、自分に割り当てられているタスク・バグを確認する
- テストチーム用レポート、自分用のレポートから今週の作業計画を決めて、チーム内ミーティングに臨む
このような全体としてのプロジェクトの流れを把握し、いつまでに、なにを対応すべきかを把握した上で、Ｂ君は自分のプロジェクト詳細画面を表示し、自身の作業内容を確認します。
- システムテストで残っているバグはモジュールα（担当者はCさん）「マクロ使用時のロジック誤り」のバグである
- 担当者Cさんの状況を画面から確認すると、問題の特定に至っており、対応中らしい。今日の1700には完了予定
- それまで、モジュールαはテスト準備をしておけばよい。他のモジュールでバグフィックスした「確認待ち」を再試験
- 今後のノウハウのため、過去のバグを検索して参考になる情報を探して再発防止に努めなければならない・・・
今日の作業を確認したB君は、
再試験に着手する前に、過去の同様なバグを探してみることにします。cikloneに標準で実装されている全文検索により「マクロ使用時のロジック誤り」に関するバグの事例を検索した結果、過去のプロジェクトで類似バグの報告があり、その時の対策状況がナレッジ情報として蓄積されていることがわかりました。
予定より３日も遅れているものの、システムテスト再開の前に、各コンポーネントについて、「マクロ使用時のロジック誤り」に加えて類似バグがないかどうかも確認しておくべきだ、とＢ君は判断しました。至急、各モジュールの確認をしてもらったところ、設計担当のD君から、モジュールβに類似のバグが見つかったので修正したという報告メールが届きました。
こんなことができるのも、cikloneがバグの発生から完了までのサイクルを一元管理しているからですね。バグの対応状況も自動で追跡しているので安心です。
最後に･･･
いかがでしたでしょうか？
cikloneを使ったバグ管理では、さらに、製品、バージョン、担当者別にレポートを簡単に作成することができます。ソフトウェア開発過程で、バグを記録するだけでなく、再発防止に努める仕掛けがあることが重要なポイントだと考えています。
cikloneは無料版での利用が可能です。皆様も是非、御検討下さい。
RSS
