無料ブログはココログ

« 2013年8月 | トップページ | 2013年10月 »

簡単すぎるネットワークカメラQwatch - TS-WLCAM -

インターネットのセットアップはもっと難しいハズでした。アイ・オー・データ機器の有線/無線LAN対応ネットワークカメラQwatchは、あまりにも簡単にセットアップできました。

設定内容

Jack20130929

<設置>

  • カメラを箱から出す
  • 電源をつなぐ
  • 無線ルータのWPSボタンを押す
  • カメラのWPSボタンを押す

<アプリの設定>

  • スマホのアプリをダウンロード
  • カメラを追加ボタンを押す
  • QRコードを読む

これだけでカメラの動画を世界中から見る事ができます。

昔だったら

昔は色々な設定が必要でした。

(1)URI(外部からのアクセス)を確保

ネットワークカメラというのは、インターネット経由で静止画や動画を外心するサーバです。 TS-WLCAMもMJPEGで動画を見る事ができます。

サーバなので、昔なら

  • グローバルIPの割当て

をしていました。最近だとグローバルIPの取得が難しいので

  • プロバイダのDDNSに登録(@niftyで200円/月)

あるいは

  • 無料DDNSと更新ツールの起動

が必要でした。

Qwatchは、このようなDDNSのURIがあらかじめ確保され、その設定と認証の設定を後述する「QRコネクト+」で簡単にしています。

(2)無線LANの設定

無線LANでつなぐには、端末をつないで

  • SSID、暗号化キーの設定

が必要でした。LAN経由で同じこともできる様ですが、無線ルータがWPSをサポートしているなら、ルータ=>カメラの順にWPSのボタンを押すだけで簡単に接続できます。

今回の設定でトラブったのは、唯一ここでした。登録が終わる前に色々触っておかしいと騒いでしまいました。表示を確認しながらゆっくりやれば問題ないでしょう。

(3)ルータの設定

外部からルータへのアクセスをカメラに中継するには、昔は

  • 特定のポートをカメラにフォワード

しないといけませんでした。これには、

  • ローカルIPアドレスを固定する

必要がありました。

IPアドレスを固定するには機器に端末を接続して設定するか、ルータ側でDHCPで払い出すIPアドレスを固定にする必要がありました。

これもUPnPをサポートしているルータでDHCPを設定しているなら、電源を入れるだけで動作します。ただし、ルータが多段になってうまくいかない時は、ブリッジモードにするか手動で設定する必要があります。

QRコネクト+

Qwatchを買うと取説、スマホ用設定ガイド、PC用設定ガイドのほか、QRコード(2次元バーコード)が印刷されたシールが付いてきます。このシールには、最初に書いた簡単な設定法のほか、アカウント情報やDDNSを使ったアクセス法(URI)が載っています。

アカウント情報やURIはパソコン用で、QRコードには スマホアプリ用でこれらが暗号化されて入っている様です。

想像するに、カメラをインターネットにつなぐと、自動的にメーカーのDDNSサーバーにアクセスし、そのカメラ用のドメインにIPアドレスが登録されます。アプリはQRコードで知った情報を復号し、URIにアクセスして認証する仕組みの様です。

つまり、機器ごとに設定が必要な情報をまとめてQRコードに含むことで、機器側のDDNSの登録と、機器固有の情報のアプリ設定を連携しています。ここでメーカーが、URI、アカウント、パスワードを機器ごとに変えていて、それをユーザが変更しなくても一定のセキュリティが保てるところが良くできていると思います。ちなみに特許出願中の様です。

まとめ

かつてPOP-NEWSというUNIXワークステーションがありました。これは、非常に安価なことと使い易さを考慮して居ることが特徴でした。ネットワークを含めて多くの管理作業がGUIでできるようになっていました。

しかし、当時は自動化のためのプロトコルがあまり普及していなかったことや、文字入力が必要だったことから、(当時としては画期的でしたが)それほど使い易い物ではありませんでした。

今回、Qwatchを設定してみて、ハードとサービスを統合し、スマホの機能を駆使することで、新しい時代を切り開いたと思いました。上記のほかにも、位置情報の登録などいかにもスマホらしい機能もあります。

反面、動画をNASに保存するための設定には文字入力が必要だったり、映像の動きを検知した際のメール通知の設定にはパソコンが必要だったりと、コストや技術的に難しいところもあり、今後に期待したいところです。

同じような価格帯でもっと多機能な物もありますが、簡単に設置できることや安定して動作することがこのカメラの魅力だと思います。電波の弱いところからアクセスした際におかしくなって電源の入り切りをしたことがありますが、それ以外のトラブルはありませんでした。

なにより、技術と工夫によって商品の完成度が上がるということを勉強させていただきました。それだけでも大変「お得な買い物」だったと思います。


[#TOC] 答えをみつける機会 - 「考えろ!」だけでは考えられない -

先日、TOCfE関西TOC/TOCfE関西分科会~ごちゃごちゃすっきり!ブランチ講座~に参加してきました。

TOCとは

最近、トヨタ生産方式の流れを汲むTOC/TOCfEがじわじわと広がっています。TOC/TOCfEは知らなくても「ザ・ゴール」という全米で250万部売れたベストセラー小説ならご存じの方がおられるかもしれません。

TOCというのは著者のゴールドラット博士がまとめた制約理論を基礎とするものです。中でも、個々の作業ごとに持ってしまいがちな作業のバッファをプロジェクトでまとめて管理することで高い生産性を実現するCCPMが有名です。

TOCfEとブランチ

そしてその2作目の「ザ・ゴール2」で書かれたのが、TOCをベースにした思考法であるTOCfEです。TOCfEには3つの有名なツールがあります。

  • ブランチ:なにを変えるのか
  • クラウド:なにに変えるのか
  • アンビシャスターゲット・ツリー:どうやって変えるのか

今回はブランチです。

ブランチでは、次に用に考えます。

1)隠れた思考の要素を導きだす。
2)「なぜならば」にあたる隠れた推論を導きだす(下から出る場合もれば、下から出る場合もあります)。
3)ブランチは正しいのか、内容を明確にし、存在有無、因果関係、十分な条件、から?因果関係を確認する。

気になった言葉

分科会ではいつものように、TOC/TOCfEの説明、ブランチの説明、演習、とあって、演習では付箋を色分けしているチームもあって、勉強になりました。

いつものTOC/TOCfEの説明でしたが、今回はゴールドラット博士の言葉が気になりました。

「学ぶことの最大の障害は答えを教える事ではないか?それは、自分で答えをみつける機会を永久に奪ってしまうからである。」

この「答えをみつける」とは、一体、どういう意味なのでしょう。ゴールドラット博士は、TOCfEの思考のツールを与えて、答えをみつけることの重要性を語られています。つまり、ツールを使ってもっと大切なことを考えさせようとしているのだと思います。

「考えろ!」だけでは考えられない

プロジェクトにトラブルがあったとき、「考えろ!」と言ったり、「考えさせろ」(あるいは「ちゃんとやれ!」)という指示をされていませんか?それは答えをみつける機会を与えているでしょうか?

指示する側から見ると、こうすれば良い、それぐらいわかるだろう、そんな思いがあるでしょう。でも、なぜそう思えるのでしょうか。どんなやり方があり、それぞれの特性を知っているから、適切な方法を思い浮かぶのだと思います。

もし、やり方を色々知っていて、考えないでいつも通りやっているなら、「考えろ!」は的確だと思います。でも「考えろ!」と言う人に限って、どのような方法があるかを教えずに、考えさせようとしていないでしょうか?

「考えろ!」という人も、多くの場合は過去の経験やどこかで知ったことを状況に合わせて適用しているだけなのですが、それを自分で考えたと思っていないでしょうか。

車輪の再発明をさせてはいけない

「答えをみつける」ということは、先人の知恵をどのように活かすかを考えることです。何もない所から、車輪の再発明させることではないと思います。

もちろん、工夫をしていたら同じようなことをしていたということもあるでしょう。でもそれは、知っていれば苦労せずに長所短所を知ることができて、さらに高度に発展させられたかもしれないのに、汎用化されていない似た様な事しかできていないのです。

いまだに、NIH症候群は根強いのでしょうか。

魚を与えるのではなく、魚の釣り方を教える

ゴールドラット博士の言葉は「考えろ!」というのではなく、「教えろ」と言われているのではないでしょうか?

たしかに「俺の若い時は」と思うことも多々あると思いますが、昔と今は違います。かつては、言語の本かマニュアルを1冊読んで、一通りのアルゴリズムを知っていれば良い時代でした。しかし、いまや言語はもちろんのこと、フレームワーク、アーキテクチャ、レビューやテスト技法、開発標準、法律、などなど、しかも、業務によってニーズは大きく異なります。

答えをみつける機会を与えるには、先ずその方法を教えることが必要だと思います。ポイントは「教える内容」であって、「教えないこと」ではないと思います。方法やツールを与えて解決策を考えさせる。TOCfE分科会で行われているような教え方が必要だと思います。


[#TiDD] チケット駆動開発による「ソフトウェア開発の現場力向上」を終えて

第3回SRA関西セミナー チケット駆動開発による「ソフトウェア開発の現場力向上」を開催しました。

講演には書籍「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」を共著させていただいたNRIネットコム株式会社 小川様、パネリストとしてパナソニック株式会社の上野様にご協力を得て、定員を超える方にご参加いただきました。皆様ありがとうございました。

プログラム順にご紹介すると、初めに私の方から「チケット駆動開発の知っておくべき大切な事 - コミュニケーションの視点から -」と題して講演させていただきました。

内容的にはGxP様での講演とだいたい同じですが、前回はプロジェクトマネージメントのバランスの視点で、今回は現場を意識したコミュニケーションの視点で加筆修正、再構成しました。

元の講演ではコミュニケーションはあまり意識していなかったのですが、全体を再構成してみるとほとんど全てのことがコミュニケーションと関連していて、コミュニケーションが重要であることがよくわかりました。

小川さんの講演では「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」と題して、運用保守、ヘルプデスク管理、ハードウェア資産管理、EVMによる工数管理のお話をしていただきました。

小川さんらしく「ふりかえり」を実施しながら改善されている様でした。また、講演後にお伺いした話では、それぞれトップダウンに進めそうですが、現場の業務との擦り合わせを十分行われたそうです。

Redmineでのメールの利用方法は、Rakeで行われている様です。以前書いたように私は/etc/alias派なのですが、それぞれの長所短所など一度議論してみたい所です。

最後のパネルでは、上野さんに自己紹介と発注側の立場でのポジションを発表していただきました。現場からの提案により実装から順にV字モデルの上の方に範囲を広げられたそうです。

トレーサビリティマトリクスの代わりとしての利用や、定例打ち合わせでは予定から議事録までTracで完結されていること、進捗報告がチケットへのリンクで済むこと、工数精査や関係者への連絡や作業依頼にもチケットを利用して「くせ付け」されていることなど、実践的で興味深いお話しでした。

今回は色々なお話やディスカッションを通して、現場に目を向けることは本当に重要だと思いました。やはり、プロセス改善は組織をあげて取り組む物だからなのでしょう。

最後に、参加者の傾向が変わっていることに驚きました。チケット駆動開発を実践されている方が2割、Redmineのユーザが3割とこれまでになく、少なかったことです。

チケット駆動開発はキャズムを超えつつあると思っていました。しかし、すでに好奇心おう盛な人たちは実践し、現実的な技術として広く普及する段階を迎えつつあるのかもしれません。

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


[#TiDD] チケット駆動開発で障害対策リリースする際のチェック法

チケット駆動開発をしているのに普通にリリースしていませんか? “No ticket, No Commit!”を実践しているなら、こんなチェックができます。

  1. リポジトリブラウザでバージョン管理ツールの変更部分を確認します。前回のリリース後の修正を順に追います。
  2. 修正コメントに書かれたチケット番号を順に追います。もし、チケット番号がないなら、修正を行った作業者に内容を確認します。
  3. チケット番号とその概要をリリースノートに追記していきます。チケットが障害チケットから派生したタスクなら、関連タスクが全てクローズされていることを確認して、障害タスクの内容を追記します。
  4. リリース予定の内容とリリースノートが一致しているかを確認し、過不足があれば作業者や担当者に確認します。
  5. リリース予定の内容が過不足なくコミットされていれば、リリース(タグを切る、コピーする、メディアに焼く、デプロイ作業、など)します。

このようにすると、予定された障害チケットと関連づけられた修正のみがリリースに反映され、コミットミスで関係ないファイルを更新してしまうことや、コミット漏れを防ぐことができます。

以前の講演で説明したチケットによるトレーサビリティの確保の一環ですが、実践されていない場合もある様ですので、ご紹介しました。


「ちゃんとやれ!」では改善しない。

ソフトウェア開発でトラブルが発生した時、「ちゃんとやれ!」と言っているだけでは、改善できません。

原因を確認する

そもそも、なぜトラブルが発生したのかを考えるべきだと思います。

  • テストが不十分
  • レビューしたが漏れた

などなど、確かにちゃんとしていないことが直接の原因なのかもしれません。しかし、よくよく聞いてみると、

  • 開発法に改良の余地がある
  • 技術的に問題がある

のかもしれません。その場合は、注意するのではなく、指導した方が良いでしょう。

「考えろ!」

このような場合「考えろ!」と注意される方もおられるかもしれません。しかし、既に考えているなら「そんなことを言われても、、」で、終わってしまうかもしれません。

そこで、ポイントだけ教えて、詳しくは調べさせるとか、関連するコミュニティや検索の仕方など、勉強に役立つ方法を教えるのが良いと思います。

そもそも

実は品質向上策を取りたいのに、そもそも

  • 予算(工数)がない
  • 見積もりが間違っていた

などの理由で網羅的な品質確保の作業が難しいのかもしれません。その場合、追加の予算確保が難しいと思われますので、別の対策が必要です(特にプロジェクトが小規模であるほど、費用の捻出は難しいでしょう)。

この場合も、注意するのではなく、指導した方が良いと思います。予算交渉や行積の方法は別途教えるとして、今を乗り切るためのポイントを教える必要があります。

危機を脱する方法

限られたリソースで最大の効果を得る方法は、最も効果のある方法から実施することです。特に信頼性が問題になっている場合は、問題の発生の可能性と被害が大きいところから、つまりリスクベースで優先順位を付けます。

こうすれば、限られた予算の中で効率よく改善できます。いわゆるパレート(2割8割)の法則によって、最大限の効果が得られるのです。

現実を受け入れろ!

このような方法は「きちんとしろ!」からイメージできることと大きく異なります。きちんとできない現実を受け入れて、その中で最善を尽くすことによって実現できる方法だからです。

「考えろ!」というのも現実を受け入れていないでしょう。考えるために必要な知識を提供し、どのように考えれば良いかを提供すべきなのは、多くの場合、注意している人の仕事だからです。

偉そうにしない

「偉そうにする」という言葉は、上に立つ人のあるべき姿ではなく、使えない上司を表していると思います。ボスの仕事はチームの能力を最大限に発揮させることだからです。

上の立場だからこそ、技術や人の育て方をきちんと学び、チームをより良い方向に導く責務があると思います。「その責務に手が回らないほど忙しいのは、責務を果たしていないから」と思うのはひねくれ過ぎでしょうか?


[#TiDD]【告知】チケット駆動開発による「ソフトウェア開発の現場力向上」

書籍 「チケット駆動開発 」 「Redmineによるタスクマネジメント実践技法 」の著者であるNRIネットコム(株) 小川 明彦氏をお招きして、第3回SRA関西セミナー チケット駆動開発による「ソフトウェア開発の現場力向上」を開催します。

小川さんには「Redmineの運用パターン」と題して、Redmineによるチケット駆動開発の運用パターンと、Redmineの適用範囲や適用の限界についてお話ししていただきます。小川さんならではの突っこんだ視点で、Redmineの業務利用についてお話ししていただけると思います。

また、私も「チケット駆動開発の知っておくべき大切な事」と題して、コミュニケーションの改善の視点で、チケット駆動開発の概要と事例、そしてチケット駆動開発の考え方、勘所、注意点など、実施する際に知っておくべき大切な事を説明します。

さらに、発注側の立場からスペシャルゲストをお招きしてパネルディスカッションをする予定です。現場での体験を踏まえたチケット駆動開発の議論を楽しみにしています。

参加費は無料です。皆様、ぜひご参加ください。


[#TiDD] チケット駆動開発でコミュニケーションを改善する

古くからソフトウェア開発では、プロジェクトの主な失敗理由の一つとしてコミュニケーションがあげられています。コミュニケーションを2者間と考えると、その問題は、発信、受信、とその間の情報の3種類に分けることができます。

発信

発信者が遠慮している、抑圧されている、言われた作業だけしている、プロジェクトを人ごとだと思っている、プライドが高く問題があると言えない、等の場合、 気付いたことを言わないという問題があります。

また、聞いたことを失念している、わからない、優先度が低い、責任を感じていないなどの場合は、放置されてしまいます。

受信

受信者が 忙しい場合や受け取った情報が大量な場合、溜まってしまいます。また、聞いていないあるいは聞く気がない場合や、うっかりを考慮しないでチェックの仕組みがない場合は、抜けや漏れが生じます。

情報

伝聞の場合や簡略化した場合、あるいは情報が偏って居る場合は情報の質が低下します。また、内容が流動的、あいまい、詳しく知らない、知ってるつもり、気付かない場合には、情報を紛失したり、内容が変化してしまいます。

対策

このようなコミュニケーションの問題には、チケットの利用が有効です。しかし、それだけでは全てを解決できません。適切な管理やサーバントリーダーシップも必要でしょう(プロジェクトファシリテーションと言っても良いかもしれませんが、カンバンを含むのでサーバントリーダーシップとしています)。

このように、コミュニケーションの改善を中心に考えると、チケット駆動開発をどのように実践すれば良いかが見えてきます。

Photo

2013年9月12日の講演では、コミュニケーションの視点から「チケット駆動開発の知っておくべき大切なこと」を説明する予定で、上記の内容のほか、サーバントリーダシップの説明を加えるなど、前回の講演から大改造中です。

また、グループダイナミクスの考え方を踏まえ、スクラムに影響を与えた組織パターンを対象に、コミュニケーションの改善パターンもいくつか示す予定です。

【告知】 「チケット駆動開発」「Redmineによるタスクマネジメント実践技法」を共著させていただいた@akipii さんをお招きして関西でセミナーをします。ぜひご参加ください。 9月12日(木)14:00〜 第3回SRA関西セミナー チケット駆動開発による「ソフトウェア開発の現場力向上


« 2013年8月 | トップページ | 2013年10月 »