詰将棋のようにTDDでC#を学ぶ実験(2)

逆引き大全のほうは、サンプルに対して1tipsという制限があるので、あまり盛り込めないが、詰将棋 TDD のほう(あるいは「覚醒プログラム学習」)のほうは、1問(1プロジェクト)に対して、ごっそと覚えるべきことを詰め込んである。というか、クラスの構造とかファイルストリームとか別々に書くと面倒なので、ひとつのテストクラスにしてテストメソッドだけ分けるというスタイルにしている。

image

項目の出し方は、IDEF0 や五行を使っているのだが、そもそものネタは patterns & practices に則っている。パフォーマンス・チューニングをする上で、

  • CPU
  • メモリ
  • ストレージ(ファイルシステム)
  • ディスプレイ
  • データベース
  • ネットワーク

を考える。業務システムで何をするかによるので、何処かが「ボトルネック」になる。ボトルネックを解決する仕組みは「クリティカルチェーン」を参考にすればよいだろう。所謂 TOC の話になる。

業務用 PC を組んだり、システムを設計するときもこの「ボトルネック」を意識する。そうすると、無駄なコストを支払わなくて済む。

ストレージ絡みを10問追加

moonmile/TestPro: TDDで学ぶC#
https://github.com/moonmile/TestPro

ざっと、ストリーム/ストレージ絡みを10問追加しました。テキストファイルの読み書きから、バイナリデータ、構造体、JSON形式、XML形式まで含めたので、業務システムで使うテクニックは入っていると思う。これができると、ストレージによる永続化が可能になるので、お試しにどうぞ。

カテゴリー: C#, TDD | 詰将棋のようにTDDでC#を学ぶ実験(2) はコメントを受け付けていません

詰将棋のようにTDDでC#を学ぶ実験

「ハチワンダイバー」を通読したので、浦野真彦著「1手詰めハンドブック」を買いました。子供用にどうぶつしょうぎを買っている訳ですが、結構いけそうなので、それならば詰将棋を試してみようという次第です。自分で読むというのもあるけど。私は、7手詰め位でギブアップですね。

[amazonjs asin=”4839933324″ locale=”JP” title=”1手詰ハンドブック”]

将棋とプログラミングは似ている

プログラミングは、新しい問題を解決すると同時に、既存の問題を解決する手段でもあります。新しい問題ってのは、人工知能とかVRとか、新しい技術ですよね。なんらかの技巧を駆使して実現するわけですが、一方で、みずほ銀行リプレースのような既存の技術の積み重ねで成り立っているところもあります。所謂、社内の情報システムの構築なんかは、大抵はこの「既存の技術」の組み立てで十分だったりします。そのあたりを主な仕事にしていると、面白いか面白くないかは別として、仕事としてやっていけるかが重要になります。

それを将棋に例えれば、終盤の詰めの場面で、詰められるかどうかの棋力が重要なのと同じで、きちんと構築されるべきモノに対しては、きちんと構築する力量が必要でしょう。プログラミングで言えば、基礎体力というべきものでしょうか。

「1手詰めハンドブック」は面白い構成になっていて、駒の種類と動き方を網羅かつ分類して詰将棋が作られています。なるほど、手駒に何があったとき(あるいは何もなかったとき)、盤面に何の駒が配置されていたときには…という具合に分類ができるわけです。1手詰めですから、手駒を打つか、盤上の駒を1手だけ動かすか、という基礎的な力が試されるものです。実際の場面では、1手で詰むかどうかは分からないわけですが、詰将棋の場合は「必ず1手で詰む」というルールがあるわけです。

これをプログラミングに置き換えると、

  • 仕様変更があったときに、どこの行を修正すれば、仕様を満たせるのか。
  • バグが見つかったとき、どこの行を修正すれば、バグが解消されるのか。
  • 何か機能を追加したいとき、何を追加すれば、機能が満たされるのか。

という具合に、ちょっとずつ進めるところに似ています。

じゃあ、この1手詰めのところを、TDD(テスト駆動)に直してみたらどうだろうか?というアイデアです。

テスト駆動的に問題を解いて学習する

プログラミングを学習するときに、どうやったら一番よいのか…は、まだ判明していませんが、既にいくつかの方法は提案されています。

  • ひたすら、先人のコードを写経する
  • Scratch のようなブロック型の言語を使って学習する。
  • 独習 C# を読み込んで書物で文法から学習する。
  • Swift Playgrounds のように RPG のように学習する。
  • 学習ビデオを買って、学習する

などなど、何を目的にするのかによるので、一概に何がベストという訳ではありません。ただ、ソフトウェア開発を主とする会社に入ったときに、新人教育でプログラミングを学ぶ場合には「独習 C#」あたりが多いでしょう。文法をひと通り覚えるところからスタートという感じですね。

私も、以前は独習させる場合(大手でない場合は、新人教育のみというパターンは少ないので)、一定のペースで独習シリーズをすすめていたのですが、これが終わってもちっともプログラミング力が上がったように思えないんですよね。確かに、文法はきっちり覚えるかもしれないけど、現場に入ると既存のコードがあって、仕様変更があって、結局のところ、独習シリーズの中にあるような文法すべてを網羅することは皆無であって、当面は、最初の数か所を覚えるだけで済み、あとは現場としてどう対応できるかが問われてきます。

「現場に問われる」という問題は、新人を受け入れる側からみる「即戦力」という視点と同時に、新人/未経験者自身が「仕事としてやっていけるか」の心の支えにも関わります。経験と未経験のギャップが確実にあって、そこをうまく OJT 的にフォローできればよいのでしょうが、最近の現場をみると、それほどフォローできているとは思えません。これは、OJT のリーダーが新人にもっと寄らないと駄目なのか、逆に新人が現場に対して自己的に「戦力になり得る」と思えるかどうか、にも関わる話です。

そうなると、学習のための学習でプログラムの文法を覚えるよりも、まずは、手を動かす形で、コーディングができる状態に持っていくのが先決ではないか?と思い始めました。そうなると、文法を網羅的に知っているという面接的な質問ではプログラミング力というのは測れなくて、もっと、違う面を持ってこないと駄目ですよね。よくある、何か課題を出して解くというのもあるけど、あれもちょっと違う感じがしています(まあ、未経験者の振るい落としとしては良い方法ではあるのだけど)。

面接としてや知識としてではなく、仕事としてプログラミング力を測るのならば、それはちょうど詰将棋を解くのと同じではないか?と思ったわけで、そうなると、問題を解く(実際にコードを動かしてみて解決する)という点では、TDD がよいのではないか、と考えました。

ひとまず10問作ってみた

Visual Studio 2015 の C# で 10問だけ作ってみました。本来は50問ぐらいあると、それなりに学習&実践できるのでしょうが、やってみると結構問題を作るのが大変だったので。

image

最初の変数と配列の扱い方、クラスにいくつかのメソッドを実装するスタイルでコードを完成させていきます。コードを組んで、実際に動かすとテストメソッドがクリアされる(グリーンになる)ので、達成基準が解りやすいと思います。

moonmile/TestPro: TDDで学ぶC#
https://github.com/moonmile/TestPro

なところにコードをアップしたので、気になる方は試してみてください。

ターゲット層

将棋で云うならば、「独習 C#」で文法を学んだだけでは、将棋の駒の動かし方を覚えた10級でしかない。目標とするのは「文法を詳しく知っている」のではなく、「プログラマとしてパフォーマンスが出せる」ということだから、将棋に例えるならば、初段で相手に勝てる、ところまで持って行かないといけない。だから、途中途中で、棒銀や中飛車としての「型」を覚える(高速道路に乗る)ように、オブジェクト指向的なテクニックを学んだり、GoF でパターンを覚えたり、いくつかのフレームワークの使い方を学んだりする。しかし、それだけでは現実には「勝てない」。

[amazonjs asin=”4861916992″ locale=”JP” title=”初段になるための将棋勉強法”]

ならば、プログラマとしてパフォーマンスが出せる≒現実に勝てる、程度が初段としたとき、文法を覚えたときの10級との間はどのように登っていくのだろうか、ということになる。

詰将棋のように TDD で C# を学ぶ前提として、

  • 「独習 C#」などで、C# の文法を学んでいる(本で読んで知っている)
  • Visual Studio の使い方が分かる。
  • .NET Framework のライブラリの使い方/調べ方を知っている(ググるのでもok)

という座学みたいなものがあり、これと実践的な「初段」の段階との間に「詰将棋のように TDD ~」がある。疑似的に5級までの実践力が養えればいいだろう。

  • 新人が3年目程度のプログラマに
  • 未経験の中途採用が3年目程度のプログラマに
  • 未経験のプログラム言語に対しての学習
  • 中途採用するときの経験度の判別に(3年程度の経験)
  • 中途就職するときの実力披露に(3年程度を目安に)

までの、疑似的な実践(スパーリングみたいなもの)ができればよいかなと。

カテゴリー: C#, TDD | 詰将棋のようにTDDでC#を学ぶ実験 はコメントを受け付けていません

ユーザー領域が壊れたらしいので、リセットするまで

ここのところ、Windows 10 のブルースクリーンが頻発するのと、どうもユーザー領域が壊れたみたいなので、OS をリセットすることにしました。

色々、症状が変で、

  • 熱暴走でブルースクリーンになる。直後に立ち上げても BIOS すら立ち上がらない。
  • Visual Studio で UWP アプリを作ったときに、XAML デザイナが立ち上がらない。
  • Visual Studio からローカルコンピュータへ UWP アプリがデプロイできない。AppLocker ではねられる。
  • 新しいユーザーを作ってもスタート画面が表示されない。Win キーが効かない。

最初の熱暴走は、水冷式のファンの目詰まりが原因だったのですが、直したあとでも微妙にブルースクリーンが頻発したりして、メモリ自体の不具合かもと思ったのですが…「新しいユーザーが作れない」ところで、あまりにも致命的なので OS のリセットです。

Windows 10 Build 14393.51 cannot perform app update from Store: error 0x80073CF9
https://social.technet.microsoft.com/Forums/scriptcenter/en-US/30f092a3-3f05-43be-a6e5-d14f59d57a62/windows-10-build-1439351-cannot-perform-app-update-from-store-error-0x80073cf9?forum=win10itprogeneral

な人と同じ状況に陥りました。この人も、リセットしているので、どうしようもないみたい。

image

OS の再インストールでもいいんですが、あれこれ C ドライブに残っているものが多いので、個人用のファイルを残したまま初期状態に戻します。

Visual Studio やら Office やらが、ごっそり消えてしまうので、ソフトウェアの再インストールは必須なんですが、Hyper-V の設定やら、こっそり /User/<ユーザー名>/Documents 等に残っている設定は、そのまま使えるので、サラにするよりは楽なのでは?ということで。

C ドライブの SSD(512GB)が、残り 100GB 位でぎりぎりだったのですが、初期化したあとにあれこれと開発環境を入れなおしたあとでも、200GB 以上残るようになりました。

image

結構、クリーンアップしたつもりなのですが、アンインストーラーのゴミが 100GB 程度あった、ということなんでしょうね。なんだかなー。

Xamarin を入れて、Android Studio を入れて、Eclipse も入れました。Java はやるつもりはないのですが、買ったデジタルペーパーの Windows ツールが Java なんですよね。これを、プロトコル解析して C# に移す予定です。

カテゴリー: トラブルシューティング | ユーザー領域が壊れたらしいので、リセットするまで はコメントを受け付けていません

深夜アニメが少なくなっても構わないよね

クレームな話を先頭に置いておくのもアレなので、ちょっとアニメな話で流しておく。ふと、ツイッターで「アニメ現場の労働条件を守るために、深夜アニメが少なくなっても構わないよね」というようなツイートを見かけたのだが、そんなに多いのか…と思ったそんなに多いんだな。もともと、アニメを見る人口が10倍以上に増えたわけでもなく(深夜アニメは20年前からすれば10倍に以上に増えている…というか、20年前は深夜アニメって枠は無かったしなぁ)、そうなると、多少増えたとはいえ、単純に10分の1の労力でできるか、10分の1の賃金でしかうまく回らない訳で、深夜アニメ自体が「投資」の対象とされているかどうかはさておき、業界として収支が廻らないのはそうだと思うところだ。が、宮崎駿の現場とか虫プロのアニメの状況を考えたりすると、いやいや深夜アニメが増えるとか増えないとかいう以前に、そういう現場が続いてるという状況もある。で、深夜アニメという枠…というか、テレビ放送が24時間やるようになって、深夜の映画枠がなくなってしまって(古い映画を流しているだけだし、放送終了時間もあったから、それほど予算も掛からなかったはずだ)、バブル時代の24時間放送を経て、不況の時代から地デジになっても24時間放送にこだわるところで、予算が少なくてもアニメ枠で埋め合わせができる(あるいは、吉本芸人枠とか?)と考えたテレビ業界なのかもしれないし、受注するアニメ制作会社が放送枠だけではなくて DVD やキャラクターグッズなどの販売をあたることができる(実際、収支が合っているかどうかは別として)と考えたところに、落とし穴があるのではないかと思っている。単純に数を減らせばいいだけじゃないかと思うのだが、どうなんだろう。数を減らしてしまうと、クビになってしまうアニメーターの人が多いのかもしれない。

中学から高校に上がるときに「うる星やつら」を観て育って、「めぞん一刻」の頃は大学生じゃなかったのであまり興味が移らずに、大学生になった頃には「らんま1/2」は観なかったわけなのだが、当時、アニメが午後7時から8時までのゴールデンタイムに放映されたいた時代は、週に4つぐらい観れば十分だった。週刊の漫画雑誌でもそうなのだが、連載ものを追うときには自分の中の時間と漫画/アニメの中の時間が同時並行になる。いまでこそ、ほとんど季節感の無い連載とか、ワンクールで終わってしまうようなアニメが頻発するわけだけど(逆に、いつまでもやっているアニメもある)、半年の連載や放映の間には、半年という時間が自分の中にもあって、なにかが「成長」してしまう。そう、この歳になってしまうと「半年」ぐらいどうということはないのだけど、中高生にとっては「半年」というのは非常に長く、貴重な時間の枠でもある同時代性を持っている。だから、ある程度の長さがあるアニメ枠(深夜枠を観るとは限らないし、観ているのは大学生以上なのかもしれない)を眺めていて思うのは、やっぱりもう少し少なくても良いのかもしれないという結論だ。

勿論、中高校生だけのものではないから(30年前はそうだったけど)、それはそれでいいんだけど、そこのある「半年」というリアルな時間の捉え方の差は考えてほしいかなと思ったりする。ただ、Amazon プライムなどのように、過去のアニメや映画が一気に見れるようになってきているので、テレビで毎週という枠に縛られることなく、集中的にアニメなどの「作品」を吸収することが簡単になっている。小6の娘が「一休さん」を一気に観ているのをみるとそう思う。私が小学生だった頃は「一休さん」を観て、次の週までには、何気にその「一休さん」の中にあったもの反芻するという時間を得られたのだが、次々と見る場合には反芻する暇がない。それは、あたかも過去の漫画を大人買いして一気読みするようなものだ。週刊なり月刊なりの枠にとらわれずに「作品」そのものだけに一気に取り組むことになる。連載という強制的な枠の中で、時間軸を共にするのがよいのか、作品そのものに没頭するのがよいのか、それは時と場合にもよるだろうし、選択しえない強制的なものであるからこそ「空き時間での反芻」を余儀なくされるのかという違いがあるのだが、まあ、少なくとも週に十数本の連載を同時並行にこなすということはしなかった。

3月のライオン

image

NHK の深夜11時に放送されている「3月のライオン」の原作を知ったのは、5年前だったかな。同時並行的に「はちみつとクローバー」に遡ったりしたのだが、将棋な部分と成長譚な部分と、著者・羽海野チカの成長(と思われる部分)が交錯していて、読み解き的にも面白い作品である。原作を読むと解るのだけど、将棋のシビアな部分と、主人公零の成長譚のシビアな部分が、3姉妹の高いテンションの部分で補われる。3姉妹が常にテンションが高いわけではなくて、シビアな部分がありつつ、そこは作品として交互に現れる「シビア過ぎにならない部分」がある。おそらく、連載において、シビアな部分が続き過ぎることを避ける(あるいは、成長譚をきちんと「勝負」として捉えられるぐらいの時間をとるべく)ために、間が設けてあるところが面白い。

アニメの場合は、淡々と原作をなぞることになるのだが、そこのテンションの高さとシビアな部分は30分という時間の中で交互に訪れる。しかし、アニメを見ている側(対象は中高生なのだろうか?)としては、シビアなまま暗澹として次の週を待つのではなく、ひとつ解決されて次の週に進むという方法が取られている。いわゆる「引き」を作ってしまうと、週の間が連続しすぎて辛くなる。また、DVD などでまとめられたときに、「引き」の後に次の話を続けてみることが可能なので、そのあたりはどうなのか難しいところなのだが(漫画本の場合は、話が連続している、かつ「漫画本」という1冊をまたがらないように作られている)、そのあたりも原作とアニメとの対比をみると面白いと思う。

でもって、現役中学生直前の小6の娘によれば、「原作通りなので、観なくてもよい」そうだ。まあなあ、でも、毎週録画してみるんだけどね、私は。

響け!ユーフォニアム2

image

原作は、現役大学生(今は卒業したんだっけ?)なので、原作を読むと所謂「若書き」があるかと思い気や、そんなことはない。おそらくラノベというジャンルが広まった効果があるのだと思うけど、青春小説(?)とラノベの中間的な作品になっている。純文学っぽい若書きの部分が少ない…というかない。キャラの「悩み」というスタイルで書かれているものは、高校特有の「吹奏楽部」という狭い範疇だし(クラスとか勉強とかいうのもあまりない。受験がちょっとだけ出て来る)、そこの対象を絞っているのは、著者自身の実体験からきているものだと思う。売り出し方としては、ポニーキャニオンが関わっているから、「けいおん!」のような音楽併用というスタイルなんだろうけど、そこはアニメのほうの「のだめカンタービレ」とも違って、えらい真面目にクラブ活動内の人の関わりが細かく描かれている。クラブ活動とはいえ、文化部と運動部とも違い「吹奏楽部」という一種運動系でありつつも感性的なものである「音楽」を扱うという特殊な分野(と私は思う)から得られるところは多いだろう。

元が小説なので、アニメにするとせりふ回しが多くなっていて、(この歳なると)なにやらよくわからなくなるので、原作を読んだほうが手っ取り早いです。

これも一話完結な感じになっているので、気分的にあまり引きずられなくてよい。

機動戦士ガンダム 鉄血のオルフェンズ

image

実は、毎週見ているのは3本しかない…というか、ひとつ前は「マクロスデルタ」しか見ていなくて(録画だし)、あとでまとめて DVD で借りて来ることが多いので、ここのところは珍しいのだ。

ガンダムならばなんでも見ると言いつつも、DVD を買ったりしている訳ではないので、まあ、小学生の頃の「ガンダム」が今も引きずっているとも言える。逆に言えば、小学生、中高生の頃に見たアニメは、単なる消費財としてのアニメではなくて、なんらの思想に影響を与えるといえるだろう。それは、アトムを作りたいとか、ガンダムを作りたいとかいう直接的なロボット関係でもあろうし、「うる星やつら」とか「めぞん一刻」のような恋愛観が異性に対する表現の仕方として覚えていたり(かなりひねくれている?けど、高橋留美子の価値観ではあるよね)、そういうものは後々、成人しても影響を残すであろし、ひとつの価値観になると思われる。勿論、それはアニメや漫画に限らず、小説や思想書でもいいのだけど、学園紛争世代が「サンデー」を読んでいた、のと同じレベルだと思うんだけどな。

ひとつガンダムの世界感を読み解きをすれば、初代ガンダムのアムロのオイディプスコンプレックスから三日月なり鉄華団なりは自由になっている。ちょっと、ヤクザっぽいのはどうかと思うけど、幼少より「デブリ」として扱われてしまう世代からスタートして、大人の世界=既存の仕組みに常に翻弄されてしまうという外敵を跳ね返すためには、多少なりとも「暴力」(という言葉は使わないけど、ガンダムがそれにあたる)を使うことになる。これは主役が小中学生という制限だからこそでもあるし、当たり前だけど、これから生まれる/育つ世代は、既存の世界へは必ず「後からやってくる者」にならざる得ない。なので、既存の世界を崩壊させる(オイディプス・コンプレックス)として扱うか、既存の世界に組み込まれるか、既存の世界を自分たちの都合のように変えていくか、といういくつかのスタイルを取る。「金持ち父さん」あたりは、既存の世界に組み込まれるところからスタートなのだけど、オルフェンズは既存の世界を自分たちの都合のよいように作り変えるところにテーマがあるよね。それは、現実に対しても良い手本(失敗も含めて、疑似体験という意味で)になるんじゃないかなと思っている。

 

そんな訳で、観ている側としては「消費財」としてじゃなくて、作品として観るには、このぐらいが限界じゃないかなと思うんだがどうなんでしょう? ただ、この他に毎週見ている(ときどき忘れるけど)、「ムジカ・ピッコリーノ」、「大科学実験」、「TED」なので、偏っているといえば偏っている。週刊誌とか買わないしなぁ。

カテゴリー: 雑談 | 深夜アニメが少なくなっても構わないよね はコメントを受け付けていません

マックで女子高生が話してたんだが、iPhone6sの電話が繋がらなくなって…の話

これは、マックで女子高生が話していたのを聞いたのだが、

3日前に、iPhone 6s の着呼が全くできなくなって、発信もできなくなった。Wi-Fi はつながるので、メールが届くので気付かなかったのかもしれない。iOS のバージョンをアップしてそうなったのかどうかは分からない。

購入して1年経ってないので、近場の購入した Softbank のショップにしてみてもらうことにした。SIM も新しくして確認したものの、電話がつながらない状態は改善しなかった。

ショップで「ダメなときは Apple Care に事情を話してください」と言われたので、Apple Care に電話して事情を話すことにした。Apple Care のほうから機器の状態やら、設定のリセットをしたものの、改善されないので、「初期化をしても改善しないようであれば、Apple の修理店に行ってください」と言われたので、次の日に行くことにした。

夜に、バックアップと初期化をしてみるが、改善されず。

午前中は幕張に行く予定があったので、その帰りに秋葉原のソフマップの上の修理店に行ってみた。予約を取ってなかった(そもそも予約を取ること自体を知らされてないし、知らなかった)ので、「電話がつながらない」の事情を話したのち、30分待ちの後、故障した iPhone6s を見てもらうことにした。さらに15分ほどしたあとに、「いま、ここには iPhone6s がないので、修理できない」という話になった。工場リセットをしてしまうと、Wi-Fi もつながらなくなるかもしれない、という言い訳をして、そのまま戻ってきた。どこで、近くに修理できるところがあるのか?と聞くと、ヨドバシの上にあるそうなので、そこに行くことにした。

ヨドバシの上に言って、事情を話したが、キャンセル待ちで7人以上あるとのこと。交換できるかどうかは分からないみたいだが、次の仕事の5時半まで待つことにした。…が、あれこれしらべていくと、予約ができることが分かったので、次の日にと聞くと、秋葉原以外は3,4日後まで予約が埋まっているという。そんなに待てないので、「Apple Care に事情を話してみてくれ」という話なので、Apple Care に電話を掛けることにした。

Apple Care では、以前の状態を記録していたので、「ショップに行くと代替機があるかもしれない、事情を話してくれ」ということなので、次の日の午前中に Softbank のショップに行くことにした。ここで問合せの番号を貰った。

近場(以前、購入したところ)に、午前中、持って行ったのだが、「iPhone6s の代替機はないので、変えられない」と言われる。なんじゃそりゃ?

そもそも Apple Care からショップへ行ってくれ、と言われ、ショップのほうではできない、Apple 修理店に行ってくれと言われるが、昨日、秋葉原に行って断られたばかりなので、なんともできない。そもそも、また秋葉原まで行かなくちゃならないのか?何処に行けばいいのか?

問合せの番号を伝えて、ショップの人が Apple Care に電話するものの「あとで、ご本人様に変わって事情を話して貰えますか?」と言ったにもかかわらず、ショップの人は、問合せ番号も使わず、私にも電話を渡さず、そのまま切ってしまう。で、「代替機はないのでできません」と言う。

仕方がないので、自分ので電話で Apple Care に電話をする。問合せ番号も伝える。昨日、ショップに行って、うまくいかなかったら Apple Care に問合せしなおしてくれと言われたことも伝える。で、ショップの人に電話を渡す。

ここのショップには代替機がないということなので、別のショップに電話を掛ける。ショップから別のショップに掛けると「在庫がない」と言われるので、私が3店舗に事情を話す。「代替機はない」と言われる。じゃあ、どうすればいいのか?

また、Apple の修理店に行かないと駄目なのか?

もういちど、Apple Care に電話をして、問合せ番号を伝えて「たらい廻しにされたくないので、なんとかできないか?」と話す。

再び、ショップから渋谷の Softbank に掛けて代替機があるかどうかを「私が」問い合わせる、「iPhone 5c ならある」ということなので、これから取りに行きたいけど、待ち時間を短縮できないか?というと、「店舗に到着してから予約カードを引かないといけない。現在、7人待ちぐらいになっているので、来てから1時間位かかるだろう」という。なんじゃそりゃ? 渋谷まで1時間ほどかけていって、1時間待って、1時間掛けて帰ってこないといけないのか?あれこれたらい廻しになって困っているというが、ダメとのこと。

ショップで故障した iPhone を受け取って、代替機を郵送とかできませんか?と聞くと、ダメとのこと。

仕方がないので、もう一度 Apple Care に電話する。問合せ番号を伝えて、この状況を何とかしてほしいと言う。

  • 3日前から電話がつながらなくて困っている。
  • これ以上、たらい廻しにされたくない。

ことを伝えて、池袋と渋谷に交換機があれば、変えられるということが分かる。

ここで、「代替機」と「交換機」が違うことが判明する。あのなー、こっちは素人だから、「代替機」と「交換機」の区別はつけないよ。どうやら、修理ができるまで使うのが「代替機」、故障などで交換してしまうのが「交換機」という言い方をしている。このあたり、ショップと Apple Care の用語が混ざっているっぽい。

近場のショップには、iPhone 6s 対応の SIM の代替機がなくて、Android とかにも変えられない。こっちは、ガラケーでもいいのだけど、変えられない。これは最初から「察している」けど、いまごろ言う。

Apple Care は、「予約は取れるけど、交換機があるかどうかは調べられない」という不思議なことをいう。交換機がなかったら、また無駄足じゃん。秋葉原の事情を話すが、「交換機があるかどうかは、お客様から電話して貰わないとわからない」という話。

ショップの人が「どうしますか?」と聞く。

まずは「調べてください」と言う。オレは、もう電話は掛けないよ。

ショップの人が Apple Care の人と電話をして、渋谷と池袋の4店舗を教えてもらう。

ショップの人が、ショップの電話で、Apple の修理店の電話をかけまくる。iPhone 6s の「交換機」がやっと見つかる。やっと仕事をし始める。

「最短で、渋谷の今日の5時に予約が取れるそうですか、どうしますか?」とショップの人から聞かれる。

ああ、これ以上、どうにもならないようなので、予約を入れてもらう。工場出荷は済んでいるのと事情は話してあるので、即交換されるハズである。

というわけで、夕方に渋谷まで出ないといけないことになる。故障した機器との交換だそうなので、故障した機器を郵送にして、渋谷勤務のうちの奥さんが受け取る、ということはできない。

というのを、マックで女子高生から聞いたんだけどな…一応、記録としてのこしておくよ。

結果はまた、渋谷の Apple の修理店に行った後にわかるらしい。

追記

再び、マックに行くと女子高生が話していたのだが、

渋谷のヒカリエに午後5時に行って、あれこれとやった挙句、改善されないことがわかり、午後5時40分ごろに「保証期間内のため本体交換」になった。即交換にはならなかった。

確認後の手続きもあって40分程度かかっているのだが、全体として確認に30分以上かかるときは、その旨をあらかじめ知らせてほしいところである(お渡し予定時間が、17時15分になっているからね)…とのことだ。

原因と対策

ここまでだと、単なるクレームになるので(クレームを入れたいところだが)、せっかくなので原因と対策を分析しておく。

あれこれたらい廻しになってしまっているのは、Softbank の各ショップと Apple 修理店と Apple Care が全然連携が取れていないところだ。故障の窓口としては、販売した店舗が請け負うことが多いので(販売の責任もあるから)、ショップが最初の口になることが多いのだ。しかし、Apple だけは Apple Store に直接問い合わせることになっている、という縛りがある。そこで Apple Store が修理を一気に請け負えばいいのだが、各修理店がばらに請け負っていることになっているらしい。実際のところは、どうだか分からないが、秋葉原の修理店と渋谷の修理店と連携が取れていないし、ショップから修理店の連携もないし、ショップ同士もばらばらになっている。たしかに、各社が Apple から委託されている感じになっているので(逆に Apple に伺いを立てている?)、それは、まあ仕方がない。個別になっている。

なので、現象として、

  • ショップから別のショップに、代替機があるかどうかを問合せできない。
  • ショップから修理店へ、交換機があるかどうか問合せができない。
  • 修理店から修理店へ、交換機の受け渡しができないし、状況を話すこともできない。
  • Apple Care から修理店へ状況を話すことができない。

という具合にばらばらだ。CRM としては最悪な状態になっている。

まあ、それは仕方がない、そういう方針でやっているのだから。

これのほうは、どうしようもないので客としての「対策」を考える。

  • ショップへの問合せをしても、ダメなので、最初の SIM 交換だけ(水没とか?)だけチェック。
  • Apple 修理店は、「予約」を入れるのだが Web 経由では、在庫等の確認ができないので電話で直接行う。無理矢理にでも電話しろ。

以前、どこかで見たけど修理店へは「予約」を入れないと、基本的にどうにもならない。状況も伝達されるわけではないので、ひとつの修理店へ何度も足を運ぶ感じがよいだろう。

改善策

対策のほうは、回避でしかないので、改善策をいくつか提案しておこう。横連携は無理なので、個別に改善できるところとしては、

  • Apple Care の受付は Google マップでの探索をやめて、住所と地図の一覧を用意するほうがよい。「一番ちかいところが、〇〇kmです」という頓珍漢なことは言わないようにする。
  • 受け付けた時点で、故障した機種の確認を最初にやる。そもそも交換になる場合は、工場出荷に戻すのに交換機があるかどうかがのチェックが必要なのに、後から言うのは時間のロスだ。ちなみに、秋葉原のヨドバシ以外は、最初の機種チェックがなかった。
  • Web の予約に「機種」を入れないと、交換になる場合に無駄足になってしまう。

で、マックで話していた女子高生の話では、「二度と iPhone にしない…」とか言っている。

ちなみに、個人の場合はこのように手間のかかる手段を取るけど、仕事で使っている iPhone(家には4,5台あるよ)が壊れた場合には、速攻、中古屋に行って買ってしまう。そして、新品交換になったほうを売り払ってしまうんだけどな。じゃないと、時間ばかりロスしてしまって、無駄になるので。

カテゴリー: トラブルシューティング | マックで女子高生が話してたんだが、iPhone6sの電話が繋がらなくなって…の話 はコメントを受け付けていません

Xamarin.Android でビルドすると意味不明な警告が頻発する場合

とあるところで、Xamarin.Android の連載を書き始めました。現在、第3回なのですが、内部的にはもうちょっと先のほうまで書き上げてあります。

そこで、記事にはないのですが(敢えて外してある)、現時点の Xamarin.Android と Android SDK のバージョンの相性が悪く、現時点で最新である Xamarin 4.2.0.703 を入れただけでは、Android のデザイナが機能しません。デザイナ自体が、Android SDK 25.x 以上を欲しているので、別途 Android SDK Manager でバージョンアップする必要があります。

image

ところが、現時点の Xamarin.Android が、完全には 25.x には対応していないらしく、リビルドをすると以下のような意味不明な警告(エラーではない)が出ます。

image

文字化けしているのは、たぶんメッセージが日本語化されてしまっているのか、そもそも *.jar の中が化けてしまっているのかわからないので…

頑張って、英語OS + 英語 Visual Studio 2015 + Xamarin.Android の環境を作って、Android SDK を 25.x にアップデートしてビルドしてみると,

image

警告(warning)が読み取れるようになりました。

warning: C:UsersmasudaAppDataLocalXamarinMonoForAndroidAndroidSDKplatformsandroid-25android.jar(java/lang/Object.class): major version 52 is newer than 51, the highest major version supported by this compiler.
  It is recommended that the compiler be upgraded.

どうやら、コンパイラとのバージョンがずれているっぽい警告が出ています。現状の Xamarin.Android がこの「52」がなんだかよくわからないのですが、

visual studio – Warning major version 52 is newer than 51, the highest major version supported by this compiler – Stack Overflow
http://stackoverflow.com/questions/38222584/warning-major-version-52-is-newer-than-51-the-highest-major-version-supported-b

を見ると、Java 8 を入れれば良いようです。確かに、現状の Xamarin.Android は Java 7 になっているので、そこの不整合のようですね。

Oracle の頁から Java 8 をダウンロードしてインストールします。Xamarin のページからは Java 7 へのリンクになっているので別途探します。

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

image

オプション → Xamarin → Android の Java Development Kit Location の値 Java 8 のほうに変更します。

image

すると、無事、警告がなくなります。

image

一応、

  • Hyper-V の Android エミュレータ
  • Kindle Fire

上では動いたのですが、まだ正式対応していないみたいなので、気になる場合は Java 7 に戻して使うということで。

おまけ

ちなみに、Visual Studio 上で Xamarin.Android のデザイナを動かすと重くて仕方がないので、axml の中身だけコピーして、Android Studio で編集するという手もありますね。こっちのほうが軽く動きます。微妙に UI が違うので、使い分けが必要なんでしょうが。

image

あと、Hyper-V の Android エミュレータって、カメラ機能が使えるんですね。

image

こんな感じで写真が撮れる。

カテゴリー: Xamarin, トラブルシューティング | Xamarin.Android でビルドすると意味不明な警告が頻発する場合 はコメントを受け付けていません

[ソフトウェア開発者の道具箱] 知恵の箱

ソフトウェア開発者の道具箱 | Moonmile Solutions Blog の第4弾は「知恵の箱」です。金の鍵 は自分から外部に発信する外向きの話ですが、知恵の箱は外部から自分に取り込む内向きの話になります。

「知恵」というのは、自分の外側にながれていく沢山の「情報」のことです。それは Twitter に流れる TL であったり、テレビから流れて来るマスコミの情報であったり、社内で流れて来る共有すべき情報であったり、チームで仕事をしているときのメンバからの情報だったりします。それぞれの関係があるので、本質的に「知恵」になるかどうかはわかりませんが、まあ、知恵の元ということです。

金の鍵のところでも話しましたが、ひとつ重要なことは「情報を制限する/開け閉めする」ことが必須ということです。つまり、開け閉めする箱の蓋は、自分で持っているにも関わらず、それがあたかも「開けっ放し」にしてあって、それは決して絞められないような心理状態に陥るということです。勿論、外側から暴力的に情報を流す(いわゆる、DV に近いもの)こともできますが、一般的に言えば、開け閉めの鍵/蓋は自分でもっています。

不特定多数の情報から「知恵」を得る

あなたが、テレビや Twitter や新聞やメーリングリストや、様々なところから情報を得ているときに、それを「見聞き」する鍵は、自分にあることを忘れないようにしてください。流れ込んでいるテレビからの情報は、テレビを消すことによってなだれ込むことをやめることができます。なだれ込む情報がなくなると、「不安」になるかもしれませんが、しばらくすると「不安」が消えます。ある意味で中毒のような症状に似ています。一見、取捨選択しているようで、なだれ込む情報に流されている場合もあれば、自分の都合のよい情報だけをピックアップして納得してしまう場合もあるでしょう。なので、そこから得るものは、

  • 流れて来るのは単なる事実
  • それが自分に関わるかどうか

に制限しておきます。

まあ、聞き流しできる精神状態の場合はいいのですが、とある自体に陥ったとき、一見、たくさんの情報を得ているように思っても、単に情報が上滑りしてしまって「知恵」になってないことが多いのです。

リーダーがメンバの「知恵」を得る

プロジェクトリーダーやマネージャが、プロジェクトメンバから情報を得るときに、いわゆる「吸い上げ」という言葉を使うことが多いのですが、この情報発信は、

  • 自発的にメンバから流された情報なのか?
  • 客観的な情報なのか?

に分類されます。警察の尋問ではないので、無理矢理聞き出す必要はありません。聞き出せないのならば聞き出せないなりの方法もあり、報告があればあったでそこから虚偽であるかどうかのチェックが必要になってきます。

例えば、プロジェクトリーダーがメンバから進捗を聞く場面を考えてみましょう。一般的に進捗会議を開いて、各自メンバが進捗率を報告する、そして、リーダーやマネージャが進捗状態をまとめる、というスタイルが多く使われます。しかし、

  • メンバが虚偽の進捗を報告しているのではないか?
  • リーダーやマネージャが虚偽の進捗を作るのではないか?

という懸念が残ります…というか、大抵、ここに陥ってしまうんですけどね。そもそも、なぜ「進捗率」を調べるのかというと、進捗が遅れることを未然に知ることによって、メンバを増やすなり、スケジュールを調節するなりの、対策をするための進捗会議なんですけどね。大抵は、「オンスケですか?」の進捗会議になるで、そりゃ「オンスケです」になるしかないでしょう。進捗自体は、コード量とか、勤務時間とかの客観的な指標を使えばよいので、実は進捗会議自体意味はありません。

もう少し、捻た見方をしてみると、

  • メンバが虚偽を報告をする「要因」が、プロジェクトメンバ内にある。
  • リーダーやマネージャが虚偽申請をすると得をする「要因」がある。

状態があるということですよね。そういう「要因」自体を、進捗報告とは別に探っていき、悪い要因を取り除いて正常な状態に戻すこともできます。

まあ、そんな訳で、上下関係のあるときは、直接情報を仕入れたとして「知恵」を得ることはできません。そうそう、孫子の兵法な感じで、内部的な間諜を入れておくというのお勧めです。間諜な話は、また今度にしましょう。

同僚のチームメンバから「知恵」を得る

どちらかというと、同列のあるメンバから「知恵」を仕入れるほうが有効です。同じプロジェクト内で、プロジェクトの成功という同じ目標を共有しているならば(暗躍する場合は、共通な目的にならないのですが、それは別の話で)、相互の情報のやり取りをしたほうがよいでしょう。

このあたり、仕事で言えば「分担」とか「分掌」とかいう感じで、壁を作ってしまうことが多いのですが、それは効率的ではなくて、ちょっとだけ重なりを作っておくのがコツです。「知識創造企業」にある「さしみプロセス」というやつですね。確か、ピープルウェアにも「のりしろ」として似たようなことが書いてあります。

ペアプログラミングみたいに、完全にコードを共有しながら作ることが理想的でもあるのですが、常にできるとは限りません。と言いますか、人によってペアプログラミングを長くやるとストレスが溜まるし、ひとりでガシガシと作っていったほうがよい場合もあります。そこは、程度の問題だったりするのです。その程度の問題が「のりしろ」になります。

完全に分離するのではなく、逆に完全に同一の仕事をこなす(相手の仕事を完全に理解する)のではなくて、ちょっとだけ理解して踏み込めるようにしておきます。それは「日常的に聞けるスタイル/状態にしておく」という物理的な方法もあれば、ちょっとだけ作業を入れ替えてみるという方法もあります。そうそう、家事を分担するときに単調で辛くなったら(相手のほうが楽じゃないかと思いはじめたら)、分担を交代してみることもアリですね。ちょっとだけ交代してみると解るのですが、最終的にはそれぞれの得意な分野に落ち着くのが「効率的」であったりします。そのあたりは「尊重」も含めてなんですけど。

仕事の同僚から何かの「知恵」を得るときは、ちょっとだけ相手の領域に踏み込みます。ちょっとだけ押して、度合いを見て、元に戻ります。これは、会社の社風であたったり、仕事場の雰囲気であったりするわけですが、ええ、

  • そういう場を作るか
  • そういう場に移るか

ということですね。私としてはどちらもお薦めです。

カテゴリー: ソフトウェア開発者の道具箱 | [ソフトウェア開発者の道具箱] 知恵の箱 はコメントを受け付けていません

オレが考える最強のDBA(Database Administrator)

のだめ開発を考える中で、SEとPGと…DBAと書こうとして躊躇してしまったのだが、DBAについて書いておこう。

数日前に、プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに を買って読んでいるのだが、20年前位だったか年配のコンサルタントの人に「データベースを扱う人ってのは、プログラマなんでしょうか?それともシステムエンジニアなんでしょうか?それとも SIer?」というのを尋ねたことがある。そのときに、DBA(Database Administrator)という分野の人をいることを知った。当時、会社で Oracle の設定をしていたり、SQL Server のチューニングをしていたので、テーブル設計をするとか、テーブルに効率よくアクセスするとか、を「誰が責任をもって担当するのか?」を知りたかった頃である。実務的には「プロジェクト内でデータベースに詳しい人」が担当する訳なんだけど、大規模プロジェクトになると大手 SIer(元請けという意味で)のSEが設定していたりする。それが SE なのか DBA なのかは、今もってわからないけど、じゃあ、テーブル設計は誰が責任を持つのか?というのは「DBA」という答えだったのだが、その「DBAの人は何処にいるのか?」という答えは得られなかった。つーか、はぐらかされてしまったんだよね。

そう、今思うと、そう意味での DBA なんて当時、何処にもいなかったのだよ。

「そういう意味での」ってのは、

  1. Oracle や SQL Server などのデータベース設定ができる
  2. Oracle や SQL Server などのデータベースのチューニングができる。
  3. データのテーブル設計(論理設計、正規化)が適切にできる。
  4. テーブル等の物理配置が適切にできる。
  5. テーブルにアクセスするための、効率のよい SQL が書ける。
  6. テーブルにアクセスするための、ストアドプロシージャなどが適切に書ける。

ってことになる。このストアドプロシージャを使うのが、プログラマだったりするからだ。

当時、大手 SIer の SE な人がやっていたのは、サーバーのセッティングとデータベース等のインストールで(内部的には DBA という分掌だったかもしれないが)、1と2の分野を担っていた。だから、3以降は、誰がやるのか決まっていなかったんだよね。元請け/下請けの関係の場合は、設計書として「テーブル設計」があるから元請けが作成することが多いのだが、果たして、5や6のように「効率よく」アクセスできるかどうかは抜け落ちてしまって、場合によっては、正規化ができていないテーブル構造がでてきたりする。だが、下請けにとって、その「まずい」テーブル設計を修正する手段を持たされていないので、その「まずい」設計のままモノ(コード)を作らざるを得ないパターンに陥る。

近年になって Web システムがこなれてきたので、データベースの設定や設計に関しても小規模に行うようになったから( Oracle のインストールは、昔はひと苦労だったのだ)、このあたりの分け方が随分マシになったのだが、それでもデータベースのテーブル設計が「?」なものは多い。まあ、そりゃ、データベースのプロじゃないから仕方がないよね、と思っていたものの、じゃあ「本物のDBA」は何処にいるんだ?って話になる。そう、俺=プログラマの視点から見たときに、先の1~6までを担ってくれる DBA はいるのだろうか? いや、そもそも、1~6までは DBA の担当なのだろうか?という疑問がでてくる。

この本の邦題は「プロうグラマのための~」になっているが、原題は「Joe Celkos SQL for Smarties, Fourth Edition: Advanced SQL Programming」になっている。for Smarties というのは「賢いやつ」とか「知ったかぶりの」という意味もあるので( “for Smarties” で検索すると定番のタイトルらしいので、皮肉なのか?)まあ、プログラマに限らない。

DBA はストアドプロシージャを書くのか?

データベースに効率的にアクセスするならば、ストアドプロシージャを書くのは「DBA」であるべきだ。なぜならば、プログラマよりも DBA のほうがテーブル構造を熟知しているし、下手なプログラマやなんちゃってSEがあれこれやるよりも、きちんとテーブル構造を知っている人がコードを書いたほうがいい。これは、昔からよく見ている。だが、その DBA が何処にいるのかという判然としない。理想的なのは、開発プロジェクト内に DBA が1名以上いて、その人が先に書いた1~6までの作業を請け負ってしまうのが望ましい。

しかし、ストアドプロシージャ自体にビジネスロジックを書いたり、テーブル自体が200個位あるような規模のプロジェクトになると、1名では足りなくなって複数名必要になる。しかも、業務ロジック(Web APIも含むだろう)をプログラム側から呼び出すようになると、きちんと設計すると、プログラマの半分ぐらいは DBA が必要となる規模になってしまう。これは何か変だ。DBA が何処にいるかわからないのに、そんな数の DBA を集めるのは不可能だから、DBA の仕事を減らすために(現実的な規模におさめるために)、1と2ぐらいの仕事だけを DBA に割り当てる。そうなると、非DBAな人(SEやPG)がテーブル設計をして、テーブルアクセスも非DBAがやるという、素人臭いデータアクセスの設計/実装になってしまう。これも変だ。

じゃあ、DBA が足りないのだから、もっと作ればいいじゃないかと思うだろうが、そうそうデータベースに精通している人がいるわけでもなく、まあ、そんなことをやるよりも、LINQ でアクセスするとか、コードファーストで作ってしまおう、という発想になってしまうのも無理ないことだ。実際、そういうパターンになる場合も多いだろうし、小規模な WEB システムであればそれで十分な場合も多い。しかし、それが「理想的」なのかといいえばそうではない。では、DBA の理想は何処にあるのだろうか?

DBA の必要条件

人数が少ない(居るのか居ないのかわからないけど)理想的な DBA が少数であると仮定して、その制約条件を考えてみよう。例えば、20名のプロジェクトで1名の DBA だけを想定する。均等に仕事を割り振ると、プロジェクトの5%の仕事が DBA に割り振られることになる。そのほかの仕事は、SE, PG, PM, PL などに割り振られる。そうすると、

DBA が最低限しなければいけない仕事に絞ると、

  • データベースのチューニングが可能である。
  • 正しいデータベースアクセスの解答を導き出せる。

を持っていれば十分な気がする。近年 Oracle や MySQL, SQL Server などのデータベースの設定自体はそれほど難しくはない。場合によっては、標準的な設定でも十分可動できたりする。

しかし、利用するメモリや、テンポラリディスクの物理配置、ログの切り捨てやバックアップ計画などの標準的なものから、環境にあわせた「チューニング」は必要だ。チューニング≒高速化は DBA にとっては必須条件ではないだろうが、システムの予防策を組む場合には必須となる知識だろう。逆に言えば、標準を超える閾値が何処なのかを知っておくだけでも十分だ。データベースアクセスの頻度など閾値を超えなければ、標準的な初期設定だけで十分だったりするし、最近はそれぞれのパターンが用意されている。

2つめの「正しいデータベースアクセス」は、「テーブル構造を作成する」よりも優先するのではないか、と思っている。業務フローなどからテーブル構造を作っていくのは結構大変な作業になる。生産現場などで使う200以上のテーブルを、5%の作業量しか持たない DBA に全て積んでしまうのは作業量的に無理がある。となれば、おおまかなテーブル構造や、アクセスの仕方は SE, PG が作ってしまい、それが「正しいデータベースアクセス」になっているかどうかを、チェックする係になってはどうだろうか?ゲートキーパー的な役割だ。

プログラムからのアクセスは、「ストアドプロシージャ」、「SQL文」、「LINQ」などの様々な手段があるから、それを統一するか場合によって選択するかはプロジェクトによって異なる。SE が作るテーブル構造も、アクセスしやすいようになっているか、最適なのかは分からない。ある程度の正規化ができていればそれで充分であろう。最適を求めるのではなく、工学的な準最適化を求めるのであれば、それほど細かく正規化する必要もない。また、データにあわせて非正規化する必要もない。そんな中で、統括的な意味あいで DBA という存在が、ひととおりの整合性をチェックし、経験上(そう豊富な実務経験は必要だろう)落とし穴になりそうな部分を潰しておき、後々に陥らないように予防しておくのだ。

これだと、少数の DBA でもなんとかできるかもしれない。そう先の2の要件とプラスアルファがあるだけだ。

で、何処に DBA はいるのか?

つらつらと「プログラマのための~」を読んでいて、DBA について考えなおしたのだが、そうなると著者は、まあ DBA としても、他に誰が DBA として適当なのだろう?という疑問がでてきる。いわゆる、資格としての DBA じゃなくて、実務的なプロの DBA だ。中国地方にひとりいるような気もするし、関東では出会ったことがないような気もするし、もっと閾値を下げてしまえば、プログラマを20名集めて、ひとり DB に詳しい人がいれば、その人をプロジェクト内の DBA とするのが現実的な解じゃないかなと思ったり。

カテゴリー: 開発 | オレが考える最強のDBA(Database Administrator) はコメントを受け付けていません

[のだめ開発] 指揮者 Conductor の役割とは(2)

とある会社で、社内研修をすることにしました(技術顧問も兼ねています)。もとが保守の会社なので、そこにプログラミング要素を付け加えるというパターンで研修内容を組み立てています。なので、プログラミング研修よりも、もっと直近的に使える「社内ツール」を自作できる、程度まで引き上げます。最終的には、製品の内製ぐらいまでですかね。

あまり、言わないようにしているのですが、SE(システムエンジニア)とPG(プログラマ)のためのスキルは別ものです。両方持っているに越したことはないのですが、それぞれが「プロフェッショナル」として仕事をする以上、どちらかの技術に精通している(ゆえに、片方の技術があまり精通しなくてよい)というスタイルになります。仕事上は「分掌」という言い方もしますが、住み分けというか得意分野というところですよね。プロ/仕事なのだから、普通の人よりも十数倍早く出来上がるというのは意外と重要な要素です。その差分が、「支払ってもらう金額」なのですから。

オーケストラというチームビルディング方法

以前、[のだめ開発] 指揮者 conductor の役割とは | Moonmile Solutions Blog を考えていたときは、「カンタービレ」のほうを考えていたのですが、今回は「オーケストレーション」のほうに重きを置きます。詳細は「のだめカンタービレ」を読んでもらうことにして、ソフトウェア開発の視点からオーケストラを見たときの類似点は、専門家の集団ということです。これは、アジャイル開発でもウォーターフォール開発で同じように使えるチームビルディングの方法です。逆に言えば、専門家ではない人を集めてチームビルディングする方法もあります。以前、Microsoft が提唱していた「ソフトウェアファクトリー」とか、Intelが採用している標準的なスキルによるチームビルディングです。これは、どちらが良いとか悪いとかいうのはないので、適材適所でチームの作り方を選びます。勿論、チームに入っているのは「人」なので、その人に向かないチームもあることを忘れないでください。そういう時は、浅田彰の「逃走論」を読んで、清くチーム/会社から去ることをお勧めします。これは、デマルコ著「ピープルウェア」やヨードン著「デスマーチ」でも言われていることですので忘れずに。

さて、今回の研修のように、

  • 中途入社が対象
  • システムエンジニア、プログラマが混在

というスタイルでチームを組む場合は、いわゆる LLC/LLP(合同会社/合資会社)に近い形態でチームを組みます。LLCとLLPは会社法的には異なるものなのですが、ここでは「各自のスキルを持ち寄る」というところに注目します。

ちなみに、新人/自発的に動けない人/モチベーションが低い人、を混ぜるとこの方式は取れません。これは、新人等を否定してるわけではなくて、そういう場合には別なチーム作りがあるということです。例えば、命に係わるようなことは「軍隊式」じゃないとうまくいかない場合もありますからね。そこは、心理学や社会学も含めてベターな方法を選びます。

LLC の場合、それぞれが専門家≒独立できる程度のスキルを持つ人達を集めて、ひとつの会社を作ります。最大のメリットは、営業口を一本化できることと、他の専門家のスキルを自分のスキルとして借りることができる、ということです。いわゆる横のつながりですよね。「引き合わせ」というスタイルです。これは、人材派遣会社と被派遣の関係とは異なります。相互にスキルを渡し合うので、対等な関係になります。LLC の場合、弁護士や医者などの独立した専門家で組むことが多いのですが、実は同じスキルじゃないほうが効率的にチームが組めます。同じスキルの場合は、自分の溢れた仕事や遠地などの都合のあわない仕事に対して、他のチームメンバに振ることになるのですが、異なるスキルの場合は、各専門家に仕事を割り振るというスタイルになります。ちょうど、建築/土建における施工のような感じで、左官、電気工事、内装などの専門家がそれぞれの仕事を受け持つという感じですね。ゼネコンスタイルになると、一次請けという上下関係が発生してしまいますが、もっとフラットな関係になります。

このフラットな関係が「オーケストラ」のスタイルになります。ひとつのオーケストラにおいて、楽器は別々ですが、上下関係があるわけではありません(ヴァイオリンのように第1、第2や、コンサートマスターという役割もありますが、それはチーム内のチームという関係です)。また、楽器の奏者が交換可能というわけではありません。奏者はそれぞれソロでも弾ける実力を持ち、さらにオーケストラとして集まるというチームビルディングの方法です。

ちょうど、システムエンジニア、プログラマ、テスター、データベースアドミニストレータなどが集まってチームを組むところと似ています。大抵の大手のプロジェクトでは、SIer を中心にして系列会社/下請けに割り振るという「ゼネコン」方式を取りますが、独立系の保守会社やソフトウェア会社であれば、オーケストレーションの手法を使えます。

そんなわけで、

  • 色々な専門家を集める
  • 専門家は対等な関係を維持する

を使ったチームを「オーケストレーションによるチーム作り」と呼ぶことにします。

既存のチームビルディングとしてはアジャイル開発スクラムが、オーケストラに近いのですが、専門家の範囲が狭いのと「スクラムマスター」という制度ができてしまったので避けておきます。かつ、スクラムマスター等の「管理/交渉/調節役」と「指揮者(コンダクター)」の役割がかなり異なります。

指揮者 Conductor の役割

のだめカンタービレには、指揮者が何人か出てきますが4巻ぐらいまでの、千秋とシュトレーゼマンの指揮のスタイルを見れば、まずは十分です(もちろん、その先にも色々参考にできるメタファーもあるので、それはおいおいに)。

千秋が、自分の音を表現するために、強烈な主導権をもって指揮をします。それぞれがうまくない学生オケの場合は、奏者のスキルが低いので、そういう教鞭的なスタイルも重要です。これは新人を含めたウォーターフォール形式によいでしょう。しかし、ある程度、おのおのの奏者のスキルが上がっていくと、指揮者の役割は変わってきます。

シュトレーゼマン曰く「楽しい音楽の時間デス」に尽きるのですが、厳しいスキルアップの後には「楽しく」スキルを披露することが重要です。ソフトウェア会社において、スキルを披露するということは、現場でのハードウェアのセッティングであったり、徹夜でのトラブル対処であったり、長期/短期に関わらずソフトウェア開発であったります。いわゆる、顧客に何を「披露」するのかが、重要になってきます。

奏者それぞれのスキルが十分であるならば、複数の奏者がスキルを合わせられるように、出番をそれぞれ調節していくのが指揮者の役目です。勿論、単なる「進行」役(プロンプタ)ではないので、指揮者の目指すところに指揮(誘導)をします。

このあたりが、スクラムマスターとは異なるところで、主にスクラムマスターが強弁であることが重要になる(顧客の対処への交渉力が必須)のに対して、指揮者(コンダクター)は強弁である必要はありません。少しもじるならば「雄弁」ある必要ありますよね。イメージを膨らませて、聴衆(顧客)や奏者(メンバ)に自分のイメージを伝える必要があります。この指揮の仕方は、のだめカンタービレにも出てきてパリ編の指揮のコンテストにも出てきます。

そんな訳で、指揮者(Conductor)と専門家(Professional)の組み合わせが「オーケストレーションによるチームビルディング」の基本になります。

でもって、具体的な話は研修にて。でもって、興味があれば相談してください。研修に加えるか、別途時間を作るか考えます。

補足…「響け!ユーフォマニア」もブラスバンドでチームビルディングの好例なんだけど、あの場合はスキルの低い奏者を集めて指揮者/指導者が引っ張る形(物語的には高校生の成長もあるし)なので、ちょっと違うかな。原作4巻はお勧め。

カテゴリー: のだめ開発プロセス | [のだめ開発] 指揮者 Conductor の役割とは(2) はコメントを受け付けていません

Android SDK をアップデートしたら Hyper-V のエミュレータに接続できなくなったとき

久し振りに、Xamarin.Android を作って、ツールを作ろうと思ったのですが、何故か

error: could not install *smartsocket* listener: cannot bind to 127.0.0.1:5037: …

のようなエラーがでて、Visual Studio から Hyper-V の Android エミュレータに接続できなくなってしまいました。Android の axml を編集するために、Android SDK をアップデートしたのですが、どうやらタイミング的に Xamarin.Android 内の Android SDK と相性が悪い模様。正確には adb がうまく起動できないようです。

こんな風に、エミュレータにアップロードする時に固まってしまいます。

image

 

エミュレータへは adb を使って接続しているのですが、どうも adb devices を実行しても空で返って来ます。多分、AppData/Local のほうで使っていれば分離できているのだけど、/Program Files を示しているときは競合しているのかも。

image

C:/Program Files (x86)/Android/android-sdk/platform-tools に adb.exe があります。

image

多分、connect がうまくいっていないので、手動で接続してあげると、繋げるようになります。

Hyper-V のエミュレータで >> ボタンをクリックして「Network」のタブを開くと、エミュレータが使っている IP アドレスが分かります。

image

これを使って

adb connect 172.16.0.20

で起動させておくと、Visual Studio から Hyper-V のエミュレータへのデプロイができるようになります。

image

多分、Program Files 配下にあるから、パーミッション絡みで起動できなくなっているような気がするんだけど、どうなんだろう。コマンドが間違っているような気も。

おまけ

Visual Studio の新しいバージョンを Hyper-V 内で試しているんだけど、そこで Xamarin を動かして Android に接続するときに困っていたのですが、どうやら adb connect で繋げれば、Hyper-V 内の Visual Studio から別の Hyper-V で動いている Android エミュレータに接続できますね。これは結構便利。

カテゴリー: Xamarin, トラブルシューティング | Android SDK をアップデートしたら Hyper-V のエミュレータに接続できなくなったとき はコメントを受け付けていません