ドールショウで茉莉花を観てきました

思い立ったら吉日ということで、ドールショウに行ってきました。

ドールショウ公式HP
http://www.dollshow.net/

ドールというか人形というか、手元には四谷シモン球体人形の画集があるぐらいで、この手のもとは遠く離れているのですが、まじかる☆マリオネット開発日誌 の茉莉花が直接見れるのであれば、実際に見てみたいということで浜松町へGo.

https://pbs.twimg.com/media/COMWceaVAAA0SZA.jpg

音声認識でモーションを付けて動きます。かつ、自立して、腰を曲げた挨拶をしても倒れないロボット(ドール)です。

以前、梨甘さんの

 

というジャンル?があって戦う二足歩行ロボットとも踊るロボットとも違う道筋があることがわかって、つい最近、みさいるさんが

 

等身大初音ミク2号機(ロボット)完成しました!: メカニカルガール を完成したこともあって、自分も駆動系をきちんとやろうと思っているところです。二足歩行ロボットのほうはサーボーモータ絡みで(価格的に)ちょっと量産が効かなそうなので、依然としてキャタピラ、ブラシモーター/ステッピング絡みになる予定なのですが、そこはほれ量産ということで、Raspberry Pi & タミヤのギアーボックスとキャタピラの組み合わせで一気に5台作ります。

1台だと自前でコントロールするだけになるし自律にしても動くだけですが、2台になると対向することで通信が発生し、3台になると相手が複数になるわけで、そうなると5台ぐらいあると通信がメッシュになって面白味がでそうですよね、という予定。このあたりは1台だけカスタムにして主導させるとか、従属関係を持たせるとか、アシモフの「我はロボット」あたりの矛盾っぽいものが出てくればと考えています。そう、Google の自動制御の車でとまった自転車を認識できない話は、そのあたりの微妙な判断がセンシティブに効きすぎているところもある(ただし、安全面から考えれば人にぶつかる可能性が少しでもあれば止まり続けるというフェールセーフな働きが重要)のでしょう。そういう予期しないものを実際に試してみたいですね。

そうそう、話していて駆動系の場合には肘や肩などの動く部分のケーブルに負担がかかるのと、コネクタ部分に引張り応力が掛かるのに要注意ですね。このあたり、保持するようにケーブルを止めるのと、配線自体を切り替え可能にしておくのはメンテナンス上、重要ですね。私の場合、基本は子供に投げらても大丈夫なぐらいの丈夫さは保っておきたいので、外観とか立ち上げの簡便さも含めて考えていかないと、ということで。

カテゴリー: 雑談 | ドールショウで茉莉花を観てきました はコメントを受け付けていません

サイプレス社エナジー ハーベスティングのワークショップに行ってきたよ

たまたまツイッターでタイムラインに流れてきた

に行ってきました。

川崎はちょっと家から遠くて急遽午後の部にしてもらって、てくてくと1時間半かけて電車で行きました。

Energy Harvesting PMICs
http://www.spansion.com/products/analog/energy-harvesting-pmics/Pages/pmic-eh.aspx

Solar-Powered IoT Device Kit | Cypress
http://www.cypress.com/documentation/development-kitsboards/solar-powered-iot-device-kit

どんなボード?

簡単に言うと、センサーの類とBLEをソーラーパネルの電力で賄って通知する、というボードです。他のボードと違うのは、供給するのはソーラーパネルに限らず熱伝導や振動を使った「比較的不安定な電力供給源」をサポートしているところです。蓄電器にためて置いたり、ボタン電池を使うのではなくて(使うこともできるけど)、ソーラーモジュールから低い電流を内蔵のセラミック容量(100uF)にため込んで、間欠的に温度センサーなどを読み取ってBLEで通知できます。ってのがミソ。確かに、ボタン電池でも1年以上持つけど、しばらく置いておくと電池は無くなるわけだし、ビーコンのように置きっぱなしの場合にはいつ電池が切れたかわかりづらいという点もあって、そうなるとソーラーパネルを利用して蛍光灯レベルのでの低い電流でもセンサーが動いてBLEが通知し続けることができる、っては需要が多そうだなというところです。その分、工夫が必要なんですが。

ワークショップなので、こんなデベロッパーキットを使って手を使って実験しました。

clip_image005

PMIC(Energy Harvesting Power Management IC)が載せてあるボードに、ソーラーモジュールをくっつけて、あちこちに持って行くと、電波強度/温度/湿度センサーが動きます。

ソーラーパネルを使う

諸々のドライバーのインストールがあるのですが、こんな風に小さなソーラーパネルから給電して、PC側でBLE通知を受けることができます。

埋め込み画像への固定リンク

Windows デスクトップのサンプルアプリが付いていて、電波強度≒センサーとの距離、温度/湿度を取得できます。

image

電力消費を計算する

このワークショップで面白いところは、実際にテスターとオシロスコープを使って電力消費量を計算するところです。ソーラーパネルでは5.5V程度の電流が流れるのですが、電流のほうは70uA程度しか流れない。オンボードのセラミック容量コンデンサ(100uF)を使って一時的ため込むわけですが、あまり連続して湿度/温度センサーから読み取りしてしまうと、BLE通知をするための電力が足りなくなるという現象が発生するんです。このため、「待ち」の部分を長くしないといけないし、実際には湿度センサー読み取りと温度センサー読み取りの間も時間を置かないと給電ができない、という仕組みを学んでいきます。

clip_image006

オシロスコープって初めて使ったのですが、ああなるほど、こういう風に使って計算するのかという実地が解かりました。

手元でキャプチャをするのは、ひとつのセンサーしかないのですが、会場では30名ぐらいの講習のセンサーを一気に取得できるというデモもありました。温度/湿度センサーはI2C通信しているそうなので、加速度センサーも積むと(GPIO経由で接続できる?)と傾きとかもとれるかも。ボタン電池ではないため、常時供給のように頻繁に送信することはできません。実際、BLE対応なので用途的にも10秒間隔とか比較的長い間隔で通知を飛ばすことになります。あとは「待ち」の部分をうまく調節するとか、外部コンデンサを積んで容量を増やして蓄電させるっていう方法になりますね。

USB-BLE Bridge は必須?

BLE Smartなのだから、iPhoneから BLExplr を使った接続できるのでは、と思ったので試してみました。

埋め込み画像への固定リンク

電波強度だけ取れているような取れていないような、ビーコン要素だけならばこれでできそうな感じ。温度/湿度センサーの読み取り関係は、Bridge が必要なのかな。このあたりは、別途調べるか、問い合わせしてみましょう。

そんなわけで、ポータブルなオシロスコープが便利だったので、購入欲が再燃中。

カテゴリー: 勉強会 | サイプレス社エナジー ハーベスティングのワークショップに行ってきたよ はコメントを受け付けていません

C++/CLI と C# ライブラリを混在させるときの構成マネージャ

とあるプロジェクトで C++/CLI と C# ライブラリを混在させたときの構成マネージャの記録を残しておきます。ライブラリのほうは、既存のC/C++ライブラリを想定して、それをC#から使いやすいようにラップします。まあ、C#から直接C言語のDLLを呼び出すことは可能なのですが、後々のメンテナンスを考えると、インポート文の羅列はちょっと避けておきたい。C++/CLI を記述するにしても、これもメンテナンスが大変(C++/CLIを知っている人が少ない)なことを考えれば、ある程度C#で書ける部分を多くしておくほうがよいでしょう、という発想で構成を作ってあります。

clip_image010

この構成が妙に複雑なのは、デスクトップアプリ側にサービスとしてC/C++のDLLを利用する部分が存在し、これをストアアプリからローカルHTTPで利用しようとするスタイルのためです。ストアアプリではWin2Dを使っていますが、これがDirectXになると、C++/CXまで参戦するという大混乱状態になりますね…な感じです。

上記のプラットフォームを見ると、x86, Win32, Any CPUが混在していますが、これでokです。プラットフォーム名を「x86」などに揃えようとしたのですが無理でした。ビルドするたびに「構築されているプロジェクトのプロセッサ アーキテクチャ “MSIL” と~」という警告がでますが無視して大丈夫です。

嵌りどころとしては、C++/CLIのプロジェクトを追加したり、ストアアプリのC#プロジェクトを新規に追加したときには、「ビルド」のチェックが外れているということです。参照設定などでプロジェクト参照をしてれば自動的にビルドの順序は設定されるのですが、プラットフォームが異なるせいか、このビルドのチェックが外れたままになっています。C++/CLI と C# デスクトップアプリ、C#ストアアプリを混在させるときは、ここのプラットフォームを選択した後でビルドにチェックをいれておきます。これによってソリューションからリビルドしたときに、普通の C# プロジェクトのように依存関係を見てすべてリビルドされます。そうしないと、ビルドされないまま残った DLL があったりして、正しくビルドができません。

image

参照設定としてややこしかったのは、デスクトップとストアアプリ間のデータを共有するために、C#で作成したPCLを利用するということです。このPCLをシリアライズ/デシリアライズすることで、データ通信を楽にしています。.NETリモートはストアアプリでは使えない(マーシャリングが使えない?)ので、自前でシリアライズする訳ですね。シリアライズ自体は、DataContractSerializerを使っているだけなので難しくはありません。その分データ量が多くなってしまうのですが、まあ、ローカルで通信する分には問題はないでしょう。

これがさっくりと実機で動くかというと、そうでもなくて、

  • VC++ 2013 用の再配布可能パッケージをインストール(msvcp120.dll、msvcr120.dll)
  • netsh でのポート設定
  • 依存するDLLの配置

を適切にやらないとうまく通りません。そういう意味ではオールC#で書いておくと、そのあたりの懸念点は減るのですが…、まあ既存のC/C++のDLL呼び出しのときは、C++/CLIを使いたいところですよね、ってことで、メモ書き的に。

カテゴリー: C# | C++/CLI と C# ライブラリを混在させるときの構成マネージャ はコメントを受け付けていません

Windows フィードバックで英語版フィードバックを見る方法

木澤(@tkrx178)さんの

 

確かに、Twitterに文句を垂れるだけでは駄目ですよね。プレビュー版では、いくつか不具合情報を送ったりしていたのですが、Windows 10 でもフィードバックを送りましょう。ってことで、改めて開いてみたのですが…、あれ?このフィードバックって数が少なくありませんか?日本語だけでフィードバックされている訳ではなくて、英語のフィードバックは何処に?(実は、これを見たときには Windows IoT Core の日本語フィードバックは0件だったんですよね。今では2件入ってます)。

image

日本語フィードバックを米国MSの中の人が見ているのか見てないのかは別として、英語圏ではどのようなフィードバックが送られているのかが気になるところです。どうやったら見れるのか?ってのが気になってあれこれ探していたらいい方法を見つけました。

英語版OSを使う

正攻法としては、Windows 10 の英語版を使う方法です。US 版だから、US の Windows フィードバックが開かれるのは当たり前。

と思って昨夜やっていたのですが、今朝みるとなぜか英語OSの中で日本語フィードバックを呼び出しているんですよ。あれ?Windowsアカウントが日本語だから、英語OSなのに日本語になってしまった?

image

と思ったら、右下のキーボードが「日本語」になっているんですよ。

キーボードを英語キーボードに変える

実は、業務の都合があって私のPCには、日本語キーボードとUSキーボードの両方のドライバが入っています。「言語設定」を開いて、English が追加してあるのです。

image

言語設定(キーボード)は、タスクバーの右下にある「J」のアイコンで切り替えができます。通常は Microsoft IME を動かしていると思うので、これを ENG にすれば ok です。

image

そうすると、日本語キーボード(Microsoft IME)の場合は日本語の表示だったものが、

image

英語キーボードに切り替えると、英語圏のフィードバックになります。

image

フィードバックの数自体が変わっているのが解りますよね。再検索(別の項目をクリックするなど)すると、英語/日本語が切り替わるので、どうやら POST するときの言語設定をキーボード設定から取ってきているようです。Windows フィードバック自体は、ストアアプリ(Universal アプリ)で作られているので、ストアアプリの設定自体が OS 自体の言語設定じゃなくて、キーボード設定からとってきているのかもしれません。ちょっとここら辺は解らず。

ちなみに、Windows フィードバックアプリ自身に対するフィードバックを送るカテゴリもあります。「アプリ」→「Windows フィードバックアプリ」に送れば、フィードバック自体も改善されるかもしれませんね。

image

これは、日本語で送ったものなのですが、後で英語に訳して英語キーボードに切り替えて送ってみようと思います。

~~~

英語キーボードにして送ると、英語OSの Windows Feedback で検索できるようになりました。どうやら、直接米国MSに伝えたい内容は、

  1. Windows フィードバックを立ち上げる
  2. US キーボードに切り替える
  3. フィードバックを送信する。

という手順で送ると、米国MSから見えやすい状態になりそうですね。

カテゴリー: Windows 10 | Windows フィードバックで英語版フィードバックを見る方法 はコメントを受け付けていません

祝!Windows 10 IoT Core 正式リリース、そして TI SensorTag が動くまで

MS太田さんのつぶやきに Windows IoT Core だと BLE 使って簡単に Azure に、という話があって、でもなー、現状の Windows IoT Core on Raspberry Pi って Bluetooth のドングルが付いてなくて…と思っていて、念のためサイトを調べ直したら、リリースノート

image

な感じで書いてあるじゃないですか!!! 確か1か月前のリリースをつい先日見たときにはなかったはずで、となるとひょっとしてバージョンアップしたのでは?と思ってダウンロードしてみれば。おお、バージョンが変わっている。しかも、よくよく見れば「Windows 10 IoT Core Public Release」になっている訳だから正式版ってことですよね。ダウンロードして、RPi2 上で動かしてみれば、バージョンは 10.0.10240。これは、PC 版のバージョンと同じ。ってことは、7/29 に同時リリースしてたッ!!! ってことですね。なんというか、もうちょっと知らせてくれればいいのに(ひょっとすると Windows Dev Center のメールにはあったかもしれない)、あれだけ Build 2015 でやっていた訳ですから、もうちょっと宣伝しても良いのではないかと。

そんな訳で、晴れて正式版になった Windows 10 IoT Core を使ってみましょう、ってことでざっくりと。

SD カードは Windows 8.1 でも作れる

最初のプレビュー版では、SD カードへの焼き込みは Windows 10 からでしかできなくて、VMWare を使ったり Mac から焼きこんだりしていた訳ですが、正式版では(正確には1か月前のプレビュー版も可能)、Windows 8.1 からも SD カードへの焼き込みができます。

Windows IoT – Setup your Raspberry Pi 2
http://ms-iot.github.io/content/en-US/win10/SetupRPI.htm

上記にある通り、DVD イメージの iso ファイルをダウンロードしてインストールを済ませると、こんな風なインストールツールが使えるようになります。

image

これを使って flash.ffu ファイルを SD カードに焼き込めば ok です。Windows 10 IoT Core Build 10240について | WIAA さんのところも合わせて参考にしてください。

サンプルは github/ms-iot/samples にある

色々試してみるときに、さっくりとコードがあるとよいので(ピン配置とかが固有なので、それのあたりは見ないと駄目なんですが)、https://github.com/ms-iot/samples からサンプルコードをダウンロードしておきます。

Windows IoT – Start Coding
http://ms-iot.github.io/content/en-US/win10/StartCoding.htm

ここに動かせるものがあるので、これを Visual Studio 2015 でビルドして RPi 上で動かします。デバッグ実行するときに、

  • ターゲットを「ARM」に変更する。
  • リモートコンピュータで、認証を「なし」に変更しておく

image

ことを忘れなければ大丈夫です。

WiFi, Bluetooth, 無線マウスが(制限付き)で使える

USB の有線マウスは、ほぼどんなマウスでも大丈夫です。無線マウスは、手元の Microsoft Wireless Mobile Mouse 3500 がうまく動きました。ただし、Bluetooth と無線マウスを同時に差し込むと、電圧の関係で動作が不安定になるので、どちらかという感じですね。

WiFi ドングルは使える、ということになっていますが、正式サポートでは Raspberry Pi のオフィシャル WiFi ドングルのみです。Windows IoT – Using WiFi on your Windows 10 IoT Core device. 手元にある、Buffalo の WLI-UC-GNM は駄目でした。

Bluetooth ドングルは Windows IoT – Bluetooth Support の中では、Orico のドングル(アメリカだと安いらしい)のみサポートなのですが、手元にある Buffalo の BT ドングルで動きました。おそらくチップが「CSR8510 A10」であれば動くような気がします。

BLE のサンプルを動かす

Windows IoT – BLE GATT Sample – Code
http://ms-iot.github.io/content/en-US/win10/samples/BLEGatt2.htm

で紹介されている TI SensorTag を試しています。SensorTag は Bluetooth Low Energy で接続するのと、加速度センサーや温度センサーが付いて実験的に使えます。以前買ったもので、大体 5,000円位です。いまだと、Blue Ninja とか、konashi 2.0 あたりを使えばよいでしょう。

 

サンプルを動かすときに、Windows IoT Core 側に設定が必要です。あらかじめ、Bluetooth ドングルと SensorTag をペアリングしておきます。

このペアリングツール、PowerShell 上では使えなくて、なぜか SSH 上で使います。入力パイプのところが変なだけなので、PowerShell 用には…というか、通常のコマンドライン用に切り替えることはできるかなと。Tera Term で接続しようとしたのですが、なぜか10秒位で切れてしまうので、素直に Putty を使ってください。

SensorTag は BLE なので、「C」で BLE のほうに切り替えてから「P」でペアリングをします。ピンコードを入力すればokです。

Pairing Tool 1

Visual Studio 2015 からビルドをして、リモートコンピュータで実行すると、こんな風に画面に Sensor タグから取得した結果を表示します。

色々繋がってしまうので(特に有線LAN)、いまひとつ組み込みシステムの恩恵が感じられませんが(苦笑)、まあ、ディスプレイを7インチの小さなものを使ってみたり、LAN は外してしまって Bluetooth 経由でデータのやり取りを行えば、結構モバイル的に使えるでしょう。BLE だけでなく、通常の Bluetooth が使えるので PC と直接つなげることもできます。

PC から Windows IoT Core にペアリングする。

image

ちなみに、アプリ自体はユニバーサルアプリになっているので、デプロイ先をローカルコンピュータにして x64 あたりでビルドすれば、普通の PC でもそのまま動きます。なので、GPIO のような制御がない場合であれば、一度 PC で実験しておいて、その後に ARM でビルドをして Windows IoT Core のほうで使うということが可能ですね。

image

そんなわけで、再びロボットアームを動かすところを、後日。

カテゴリー: RaspberryPi, Win IoT | 祝!Windows 10 IoT Core 正式リリース、そして TI SensorTag が動くまで はコメントを受け付けていません

Windows 10にアップデートしたらHyper-Vのネットワークが効かなくなった場合

ほぼ、自分限定かもしれないけど、トラブルシューティング的に残しておきます。

現象

  • Windows 8.1 から Windows 10 にアップグレード
  • Hyper-V のゲストOSから接続できていたネットワークが繋がらなくなる。

原因

image

Hyper-V からは、Hyper-V Extensible Virtual Switch を通してホストOSのネットワークにつながっているのですが、もともとできていたネットワークアダプタ(「イーサネット6(無効)」と書いてあるもの)が、有効にできなくなってしまいました。有効にできない(削除もできない)のは妙な感じがするのですが、まあ、別なアダプターを作ってそっちに切り替えてやれば ok です。

最初は元のネットワークが有効にならなくて、あれこれ弄っていたいのですが、新しく作って切り替えた対処のほうが簡単そうです。

ちなみに、今の PC にはネットワークボードが2本差しになっていて、その一方しか使っていない、というのがトラブルの元っぽいです。何故か、ケーブルの繋がっていないほうに対して優先してつなげようとするので、ケーブルが繋がっていない「イーサネット4(未使用)」のほうは「無効」にしておきました。

対処

仮想ネットワークを構成する
https://technet.microsoft.com/ja-jp/library/Cc816585(v=WS.10).aspx

を参考にして Hyper-V の仮想ネットワークを再構成します。若干文言が異なる(「仮想ネットワーク マネージャ」ではなく「仮想スイッチマネージャ」など)ので、ちょっと注意が必要です。

Hyper-V マネージャを開いて、「ホストOS」→「仮想スイッチマネージャ」をクリック。

image

「新しい仮想ネットワークスイッチ」を選択して「外部」で仮想スイッチを作る。名前は適当に変えておくのがベターです。

image

ゲストOS(仮想マシン)のほうで、設定を選択肢て、ハードウェアの追加で「ネットワークアダプター」を選択

image

仮想スイッチを、先に作ったスイッチを選択して、適用すれえばよい。

image

これで、ゲストOSのほうから直接ネットワークにつなげることができます。

もとの動かなくなったアダプターが気持ち悪いのですが、まあ、ネットワークが復旧できたのでひとまずこれでok。

カテゴリー: Windows 10 | 1件のコメント

.NETラボ勉強会7月で Windows IoT on RPi のデモ

Windows 10 直前ということで、Windows 10 IoT Core on Raspberry Pi2 の発表を、.NETラボ勉強会でしてきました。2か月前のハンズオン(もどき)では、到底ロボットアームを動かすところまでいかなかったので、今回はデモで動かすところを中心に。

DSC02614

IoT ということで、クラウドに接続する話が巷では多いのですが、ロボットアームやら戦車を動かすことが主目的なので、ネットにつなげることは一切せずに(笑)やっています。現状の Win IoT on RPi の制限で、Bluetooth やら WiFi やらが繋がらないので、有線LAN オンリーになり無線でうろがしたいのに有線LANが必要という妙なスタイルになっていますが、このあたりはいずれリリースされる正式な Windows IoT で解消される予定です。

 

DSC02616

Windows IoT の概要とロボットアーム/戦車を動かすところまでで、詳細は省いてしまっています。中身のほうはぼちぼちとブログにアップしていきますね。

発表資料

Windows IoT on Raspberry Pi で ロボットアームを動かそう

動きもの

以下は、ソースコードも含めてぼちぼちと上げていきます。

グリッパーアーム

イスペット社 グリッパーアームを動かします。普通のブラシモーター5個をつかっているので、TA8428K モータードライバーを5個使って動かします。GPIO を制御するだけなので、比較的簡単なやつですね。

IMG_0173

タミヤギアーボックスを使った戦車

変速ギアのタミヤギアーボックスを使った戦車の例です。モーターが2個なので、L293D モータードライブを1個使って制御します。コントローラーには、xbox 360 コントローラーが使えます。そのうち、Bluetooth が使えるようになったら、xbox one コントローラーでも動かせるかもしれません。

IMG_0179

下に写っているのは、車軸付モーターギヤボックス です。低速ギアがすでに入っているので、ゆっくり動かすのには便利です。

meArm

phenoptix 社から購入した meArm を使ったロボットアームです。サーボモーター4個を、PCA9685 で制御します。Arduino だと PWM 制御が簡単なのですが、Raspberry Pi だとちょっとやりづらいので、I2C 対応の基板を買って作成します。Adafruit 16-Channel 12-bit PWM/Servo Driver – I2C interface – PCA9685 を使っています。

IMG_0175

という訳で、Raspberry Pi で色々動かせることが分かったところで、次回はどうやって動かすのかという具体的なコードを紹介…ってのを作成中。

カテゴリー: RaspberryPi, Win IoT | .NETラボ勉強会7月で Windows IoT on RPi のデモ はコメントを受け付けていません

小5の夏休みにチケット駆動を再び

小4の夏休みの宿題をチケット駆動で乗り切る方法を模索 | Moonmile Solutions Blog
http://www.moonmile.net/blog/archives/6049

去年、試してみたチケット駆動ですが、結局のところ「監視作業」を1週間やりました。今年も同じで夏休み前の連休に計画を立てたのですが、初日からムリ…だったので、再び監視してます。「監視」とは言いますが、脇で仕事をやっているわけで、そのあたりは「習慣づけ」の問題です。ある程度「習慣化」してしまえば、習慣自体が苦にならなくなるので、本人的にもそれほど大変になりません。これは諸刃の剣で、将来的に、無意識に誰かの監視下で習慣化させてしまう危険もあるので、ほどほどにしておきましょう。

その日のチケットを作る

いくつかの宿題(公文とかも含めて)があるので、箇条書きとして書き出します。ただし、1枚に箇条書きにするのではなくて、付箋を使います。今回は、大き目の付箋にひとつひとつ書き出し。

慣れてくると、箇条書きにチェックマークを入れるだけでも進むのですが、チケット駆動の良いところは、

  • チケット=作業単位の順序をさっと入れ替えられる。
  • 終わった作業(チケット)をチェックすると達成感を得られる。

という2点があります。カード的に並べた付箋のチケットを、「これからどれをやるのか?」と1枚選んでやり始めます。PSP(Personal Software Process)を兼ねて、開始時刻と終了時刻を書いて集計してもよいでしょう(今回はやってません)。夏休みの宿題にせよ、仕事の作業単位にせよ、時間制約(締切)があるので、掛かる時間を意識しておくことは悪くはありません。そのあたりは、ほどよく時間を気にしながら(進捗状態を気にしながら)作業を進めるというのがポイントですね。ええ、外側から「進捗どうですか?」と短期的なポーリングを掛けるのは論外です。見ればわかるのですから。デマルコ著「ピープルウェア」の第20章の「チーム殺し、7つの秘訣」を避ければ十分です。

カテゴリー: 雑談 | 小5の夏休みにチケット駆動を再び はコメントを受け付けていません

計画を見直せない病、という点で国立競技場の件を考える

すわ、例の中抜き構造ですか?と思っていた国立競技場の予算超過の件ですが、新国立競技場の工事費が下がらない理由|建築エコノミスト 森山のブログ を通読していくと(「~めぐる議論について」も全て読む)、概算をせずに決定をしているのではなく、コンペの後に概算が来るというコンペ後の決定プロセスの問題みたいです。まともに作ろうと思えば 3,000億円、という価格(?)は正当なもののようです。ちなみに、森山さんのブログは進撃の巨人あたりから読んでいるので、読者としては古参です。

コンペをした頃の予算が不明なのですが、新国立競技場 – Wikipedia によれば、当初見込みが 1,300億円となっています。他競技場が500億円ぐらいなので、見込自体も高いし、その後の全部のせ状態で3,000億円という見込みも相当高いです。高いです…が、これは中抜き構造ではなくて、先のブログにあるように正当に建設したときの価格なので、それだけ掛かるということですよね。それはそれでokです。というところから議論をスタートさせます。

私としては「福島原発は完全にコントロールされている」という首相の言葉が嘘っぱちで、その後の招聘云々も全然嘘っぱちなので、国立競技場が建つとか建たないとかには興味ありません。あくまで「当初の計画/予算を大幅にオーバーしているときに、それを見直せないのは何故か?」に焦点をあてて考えます。まあ、内実は見栄とか誰かが得をしているとか、そういう問題に帰着することが多いので国立競技場そのものに関してはパス。都民なので、都民投票があったら行くぐらいのことはしますが(それくらいの権利はあると思う。都民税を払っている身だし)。

関連図を作る

本来はもっと複雑ですが、簡略化させます。

image

  • 国/都から計画者(コンペ主催とか有識者会議とか)に予算を割り当てる。
  • コンペなり試算をして施工者に発注する。
  • 施工者が立てた国立競技場を国民なりが利用する。
  • 国民なり都民なりは、国に税金を支払う。

と考えます。内情は色々あるのですが、モデル化するとこんな感じでしょう。ツイッターなどを見ると(テレビはあまり見ないので、あとは新聞とかWEBサイトの諸々ぐらい)、色々どうすればいいという意見がありますが、その意見は「立場」によって違ってきます。国の立場なのか、国民の立場なのか、実施者の立場なのか、計画者の立場なのかということですね。それぞれ相手のことを慮ったり全体最適化を考えれば、そんなことが言えないはずなのに、そういうことを言ってしまうのも「立場」の問題です。でもって、立場から出てくるさまざまな「?」な発言は、立場の違いもあり「当事者」ではない(それぞれの立ち位置にいない)ことから、行動経済学的にもそういう思いに動くでしょう、って感じです。例えば、

  • 国や都の立場からすると、納税分でつくるので「お金」を自分で払うわけではなく、「予算」としての数字でしかない。
  • 計画者にとって予算を割り当てられた場合、「予算内」では自由に利用できる。予算超過分を「国/都」に出すのは難しい(国立競技場に関しては、コンペ→予算の順で決定するので、現在は予算計画の段階、予算が決まってしまうと、後からの修正は難しい)。
  • 実施者にとっては、実際に材料費、人件費等がかかるので、赤字にならないように注意する。よって、ある程度の「保険」を見込む必要がある。
  • 国民にとっては、税金を支払い、利用をする立場ではあるものの「税金」と「利用」の間は遠い。

というそれぞれの立場があるので、立場ごとに語っても立場ごとの効率を最大化するだけで、全体の効率は良くなりません(一瞬、良くなるように見える場合もあるけど)。そこには、全体の計画を見直す必要があるのですが、大抵の場合は「計画を見直さない」ことになります。何故か?

計画を見直すコストを考える

ITプロジェクトでは、よく計画を見直さずに突き進んでデスマーチ化するプロジェクトが多いのです。経済的な理由もありますが、大抵の場合は「交渉コスト」の増加のため、計画を見直しません。交渉コストというのは「行動経済学」でいう、人と人とのか関わりです。相手を説得するとか、相手に自分の意図を伝えるとかいうコストです。例えば、ジュースを買うときに、お店で買うのと自動販売機で買うのと、どちらが楽かというのが交渉コストです。ちょっと位、送料がかかっても Amazon のほうが便利ですよね、というアレです。

計画を立てたときに、後から計画を立て直すのが大変なのは、「計画が変更になった理由を相手に伝えなければいけない」というプレッシャーです。プレッシャー≒交渉コストですね。心理的であれ経済的であれ(飛行機で行かないと駄目とか、大勢集めないといけないとか)、「交渉コスト」が実際の負のコスト(予算の超過等)を上回ると、交渉しなくなります。つまり計画を見直さなくなります。「日本が戦争に負けた~」構造が今にも伝わっている、ような日本特有の構造に帰着させる意見もありますが、私から言えば「交渉コスト」の問題です。風土ではなくて、人と人との関係の構造ですよね。

アジャイル開発が一般的にきっちとした計画を立てない(チケット駆動を使うとか、スクラムを使うとか)のは、計画の変更コストが高いためです。変更コストは、時には M$ Project を使ったときに見直しが大変、という理由もあります。特に Excel で計画表を立てている場合、この変更コストが増大して、Excel の表を変更するのが面倒だから計画を変更しない、という巨大な「交渉コスト」が発生することがあります。

そんな訳で、計画自体にコストをかけてしまうと、計画を変更すること自体のコストが「モッタイナイ」ことになります。変更するコスト≒交渉コストが、当初の計画コストを上回るためです。

交渉コストを考えるときに重要な法則として、人は時間的に遠くのものはコストを低く見積もるという法則があります。時間によるバイアス効果なのですが、同じ利得であれば、遠くの利得よりも直近の利得のほうを好みます。これは損失の場合でも同じで、遠くの損失よりも直近の損失を強く感じます。逆に言えば、直近の損失よりも遠くの損失を弱く感じるわけです。過去に大きな損失があっても過去が過去であれば忘れてしまうし、遠くの未来に損失があっても直近のわずかな損失に目を取られます。これは交渉コストにも適用できるので、過去の計画コストは時間的に遠くであるがゆえに、低く見積もられがちになり、相対的に再計画を立てるときの交渉コストを高めてしまいます。これが、計画を見直したくない病の主な原因です。

このあたり、遺伝子的な進化論的にも同じで、環境に順応するために脳の効率的な活用をするときには、直近の減少に対して「習慣的」に効率よく対処する必要があります。このため、過去の成功体験(生き延びた経験)に準じて、現状に対処します。つまり過去の計画に沿って、現状に沿わずに再計画せずに進むほうが楽なんですよね。これは、個々の生物にとっては不利な状況(死んでしまうとか)に陥ることになりますが、群全体にとっては有利に働きます。一部が残って「遺伝子」を伝えていけばよいわけです。これが国レベル、民族レベルで起こっていると考えればokです。

計画自体のコストを下げる

  • 計画を見直すための交渉コストが高い
  • 時間的に遠くのコストは逓減される

という2つの現象を組み合わせると、計画を見直したい場合には、そもそもの計画を立てるコストを下げるという方法が良さそうです。きっちり細かく計画を立ててしまうと、現状でそれに従うほうが交渉コスト(実行コスト)が下がるので、自然と「計画通り」に進めることが一番の効率化になります。そうです。計画駆動が一番効率が良い状態は、「まったく変更がない」ときに効率が良くなるという現象です。となれば、未知数がないときには、緻密な計画を立ててそれに沿って進めるとコストが低くなります。実は、プロダクト=製品開発、ベルトコンベア生産の場合には、これが当てはまります。それぞれの作業を最大化することで、効率があがるので、それぞれの場所で考えることはせずにあらかじめ計画を立てて作業手順を決めておきます。

逆に、実行時に計画にはずれることが多いことが予見できたならば、計画自体に大きなコストをかける必要はありません。その都度、計画を見直すコストを下げるように、大計画≒大き目な方針、と小計画≒それぞれの現場の作業とを分ける必要があります。労働集約的にアジャイル開発やセル生産などは個々の力量/能力に追うことが前提となっていますが、それは個々の力量/能力が、最初の計画では推し量れない≒変数だからです。

逆説的ではありますが、時間によるコストの低減効果に従えば、

  • 「作業ごとに計画を立てるコスト」<「過去の計画に従うコスト」

となるようにすれば良いわけです。綿密な計画を立ててしまうと、過去の計画に従うほうがコストを下げるので、無駄な計画に従っているほうが楽、という状態に陥ります。良くも悪くも、隷属化しているほうが楽というのがこの状態ですよね。「作業ごとに計画を立てる」というのは、個々が作業に対してコストを下げるように努力をするということです。イコール楽をしようとすることですね。楽をするためには、頭を使って無駄な作業をしないようにしないといけません。このあたりはセル生産に詳しいですね。

小規模の計画は個々にまかせて、全体の計画(全体の予算)等の大枠だけ決める方法をとってみましょう。

  • 国や都としての「出せる予算/工期」を決める。
  • 計画者では「出せる予算/工期」内かを見積もることに集中する。
  • 実施者は「出せる予算/工期」内で実施する。

という予算と工期の大枠を決めます。予算の大枠が決まれば、そのうちで高いかどうかは別な話です。それがザハ案であろうと、別の案であろうと、他の競技場の500億円という予算内で収まれば、何でもいいでしょう。逆に言えば、大幅に予算や工期を超えると想定された時点で、それはアウトです。

再計画のコストを下げる

計画変更のストを考えるためには、2つの視点が必要です。

  • 過去の計画に従うよりも、再計画をしたほうがコストが安くなる
  • 再計画するときの交渉コストを下げる

誤った(と思われる)過去の計画を捨てて、やり直す場合には、先の国立競技場の予算組みのように「大幅な予算超過」が効率的です。3,000億円としたり、ちまちま削減したりせずに、「ザハ案にすると5,000億円超かかります。だから見直しましょう」で有無を言わせずですよね。駄目なものは駄目なんだから、前計画がどれだけコストがかかるか(駄目さ加減)を強調すれば、再計画のコストは相対的に下がります。かつ、前計画を進めたときに、超過する金額が膨大になります。ちなみに、国立競技場の場合は、国民/都民からの税金なので、このあたりの手法がとりにくいのですが、ソフトウェア開発の場合、「代案」を出すときにはこの手法が使えます。このままいくと、これだけ超過します、という場合には「大幅に超過する」ことを強調した後に「代案」を出すというテクニックですね。

  • 「前計画を見直さないときのコスト」>>「再計画したときのコスト」

もうひとつ、再計画自体の交渉コストを下げておきます。これの主な手法がアジャイル開発にあります。綿密な計画を立てるのではなく、おおざっぱな計画に沿うようにして変更しやすくします。変更しやすくする手段としては、きっちりとした計画表を作るのではなく、チケット駆動などを利用します。勿論、将来的に「計画駆動」の計画自体が流動的に変更可能になれば、話は別なのですが、現状のところ計画を変更する≒計画表を変更するコストが高いために、このような現象になっています。

国立競技場の件で交渉コストを下げる(この場合は、「予算が超過してしまうから、ザハ案を捨てて別の案にする。あるいは、旧国立競技場をそのまま再現する」等の提案)ためには、交渉コストより将来的に得られる利得が上回ればよいのです。

  • 「将来的な利得」>「計画を見直す時の交渉コスト」

ただし、将来的な利得は時間的な低減効果があるので、それなりに見合うだけの大きな利得(想像ではあっても)が必要です。このあたりは、損失ではなくて利得にしないと駄目です。損失の場合は、やはり時間的な低減効果が働いてしまって、先行きの赤字(国立競技場の年間赤字)が低く見積もられてしまって(実際、0.4億円プラスという試算が出てきてしまう始末)、相対的に現在の交渉コスト≒再計画のコストが高くなってしまいます。よって、計画を見直したときの「利得」がより多いことを前面に押し出すとよいのです。ソフトウェア開発で言えば、現状の実装が難しいものや、危うい動作を削除してしまい何か別のものを付け足すことによって、運用時のコストが下がりかつ利得が多く得られる可能性がある、という具合に話を持って行きます。

計画を変更するための原動力を加える

計画や構造が正しいとか正しくないとか、過去の戦争の失敗のあれこれとか民族性だとかナントかではなくて、計画を変更するための力を加えればよいのです。計画を変更することが目的なのですから。それも方向的に対峙する方向から力を掛けるのではなく(真っ向から反対という意味)、横から力を加えます。場合によっては、ななめ後ろから力を加えるわけです。援護射撃っぽく見せて、かつ行かせたくない方向に射撃する(後ろから打たれたくないから、その逆に走る)という方法です。

まあ、国立競技場の件はさておき、計画を見直せない病を疑似体験しておくのも悪くないかと、と思って書き下しておきます。

カテゴリー: プロジェクト管理 | 計画を見直せない病、という点で国立競技場の件を考える はコメントを受け付けていません

Windows IoT on Raspberry Pi で動作するマウスを探す

ちょっと…というかかなり間が空いてしまいましたが、Windows IoT on RPi2 の続きです。今月末の .NET ラボ勉強会で再び Win IoT のデモをやるので、それの下準備も兼ねて。

先日、大量のマウスをオークションで購入しました。30個程度(おまけが8個だったか)で送料込みで2,000円弱ぐらい。今回は種類が欲しかったので、秋葉原の中古をあさるよりもこの手のがさっとした種類が欲しかったので丁度よかったのです。

https://pbs.twimg.com/media/CHqQRg8UsAAQTCZ.jpg:large

Win IoT on RPi2 の場合、特定の場合のマウスしか動かなくて、どの「特定のマウス」が動くのかはは解りません。リリースノートには、マウスが動かないときには他のマウスを使ってくれというコメントがあるだけで、特定はできないのです(開発者が使っているマウスの種類が解ればいいんですけどね)。

ブログ等をちらちらと眺めると動いている人もあるのですが、自分のところのマウスでは全く動きません。仕方がないので、.NET ラボの方にいくつか借りたのと、上記な感じでがさっと検証用に買いました。

結果

ちまちまと接続してはチェックを繰り返すこと1時間ほどですが、大体の傾向はつかめたので結果を張り付けておきます。

image

DELLやVaioの古いマウスが動いたので、どうやら解像度の問題っぽいですね。古めの解像度の低いUSBマウスを利用すると良いようです。おそらく手に入りやすい(中古で)、Microsoft Optical Mouse の一番古いタイプだと思います。

image

これらの動くマウスを使うと、Windows IoT の画面で右上の電源ボタンを押すことができます。こんな風にメニューがでます。

image

25日の .NETラボ勉強会では、マウスでロボットアームを制御する話ができればよいかなと。あとできれば、meArm と Windows Remote Arduino のデモも交えて。

カテゴリー: RaspberryPi, Win IoT | Windows IoT on Raspberry Pi で動作するマウスを探す はコメントを受け付けていません