これらのバージョンでは今後セキュリティパッチが提供されなくなり、危険な状態に晒されることになるので、サポート範囲内のバージョンへアップグレードする必要があります。

詳しくはこちらに分かりやすくまとめられています。
http://www.atmarkit.co.jp/ait/articles/1503/04/news141.html

日々の活動を経て「リリース判断可能なプロダクト」が完成しました。
そのプロダクトが「リリース可能なプロダクト」かどうかを検証・判断するための会議を「スプリントレビュー」といいます。

■スプリントレビュー
この会議は、開発チームの成果物をプロダクトオーナーが確認する場です。
・開発チームが開発したものをPOにデモをする
・POはリリース可能かどうかを判断する

以前プロダクトバックログを作成する段階で、その要求に対する完了の定義を決めておきました。
今回のスプリント計画で開発することにしたプロダクトバックログ毎に、その完了の定義を満たしているのかどうか、デモを通じて検証します。

その結果を見てPOがリリース可能かどうかの最終判断を下します。
ここでNGになったプロダクトバックログについては、その残作業を次のスプリントに持ち越します。

NGになったプロダクトバックログを、スプリントの期間を延長して完了させるのではなく、次のスプリントに持ち越す点に注意して下さい。

これは開発チームの「ベロシティ」を測るためです。

■ベロシティ
スクラムのルールとして各スプリントの長さは均一にしなければなりません。
また、以前プロダクトバックログの見積もりを行う際にプランニングポーカーの手法を説明しました。
この手法で見積もりが行われた場合、それぞれのプロダクトバックログには、それを実現する場合にどれくらいの工数が掛かりそうかがポイントで表現されています。

つまり、1スプリントで消化できたプロダクトバックログのポイントの総計が、今の開発チームが1スプリントで消化できるポイントであり、今の開発チームの実力を表します。それを「ベロシティ」と呼びます。
このベロシティを測り、また比較するために、スプリントは均一でなければならないのです。

今の開発チームのベロシティがわかれば、今後のスプリント計画も立てやすくなり、プロジェクトの見通しも立ってきます。
開発チームとしてはベロシティ、つまりチームの実力を測る、その目安にもなります。

スクラムでは開発チームがベロシティを向上させるべく、次のスプリントへ向けて今回のスプリントをふりかえるための会議体が用意されており、それを「スプリントレトロスペクティブ」といいます。

■スプリントレトロスペクティブ（ふりかえり会）
次のスプリントを今回のスプリントよりも良くするためのアクションを決める
・プロセスやツールなどの観点で今回のスプリントを検査する
・うまく行ったこと、今後改善すべき点を整理する
・今後のアクションプランを作る

ふりかえりを行って次のスプリントに活かす、つまりPDCAサイクルを回すことで開発チームの業務を改善する仕組みが、スクラムには用意されています。

以上、ここまでが1スプリントで行う活動になります。

まとめますと、
・スプリント計画ミーティング
・デイリースクラムを実施しながらの日々の開発
・スプリントレビュー
・スプリントレトロスペクティブ
を1スプリント内で実施し、それを繰り返すことでプロダクトを作成していき、最終的にはそのプロダクトをリリースする、という流れになります。

今回を含め、今まで５回に渡りスクラム研修のまとめということで書かせていただきました。本連載は今回で終了です。

アジャイル開発におけるマネジメント手法の一つである「スクラム」。
その基本的なルールについては、本連載を書く中で改めて整理できたと感じています。今後はスクラムを実践しながら、更に学んでいければと思っています。

最後に、スクラムをはじめようと思っている方に向けて、スクラムの実践の手引とも言える、すばらしい書籍をご紹介させていただきます。
SCRUM BOOT CAMP THE BOOK

最後まで読んでいただき、ありがとうございました。

まず、スプリントをスタートするにあたって、
今回のスプリントで何をどう作るのかを決める必要があり、
そのための会議を「スプリント計画ミーティング」といいます。

■スプリント計画ミーティング
このミーティングでは下記の事柄を決めていきます。
・プロダクトバックログを分析・評価し、今回どれを作るのか、POと開発チームで合意する
・プロダクトバックログを具体的なタスクに分割する（このタスクをスプリントバックログといいます）
・具体的な実現方法を検討する（あとは作るだけ、という状態まで詳細を詰めます）
・タスク毎に見積を行う（プランニングポーカーを活用）

このミーティングにかける時間は、
1ヶ月のスプリントであれば、8時間が目安です。

計画が決まれば、後はその計画にそってタスクをこなし、
リリース判断可能なプロダクトを作成していくという、
日々の開発作業に入っていきます。

ただ、皆さんよく御存知の通り、
全てが計画通りに進むとは限りません。
スクラムには、日々の作業が本当にゴールに向かっているのか、
を確認するための会議体が用意されており、
それを「デイリースクラム」といいます。

■デイリースクラム
スプリントの目標を達成できるか、どこかに問題がないか、
を検査するために行う日々のイベントです。
・毎日決まった時間に決まった場所で、開発チーム全員で行う
・15分以内で行う
・その日に何をすべきかを共有する
・作業を進める上での問題点を洗い出す
・問題があれば、対策を決める（別途時間を取って行います）

このイベントではタスクボードを活用します。
ホワイトボードを Todo, Doing, Done の3領域に区切り、
スプリント計画ミーティングで洗いだしたタスクを
ポストイットに書いて貼り付けます。
最初は全て Todo にありますが、タスクが進む毎に
Todo→Doing→Done へ移動させることで、
タスクの進み具合を把握できるようになります。

このタスクボードの前でデイリースクラムを行うことで、
開発チーム全員で状況を共有します。

このように日々の作業を行っていき、
リリース判断可能なプロダクトの完成を目指します。

今回はここまでです。
次回はプロダクトが完成した後の活動について書いていきたいと思います。

■プロダクトバックログ
プロダクトバックログとはプロダクト（システム）に対する要求の一覧を指します。
・ユーザのニーズ等からプロダクトオーナーが作成する
・１つの要求についてユーザストーリ形式(※)で記述する
・プロダクトオーナー（PO）が開発する順番に並び替える（順番の最終決定権はPOにある）
・要求は可変なので常にメンテナンスして最新の状態に保つ必要がある（優先順位の高いものから開発することでプロダクトの価値を最大化する）
・要求毎に完了の定義を決めておく（デモ手順とその結果を決めておくことでリリース判断可能にしておく）
・開発チームによって見積が行われる（プランニングポーカー(※)という見積手法が主流）

※ユーザストーリ形式
「誰々としてこれこれがほしい。それは何々のためだ」という役割・機能・価値の３つをストーリとして記述する形式

※プランニングポーカー
開発チーム全員でカードを使って行う、複数人の知見を活かした見積の手法。
フィボナッチ級数（1,2,3,5,8）のカードを全員が持ち、基準となるストーリ（要求）とその数字（ポイント）を決めた上で、その他のストーリについて、下記の手順で見積を行う
・対象を個人で頭のなかで見積もる
・一斉に数字が書かれたカードを出す
・差異が出たら、その差異について、まずは最小と最大の数字を出した人が、その根拠を説明する
・それを踏まえて再度カードを一斉に出す
・これを差が少なくなるまで繰り返す（全て一致しなくても差が少なければ、小さい方を採用する）

■スプリント
全体の工期をスプリントという固定の期間に区切って繰り返し開発を行います。
１スプリントの中で実現するストーリをプロダクトバックログの中から決めて（複数可）、リリース判断可能な動くソフトウェアを開発します。
・最大１ヶ月までのタイムボックス
・各スプリントの長さは均一（延長してはならない）
・開発チームはこの期間の中で、計画、設計、開発、テストなどプロダクトのリリース判断に必要な全てのことを行う（ゆえに開発チームは自己組織化されたチームである必要があります）

今回はここまでです。
次回は１スプリントの中で行う具体的な活動について書いていきたいと思います。

スクラムというマネジメント手法にはルールがあり、そのルールを理解するためにはまず、スクラムにおける用語を知っておく必要があります。今回はその用語のなかで登場人物（役割）に関するものを書いていきます。

スクラムには登場人物（役割）として
・プロダクトオーナー
・開発チーム
・スクラムマスター
がいて、この３者のグループをスクラムチームと呼びます。

■プロダクトオーナー
・プロダクト（システム）の価値を最大化することに責任を持つ
・プロダクトバックログ（開発要件）の定義や優先順位付けを行い開発チームに伝える
・要件とその優先順位を決める必要があるので基本的にはお客様側の人が担当する

■開発チーム
・スプリントごとの成果物のリリースに責任を持つ
・自己組織化されたチームである（自分たちで判断し仕事を進めることができる）
・チームは10名弱で構成される
・開発ベンダー側が担当する

■スクラムマスター
・スクラムの推進に責任を持つ
・スクラムチームの支援をおこなう
・開発ベンダー側が担当する

私はまだスクラムを実践したことがないのでスクラムマスターの立ち位置や具体的な仕事内容が正直ピンと来ていませんが、ひとつ言えることは、スクラムマスターはプロジェクトマネージャではないということです。あくまでスクラムに沿ったマネジメントが円滑に進むよう力を尽くすのが仕事です。

今回はここまでです。
その他の用語も出てきましたね。次回はその辺りの用語について書いて行きたいと思います。

スクラム（Scrum）とはアジャイル開発におけるマネジメント手法の一つです。

そもそも私は研修を受けるまで、アジャイル開発すらどんなものなのかもよくわかっておらず、最近「スクラム」ってよく見かけるな～ちょうど研修があるみたいだから受けてみようかな～というぐらいのノリで受講してみたという状態で、まだ実際のプロジェクトで実践もしておりませんので、ど素人には変わりありません。ですので間違っている部分もあるかもしれませんがその点、暖かい目でご覧いただけると幸いです。

まず、アジャイル開発について簡単に書いてみたいと思います。

アジャイル開発の目的は、お客様の満足を最優先とすることです。
その手段として
①短い間隔で、継続的に、動くソフトウェアをリリースする
②お客様と開発者が協調してプロジェクトを成功に導く
があげられ、そのような特徴を持ったソフトウェア開発技法をアジャイル開発といいます。

では、お客様の満足度を最優先とするとはどういうことでしょうか？それは
・お客様が必要と思う、今使いたいシステムを最優先で提供する
・お客様からの意見をフィードバックして、満足度の高いシステムを作成する
・使わない機能は作らない、という決断を促す
があげられます。
アジャイル開発はリーンという考え方がベースにあり、QDCを固定してスコープ（開発対象要件）を可変にするという基本的な考え方があります。アジャイル開発とよく対比されるウォーターフォール開発との大きな違いはここにあります。ウォーターフォール開発は要件定義フェーズで最初にそのシステム全体の要件を固めてしまい、その後設計、開発、テストという流れに沿って開発を進めていきますが、アジャイル開発はビジネスの流れの中で、その時に最も優先順位の高い機能から開発・リリースしていきます。要求の追加・変更には、その優先順位が高ければ順次対応していきますが、QDCの範囲に収まらない（つまり優先順位の低い）機能は作りません。

アジャイル開発とウォーターフォール開発は全く違う手法のように思われがちですが、今まで行ってきたウォーターフォール開発の要件定義・設計・開発・テストという流れを、今必要な機能単位で何回も繰り返すと考えていただいても間違えではないと思っています。

また、アジャイル開発はウォーターフォール開発と比べ、
・ドキュメント等の作成は省略できる
・安く、早くシステムを構築できる
というイメージを持っておられる方もいらっしゃるかもしれませんが、それは間違えです。
ドキュメントは作らなくていいわけではなく、無駄な（使われない）ドキュメントは作らないだけです。開発や運用上必要なドキュメントは必要なので作成します。
また、機能毎にリリースしますがユーザのフィードバックを受けての戻りを前提にしていますし、リリースされたものもシステムの機能の一部でしかありませんので、安く早くシステムが構築できるわけではありません。

アジャイル開発もウォーターフォール開発もお客様に喜んでいただけるシステムを提供するという開発側の思いに違いはありませんので、アジャイル開発はウォーターフォール開発を否定するものではありません。アジャイル開発が向いているシステムもありますし、ウォーターフォール開発が向いているシステムもあります。お客様に満足いただけるシステムを提供するためにはどの手法が最適なのかを考えて選択する、その選択肢の一つとしてアジャイル開発という手法が最近注目されているのだと思っていただければと思います。

なお、以下のようなサイトがありますので、ご興味が有られる方はどうぞ。
アジャイルソフトウェア開発宣言
http://www.agilemanifesto.org/iso/ja/

次回からはスクラムについて書いていこうと思います。

企業PCの WindowsXP→Windows7 への移行が

目に見えて進んでいるようですね。

http://internet.watch.impress.co.jp/docs/news/20141027_673193.html

ブラウザもIE10が主流になってきているようです。

ちなみにIE8のサポートは2016年1月までの予定らしい。

待ち望んでいるWeb開発者も多いのでは？

Adobe が Google と共同開発したオープンソースのフォントファミリーの一つで、

英語名 Source Han Sans の和名です。

デザイナーさんの間では話題になりまくっている書体だそうです。

和文フリーフォントの最上位でしょ！グーグルとAdobeが作った「源の角ゴシック」をゲットすべし

たしかに、フォント次第でサイトのイメージはぐっと変わってくると思います。

私はWebのシステムを作っている側でデザインはど素人ですが、

フォントを工夫するだけで、お客様のシステムに対する印象もよくなり、

愛着も持ってもらえるかもしれません。（もちろん中身も大切ですが）

「源ノ角ゴシック」の派生フォントとして「源真ゴシック」や「源柔ゴシック」も出ているようです。

http://fontfree.me/

このサイトを眺めているだけで、なんかわくわくしてきます。

フォントの世界も深そうですね。

またその製品群をさす言葉でもあります。

Xamarin社は2013年11月に「Xamarin for Visual Studio」をリリースしました。

これを使うと、なんと Visual Studio 2013 （主にC#, VB.NET）で、

iOS/Android のネイティブアプリが作れちゃうそうです！！

ライセンスは有償ですが、30日間の試用期間もあります。

Visual Studio を使い慣れている方で、

iOS/Android アプリを作ってみたい方には、

おすすめかもしれません。

これですね。サイト毎に表示される小さなアイコンのことです。

必要に迫られないと、調べもしないものですね、、、

HTMLに組み込む場合、

<head>

<title>ファビコンってこんな感じで指定するらしいよ</title>

<link rel=”shortcut icon” href=”favicon.ico”>

</head>

みたいに、head タグ内にlinkで指定します。

指定する画像は16×16で「.ico」というファイル形式がいいようです。

既存の画像をicoファイルに変換してくれるサイトもありますね。

知らないことばっかりです。

こつこつ頑張ります。