SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

「Developers Summit 2013 Kansai」レポート(PR)

【デブサミ関西2013】Visual Studio 2013にみる開発環境の方向性

  • このエントリーをはてなブックマークに追加

 ビジネスに貢献するソフトウェアを開発するには、現場力を最大限に発揮できる開発環境が不可欠。長沢智治氏のセッションでは、チームをよりコラボレーションし、本業に注力できると定評のある Team Foundation ServerとVisual Studioについて、最新動向を交えて、現場力を生かすポイントがデモを交えて紹介された。

  • このエントリーをはてなブックマークに追加

日本マイクロソフト株式会社 エバンジェリスト 長沢智治氏
(TFSUG 世話人/E-Agility 協議会 実行委員/ASTER ツールWG メンバー)
日本マイクロソフト株式会社 エバンジェリスト 長沢智治氏

ビジネスが求める価値を提供し続けるために

 情報システムをビジネスという視点で見ると、常にまずアイデアがあり、それをプロダクトやサービスという形にし、そこから出てきたデータから学ぶという流れがある。以前のビジネスでは、このサイクルを一回、回せばよかった。ビジネスモデルを固定できたからだ。

 しかし、今あるビジネスはどんどん変わっていく。なぜなら、次々に新しいテクノロジーが出てくるからだ。市場の動向が変わり、競合が想定外のことをやり始める。お客様の意識も変わる。対抗するためには、ITの力が不可欠だ。長沢氏は「開発と運用がシームレスに連携し、フィードバックの流れが価値の流れを形成し、開発作業からビジネスまでのサイクルが繋がっていることが必要」と指摘する。

開発作業からビジネスまでのサイクルが繋がることが重要
開発作業からビジネスまでのサイクルが繋がることが重要

 続いてITの世界にフォーカスすると、ビジネスが回っている中で、ITをフル活用する時代になっている。その世界観の中では、ITの価値がビジネスにマッチしていないと、ボトルネックになってしまう。その分かりやすい例として長沢氏が挙げたのがMTTR(Mean Time To Repair)。平均復旧時間だ。ITがビジネスに力を発揮できなくなったとき、いかに早く戻せるかが問われている。

 長沢氏が着目する第3の視点は「価値を提供し続けるIT」のためのサイクルタイムだ。ビジネス価値に優先順位をつけ、受け入れ基準を満たした動くソフトウェアを早く提供する必要がある。ただ早ければいい、というだけではない。ビジネスのリズムに合わせなければならない。

 今、よく言われているのは、定期的に提供することの有用性だ。例えば2週間に1回のリズムで、価値のある物を作ることができれば、ビジネス側がITに協力してくれるようになる。逆にリリースのサイクルがまちまちで、いつ自分がほしいものが出てくるか分からないと、協力できない。ビジネスのアイデアを、実際にデプロイするまでの期間を安定させる必要がある。

 そのための一つの方法が、スクラムのタイムボックス利用による、定期的な提供リズム作りだ。開発チームは自分たちのポテンシャルを見て、例えば2週間で作れる物を選び、確実に作っていく。

 もちろん、品質という問題もある。サイクルを回していくということは、ウォーターフォールでいうところの、要件定義、設計、実装、テスト、デプロイを何回も繰り返す形になる。もちろんテストは必要に応じて行った方がいい。しかし多くの場合、テスト用の開発環境上で行われ、本番に近い環境上では実行されていない。受け入れテストも同様で、特に手動のテストは、その環境でしかやらない。

 長沢氏は「それではもったいない」と指摘する。テスト資産は、工程に関わらず常に活用することで安定し、開発側が安心できる開発環境になる。プラクティスもツールも、進化しており、運用環境に似た環境を仮想で用意できるようになっている。そこにデプロイし、テスト資産を常に動かし続けることが可能だ。

スクラムのタイムボックス利用して定期的な提供リズムを作る
スクラムのタイムボックス利用して定期的な提供リズムを作る

 リズムを作り、資産をうまく活用できるようになっても、開発を難しくしている要因として長沢氏が挙げるのが資産の分散だ。要件定義書、設計書、ソースコード、バグ票などが別々の場所、ツールで管理されている。それぞれの相関関係や、時系列的な経過などをたぐっていきたいのだが、ツールが別だとトレースできない。そのため開発者には、開発能力よりも情報収集能力が求められる事態になっている。つまり、本業に集中できていない。

次のページ
開発の透明性を確保し、運用ともコラボレーション可能にする環境を披露

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
「Developers Summit 2013 Kansai」レポート連載記事一覧
この記事の著者

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/7436 2013/10/23 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング