ガラポンTV開封の議

以前から欲しかったガラポンTV。
地デジ8局を120日間全録できるという優れもの。
ただし、録画はフルセグでなくワンセグになる。
先日の保田氏の講演会を聴いて速攻買うしかないということで、すかさず購入。
ようやく本日時間が取れたのでセットアップ。
いや、これすばらしいですね。
まさに、テレビ視聴のスタイルを「ガラポン」しますね。

私の場合、最近ほとんどテレビは見なくなったのだけど、テレビ番組そのものが嫌いでみなくなった訳ではない。

最近、視聴率低下等による制作費の削減から番組の質の低下がその原因に問われたりしているが、では質が高い番組を（まあそもそも何を持って質が高いというかもあるし）作れば私も含めて再度皆がみるようになるのか？

そうではなかろう。
やはりみている時間がないのだ。インターネットの普及により他に圧倒的に時間を使うことが多すぎる。Webサーフィンしたり、メールをみたり、SNSをしたり。

でも、面白い番組（つまり自分に合う番組）はみたいと私も思うが、以下の理由によりなかなかみる機会そのものがない。

• 番組にあわせた決まった時間にTVの前にいられない。
• そもそもどんな番組をやっているか？番組表をつぶさにみるのが億劫で番組表をみる習慣がなくなった。
• 仮に、番組表をみたしとしても概要だけでは、自分が面白いと思う番組なのか不明。
• 録画機ももちろん持っているが、上記の理由によりそもそも予約録画するにいたらず。
• ツイッターなどで、これは面白かったなどの情報をみて、あーこれはみたかったなと思うことは多々あれど、とき既に遅し。

とまあ、上げればもっと出てくると思うけれど。

といった問題点をほぼすべて解決してくれるガラポンTV。

24時間全録なので撮り逃し無し。パソコン、iPhone/iPad、Androidからいつでもどこからでも視聴可能。

あと、これが最大の特徴だと思うのだけど、ガラポンTVサイトというコミュニティが充実している。

ここで、自分がみて気に入った番組を紹介したり、イイねをつけたり。

ここをみて、なにが皆によく見られた番組なのかを知ったり、人のコメントをみて、その番組が自分に合っていそうかを判断したり。

リンクをクリックすると即座に視聴できるのもよい。

保田氏も言っていたが、ガラポンTVのようなハードはだれでも作れるが、このコミュニティは一朝一夕にできるものではないので、ここがガラポンTVの最大の差別化でありアドバンテージになると。

この点は私も大いに同意するところ。

その他、APIもオープンにしていたり、よくわかっているなーと。

と、よいことづくめだが、いちおうそうでない点も書いておくと、

画質：これはワンセグなので地デジ画質ではないです。割り切ってみましょう。画質より利便性を優先する人向けの商品です。

セットアップ：ここまで機能が実装された商品としては、セットアップ等はかなり簡単にできているけれど、それなりのパソコンやネットのリテラシーは必要です。

ちなみに、私は初期設定のとき、アクティベーション前なのに、赤ランプのみの点滅というマニュアルに無い事態に遭遇して、少々戸惑ったのですが、なんとか自力で切り抜けました。

今後、使い倒すのが楽しみです。

Twitterやfacebookの投稿をみて、あーこの番組は見たかったなというストレスから解放されると思うと、なんとなくうれしい気分。

参加レポート：developers summit 2014 なぜ、システム開発は必ずモメるのか？

なぜ、システム開発は必ずモメるのか？　プロジェクト見積もりから契約作成まで 

2/14(金)、大雪の降る中、行ってきましたよ。会場は目黒雅叙園。

雪なので、人は少ないだろうなぁと思ったら、あに図らんや大満員状態。
「やまもといちろう」さんのネームバリューもあるんだろうが、やはりネタがネタだけに皆関心があったんだろうね。
もう一人のお相手は、東京地方裁判所の民事調停委員を務める「細川 義洋」氏。
やまもと氏が進行役とネタ振り。それに細川さんが答える形式。


聴講者も若い人が多かった。
時代が変わり、必要とされる技術、が変わってもシステム開発そのものは無くならないし、当然それに伴う揉め事は、増えこそすれ減ることはないと。

以前は、もめ事があっても当事者間同士で話し合っておさめることが多く、裁判などで 解決を図るというケースは少なかったと思うのだが、最近では事例が増えてきているようだ。

私が一番ためになった話は、細川氏の発注者ｖｓベンダーの訴訟になった場合に、裁判官はどういう視点で両者の主張を判断するかといったポイント。細川氏からのお話。

裁判官はスキルギャップ というポイントをもっとも重視するそうです。
つまり、発注者とベンダーを比べた場合、ベンダーがシステム開発に関してプロ（つまり発注者より圧倒的にスキルと経験がある）なのだから、リスク、影響度などを勘案し、場合によっては、そのプロジェクトを中止する勧告を発注者にする責任がある。

仕様変更の連続で、コストが膨らむ、納期遅延、等がわかっているのに、プロジェクトを中止せずそれを受け入れて、プロジェクトを続けて、赤字になった、もしくは、プロジェクトが中断にいたり、発注者側に損害を与えた。
というのは、そうなるのをわかっていながら、プロジェクトを続けていたベンダー側の責任であると。

と、かなりベンダー側に不利な判断をされるケースが多いそうである。
ベンダー側の立場の経験が長く、今でもベンダーの配下で仕事をする側の人（私も含めて）から、言わせると、おいおいそれはあまりにも一方的だろうと。


発注者は検収権限も持ってるし、最後お金を入金する、しないも発注者側。
プロジェクトで嫌われたら、次の発注が他社に流れていってしまって来ないリスクもベンダーにはある。

と、営業面や契約上の立場は、圧倒的に発注者側が強く、ベンダー側から、
「これ以上、プロジェクトは続けられないので、中止。それまでのお金を一旦払ってください。」
なんてことは、口が裂けてもそのPMさんから言えるわけもなく、裁判官様ぁーと言いたくなるが、裁判官は案件をやったことないわけだから、あくまでも現行の法律と過去の判例に則って判断するしかないという、不都合な真実がそこにあるということ。

これら、法律も昭和30年代に出来た物ということで、そもそもその時代にはITなんてものが無かったわけである。

ということで、ためになったと同時に色々考えさせられてたセミナーでした。