無料ブログはココログ

« 2011年9月 | トップページ | 2011年11月 »

[#TiDD] チケット駆動開発で自律的な組織を目指す

自律的な組織とはリーンソフトウェア開発で「海兵隊」で示されたような、自己決定のための裁量権を持っていて、課題や問題を自らの判断で解決できる組織です。集中体制は変化に弱く、想定外の事象によって独裁国家の様に一気に崩壊する危険性をはらんでいます。これに対して自律的組織は、オブジェクト指向のメタファに用いられる多くの細胞の組み合わせからなる生命体のような構造です。各細胞に対する攻撃は、各細胞やその近隣の細胞で解決されますので、想定外の事象にも比較的強い構造といえます。

自律的組織を実現するには自己決定権を実現するための見積もり技術が不可欠ですが、ここでは単に裁量権の観点で議論してみます。

1.アジャイル開発における自律的な組織

アジャイル開発においては、開発組織とユーザとの間で、優先順位したがって各イテレーションのスコープが決定され、開発組織の裁量で開発作業のタスクが実施されていきます。タスクはタスクボードで可視化され、状況と課題が共有され、開発者たちの決定をコミットすることで開発が実施されます。

注目すべきは、アジャイル開発のプロセスとして決められているルールの中に自己決定のための裁量権が明示されていることで、自律的な組織を実現している事です。

2.従来法における自律的な大規模組織

アジャイル開発によって実現される自律的組織ですが、従来型、いわゆるウォーターフォール開発においても自律的な組織が構成されることがあります。それは開発対象が複数のサブシステムに分割されて、それぞれのチームに裁量権が与えられている場合です。各チームにおいて、課題や問題を自らの判断で解決することができます。

しかし、従来型の開発においてはその裁量権の多くをリーダーが独占しています。他のチームに対してのみ自律的であり、開発者はチーム内の状況をリアルタイムに知ることができず、問題や課題の解決を検討することすらできません。

3.自律的な小規模チーム

小規模なチームの場合は、従来法による開発であっても、ある程度は自律的な開発を行うことができます。大規模開発において、自律的な開発の最も大きな障害は、最新の状況をリアルタイムに知ることができないことです。状況を知らなければ、その解決ができないからです。

小機御組織においては、全員の状況を互いに知ることが可能です。日々の打ち合わせにおいて、(1)コミュニケーションを活発にして状況を共有する、(2)その解決策をチームで検討する、(3)協力して解決する、という状況を作り出せれば、チームは自律的な開発を行えるようになるでしょう。

しかし、その状況を作り出すには、リーダがあまり口を出さないこと、開発者の技術力とコミュニケーション能力の高いことが求められます。また、会議は口頭で行われますので、時間がかかること、声の大きい人が勝ってしまう危険性のあること、に注意が必要です。

4.チケット駆動開発による自律的な開発

チケット駆動開発においては、2種類の自律性があります。タスクはチケット化され、個人の作業管理に役立つ粒度にまで分割され、開発者によって担当チケットが自律的に管理されています。また、チームの課題や問題もチケットを介して共有されますので、アジャイル開発はもちろんのこと、従来法においてもリーダの運営次第でより自律的な組織運営が可能です。

チケット駆動開発で得られる自律性は、リーダの権限を委譲して開発者に裁量権を与えていることに注意する必要があります。開発者は、リーダの指示に従うだけではなく、同じゴールに向かって協力し合う必要があります。

自律的な組織では「アジャイルと規律」で言われてるように、開発者には高度な技術者が求められます。少なくとも状況を把握して判断できる能力が必要であるからです。また、互いに協力して作業するには、ある特定の技術ができる専門工ではなく、一通りの作業のできる多能工であるほうが、作業を柔軟に割り当てられるので有利です。

5.まとめ

このように自律的な組織を実現するには、ルールの中に自律的に計画変更する要素が含まれるアジャイル開発がが有利です。しかし、小規模な開発であれば自律的な開発を進めることもある程度可能ですし、チケット駆動開発においてはより有利になります。もし可能であるならアジャイル開発を、そうでなければチケット駆動開発を検討してみる価値があると思います。

自律的なチームを構築できたなら、開発者の能力を最大限に引き出せる可能性があります。チケット駆動開発は自律的な組織に必要となるリアルタイムの情報共有を可能にし、プロジェクトを支援します。その適用可能な分野は広く、様々なプロジェクトがあるでしょう。

ソフトウェア開発を成功させる秘訣は、そのプロジェクトにふさわしいプロセスを実現することです。チケット駆動開発には多くのバリエーションがありますので、多くのプロジェクトに役立つ可能性があります。今後、どのようなテーラリング(カスタマイズ)が可能であるか、整理していきたいと思います。

レビューを考える - SEA関西プロセス分科会 - #seakansai

森崎先生のレビューの講演に参加しました。
個人的には@ITの記事のようなことを期待していたのですが、そのような記事ではわからない議論をすることができてとても有用な講演でした。

議論を通じて感じたことは以下の点です。

(a) 開発者は項目の抜けに敏感

 実践していなくても頭の中がWモデルになっているのかもしれません。テスト項目の源泉を仕様書に求めるので、どうしても項目の抜けが気になるのでしょう。

(b) レビューに優先順位をつける

 優先順位というとリスクベーステストを思い浮かべてしまい、全てをしないでどうするのかと思われるかもしえません。しかし、極限までレビューすることは困難で、時間の制約や体力の限界で終わってしまうので、優先順にレビューのフォーカスを変えていくことが有効だと思いました。

(c) レビュー道の極意は、レビューをせずにバグをとる

 私が勝手にN先生のフロントローディングの話をまねました。すべてをレビューできなければ、その対象を減らすために、ドキュメントのひな型を用意する、ワープロの文章チェック機能を使う、エディタの自動整形機能を使う、静的解析ツールを利用するなど、効率化や自動化は有効でしょう。

(d) レビュー技術の研鑽には経験を積むことも重要

 ドメイン知識がソースコードになっていることから、コードを良く知っているというのも、抽象化できる人なら高度な技術者なのだろうと思います。理由もなく、これまでそうしていたからというのは統一性には役立ちますが、将来役に立たなくなるでしょう。

(e) レビューの特性を生かせ

 テストで見つかると工数がかかるからということがレビューのモチベーションになっていますが、それだとどれだけ時間をかけても良いことになってしまいます。しかし、欠陥の種類によってはテストの方が早く見つかるものも少なくないでしょう。懇親会ではテストは積み上げという議論があり、それからするとレビューの特徴はトップダウンです。レビューに向いているトップダウンでしかわからない所を攻めるべきでしょう。ボトムの細かなところは、なるべくほかの手段で済ませたいですね(それには(c)が有効でしょう)。

つらつらと書きましたが、このようなことを考える良いきっかけになりました。

[#TiDD] デジタル化の効果をファシリテーションに利用する

第2回RxTstudyの講演ではお話しできませんでしたが、コーチングについて少し触れたいと思います。
コーチングに関しては、以前「チケット駆動開発とコーチング」でも少し触れていますが、コーチングは性格を変えるものではなく、それぞれのタイプにあった対応をするそうです。たとえば、スライド中の性格の分類で一番気の弱いアナライザなら、直接お話しするよりもメールでやり取りをするようです。

このことは、デジタル化の特長を利用したものだと思います。デジタルはアナログと違って1か0です。同じ文章であるなら積極的な人も消極的な人も受け取る人の印象は同じになうからです。また、口に出しては言えなくても、文章でなら言いやすいというのもあるでしょう。

掲示板やTwitterなどで強気の発言や毒のある発言をする人に、実際に会っってみると意外と優しい感じの人だったという経験をされた方も多いと思います。それは、このようなデジタル化の効果だと思います。

さて、プロジェクトファシリテーションの目的は、メンバーの能力を最大限に発揮させることです。ファシリテーションの能力が求められる立場の人は、口頭でモチベーションを高めたり、説明する機会も多いでしょう。そこで、ファシリテーションを勉強すると、自分には出来そうもないことも中にはあると思います。それは本当にできる様にならないといけないかというと、必ずしもそうでないと思っています。

「メンバーの能力を最大限に発揮させる」といった時、そのメンバーは誰なのかと考えると、そこにはリーダーも含んで良いと思います。もちろん、最低限のことはできなければいけないとは思いますが、自分の個性を知って、できないところは、デジタル化の力や他の人(メンバーや上司など)の力をうまく使えば良いと思います。

もちろん、メンバーの中にはリーダーはこうあるべきというイメージで評価する人もいるでしょう。プロジェクトを成功させるには、その様な人の能力、リーダー本人の能力、全て含めて最大の能力が発揮できるようにすることが大切なのだと思います。

そして、そのような考慮は、プロジェクトの特性やメンバー構成を考慮して配員する際にも有効だと思います。

[#TiDD] アダプタブル・ウォーターフォール開発の事例 ~想定外の作業はチケットで補完せよ!~ #RxTstudy

第2回 RxTstudy(Redmineやタスク管理を考える勉強会@大阪)で講演をしてきました。

これまで、補完型チケット駆動開発と呼んでいたもののうち、従来型の開発に提要したものをアダプタブル・ウォーターフォール開発と呼んでいます。今回はその事例を紹介します。

講演で少ししかお話しできなかったコーチングのお話は、別の記事に書きました。

要求開発はアジャイルのフロントローディング #redajp

要求開発アライアンス 西日本10月勉強会に参加しました。

これまで、XPJUG関西のMLなどで名前は知っていたもののよく理解していませんでした。今回はチュートリアル編と言うことでお勉強のために参加しました。

まずは稲田さんの概要説明です。感想を交えながら主要なキーワードを説明されました。後半は「要求開発~価値ある要求を導き出すプロセスとモデリング」の共著者の萩本が、要求開発への思いを要求開発、そして匠メソッドに至った経緯を含めて説明されました。

1.全体の感想

最も印象的だったのは

「開発時にモデリングしていては遅すぎる」

と言う言葉でした。アジャイル開発では、顧客に価値を提供するために優先度の高い仕様から実現しますが、要求開発はバックログとして仕様を具体化する前にも、IT技術者が関わって価値の高い者を提供しようというものです。いわば、アジャイル開発のフロントローディングです。

このことが実現できるなら、仕様をあらかじめ決めざるを得ない、アジャイル開発の効果が少ない場面でも有効だと思いました。スコープが変更できない場面でアジャイルは、段階的に開発することで、技術的に未知な部分やUXのリスクを低減できるものの、価値を想像するという感覚は生まれません。そのような開発においても、IT技術者が要件定義の最初から関与することで、戦力的な価値を提供可能な要求を開発することができると思います。

2.要求開発が提供するもの

要求開発は、必要な事と、選択して整備する仕組みを提供します。

その基本は、こたつモデルと呼ばれるもので、戦略的(将来の価値)、業務問題解決(現在の価値)、技術活用の視点、この3つでこたつを囲むように進めていきます。価値、戦略、業務、IT活用、IT実現、に分けて、それらをつなげて、同時並行に回します。早くつなげて価値を創造するのです。戦略と実現の線上にしか価値は存在しないのです。

これらはWHATとHOWの関係です。実装(HOW)に対する要求(WHAT)のように、要求(HOW)に対する業務(WHAT)、業務(HOW)に対する戦略(WHAT)という関係です。これらを、トップダウンに決めるというよりは、HOWを手さぐりしながら開発していきます。そこでは、ものを作る力ではなく、描く力(価値・要求を手さぐりでデザインする)が重要です。要求開発で用いる「プロジェクトシート」は将来の価値と短期的視野で表します。

要求開発で実施することは、フェーズ(準備、立案、デザイン、シフト)とPDCAのマトリックスで表され、「プロセスキャビネット」と呼ばれます。これらは選択的に実施されるのですが、プロセスセルという枠組みがあり、必要と思われるものを組み合わせてプロセスフローを実現します。稲田さんは、この仕組みを「詳細に走らないように用いています」とのことでした。

3.要求開発への思い

要求開発は、萩本さんをはじめとする、今世紀の初めの頃の豆蔵の方達が提唱されました(豆蔵は、オブジェクト指向、RUP、アジャイル開発などで有名な会社です)。ビジネスの開発方法論の必要性から、BDA(ビジネス・ドリブン・アーキテクチャ)、そして要求開発の方法論に発展したそうです。要求開発はカスタマイズ可能で、目的と手段を連鎖させ、プロセスセルはPDCAの慣習化として実現され、無駄なものを作らない方法です。そこには、分析モデルを開発で作るのはおかしい、という思いがあったようです。

要求開発では価値のあるものをつくります。要求開発の4象限はRUPと同じで、HOWはWHATに、つまり価値の高いものを作るためにITエンジニアが手さぐりの協力をします。システム開発以降でIT技術者が協力してももう遅いのです。業務を変えないといけないので、開発はビジネスのところでします。ビジネスの中でアジャイルするのです。

ビジネス戦略を決める際に予想することはは難しいです。やっていないとわからないところがあるので、それをアジャイルでやってみます。そのために、「こたつモデル」は重要で、知識のカスケードをするためにこたつを実現します。ただ、立場の違う人が集まるだけでは空中戦になりがちで、声の大きいものが勝ってします。そこで、ファシリテーションとマネジメントが重要になってきます。

このような萩本さんのお話を聞いて、なぜXPJUG関西の人たちが注目しているかがわかったような気がしました。

4.まとめ

ソフトウェア開発は、単純なウォーターフォールモデルで実現できるような簡単なものではなく、自分たちの能力とその限界を知った上で最高のパフォーマンスを実現しなければうまくいきません。そのための一つの答えがアジャイル開発であったのです。しかし、システム開発を最初からアジャイル開発だけで実現できないので、従来のV字モデル(あるいはW字モデル)の実装部分だけを、アジャイル開発に置き換えている会社も多いでしょう。でも、それではだめだったのです。

価値の高いソフトウェアを開発するには、要求は定義するだけではだめで、開発しないといけないということなのです。要求開発は、いわば「アジャイル開発のフロントローディング」だったのです。

(聞きかじりを個人的な思いでまとめました。間違い等ありましたらご指摘ください)


アジャイルを考える - Agile Tour Osaka 2011 -

去年は自宅で見ていたAgile Tour Osaka 2011ですが、今年はLTに出番がいただけたので朝から参加しました。講演を聞く中で、多くの刺激をいただくことができました。

1.インパクトのあった言葉

アジャイルを標榜しながらもチケット駆動開発で現場を改善しようとしている私にとって、最もインパクトのあった言葉は、

アジャイル開発ができない理由として「制約」と言われるものは「解決すべき妨害事項」

「守破離」と言われるが、「守」をせずに「破」をしてしまう

という@ryuzeeさんのお話でした。@ryuzeeさんのほか@smorisaki先生のお話にあったように、何かをするには説明責任が伴いますし、何かをせずにおくことも

変化しなければ緩やかに滅びる、という背任!(@ryuzeeさん)

であるなら、安易にプロジェクトを進めるのではなく、解決すべき妨害事項が現時点においては制約であることを説明する必要があると思いました。

2.アジャイル開発導入への妨害リスト

私から見えている「妨害リスト」は以下のようなものだと思います。

契約
まずはこれでしょう。準委任でなく一括請負になる場合には、減価償却したいという場合があって、ちょっと厄介です。また、藤井さんの講演にあったように、信頼関係を築かないと始まりません。

多能工を増やせない
複雑で先進的なシステムの場合、すべてを把握・実現できる多能工ではなく、専門工になりがちです。いずれは多能工化したくとも、新しい技術を順次取り入れたり、新しい人が入るような状況だと、実現が困難になります。

システムの並行開発
連携する複数システムを並行して開発する場合など、あらかじめインタフェースを決めて開発します。インタフェース汎用的でない場合などは仕様が限定されてしまい、段階的にリリースする場合も、スコープの変更ではなくリスク低減が目的とされます。

危機感の共有
実は、組織やチーム内の合意形成が最も困難ではないかと思っています。様々なステークホルダーのいる中で、プロジェクトの目標は、価値、利益、信頼性、QOLなど様々ありますので、プロジェクトの問題点が共有でき、解決法としての合意が必要になります。

それぞれ程度の問題で、簡単な問題や長期的に効果が見込める問題であれば解決すべきでしょう。

しかし、現実を見ると目の前にはプロジェクトがありそこで求められていることは、アジャイルを実践することだけではありません。すぐに求められていることは、アジャイルを実践した先にあることなのだと思います。

2.アジャイル開発導入をあきらめてみる

アジャイルを一旦あきらめて、すぐに解決したい問題の観点で、各講演を見直すと、以下のような項目があがります。

任せること(設楽さん)
そのために細分化、見える化、自動化する。見える化は変化を検出可能にすること。チケットをうまく使えばできそうです。

説明すること(森崎先生)
事例とシミュレーションを組み合わせて説明する(Exsample scenario)。全てを実績で説明することが困難な場合、過去の実績と未来の予測を組み合わせて利用する方法です。メトリクスサーバをうまく利用できそうです。

見積もりと計画(藤井さん)
処理されるデータを中心に見積もるCOSMIC法は興味深いと思いました。ファンクションポイント法も表面的な機能だけでなく、内部のデータも見積もりに加える事例もあるようですので、分野によっては効果的だと思います。また、ベーム先生のアンカー留めスパイラルモデル(1994)は、マイルストーンをしっかり決めて守る事なのだと思います。この他にも、アジャイルUP、AMDD、southernSCOPEといったキーワードは参考になると思います。

自己組織化(吉羽さん)
トップダウンの外科医チームのような組織は、構造化プログラミングされた巨大なプログラムだと思いました。頑張れば何とかなるかもしれませんが、外乱に強い安定した組織にするには、オブジェクトの能力が発揮できる自律分散型の組織が必要だと思いました。

これらは、成功したアジャイルにより得られるものではありますが、危機感の共有と工夫によってある程度実現できるのではないかと思っています。そして効率化していけば、その先にアジャイル開発に近いものが見えてくるのではないかと思っています。

謝辞

このように多くの刺激をいただけたAgile Tour Osaka 2011のスタッフのみなさま、発表者の皆様に感謝いたします。

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


[#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011

Agile Tour Osaka 2011でライトニイングトークをさせていただきました。当日になって修正したり、説明を追加してしまい。3分の2ほどしかお話しできませんでした。せっかくスライドを作りましたので公開します。

「チケット駆動開発によるアダプタブル・ウォータフォール開発」というタイトルで、ウォータフォール開発には難しいことがあるけど、チケット駆動開発を導入するとアジャイルの良さを取り入れることができるというお話です。アダプタブルというのは、アジャイル開発の名称の候補であった(参考アジャイルマニフェスト10周年 - アジャイルマニフェストはどう生まれたのか<kawaguti の日記>)アダプティブを参考に、これまで従来型開発における補完型チケット駆動開発と呼んでいたものに命名しましたです。当初、アダプティブにしようかとも思ったのですが、あらかじめ変更のための仕組みを入れておくのではなく、必要に応じて変更の仕組みを入れることが可能であることから、アダプタブルとしました。

まだまだ整理しないといけないこともありますので、これから徐々にやっていこうと思います。


Jenkinsの特長 - メトリクス収集サーバの視点から -

第1回大阪Jenkins勉強会に参加してきました。これまでXP祭り関西でHudsnの運用のお話を聞いたことがありましたが、直接動作を見ながらの説明で良くわかりました。以下、自分なりのまとめと、メトリクス収集サーバの観点からの感想です。

Jenkinsまとめ

JenkinsはHudsonをルーツとするCI(継続的統合)ツールです。ソフトウェア開発を進める中で、以外とはまりやすいのがソフトウェアの結合です。インタフェースを決めて開発をしていたのに動かない、この前まで動いていたのに動かなくなった、担当者がいないとビルドできない、といったことは、笑い話になるほどありがちです。

CIツールを用いると、ソフトウェアのビルド、デプロイ、テストを常に実行する環境を構築できます。ここでいう「常に」というのは

・必要なときに画面あるいはコマンドラインから
・リポジトリにコミットしたとき
・定期的にリポジトリをポーリング(チェック)して更新があったとき

です。Subversionを用いたJavaの開発で使われることが多いようですが、勉強会の時点で427(どこかの薬局のCMを思い出しますね)ものプラグインによって、様々な言語や環境と連携することができます。もちろん、シェルスクリブト等を介して外部のコマンドと連携することもできます。

上述の起動タイミングのうち、ポーリングによる方式だと、頻繁に更新されるリポジトリでの実行負荷を下げることができますし、さらに複数のJenkinsで連携することもできるそうなので、大規模な開発にも対応できるようです。

そしてJenkinsで忘れてならないのはインストールが容易なことです。コマンドラインでたった1行実行するだけで、インストールができます。プラグインの設定やプロジェクトの設定もインストール時に構築されるWebの画面から簡単にできます。勉強会のLTではHudsonからJenkinsへのアップグレードも非常に容易であることが、開発者の川口さん自身による動画で紹介されました。

メトリクス収集サーバの視点から

ソフトウェア工学の世界では、当初からメトリクスの重要性が語られ、多くのメトリクスが提唱され、実証されてきました。それぞれのメトリクスには有用な場面があるものの、その収集のための負担の大きいことから、コード行数以外はあまり活用されてきませんでした。

そこで、開発者に負担を与えないように、リポジトリからこっそりとメトリクスを収集する方法がとられるようになりました。私もEPM(PDF)というメトリクス収集環境の開発にかかわりました。しかし、その開発は、とても大変でした。

メトリクス収集環境で最も大変なのは、サーバの構築とツールのインストールです。1日1回メトリクスを収集するには、ツールのインストールはもちろんのこと、関連ライブラリWebサーバやコンテナのインストール、アカウントやcronの設定が必要です。このあたりになるとインストールできる人が限られてきますので、簡易なインストーラの開発や、OSの仮想イメージでの提供までしていました。

しかし、Jenkinsを用いたならツールの開発だけで済みますし、基本的なメトリクスならプラグインもあるでしょう。開発者に負担を与えることなくメトリクスを収集できるので、めったに役に立たないメトリクスであっても、あらかじめ収集しておくといったことも可能になるでしょう。

勉強会でもメトリクス収集の話がありました。メトリクスの収集だけであれば品質保向上にはなりませんが、作業やプロダクトの状況確認や、異常の早期発見には大いに役立つでしょう。

このように、Jenkinsのソフトウェア工学への活用には、大いに期待しています。



iPod/iPhone用 FMラジオ付目覚ましスピーカー PSP-BQB

これまで自宅でiPhoneの音楽を聴くときはBOSE Companion2というPCsぴーかで聞いていました。これがPC用と思えないくらい低音が効いていて良い音が出るので、特に不満もなかったのですが他に流用したくなったのでPhone用のスピーカを探すことにしました。コストパフォーマンスで言うとBOSE Companion2しかないのですが、予算の問題と最近目覚まし時計が壊れたこともあって、目覚まし兼用の小型スピーカーを探しました。

たまたま近くの電気店でセール押していたので、いろいろ検討していたのですが、最近はかつてのように簡単に聞き比べができないのですね。スピーカーの切り替えスイッチはあるものの、音源がつながっていないのです。仕様だけを比較して買おうかとも思いましたが、安いスピーカで良い音が出ることの方が珍しいので、やはり視聴して買いたい

。そこで、店員さんに視聴できないか聞いてみると「どちらですか?」「オーディオプレーヤーはお持ちですか?」とか言われます。どうも客の音源をつなぎなおしながら視聴させる仕組みのようです。「色々聞きたいのですが」というと「それぞれ繋ぎなおすので面倒なんですよね」とスピーカ切り替えスイッチの配線が信用できないようなそぶり。「一応、客なんだけど」と思いつつ、まあ、5,000円ぐらいのものに「手間もかけられないよな」と思い直し、勝手につなげてよいか聞いてみました。

Win-Winの関係が成り立ったようで、すんなりOKとのこと。許可が出ればこっちのものです。接点が汚れないか気にしつつ、iPhoneを準につないでみました。BOSE の高級機が良い音なのはもちろんのこと、BOSE Companion2はやはりコストパフォーマンスが優れています。そして残念ですが、やっぱり安い機種は音に厚みがなくカサカサ言うような感じです。低音が出ないだけでなく、iPhoneそのままので十分とおもえるほど安っぽいバランスの悪い音でした。

そのような中で、低音は出ないもののそれなりにバランスよく聞こえたのが

プリンストンテクノロジー iPod/iPhone用 FMラジオ搭載 目覚まし機能付きスピーカー(ブラック) PSP-BQB

でした。実際に17インチのブラウン管テレビと比べるとAMラジオとFMラジオぐらいの差を感じました。スピーカーは小さいけれども割と音の良いラジカセのような感じと言えば良いでしょうか。

機能的には

スヌーズ機能付きの目覚まし
「ピッ、ピッ」ではなく「ボッ、ボッ」という感じの音、聞きなれませんが、目は覚めます。FMラジオやiPhone/iPad、外部入力も設定できます。 月~金だけ鳴らす設定が便利です。

FMラジオ
スキャンやプリセットできます。アンテナ線を束ねたまま使っていますが、良く入っています。

iPhone/iPad
騎手は各種サポートしています。コネクタのカバーがたくさんついていて、完全な蓋のほか新旧のiPhone/iPad用の形状に合わせたカバーがありますので、安定した取り付けが可能です。「Made for iPhone」の認定済みですので、接続時に注意を促すダイアログが出ることもありません(聞き比べた機種によっては接続するたびに注意が表示されるものがありました)。

外部入力
ステレオミニプラグというのでしょうか、イヤフォンと同じ形状のコネクタでライン入力できます。上述のように、DVDの音声を出力すると17インチのブラウン管TVよりも良い音で聴くことができました。

残念な点は、電源が抜けると設定が消えてしまうこと、ボタン(スイッチ)のつくりがあまりよくなく、カチカチいったり、ボタンごとに感触が異なるところです。

若干の難点があるものの、総合的には「4千円程度でこれだけ使えれば十分」と思っています。詳しくはメーカーページを見てください。


« 2011年9月 | トップページ | 2011年11月 »