無料ブログはココログ

« 2014年4月 | トップページ | 2014年6月 »

完成度は低いが音は良い!Logitec AAC対応Bluetoothレシーバ LBT-AVAR300WH

以前使っていたSONYのBluetoothレシーバから、ロジテックのものに買い替えました。もう戻れません。

これまでのものはSBCコーデックに対応したもので、モノは良いものの再エンコードになるのでどこかコモッたような音がしていました。ワイヤレス接続は便利なので音質は少々我慢して使っていましたが、コントローラ部分が取れて何処かに行ったので、新しいものを買いました。

最近はiPhoneの音楽形式であるAACに対応したBluetoothレシーバが出ていて、再エンコードなしに音を伝送できるものがあります。良い音で聞きたいので色々調べていると、どれも何らかのトラブルが報告されていて決めきれませんでした。

そこで、問題があるなら安い方が良かろうと選んだのが、このレシーバでした。明らかに音が良くなりました。フラウン・フォーファのコーデックから午後のこ~だを初めて使った時のような感動を覚えました。とてもすっきりした良い音がします。

その反面、完成度が低く、電源を入れた際やアルバムを切り替えた際に、昔のステレオの様に「ボム!」と言う感じの音がしたり、バッファの残りを再生したような音が鳴ることや、音が止まる時もあります。

音が止まった時でもコントロールはできました。どうも256kbpsでエンコードした音源で良く起きるので、バッファがあふれているのだと思っています。

そんな感じで完成度はとても高いとは言えませんが、音質はこれまでと格段に良くなり、もう戻ることは無いと思います。2,000円もしなかったので、買って良かったと思っています。


続きを読む "完成度は低いが音は良い!Logitec AAC対応Bluetoothレシーバ LBT-AVAR300WH " »

イミュータブル容易化設計

クラウドや継続的デブロイの文脈でImmutable Infrastructureが語られることが増えてきました。Immutableとは「不変」と言う意味で、インフラを作成後変化させないことで、いつでも初期状態に戻せ、簡単に置き換えられる状態にしておくことです。

クラウドがなかった頃は、ハードウェアの立ち上げからOSの起動までに多くの時間が必要でした。多数のマシンでネットワークを組まない限りは、その後の設定やアプリケーションのデプロイに時間がかかっても大きな問題ではありませんでした。

しかし、クラウドを用いると手作業でも簡単にインスタンスを作成できますし、CLIを使ったスクリプトやChefなどを用いると簡単に作成できます。それに伴ってデプロイ作業もトータルで効率化したくなるでしょうし、逆にデプロイを自動化したならそのターゲットも自動化したくなるでしょう。

しかし、これらの延長上でイミュータブルを実現しようとすると、大きな工数が必要になる場合があります。 あらかじめデータの配置や運用を考慮した設計がされていないからです。ここでは

  イミュータブル = リセット + サイドエフェクトの分離と保存

と定義して、どのような設計が必要かを考えてみます。

リセット:常に初期状態を再現できる

リセットは最初の状態に簡単に戻せる仕組みで、古くから計算機にありました。電源の入り切りではなく、独立したボタンとして存在することで想定外の状態から復旧することができます。

リセットが一般に認識されたのは、ファミコンの登場からでしょう。やがてソニーのVHSデッキにもリセットボタンがつけられるようになり、当時は組み込み屋さんだった私はその割り切りに驚いたものです(業務系では業務時間外やバックアップなどのメンテナンスのタイミングで定期的な再起動をしていることもあるようです)。

初期状態の再現

初期状態の再現を考えると、以下のようなレベルがあるでしょう。

  1. 考えながら手作業
  2. scriptコマンドなどで履歴を残す
  3. 手順書を作成する
  4. 汎用のスクリプトを作ってから実施する
  5. 自動化ツールの導入

下に行くほど初期状態の再現が容易にできています。人間は失敗する動物ですので、考えることが少なく、単純な操作で再現できることが望ましいでしょう。

ここで、効率を考えるなら必ずしも自動化ツールが最適ではないことを考慮してください。一度だけの作業なら、手作業であっても並列作業やパイプラインによって効率を上げることが可能だからです。初期状態の再現性を高めると言う視点が重要です。

初期状態に確実に戻るなら、その方法が運用のリセットボタンになります。変な状態になっても特定の状態に確実に戻すことができます。

サイドエフェクトの分離

サイドエフェクトとは状態を持つことです。ソフトウェアに関係するデータは、不変な部分、変化するが保存の不要な部分、変化して保存の必要な部分、の3つがあります。これらが混在した状態だと運用が難しくなります。

AWSならそれぞれ、インスタンスイメージ、エフェメラルディスク、データベースやEBS・S3などにあたります。UNIX系のOSのパーティションもそのような分類になっていてバックアップが容易になっています。

これらを混ぜてしまうと管理が混乱します。プライベートのLINUXマシンでディスクがあふれて、一時しのぎで異なる分類のパーティションを使ってしまって面倒なことになったのは私だけではないでしょう。

サイドエフェクトの分離は運用でもある程度可能ですが、それぞれの配置場所をソフトウェアの設計時から意識して分離して、設定できるようにしておく方が良いでしょう。

状態の保存

状態を分離したサーバのバックアップは全体の保存と差分の保存を組み合わせます。常にフルダンプの様な全体の保存をしていれば特定の状態をいつでも取り出せる様になりますが、時間がかかり、データ量も膨大になります。実際の運用を想定してコストと安全性、利便性バランスをとります。

動画の圧縮からバランスの取り方を考えてみましょう。静止画を時間順に並べることで動画を作れますが、動画ではGOPと呼ばれる単位で動画を区切ることでデータ量を減らしています。GOPの期間が長いとデータ量は少なくて済みますが、何らかのエラーがあると次のGOPの先頭にある静止画までのデータを見ることができなくなります。そこで、許容できる時間で復旧できるように、一貫性のあるデータ一式(静止画)を一定のの期間ごとにはさみます。また、差分が大きくなる場合にはより効率の良い静止画を挟んでGOPを分けることも行われます。

サーバーに当てはめると定期的に全体の保存をとることが必要なほか、大きな修正時にも全体の保存をすることになります。差分の作業で済むからといってそれだけで済まさず、warファイルやDDLを用意しておくなど、全体に作り直しておくと管理が容易になります。

まとめ

イミュータブル容易化設計を考えてみました。インフラを作成後は変化させないことで、いつでも初期状態に戻せ、簡単に置き換えられる状態にするには

  • 初期状態が容易に再現できるように、運用のスクリプト化を進める
  • 状態を持つ部分(サイドエフェクト)を分離する
  • 復旧を考慮して特定の状態を取り出せるようにする

といったことが必要です。初期化状態で運用できる(Immutableな)部分がリセットできるだけでなく、それ以外の部分も問題なく運用できることが重要です。安定して運用ができたなら、徐々にImmutableな部分を増やせるでしょう。

Immutable Infrastructureの考え方は特定のツールがなければできないものではなく、その考え方を踏まえれば、スクリプトなどでもかなりのことができるでしょう。

Immutable Infrastructureはクラウド環境のようにサーバの構築が容易な場合や、多くの台数を用意する場合には非常に有効な考え方です。立ち上げ時の負担が減るほか、トラブル時の対処が大きく改善されるでしょう。

その反面、サーバ数が少ない場合や自前サーバの場合などでは、効率はそれほど良くないかもしれません。そのような場合は以前紹介したYggdrasil(ゆぐどらしる)の利用するなど、より良い方法を設計したいですね。

いずれにしろ、力技で頑張ることだけが唯一の方法であってはいけません。神経をすり減らすのではなく、無駄な作業を減らして技術者らしく「楽」をしましょう。


[#Agile] ソフトウェアの価値とアジャイル開発

ソフトウェアの価値とは何か?色々な議論があるかと思いますが、規模、対価、顧客満足から考えてみます。

規模尺度

ソフトウェア工学でソフトウェアの価値と呼べそうなものに規模の尺度があります。

規模尺度はメトリクスから始まっています。最初に注目されたのはソースコードの行数(LOC)です。行数は工数との相関が高く、LOCとソフトウェアなどの特性から開発工数を見積もるCOCOMOが生まれたほか、工数あたりのLOCから生産性の尺度、KLOCあたりの障害数から品質の尺度が生まれました。

しかし、ソース行数はプログラム言語によって異なることから、言語に影響を受けない機能数を基準としたファンクションポイント(FP)が生まれました。統計情報からFPの機能規模から工数や行数を求めることもできます。

これらの規模は技術的な価値を示すものです。工数との関連を示すメトリクスとしての意義はあるものの、直接ビジネス上の価値を示すものではありませんでした。

対価尺度

対価尺度としてはビジネス上の価値である売上が考えられます。ソフトウェア開発では、工数に単価を乗じたものの合計が見積もりや売上になります。外販するパッケージやサービスの場合は、総売上がそのソフトウェアの価値になります。

売上を価値とする方法は独占販売では価値が高く大きくなり、競合が存在する場合は価値が低くなります。これは一般的に「価値がある」と言う場合の価値に近いものになります。

その反面、運用のコストがかかる場合やハードウェアに付随する場合、オープンソースのプログラムでは、ソフトウェア単独の価値を適正に示すことが難しくなります。

顧客満足

顧客満足を価値とした場合は、開発するメリットが価値になります。アジャイル宣言の背後にある原則には、

 「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」

とされ、顧客満足を基準としてソフトウェアの価値を高めようとしています。

また、「わかりやすいアジャイル開発の教科書」には、以下のように書かれています。

ソフトウェアの開発を委託する顧客は、「このソフトウェア/システムがあれば業務効率が上がって収益が上がるはずだ」など、そのソフトウェア/システムに対して費用を払って得られる利益を期待しています。その利益が顧客にとってのソフトウェアの価値になります。(p.32)

アジャイル開発では、ソフトウェアの規模でも、そこから得られる売上でもなく、売上からコストを引いた利益が基準になります。これはリーンキャンバスやビジネスモデルキャンバスで収入だけでなくコストも考慮することや、アメーバ経営の「売り上げを最大に、経費を最小に」という原則と付加価値のメトリクスである「時間当り採算」とも一致し、よりビジネスに近い価値の基準であることがわかります。

また、オープンソースのソフトウェアについても、開発者やコミュニティが顧客であると考えれば、顧客満足を基準に開発していると言えるでしょう。

顧客満足のメトリクスとバックログ

利益を基準としない顧客満足もあります。この場合は、ヒアリングやアンケートが主な計測方法になります(最近はTwitterやSNSの情報も利用される様です)。これは、ユーザビリティテスティングでも利用される方法です。

ここで注意しないと行けないのは、規模や対価は絶対値を示す比例尺度であるのに対して、顧客満足度は利益を除くと相対的な順序尺度であることです。

仕様を決める場合を考えると、最低限必要な機能がどこまでかは比較的明確かもしれません。しかし、追加機能は個々の機能による利益や、心地良い体験(UX)を絶対量で示しにくいので、相対的な順序づけが合理的です。

アジャイル開発ではこのように顧客満足に応じて順序付けられたバックログを、優先順位にそって順次開発していきます。バックログは常に見直されるので、常に顧客にとっての価値を最大化できます。

アジャイル開発におけるソフトウェアの価値

アジャイル開発の価値が利益であっても、メンバーの増減がなければ価値の順序は売上の順序と変わりませんので、あまり厳密に議論する必要はないかもしれません。

しかしビジネス上の価値を考えると、いつ黒字になるのか、いつどの程度の利益が得られるかは重要な関心事です。もし、XXまでに必ず黒字化する、YYまでに何が何でも利益をZZにする、と決めるなら、人を増員あるいは減員できるのでソフトウェアの価値には利益の方がふさわしいと思っています。

以上のことから、アジャイル開発に置けるソフトウェアの価値は「利益」あるいは「メリット」だと思います。

なお、アジャイル開発では原則やプラクティスの上位にある価値もありますが、これは「価値観」と呼ぶ方が良いと思っています。


イノベータに必要な能力

学会というと堅苦しいイメージがあるかもしれませんが、論文誌とちがって学会誌は研究成果だけではなく、コラム等のわかりやすい記事も載っています(例:ソフトウェア開発と時間 - 時の記念日特集寄稿コラム -)。

今月の電子情報通信学会の情報・システムソサエティ誌(19−1)の巻頭言「イノベーションを起こすのは誰だ?それは君だ!」(土井美和子(東芝)さん)も興味深く読ませていただきました。

巻頭言では以下のような内容が書かれています。

  • 日本能率協会の調査によると2015年度の経営課題のトップが「新製品・新サービス・新事業開発」であり、時代がイノベーションを求めている
  • 世界的に技術探求型から、ユーザの潜在的なニーズをくみ取り、技術やサービス等を組み合わせたビジネスモデルでの確信を実現する「ユーザ起点イノベーション」が重視されるようになってきている
  • 経営者は「推進力」「構想力」「挑戦心」が新事業創造を索引する人材(経済産業省「フロンティア人材研究会報告」2012年3月)
  • 真のイノベータに必要な能力は「利他精神」「自己管理力」「質問力」「捨てる力」(同研究会委員)
  • 著者は「人を巻き込む力」を加えたい

として、行動展示で有名な旭山動物園で飼育員がワンポイントガイドで距離を縮めたことから「質問力」と「人を巻き込む力」 を、同じく行動展示で奇跡を起こしたおんねゆ山水族館をプロデュースした中村元氏がボランティアであったことから「利他精神」を説明されています。

そして「質問すれば気付きがあり、仲間が増え、イノベーション”ワォ”が生まれる」と結ばれています。グイグイ引っ張るのではなく、共に助け合い、不足するものがあれば紹介してもらい、色々な意見を聞く、といったアプローチです。

世の中が複雑になり、一人で革命を起こすことが難しくなりました。回りの人を巻き込んで知恵を出し合う、ある意味コミュニティ(勉強会のバリエーション)を作れるサーバントリーダシップが求められているのでしょう。

火消しの成功条件から改善を考える

収拾がつかなくなった大火事プロジェクトの火消しは大変です。しかし、よりひどくなることは少なく、大成功とはいかなくてもそれなりの収束を迎えることが多い様に思います。火消しの際には以下の成功条件が整っていることが多いからでしょう。

  • 問題が顕在化している
  • 権限が委譲されている
  • 優先順位が決まる

これらを詳しく見ると、組織やチームを改善する際の成功条件が含まれていることがわかります。

問題が顕在化している

混乱の多くは、コミュニケーション、構成管理、障害管理などが原因ですが、問題が明確になっていないと適切な改善ができません。一般に良いと言われているプラクティスを導入しても、改善効果はありませんし、逆効果になる場合もあります。

問題が明確であれば、その問題を解決することで必ず効果が出ます。大火事プロジェクトではすでに問題が大きくなっていますから、既存のメンバーには普通になってしまった問題であっても、火消しはすぐに気付くことができます。

問題が明確になると、それまで気付かなかった人たちも同じゴールを目指せます。それまで自己保身に走っていた人も、ゴールの共有によって前向きになれるでしょう。

権限が委譲されている

火消しに入る場合はどうしようもない状況なので、火消しに多くの権限が委譲されます。普段ならリーダーが希望してもすぐに増員は認められない組織でも、非常事態なので火消しの希望は多くが通るでしょう。

これは上長のコミットメントによって改善が進むことを示しています。一般に改善が実施できるのは権限のある範囲ですので、上長のコミットメントは重要です。

優先順位が決まる

従来型開発では、仕様を決めたなら全ての機能を実装しないとプロジェクトが完了しないのが普通です。しかし、いつ終わるかわからない状況になるとリリースが最優先になり、実害のない機能や実現の難しい機能が後回しや取り消しになることがあります。

このように必要最低限の機能を実現するとそれが仕様の基準になり、残りの仕様が決まり易くなります。機能の優先順位が決まっていない時には、全てを最適化しようとして調整が困難であっても、優先順位を決めて段階的に開発すると問題の解決が容易になり、繰り返しによって経験値も上がります。

まとめ

あまりやりたくない火消しの仕事ですが、それ以上ひどくなることは少なく、やりがいのある仕事です。それは、ここに挙げた成功し易い条件が整っているからです。

これを、改善の成功条件としてまとめ直すと、以下のようになります。

問題の共有:チームが同じ方向を向くことで問題が解決できます。
コミットメントを得る:上司に率直な意見を言い、部下の率直な意見を聞くことが、改善の近道です。
優先順位を決める:優先順位を決めて徐々に確認すれば、混乱が防げます。

火消しでも、改善でも、プロジェクトの問題を解決することは変わりません。プロジェクトや組織の運営は常に改善です。これらに共通する成功条件を意識して、より良いプロジェクトを実現しましょう。

« 2014年4月 | トップページ | 2014年6月 »