SimpleBoxes

さぁ、楽しいバグ取りの時間だ — バグに対してのワークフロー

現職でも前職でも JIRA というバグトラッキングシステムを使っています。

バグが報告された時にどのようなフローで処理するかをざっとまとめてみました。

チケットの発行

報告のあったバグはシステムに登録されます。

登録されたひとつひとつのバグはチケット (ticket) と呼ぶことが多い感じです。

以前の会社では issue とも言っていました。JIRA のシステム上では issue となっています。

ちなみに英語では、"raise a ticket (an issue)", "create a ticket (an issue)", "make a ticket" と言ったりしています。

バグの報告内容

  • 概要 (Summary)
  • テストしたソフトウェアバージョン
  • テストしたハードウェアならびに OS とそのバージョン
  • 再現手順
  • スクリーンショットやムービー

バグは再現性があるかどうかが肝で、再現する手順が明らかならば、そのバグは八割方直ったも同然です。

バグに対してのアクション

プロジェクトの進行状況や日程などによって変わりますが、バグが報告された際、すぐに修正作業に入ることはまれです。

  • レポーター (Reporter)

    バグを報告した人。テスターでなくてもバグの報告者になりえますが、テスターがレポーターになることが多いです。

  • ディスパッチャー (Dispatcher)

    バグの優先順位を決めたり、割り当て分担を決める人。テクニカルリーダーがこの役目を担うことが多いのですが、プロジェクトマネージャーやシステムエンジニアがチケットの割り当てを行うこともあります。

  • 担当者 (Assignee)

    バグの修正作業を行う人。当然ながら開発者 (デベロッパ) がバグ修正を行うことが多いです。

基本的な流れとしては、

  1. レポーターからバグの報告を受ける
  2. ディスパッチャーが各開発者の負荷や開発範囲を考慮して、それぞれのバグを開発者に割り当てる
  3. 開発者がバグを修正する

という形になります。

トリアージと優先順序

もちろん報告されたバグは全て直すのが理想ですが、リリース日程がタイトな場合には、全てのバグを直すのが事実上不可能なことがあります。

その場合、報告を受けたバグに優先順位をつけて、どのバグから優先的に修正するか、もしくは、修正しないことにするか (修正するにしても次のバージョンアップで修正する) などを決めていきます。

以前勤めた職場では、優先順位決定プロセスを「トリアージ (triage)」と呼んでいました。

災害などの非常事態に行う医療トリアージから来ています。

例えば、優先順位としては、以下のようなものが挙げられます。

順位 内容
P1 緊急。アプリケーションがクラッシュするなど、このバグのために他のテスト作業や開発業務ができない。深刻なセキュリティの脆弱性など
P2 重要。リリース前に直すべきバグ。アプリケーションが要求仕様通りに動作していない
P3 不具合だが回避方法がある、ミススペルや翻訳不備などのローカライゼーション系不具合、などの緊急度の低いバグ
P4 見た目だけの問題や微妙な挙動の一貫性不備、などの動作そのものには影響しないバグ

これは一例ですが、基本的な優先順位の意味付けはチーム内で共有しておく必要があります。

優先順位に付いている「P」は priority の略。

トリアージは以下のようなメンバーで行います。

  • テクニカルリーダー (あるいは、プロジェクトマネージャ)
  • システムエンジニア (あるいは、デザイナー) : 仕様作成者
  • テストリード
  • シニアソフトウェアエンジニア

これに (チケット内容の詳細を確認するため) レポーターが参加したり、実装の詳細をしっているエンジニアが参加したりする場合があります。

ソフトウェアリリース

バグに対してのワークフローからは少し脱線しますが、バグの優先順位はソフトウェアのリリースと関連付けられる場合あります。

ソフトウェアのリリースに関しては、正式公開されるまで

  • 基本仕様の実装完了 (Feature Complete)
  • アルファ版 (Alpha)
  • ベータ版 (Beta)
  • リリース候補版 (Release Candidate)

というような内部リリースの段階を踏みます。

リリース予定日から逆算してスケジュールを組むことが多いと思いますが、この内部リリースの大まかな定義 (目標) として、優先順をつけられたバグの数を使うことがあります。

つまり……

リリース 内容
Feature Complete 仕様実装がほぼ完了。新規機能追加を基本的に行わず、テストフェーズに移行
Alpha 最優先のバグ (P1) = 0。追加仕様の実装
Beta 重要なバグ (P2) = 0
Release Candidate その他、バグを可能な限りなくす。P3 バグ = 0 が目標

内部リリースのフェーズに応じて、その時点で残っているバグの優先順位の見直しが行われます。

場合によって、緊急度の低いいくつかのバグは次期バージョンに持ち越しされることもあります (defer)。

チケットの状態

報告されたチケットは、担当者に割り当てられるまではディスパッチャーが預ります。

チケットの状態 (status) にはおおよそ以下のように分類されます。

状態 内容
公開 (Open) チケットを受理。修正作業に入る前の状態
作業中 (In Progress) 担当者が当該チケットの修正作業中
修正済 (Resolved) 担当者がバグを修正し、テスターに検査依頼
完了 (Closed) テスターが修正内容を確認し、修正の承認が終了した状態

会社やプロジェクトによっては、更に以下のような状態が追加されている場合もあります。

状態 内容
新規 (New) Open の前段階。担当者に割り当てられる前の状態。New がない場合は、Open が New を兼ねる
検査中 (Testing) Closed の前段階。テスターが修正内容を検査中。Testing がない場合、Resolved が Testing を兼ねる

担当者 (開発者) のアクション

担当者はバグを修正して、テスターに「修正済 (Resolved)」として渡す役目を担いますが、単にソフトウェアを変更して「修正」する以外にもいくつか取りうるアクションがあります。

状態 内容
修正完了 (Fixed) ソフトウェアを変更し、バグを修正した
再現不可 (Cannot reproduce) 報告されたバグが再現できないため修正が困難。レポーターないしテスターに差し戻し
重複 (Duplicated) 他のチケットとしてすでに報告されている
修正不可 (Won't fix) 外部要因 (ハードウェアあるいは OS もしくはサードパーティライブラリ) による制限により修正不可能
仕様 (By design) 「それは仕様です (Working as intended)」

先述した通り、バグは再現性が非常に重要です。開発者の環境で再現できれば、そのバグは八割以上直ったのも同然とも言えます。

「再現できない (I could not reproduce/replicate it)」場合は、レポーターもしくテスターに差し戻して手順や条件の見直しをしてもらいます。

フロー概要図

以上を踏まえて、ざっと図にまとめると以下のようになります。

[図] チケットに対するワークフロー

人物っぽいシンボルについては

  • D : 担当者。主に開発者が担う。
  • L : ディスパッチャー。主にテクニカルリーダーが担う。
  • T : テスター。修正されたバグを検査する

のようになります。

レポーターは前述のとおり、テスターが担うことが多いのですが、必ずしもテスターがレポーターになるという訳ではありません (バグの報告は誰でもできます) 。

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

スポンサーリンク

バースデーカードを作ってみた

[写真] 今年の誕生日カード

先日、娘が誕生日を迎えました。

一応毎年カードみたいなものを用意していて、去年はカードの代わりに iPad で動く「誕生日アプリ」……マイクを使って息を吹きかけるとロウソクが消えるエフェクト付き……を作りました。

今年はどーしよーかなぁと思っていたんですが、なにやら最近少しだけ「ペーパークラフト」に興味を持っているようなので、ちょっとした工作をしてみることに……。

ざっと調べると、ペーパークラフトで文字が浮き出るような効果を出すために使える POPUP フォントなるものがいくつか見つかりました (Balloon Tales | Articles | Tutorial: Pop-Up LettersPop-Up Font | dafont.com)。

フォントを見てみると、専用フォントを使わなくても、ある程度線が太ければ利用できそうな感じだったので、自作してみることに。

ポイントは文字が浮き出たときに補助となる出っ張り部分。切り抜きのひな形を作るのはそれほど難しくありません。

[図] 紙半分の折り目にあたる部分に線を引く

まず、紙の半分、(印刷したときに) 折り目にあたる部分に直線を引きます。

[図] 折り目にまたがるように文字を置く

折り目をまたがるように文字を置きます。今回使ったのは Optima の Extra Bold 。個人的に気に入っているフォントで FloatyMemo のロゴにも使っています。

[図] 出っ張る長さを測る

折り目から文字の底にあたる部分の長さが、文字が浮き出てくる長さに相当します。

[図] 文字の上に出っ張り補助部を付ける

先に測った「折り目から文字底までの長さ」の分だけ文字の上に補助部をつけます。

[図] 他の文字も同じようにして補助をつける

他の文字にも同じようにして補助線を付けていきます。今回は文字を反転させています。これはカードの裏面に作ったひな形を印刷するためで、そうすることによって印刷した線が見えなくなります。

[図] 折り目になる部分

印刷した線は折り目以外は切り取ります。

  • 一番最初に引いた直線 (紙半分、カード自身の折り目にあたる)
  • 文字の底 (文字下部の折り目)
  • 文字の天で補助部と接する線 (文字上部の折り目)
  • 補助部の天 (出っ張りの折り目)

がそれぞれ折り目になります。このうち、「文字の天で補助部と接する線」以外は同じ方向に折ります。裏面に印刷するので、印刷面から見て「山折り」になって、「文字の天で補助部と接する線」だけは「谷折り」になります。

[写真] カードの裏面に印刷

少し厚手の紙に印刷します。印刷面がカードの裏面になります。

[写真] 線に沿って切っていきます

定規とカッターで丁寧に切っていきます。曲線部分はやや慎重に。折り目にあたる部分は山側になる方に軽く切れ込みを入れます。「文字の天で補助部と接する線」は表面が山側なので、そこだけは印刷面とは反対側から切り込みを入れます。

[写真] ゆっくり折っていきます

実のところ、折る作業が一番気を使うところかもしれません。写真だと分かりづらいですが、今回「T」の文字がやや失敗してしまって、横棒と縦棒のつなぎの部分が少し折れてしまいました。

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

スポンサーリンク

お疲れ……

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

スポンサーリンク

アジャイルソフトウェア開発・スクラム会議導入に対する経過観察

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~うちの会社では、ソフトウェア開発にアジャイル的な手法を取り入れています。

その一環という訳ではないのですが、半年ほど前から私のチームでは、毎朝 10 分程度の立ち会議、いわゆる「スクラム会議」を行っています。

まだ導入して半年。その効果を評価できる段階にあるのかどうかは、正直なところ分かりません。とりあえず、今のところ、うまく回っているような感じです。

スクラム会議では……

  • 前日 (前回のミーティングから) やったこと
  • 今日 (次のミーティングまでに) やること
  • 障害になっていること

参加者全員が順に報告しあいます。厳格に持ち時間を決めていませんが、一人 5 分以上話すことは非常にまれです。

私の個人的な印象では、スクラム会議のポイントは「情報の共有」にあるのではない感じがします。

もちろん、情報の共有という側面もあります。詰まっている (障害になっている) 部分を早くに把握でき、迅速なバックアップにつながる場面もあるでしょう。

ただそれよりも、やったこと・やることをアウトプットする習慣がつくようになるというのが、ポイントではないかと個人的に感じています。

「スクラム会議」という名目で、各人が「今日はこれをやります」と他の参加者に対して宣言するわけです。これは一種の強制力として働きます。

やったことを報告することで、各人に進捗度合を認識してもらう効果があります。それ自体も重要なポイントになりますが、進捗度合いを認識することで、今後の作業の見積りがより正確になるという効果が期待できます。

先にも言ったとおり、評価できる段階にあるのかはまだ分かりませんが、とりあえず、今のところ「スクラム会議」には好感触を持っています。ただし、チームサイズが大きくなっていると破綻する可能性が高いような気もしていて、そこら辺は今後の課題といったところでしょうか。

大人数になってきたら、一人当たりの持ち時間を厳格に制限したりなどの工夫が必要になってくるかもしれません。

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

スポンサーリンク

ラグビー日本代表戦 (vs ノースハーバー)

最寄のノースハーバースタジアムにて、ラグビー日本代表とニュージーランド・ノースハーバー州代表の対抗試合が行われると聞いて、見てきました。

お金を払ってラグビーの試合を見に行くのは初めて。せっかくラグビーの本場 (?) にいるので、スーパー 14 と呼ばれるプロラグビーの試合やオールブラックスの試合などは、機会があれば是非見てみたいと思っていたのですが、これまで機会を逃してしまっていました。

[写真1]

ノースハーバースタジアムは、オークランドだとイーデン・パークの方が大きいですが、ノースショアでは最大級のスタジアム。来年行われるラグビーワールドカップの会場としても使われます。

[写真2]

一階客席とグラウンドは至近距離。全体を見渡すのは若干不利ですが、迫力はあります。この日は日本代表戦の前に地元カレッジの対抗試合が前座としてありました。

[写真3]

試合の前座に和太鼓のパフォーマンス。和太鼓のパフォーマンスはこちらではそこそこ見かけます。メンバーは日本人だけじゃなかったり……というかたいてい日本人は少数だったりしますが。

[写真4]

会場で配られていた旗。日本バージョンとニュージーランドバージョンがありました。どちらもノースハーバーチームのロゴが裏にプリントされています。透けて見えるのが分かるでしょうか。

[写真5]

ラグビーの国代表は伝統的に愛称があるようです。ニュージーランド代表は言わずと知れた「オールブラックス」。オーストラリア代表は「ワラビーズ」、南アフリカ代表は「スプリングボックス」などなど。日本代表の愛称は「チェリーブロッサムス」……。

[写真6]

日本代表の対戦相手、ノースハーバー。ニュージーランドでは、オールブラックス (国代表) を頂点として、地区代表・スーパー 14 → 州代表・NPC のようなピラミッド型の階層構成になっています。州代表からの選抜メンバーで構成された地区代表、その地区代表の選抜メンバーで構成されたオールブラックスという感じ。

[写真7]

ラグビー素人の私から見ても、前半は終始ノースハーバーに圧倒されてしまっているような展開。

ラインをスルスルっとあっさりと抜けられてしまう場面が何度も見受けられました。押され気味なので、せめてキックで距離を取ろうとしたりするのですが、それもミスキックになってしまったり……。

前半、ノースハーバーは 1 トライを含めた 16 点をあげますが、一方の日本代表は 0 点。

[写真8]

前半、ほぼ唯一のチャンス。結局守りきられてしまうのですが……。

こちらは初冬。夜というのもあって、かなり冷えてこんでいます。選手の吐く息や身体から出る熱気が湯気となって見えますが、特にスクラムを組むとそれが塊のようになるので、はっきりと分かります。

[写真9]

後半の後半になってきて、遅ればせながら日本も反撃。最後の方はどうにか主導権を握るような形で 3 トライを奪います。若干エンジンがかかるのが遅くて、前半と後半始めに取られてしまった得点には届きませんでしたが、最後はなかなか盛り上がって終わりました。後味は悪くなったような気がします。

日本代表が弱いというよりもニュージーランドが強いという感じ。一時に比べ、圧倒的に強くはなくなったとも言われるニュージーランドですが、やはり日本と比べるとまだまだその力の差はかなりあるんだなぁと思いました。

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

スポンサーリンク

大前研一氏の特別講演

日本への帰省の際、Information On Demand Conference Japan 2010 に参加してきました。こういう機会は日本で働いていたときでもあまりなかったので、なかなか新鮮でした。

二日間に渡っていくつものセッションがありましたが、初日には大前研一氏による特別講演「緊急提言!新しい 10 年へ向かって、今、日本は何をなすべきか」がありました。

スライドなど一切ない講演でしたが、さすがに大前氏の話す内容は明快で、メモもとても取りやすかったので、記録として残しやすい印象がありました。

ここでは大前氏の特別講演の内容を私がまとめたものを公開します。以下の内容は、その場で取ったメモを元に私がまとめたものです。正確性に欠けると思いますが、ご了承ください。

四つの図は私が手書きしたメモをスキャナで取り込んだものです。

変わってきたお金の流れ

[図] 手書きメモその 3

「以前から『緊急提言』と何度も緊急な提言を行なってきましたが、一向に政府はやってくれません」というつかみから入る大前氏。

ここ数年で「お金の流れが変わってきた」と大前氏は言います。

300 年から 200 年前は、先進国が南の途上国を軍事で植民地化していくという、軍事力による流動でした。

50 年ほど前になると、先進国が途上国に ODA という形を使って政府レベルで資金を流動させていました。

これがここ数年で変化しています。先進国にはお金が余るようになってきました。その額は 8000 兆円に上り、これらを先進国で回して利益を得ようとしてもほとんどリターンがない状態になっています。その半数の 4000 兆円はホームレスマネーになっています。

これらの余ったお金は、先進国の株式市場を通して、中国・インド・インドネシア・トルコといった国々に流動するようになってきました。先進国もそうでしたが、まず為替が上がって、その後、株式が上がります。こうした国でもこの傾向が見えています。

先進国のお金を持った個人から途上国にある民間企業というお金が流れが人類史上初めてできています。

鍵を握る国

[図] 手書きメモその 4

大前氏が「企業参謀」(1985) を書いた頃

  • Company
  • Competition
  • Customer

という「3C」が企業のキーポイントでした。

それが「ボーダレス・ワールド」(1990) では

  • Investment
  • Information
  • Industry

という「3I」に加えて

  • Capital
  • Communication
  • Currency

の「3C」がキーポイントになっています。アメリカ GE / IBM という巨人が information だけで 5 万人雇用するという話があったりしましたが、実際インドのとあるシステム会社では SE だけで 5 万人から 7 万人いたりします。そういう時代になっています。

先の話でも出た、ブラジル・ロシア・インド・中国……これらは BRICS とよばれて非常に勢いがあります。

インドネシアもかなり勢いがあって、インドネシアでは BRICS にもう一つ「I」を加えて「BRIICS」と言ってくれと息巻いていたりします。

こうした勢いのある国は共通点があって

  • 人口が 5000 万人以上であること
  • 平均年齢が 25 〜 30 歳と「若い」国であること
  • ひとりあたり GDP が US$3,000 以上であること

インドネシアは人口 2 億 4000 万人で、平均年齢が 27 歳です。インドネシア以外にもトルコ・タイ・ベトナムといった国が該当します。

基本的には年収 US$2,500 〜 3,500 あたりの人たちが最も多く消費します。あまり世界的な景気に左右されないのが特徴で、いわゆる「消費する人々」です。

EU やアメリカと比べて日本にとって大きな優位点は、これら「消費する人々」がアジアという近隣だけでも 7 億 4000 万人、つまり日本が 7 つ分あるような規模でいるわけです。

これからの十年、こうした国々が日本が生き残っていくためのキーになっていくでしょう。

十年後の経済ランキング

[図] 手書きメモその 1

今後十年ということで、十年後の 2020 年の世界の経済ランキングを予想しています。

実は今でも世界一位の経済大国は、アメリカではなく「EU」であると明言します。「EU」は 28 カ国からなる地域統合体ですが、経済的にも法律的にも「国」と言えるだけの条件を備えているとのこと。

世界一位の地位は十年後も EU であり、それに続くのがアメリカだろうと予想しています。この順位は 2010 年も 2020 年も変わらないということです。

2010 年の時点では、それに日本が続いていますが、十年後には中国が三位に、インドが四位と続きます。中国は二十年ほど前は、九州と同程度の GDP しかありませんでしたが、今では日本と横並び、今年中にも日本を抜くと予想されています。インドは遅くとも 2025 年には為替で抜いているでしょう。

五位・六位には、インドネシア・ブラジルが入り、日本は七位になるであろうと予想しています。

日本が生き残っていくために……

[図] 手書きメモその 2

こうした今後十年の動きの中で、日本はどのように立ち振舞っていくべきか。最大のネックとなるのは「人材」であろうと大前氏は指摘します。

輸入して調達することのできる「モノ」ではなく、現地の内需に応えることができる人材の有無が勝負になります。

日本経済 7 つ分もある市場の内需に応えることができれば、今までと同じ「いい商品をより安く!」という形のビジネスでいけるわけです。

日本が得意とするのはインフラ作りで、品質などでは他国を圧倒しています。ところが、個々の連携がバラバラで柔軟性にも欠けています。日本はトータルなサービスとしてこれらを提供するのが苦手です。新幹線もそれで負けています。

新幹線のダイヤは他国では真似できないほど、高度な運用ノウハウ BOT (Build-Operate-Transfer) もあります。ただし、トータルでパッケージする指導者・会社がないとダメです。トータルで勝つことが必要になってきます。

国民 DB とクラウドコンピューティングで全国規模のインフラを構築し、住民サービスをブラウザから行えるようなシステムを作り上げれば、システム会社はまだまだいけます。

日本 7 つ分の市場を求め、アジアに出る勇気が必要です。人材づくりには二十年かかります。今すぐ取り掛かる必要があります。

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

スポンサーリンク

Lumix LX3 を購入しました

[写真] 購入した Lumix DMC-LX3 の正面。

Lumix DMC-LX3 を購入しました。

これまでデジタルカメラは Finepix S9100 (→FinePix S9100 インプレッション) と IXY DIGITAL 30a を使い分けていました。

  • 手軽に持ち出せるコンパクトな機種 → IXY 30a
  • 本格的に撮りたいときの多機能・高機能な機種 → S9100

FinePix J20

しばらくこの二台体制だったのですが、一年ほど前から IXY 30a が不調で、昨年台北に出張した折に FinePix J20 という機種を購入して使っています。

FinePix J20 は

  • 小さくて持ち運びやすい
  • お手頃価格

を最重視して選んだ結果です。

出張中だったため、スペックを調べる時間があまりなく、スペックを意識しないで、店頭で値段と大きさを確認して購入しました。

1/2.3 型 1000万画素 CCD (ハニカムではない) という若干余裕のない素子で、レンズも IXY 30a よりも暗いせいか、画素数では優っていても実際の解像感は IXY 30a の方が優れている印象があります。

しかしながら、IXY 30a より薄くて、かなり軽いので、機動力は抜群です。手軽に持ち運んでサッと撮りたいという要望に充分に応えてくれています。

FinePix S9100 の不具合

一方、多機能な機種として使っている FinePix S9100 は、ある不具合を除いて順調です。というのも……

[写真] FinePix S9100 の勇姿

落としてしまって……大した高さではなかったのですが……打ちどころが悪かったらしく、背面液晶が映らなくなってしまいました。

幸いなことに FinePix S9100 は電子ビューファインダー (EVF) なので、撮影した写真の確認もファインダーで行うことができます。折角のマルチアングルが利用できないというのを除けば、とりあえず普通に利用することはできます。

新機種選定

それでもやはり不便に感じる場面もあるので、新しいデジタルカメラは機会があれば欲しいなぁとは思っていました。そんな折、「3万円ぐらいであれば、買ってもいいよ。ただし落とさないこと前提で!」との了解を得たので、早速調査することに……。

条件としては、

  • 3 万円程度
  • 明るいレンズ
  • 広角 (35mm判換算で28mm以下)
  • FinePix S9100 よりも小さく軽いもの

になります。

一眼レフにも興味はあるので、予算に収まる一眼レフも少し探してみました。中古なども見ると予算に収まるものはあるんですが、他の条件「レンズや本体サイズ」を考慮するとかなり厳しくなります。時間的にもそれほど余裕があったわけではないので、今回も一眼レフは見送り。

そんな中、まず候補に挙がったのが、発表当初から気になっていた PowerShot S90 でした。

広角側で F2.0 という明るいレンズを搭載しているのも大きなポイントですが、前面レンズ周りのリング上の操作部「コントローラーリング」が使いやすそうです。FinePix S9100 の手動ズーム操作にすっかり慣れているので、コントローラリングをステップズームの操作に割り当てることで、同様な操作を継承できることが期待できます 。

PowerShot S90 (以下、S90) の価格を調べてみたら、Amazon にて 3 万円程度で購入できる様子だったので、第一候補としてほぼ決まりました。

S90 を第一候補として挙げた時、対立候補として挙がってきたのが、Lumix DMC-LX3 (以下、LX3) です。

LX3 vs. S90

機種名 Lumix DMC-LX3 PowerShot S90
映像素子 1/1.6型 CCD 1130万画素 (3.4) 1/1.7型 CCD 1040万画素 (3.3)
レンズ 2.5倍 [24 - 60mm] (F2.0 - F2.8) 3.8倍 [28 - 105mm] (F2.0 - F4.9)
手ぶれ防止 レンズシフト式 センサーシフト式
撮影感度 ISO80 - 3200 (モードにより最大 ISO6400 まで増感可能) ISO80 - 3200 (モードにより最大 ISO12800 まで増感可能)
撮影可能範囲 50cm - ∞ (マクロ [W]1cm - [T]30cm -) 50cm - ∞ (マクロ [W]5cm - [T]30cm -)
大きさ/重さ 108.7 x 59.5 x 27.1 (48.0) / 265g 100.0 x 58.4 x 30.9 / 198g
公称撮影可能枚数 380 約220枚
実売価格 \34,525 - \68,595 \29,800 - \45,800
備考 顔検出機能
内蔵メモリ50MB
顔検出機能
レンズバリアあり

実売価格は価格.comの 2010 年 5 月上旬時点での価格帯を示しています。

スペックだけ見ると大きさはあまり変わらないような感じですが、これは「突起部除く」大きさで、LX3 ではレンズ部分の「突起」が大きく、実質的には 48.0mm が厚み (レンズキャップ利用時) となります。

ですので、LX3 は S90 よりひと回り大きくて重いカメラと言えそうです。機動力では S90 に分がありそう。

映像素子は画素数・大きさが微妙に異なりますが、ほとんど差はないと言ってよいでしょう。

どちらも広角端が F2.0 から始まる明るいレンズで、LX3 は 35mm 判換算で 24mm からと広角側が強くなっています。S90 は 28 - 105mm で LX3 と比べると望遠側が強くなっています。S90 は 28mm F2.0 なので、S90 の方が (同じ焦点距離での比較した場合) 微妙に明るいとも言えます。

S90 で気になったのは、コントローラーリング以外の部分の操作性で、ウェブ上で見る限り、あまりいい評価が見られませんでした (ただ、他の人が言うほど気にならないという人もいました)。私が店頭で触れていた限り、特に問題なさそうな印象ではありましたけれども……。バッテリーの持ちも LX3 と比較すると分が悪いです。

LX3 の価格は Amazon で 5 万円弱。価格.com での最安値でも 35,000 円程度します。予算に収めるのは厳しそうで、候補としたものの、購入は厳しいだろうなと思っていました。

邂逅

S90 を購入するつもりで、秋葉原を散策していたんですが、S90 の店頭での価格が案外高くて、そのままでは予算内に収まりそうにありません。価格交渉もするつもりでしたが、時間も若干押していたので「帰って Amazon で買うか……」と思いながら、寄ったソフマップで見つけたのが中古の LX3 でした。

純正の本革ケースも付いて、予算に収まる値段で何気に置いてありました。

店員さん *1 に聞いてみたところ、日本で発売されていたバージョンではないようで、ユーザーインタフェースに日本語が表示できないとのこと。

[*1] 日本人店員が接客中で、スパニッシュの店員さんが相手をしてくれました。さすがに世界中から観光客がやってくる秋葉原、少し大きめな店になると、中国語・英語……二ヶ国語以上話せる店員が常駐している様子でした。

個人的には英語のインタフェースでも問題ありません。日本語マニュアルはとりあえずウェブサイトからダウンロードできるでしょうし……。

LX3 は発売から二年近く経っていても、あまり値崩れしていません (最も噂されている後継機種が出たら分かりませんが……)。中古ではありますが、純正本革ケース付き、おまけで SD カードも付けてもらうことにして……。しばらく店頭で悩みましたが、購入することにしました。

純正本革ケース

純正の本革ケースは「速写ケース」と呼ばれるスタイルのもので、前面をカバーする上部と両サイドをカバーする下部に分かれていて、ケースから取り出すという動作ではなく、ケースの上部を外すという動作で撮影体制に入れます。

[写真] 純正本革ケースをつけた LX3

ケース下部は三脚穴でしっかりと固定するようになっているので、通常の使用で勝手に外れるということはありません。ただし、バッテリー・SD カードの取り出し、PC への USB 接続時には、ケース下部を都度外す必要があります。

ケースを付けることで、本体がひと回り大きくなってしまいますが、最低でも本体底部をカバーしてくれているという安心感があります。また、厚みも若干増すので、ホールドしやすくもなる感じがします。

インプレッション

発売から二年近く経っている機種なので、今更感はありますけれども……。

初めての Lumix だからなのか、操作についてはまだ完全に慣れていません。特に癖のある操作性という訳ではありませんので、基本的な操作にはすぐ慣れました。ボタンの数などは FinePix S9100 に負けず劣らず多い印象ですが、分かりやすく配置されていると思います。

個人的な感覚では LX3 は FinePix S9100 よりも多機能です。一部の機能は、それを利用するためにどのような操作が必要か、が分かりづらくなっているものもあります。異なる画面比をワンショットでまとめて撮れるという「マルチアスペクト」という機能がありますが、これを利用するための操作手順を説明書なしにぱっとできる人は少ないような気がします。

例に挙げたマルチアスペクトは普段使いするような機能ではないため、多少分かりづらくても問題ありません。ただ、この手の操作が多少「取っ付きにくさ」に繋がっているという印象を受けました。

今ひとつの評判のレンズキャップですが、FinePix S9100 でも同様にレンズキャップを都度外す必要があるので、あまり気にならなくなりました。FinePix S9100 と違ってレンズガードを付けていないのがやや不安なぐらいです。

若干ネガティブな面ばかり触れましたが、撮っていて楽しいカメラであることは間違いありません。

何よりも 16:9 という画面比が新鮮です。35mm 判換算 24mm という画角は 16:9 でより強調されるような印象があります。背面液晶画面が 3:2 の比率なので、当初は 3:2 で撮っていましたが、広さが強調される 16:9 が気に入ってからは、もっぱら 16:9 ばかりで撮っています。

ウェブログ用写真に向いているといわれる 1:1 の画面比もなかなか新鮮です。トリミングすれば同じなんですが、やはりその画面比を実際に確認しながら撮る方がはるかに直感的です。

作例

稚拙ではありますが、私が撮った写真をいくつか紹介します。以下の写真は全て Fireworks でリサイズ・ドロップシャドウの付加という加工を行い、JPG / 80% クオリティで書き出しを行っています。

それぞれオリジナル画像にリンクしています。[] の情報は先頭から、シャッタースピード・絞り・感度・35mm 判換算での焦点距離・ファイルサイズになっています。

[写真] 作例1

LX3 はかなり豊富なシーンモードが用意されています。「サンドブラスト」はその中のひとつ。雰囲気のあるモノクロ写真が撮れます。[1/500s f/4.0 ISO1600 24mm 806KB]

[写真] 作例2

ディズニーランドのエレクトリカルパレード。シャッタースピード優先であえてシャッタースピードを落として撮影。[0.8s f/3.5 ISO80 24mm 2.5MB]

[写真] 作例3

こちらは会社からの帰り道、「夜景」モードで撮影したもの。この写真はあまりノイズが目立たちませんが、ISO800 だと FinePix S9100 よりも若干ノイズが乗るような印象があります。[1/15s f/2.0 ISO800 24mm 2.1MB]

[写真] 作例4

マクロモードで接写。FinePix S9100 同様、1 cm まで寄れるマクロはいい感じ。LX3 の方が広角で絞りも F2.0 までいけるので、遠近感がよりはっきりと……。[1/25s f/2.0 ISO400 24mm 1.9MB]

まとめ

長々と書いてしまいましたが、まとめると「Lumix LX3 楽しいし、うちの猫はかぁいい」ということです。

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

スポンサーリンク

丸丸丸

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

スポンサーリンク

お小遣い

ログを見直していたら、結婚した折に「お小遣い制」になったと書いてありました。

お小遣い!

おぉ、なんか懐かしい。そう言えば、もらっていました、お小遣い。

ニュージーランドに来てからなんか自然消滅的にもらわなくなった気がするんですが、どうだったかな。

[追記 : 2009.04.18]

こらこらこら、お小遣いなくて生きていけるんかい(汗汗

by がん / コメント欄より

想像していたよりも困ってないです。

そもそもニュージーランドでは現金を持ち歩かないというのも大きいかも。

今はたまたま 10 ドル程度手元にありますが、普段はお札どころか小銭もほとんど持ち歩きません。

たまに嫁さんに「今小銭ある?」って聞かれる時もあるんですが、大抵役に立たない>自分。

お小遣いとしてはもらっていませんが、間食用のお菓子とかはその都度必要に応じて適当に買ったりしています。

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

スポンサーリンク

ちょいメモ 2009.04.09

イースター連休

明日からイースター連休になります。

イースター連休の始まりは例年都市部から出て行く方面が渋滞するのですが、今年は学校ホリデー開始と重なってやや早めに渋滞が始まるようです。

と言っても日本の渋滞ほどの激しさはありませんけれども。

イースターエッグ

職場でイースターエッグ (チョコレート) をもらいました。

ラップトップの横に置いていたら、ラップトップからの熱でいつの間にかゆるゆるになってました。危ない、危ない。

Serene Bach 3 開発進捗

Serene Bach 2 からデータ変換ツールの Ajax 部分を思案中です。

基本的には Serene Bach 2 同様、再構築の Ajax 部分をそのまま再利用するのですが、JavaScript を共有して利用するか、継承して利用するかで少し悩みました。

現在、継承はしないで、同じオブジェクトを共有して利用する方向で実装しています。

継承も検討した名残 (?) で JavaScript で継承を行なう関数 extend も追加しています→JavaScript継承パターンまとめ

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

スポンサーリンク

1/3