ぷろまねさん

グローバルコンサルティング会社でシステム開発・運用保守（アプリ方面）のプロジェクトマネジャーをしています。2014年PMP取得。アジャイル開発などの開発手法、Redmineなどの開発ツールを話題の中心に書いてます。

長時間残業の依存しない働き方

数ヶ月期間を空けてしまったが、実は（元）同僚も見ているようなのでちゃんと更新していこう。。。

昨日、僕の会社で年次全社ミーティングがあった。今回の内容、これまで8回出席した中で最もエキサイティングで素晴らしい回だったので思ったことを残しておきたい。

ざっくり言うと、以下のような内容だった。

  • 各組織のアップデート（特にDigitalのキーワードで）
  • ワークスタイル変革のアナウンス
  • チームラボ猪子氏のゲストスピーチ

3点目も非常にエキセントリックな内容だったので別途記事にするとして、今回は2点目について。

忌むべき文化

「仕事が出来れば何をしてもOK」というのが昔からの会社の文化だった。その一方で、大企業にもなりこれまでのように昇進・昇給することも難しくなってきたこともあり、「残業代で給料を稼ぎたい」という考え方もとくにSIやアウトソーシングの現場には出てきていることも事実。

両者は相対する価値観にも関わらず、これらが掛け合わさって以下のような問題が顕在化して久しい。

  • 長時間残業することを前提とした働き方、時間に対するルーズさ
  • 顧客や（特にカラーの異なる）他者に対する礼節、個人の尊重の欠如

更に具体的には（ミーティングでは自分が当てはまる場合は立ってマルを出すというやり方だった）

  • 定時外にミーティングすることが常態化している
  • 深夜に「明日朝までにやっておいて」と平気で支持する
  • 残業を前提としたプロジェクトスケジュールを立てている
  • 顧客メンバとすれ違っても挨拶をしない
  • オフィスにゴミが落ちていても気にしない
  • 顧客や中途採用組の同僚について平気で悪口を言う
  • 朝出社時にまったく挨拶せずに無言でPCを立ち上げる
  • 朝の出社や会議開始などに遅れることが常態化している
  • 育児中などの家庭の事情を持ったメンバに配慮が出来ない
  • （本当のパフォーマンスではなく）多く残業しているメンバを評価する

特に長時間残業について、問題の出方には2パターンあると思う。

  • プロジェクト予算が潤沢な場合、求めるクオリティや作業量は高い一方でコストがかさんでもあまり問題にはならないため、マネジメント側も残業に対して寛容（ルーズ）になる。スタッフ側も残業代を稼げるのでダラダラと長時間働く。
  • プロジェクト予算が枯渇している場合、予算とスケジュールがタイトな一方作業量が多いため、上から下に「何とかしろ」というマネジメントではないマネジメントが続き、長時間のサービス残業が強いられる。（結果、プロジェクト終了前後で大量に退職者を発生させる）

幸いなことに私自身は（若干は自分のマネジメントの成果、と信じておこう）後者のような状況に長期間関わったことはないが、前者の状態は確かに存在してしまっている。

半ば当たり前になってしまっていたこの文化に対して、初めて全社ミーティングで取り上げそこにメスを入れていかなければいけないと会社としてオフィシャルに表明されたことはこの会社にとって非常に大きな意義があるはずだ。

僕のチームの場合

今月、残念ながら緊急性の高い障害が発生してしまったのでまさに自分のチームでも長時間残業をせざるを得ない状況となった。そうでなくとも残業に対して寛容（ルーズ）な雰囲気のあるプロジェクトのため何もしなければ問題となるレベルまで残業が膨らんでしまう状態だった。そのような状況を絶対に作りたくなかったので（この背景はちょうど資料作成中などで別途書きたい）、以下のようなマネジメントをしていった。

  • 残業時間の定期的なモニタリング。マネジャー、チームリーダクラスで週次でレビューする。これは長時間残業が発生していない平時から実施している（そうでなければ変化を早いタイミングで察知出来ないし、察知できる仕組みを確立しておけない）。
  • メンバのタスク単位でのマイクロマネジメント。チームの自走化ができているので、平時は週2回の案件レビュー会以外はほとんどタッチしないようにしている。そういう時でも細かくみてしまうとメンバのマネジメントスキル向上を阻害してしまう。一方で今回のような問題が発生した場合はタスク単位で状況を把握し、優先順位付け（次にすべきタスクの指示、今日やるべきこととそうでないことの切り分け）や、タスクの具体的な方向性の指示などまで含めてマネジャー側から行う。これはタスクの整流化・効率化の意味合いだけでなく、通常移譲しているマネジメントタスクをいったんマネジャー側に戻すことでメンバに実タスクにフォーカスする時間を確保することにもなる。*1
  • 長時間残業が及ぼす影響（会社のコスト、個人の評価、健康、また労働基準法的観点から）についてメンバに知ってもらう機会を作る。上述のようなマイクロマネジメントを行う上で、いきなりマネジャー側から実施してしまってはモチベーション低下や反発を招きかねないし、また実際にそのような影響について若いメンバは特に単純に知識がない。背景を知ってもらい、意図を理解してもらった上で行う場合とそうでない場合は結果にも影響してくる。

十分に行えた部分とそうでない部分があり、自分としても非常に勉強になった経験だったが、メンバに対してコスト意識、パフォーマンス（成果/コスト）意識の醸成につながっていけば、全社的なムーブメントにも寄与するはずだ。

*1:とはいえマネジメントタスクを取り上げる、細かい作業指示をするというのは当然メンバのモチベーション低下につながるので塩梅が難しい。。今回も残業時間低減だけを考えればもっと強行的にマイクロマネジメントをすべきだったが、かなり口出ししない部分を残し、故にその分残業時間は膨らんでしまったと思う。

アイディアの育て方（バンドマンの曲作りを例に）

雑記

アイディアを生み出すということが、ビジネスにおいて昔よりも比重が大きくなってきている。これはIT技術の進化によってシミュレーションなどの方法が次々と確立され、実験コストが飛躍的に低下したからだ。

そんなアイディアを生み出す伝統的な方法がブレスト、すなわちブレーンストーミングである。すこし前にこんな記事もあったが、僕もこの意見に賛成で、ブレストからは大したアイディアが出ることはないと思っている。

ブレストの欠点

まずはブレストの欠点を出しておこう。複数人で議論していることで決定的に問題なのは各人が他の人の議論に惑わされて「深い思考」が出来ないことだ。色々な人が色々な角度から話をするので、話題が分断されある一点を掘り下げるということが出来ない。

この点は更にもう一つの欠点を招く。各人は深く掘り下げた思考が出来ないため、例えいいアイディアがあったとしてもそれに自信が持てない。いいアイディア、すなわち新規性・革新性があってかつ価値があるアイディアというものは、その新規性が故にパッと思いついただけでは「本当に価値があるのか」「実現可能なのか」などというところまでは判断出来ない。ブレストの原則として「他人の意見を否定しない」ということを頑なに守ったとしても、そもそも各人が自信が持てないようなアイディアを口に出しにくいはずだ。

これはビジネスではなく、以前に僕がバンド活動、音楽活動を行っていたときに思ったことだ。

バンドでの曲作り、といって（特にそのような活動を行ったことがない人からすると）どういった過程を思い浮かべるだろう？ギターがリフ*1をなんとなく弾き始め、それにドラムやベースが合わせてだんだんとリズムとグルーヴが出来上がる。それを聴きながらボーカルが歌詞を書きながら最後に歌を乗せる、というような感じじゃないだろうか*2。この「何となく出来上がっていく」というのがバンドがバンドとして曲作りしている、という感じではないだろうか。

しかし、残念ながらこのような曲作りで名曲を作れるのはいないとは言わないまでも、ほんの一握りしかいない。それこそ十年単位で一緒にやっているメンバであれば出来るかも知れないが、これから活動を始めようとしているようなバンドでは絶対に無理だ。

このような場合「芯」がない、というか「芯」をメンバが見えない状態になっている。曲のテーマは何か、良さは何か、新しさは何かといったところが曲自体が未完成な状態では伝わってこない。これは最初にリフを弾き始めたギタリスト（でなくても構わない、最初に弾き始めた楽器）でも分かっていたり分かっていなかったりするはずで、最終形としてどういった形になるべきかは絶対に分かっていないはずだ。そういった「芯」が見えない状態で始めると、みんなが他のメンバの様子を伺って「なんとなく」合わせているだけになってしまって面白みのない曲にしかならないのだ。

まずはひとりで

それよりも、まずは納得いくまで一人でアイディアを煮詰めるほうがいいものが出来る、と思う。一人で煮詰めて自分が「最終形」と思うところまで形にする。

ここで「掘り下げ」が出来る。最初のアイディア、ビジネスで言えば妄想レベルの「こういうのどう？」といったこと、曲作りで言えば最初のリフなんていうのは何となく夢想していたり、何となく楽器をいじったりしていれば1つ2つ思いつく。それを最終形にしていくのが時間の最もかかる作業だし、集中しなければならない作業なのだ。それを多人数で30分や1時間の間にしろ、というのは無理な話だろう。

名を残しているクラシックの作曲家たちは大勢で集まって作曲しただろうか。そうではなく、ほとんどの楽曲は作曲家が一人で書き上げたものばかりだ。センスや技術を研ぎ澄まして結晶化させる、ということには一人での作業のほうが向いているということは、この歴史が教えてくれている。

ようやく出来上がった「俺的最終形」を、まずはメンバに聴かせる。どういった展開をしてどこで何を一番聴かせて、それらを総合してどういったテーマなのか、その時点になったら語れるようになっているはずだ。

最後に周りが磨く

もちろんギタリストは他の楽器が上手いとは限らないので、自分が思う最終形を作ったとしてもドラムのフレーズはダサダサ、ということもあるだろう。

しかし上記のように「俺的最終形」を聴かせられた時点であれば、各パートのメンバは「だったらここはこういうフレーズのほうがいい」という提案が出来る状態になっている。これは「俺的最終形」を聴かせられない、ただ断片のみ披露された時点では出来ない。なぜならばどういう曲かが（他のパートは拙いなりに）見えているから。

もちろんここで「そんな曲俺はやりたくない」というメンバも出てくるだろう。これ今回の「アイディアの育て方」という話とは別なので割愛する。

*1:曲のテーマとなるキャッチーな繰り返しのフレーズ

*2:ここまでイメージ出来ていたらバンド活動していた人に違いないけど

飽きると勝手に越境する

雑記

DevLOVE Advent Calendar 2014の12/5分の記事です。「越境」というキーワードで1日づつ様々な方が記事を書くというシリーズです。12/4はギルドワークスの@yohhatuさんの「ええやん」と思ったらやっていこうでした。こちらの記事を読む前に以下の下書きをしたのですが、読ませていただいたら「あ、なんか同じこと言ってる。。。」となりました。かなり自由度の高いテーマの中、偶然ですね。

自己紹介

グローバル総合コンサルティング会社にてシステム開発・運用のプロジェクトマネジメント、サービスマネジメントを主に行っています。自チームでのRedmine導入を始めてから、もっと楽しく効率よくソフトウェア開発をしていきたいなと思い、最近アジャイル・DevOps関連の勉強中です。

自分にとっての越境

つい先日、やっと肩書きもマネジャーになりました。おめでとうございます、ありがとうございます。これもひとつの節目、ということで越境かと。

越境、すなわち境界を越えるということですよね。境界、境い目を作るというのは人間があるものとあるものを識別するために設定した恣意的な行為です。本来境界などというものは自然界には存在しない。例えば国境なんてものは人間がそこに線を引かなければ存在しないのです。さらに陸と海の境界線も、絶え間なく動いているものですし、砂と水が混ざり合っているので1ピクセルの線で厳密には引くことはできないです。

何が言いたいかと言うと、境界線によって設定される領域などというものに本来意味はなく、色んな場所に散らばっているものを如何に有機的に結びつけて新しいもの、価値のあるものを作り出せるのか、ということが重要なんじゃないか、ということを以下で語ってみます。

スペシャリストとジェネラリスト

スペシャリストとジェネラリストという対義語があります。特定の領域に造詣が深く専門的職能を使い活躍する人をスペシャリスト、各方面に広く浅い知識を持ちそれらを組み合わせて活躍する人をジェネラリストというのが一般的な認識でしょう。

マネジャーという仕事はジェネラリスト職と言われます。チームメンバの成果や意見をまとめ、色々な顧客や上位マネジメント層と折衝する、確かにジェネラリストっぽいです。

しかし一方でスペシャリストとしての性質も有しています。プロジェクトマネジメントで言えばPMBOKでまとめられているような知識セットがあり、EVMやクリティカルパスメソッドなどのツールなどを有効に使えば、プロジェクトマネジメントという領域で効果的な価値を生み出すことが出来る（はず）です。究極のプロジェクトマネジャーは果たして、ジェネラリストでしょうかスペシャリストでしょうか。

この問いに対するヒントは確かトム・デマルコ『ピープルウエア』にありました。記憶ベースで記載するので正確ではないかも知れませんが、「軍隊の優秀な指揮官を教師にすれば非常に良い教育が出来るはずだ、という人がいる。しかしそれに対しては『では、優秀な教師を指揮官にすれば非常に良い軍隊になるのか？』と問えば良い。」という内容です。すなわちデマルコが言いたいのは軍隊と教育機関、それぞれには別々の背景・文脈があるので普遍的に通用しうる管理・指導などというものは存在しない、ということだと思います。

プロジェクトマネジャーはPMBOKなどの知識をベースにしながら、業種や状況を踏まえて取捨選択、カスタマイズした管理を行わなければいけません。そのために業務知識や技術知識、財務やヒューマンリソースに関する知識、コミュニケーション能力など幅広い知識・能力を持ち合わせていなければならないという意味でジェネラリストなのでしょう。

では一方で一般にスペシャリスト職と言われるような職業ではどうか、自分の専門領域だけの知識を日々積み重ねていけば良いのかというとそうではないでしょう。結局自分の専門以外の領域の知識を仕入れ、専門領域と組み合わせない限りは新しいもの、価値あるものを生み出すことはほとんど不可能に近いです。

結局ジェネラリスト職、スペシャリスト職などという区分も程度でしかなく、自分の職種に依らずどこまで自分の専門領域を深掘るべきか、どこまで手広く知識を付けるべきかというバランスを自分で取らなければなりません。

飽きると勝手に越境する

では何を以ってそのバランスを見極めれば良いのでしょう？個人的に最近勝手に思った（というか思うことにした）答えとしては「自分が飽きたかどうか」でいいんじゃないかということです。

世の中にはひとつのことにひたすら傾倒してその道を極めるような人もいます。僕の会社にもSAP社のソリューションについて唯一無二の知識を持っていて、何かSAPソリューションで課題が発生したらとりあえずその人に聞いてみよう、なんて人もいます。

それに対して僕の場合は飽きやすい。その時々でなんとなくテーマはあるんですが、読む本のジャンルがコロコロ変わります。ここ2-3年で、マネジメント論、人類の歴史、宗教、哲学、美学、倫理、未来、デジタル、Redmine、アジャイル、DevOps、経済学、組織行動、システム思考、人工知能と、（小説や漫画を除いても）結構雑食なほうだと思います。

一時期はもっと何かに絞ったほうがいいんじゃないかと思ったこともありました。それこそもっとスペシャリティを持つべきじゃないか、自信を持って「僕は○○なら誰にも負けません」と言えるようなものを作るべきじゃないかという不安感です。

しかし最近飽きるということを非常にポジティブに考えるようになりました。これにはある元上司と、ある知人の以下の言葉が元になっています。

お前はなんだかよくわからない状況にぽんっと突っ込んでも分からないなりに成果を出せる。だから使いやすい。

お前は何か新しく始めてもすぐにそこそこ良い感じのアウトプットを出してしまう。

片方は仕事、もう一方は完全にプライベートでしか関わりあいのなかった人たちからほとんど同じようなことを言われたわけです。飲み込みが早いということだとポジティブに受け取っています（真意は分かりませんが）。

つまり飽きるのは「だいたい分かった（気になる）」からのはずです。このくらいのことが分かったら自分が必要とするレベルの知識が身についた、これよりも深く知ったとしても（だんだん限界効用は逓減するので）それほど面白くない、そんなに役に立たない、と「飽きた」と感じたときに判断しているのです。そこででは次は○○の領域に、と勝手に越境が発生する。

これを続けていけば自分の求めているレベルのスペシャリティとジェネラリティに到達することが出来るんじゃないでしょうか。そして越境を重ねただけ散らばった知識や能力を、どこかの機会で有機的に結びつけることで新規性と価値を提供出来るはずです。当然そのためには単に飽きるだけではなく、次は何に取り組もうかという探究心が続かなければいけないのですが。

こう考えると飽きることに対して気軽になれ、気楽に越境を経験出来るのでは。

次のひとへ

@emorinaさんです。ちょうどこないだのDevLOVEプレイバック甲子園でRails Girlsのプレゼン聞きました！よろしくお願いします。

 

A Guide to the Project Management Body of Knowledge: Official Japanese Translation(プロジェクトマネジメント　知識体系ガイド　PMBOKガイド)

A Guide to the Project Management Body of Knowledge: Official Japanese Translation(プロジェクトマネジメント　知識体系ガイド　PMBOKガイド)

 

 

ピープルウエア 第3版

ピープルウエア 第3版

 

 

Redmineのカスタマイズ方法

Redmine Slideshare ソフトウェア開発ツール プロジェクト管理

先日自チーム内の勉強会で「Redmineのカスタマイズ方法」についてPowerPoint資料にまとめたので一般公開出来る内容に微修正して公開しておく。

例によってチームメンバの英語の練習を兼ねた資料なので全編英語、Redmineの画面も英語版でスクリーンショットを取得しているので、英語版で使用する場合に特に参考になるだろう。

 
Redmineの導入をひと通り終わったプロジェクトで次に問題となることの一つが「あの人しか設定をいじれない」ということなんじゃないだろうか。
カスタマイズ方法についてRedmine.JPの「Redmine Guide日本語訳」も充実しているのである程度の興味があれば十分な情報がすぐに得られるはずだが、なかなか「とっかかり」がないとそれも難しいよう。
そういった場合に導入推進者がこの資料などを使用してメンバにカスタマイズ方法をレクチャーするというのが「とっかかり」としていい機会になるはずだ。
Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法

 

 

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

 

 

プレイバックDevLOVE現場甲子園2014に参加してきました

イベント アジャイル

DevLOVEのイベントに初参加してきました。

 
今回は以前に行われた「プレイバック現場甲子園」ということで、2013年、2014年に行われたプレゼンテーションの再演ということでしたが、半分以上は焼き直してました。
計10人の20分のプレゼンを聞いたので、全部まとめていると大変なので面白かった・考えさせられたものだけまとめておきます。

俺のエンジニアリング：及部敬雄さん

「ぼくのかんがえたさいきょうのふつうのチーム」のアップデート。
「エンジニアリングにチームビルディングは必要なのか」という問いでした。テクノロジーに走るとむしろ無視されがちな話題だったり、逆にそういう話題を考えるときには当然必要という前提だったりするので面白い問いだと思います。
ダメダメなチームでも、各チームメンバに話を聞いてみると意外と現場にいるメンバはどう改善すべきかに気付いている、けどそれを変えようという行動は起こしていない、というのはあるあるだなと。「人は変化を好むが、他人に変化させられることを好まない」（『リーン開発の現場』より、だそう）ので、そういったときの改善策の持ってき方として、「みんなにヒアリングした内容をまとめただけです」といって持っていくというのは凄くいい方法。結局メンバに「やらされてる感」が出てしまうともうダメで、（嘘でもいいから）彼ら・彼女ら自身から改善案が出る（出たように見せる）ことが必要なのだと。 
リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

 

 

ユーザーが「それいいね！」と言うまで：志田裕樹さん


ユーザーが「それいいね!」と言うまで // Speaker Deck

犬版のTwitterサービスをやっているとのことで、ユーザーにGoogle Hangout経由でインタビューしたり、やはりエンタープライズシステムの運用・開発とは違うな、とただただカルチャーギャップを感じました。

エンタープライズシステムの場合、特に運用の場合だと、クライアントサイドの予算制約があるので、「如何に要求を抑えるか」という部分に目線がいきがち。開発の場合でもユーザと直接要求開発することはあまりなくて、クライアント企業のトップマネジメントと大枠は決めてしまうので、要求の曖昧さも薄い。
 

自分のチームをどう作る？ by すぎいまさかつさん

SIerでちょっと前に課長職になった方が自分のチームをどうするか、というお題。それに対してFearless Changeという本からヒントを得たことを中心に実践したことの紹介。僕もちょうど先月から課長なので同じ立場だったので非常に「分かる」問題意識だった。
他のチームと差別化した旗印（この方の場合はアジャイル）を掲げることで、人を育てられる（長期的に人材を確保し、頻繁な出入りが発生しない）ようにする。その他、「とりあえずやってみる」とかはよく言われることだけど、懐疑派代表（実践したいことに対して否定的な人物）を味方に付けるというのはあまり語られないことだと思うのでなるほどと思うところもあった。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 

 

デザイナーもアジャイルをやってみたい by 秋葉ちひろさん

エンタープライズシステムの世界だとデザイナの人の話を聞く機会なんてほとんどないので新鮮。それ故自分の業務には直接結びつかないなと思いながら聞いていたのだけど、どちらかというと提案書とかのパワーポイントを作っているときの作業の仕方に似てるなと。
「4時間で2画面」よりも「1周間で10画面」のほうがデザインには合っているというのは納得。アジャイルの方法を取り入れたときにイテレーションの間隔をどれくらいにするかというのはそれぞれのチームやメンバ、あるいは作業の内容に依って違うべきで、唯一解的なイテレーション間隔というのはないと思う。
「価値検証（サービス自体がユーザにとってどのような価値をもたらすのか）」と「デザインの検証」（デザイン自体の良し悪し）が同時に起こることを防ぐというのはパワーポイントの紙書きのときにも当てはまる。最低限のデザインの価値とテイストが分かるものをいかに素早く作るかというのはまさに鉄則。また、最初から凝りすぎてそれがボツになったときのMP消費（笑）が半端ないというのも一緒。
 

私がドメイン駆動設計をやる理由 by 増田さん

ドメイン駆動設計、いわゆるDDDは名前は知っていたもののどういうものか全く知識がなかったので知れてよかった。曰く、「変更コストが（地道ではあるが）劇的に下がる」とのこと。ポイントはモデル駆動、三層＋ドメインモデル、チームをドメイン駆動に、の3つ。
 「モデル駆動」としては現実世界の感心事をモデルとして単純化し、それをソースコードで表現するという2ステップをとる。パッと聞く限りは普通に要件定義書・設計書を作成してコーディングしていくのと何も違わないのでは？と思った。聞く限りは、例えば要件定義時にパッケージ図として書くなど、開発側の人が「この業務要件をどうソースコードに落としこむか」をその場で考えてモデル（設計書）に落としこむ、というところが違いか。
「三層＋ドメインモデル」というのは、プレゼン層、アプリ層、DB層とドメインモデルという分け方にすること。単純に三層だけだと、それぞれのレイヤに業務ロジックや重複ロジックが現れがちだったため、リファクタリングを繰り返した結果、ドメインモデルの部分に業務ロジックが集約されたとのこと。確かに、業務ロジックがどこかに集約されていれば、変更時の影響分析は格段にやりやすくなるはずだ。 
 

中間管理職がいなくなったらプロジェクトがうまく進みだしたよ♪：西秀和さん

管理者が突然いなくなったら現場はどうなるのか？というまとめ。個人的には心が痛いプレゼンテーションでした。
IPA IT人材白書によるとアプリ技術者2人に対してプロマネが1人いる計算になる。しかも企業はさらにプロマネを増やしたいと言っている！IT人材白書2014については僕も以下の記事でまとめていた。上記は掴みのネタとしては面白いと思うけど、実際にはプロマネはインフラ技術者の管理にも必要だし、日本国外（オフショア）の開発の管理にも必要なので、「2人の作業者を管理する管理者が1人」というのは正確ではない。

IT人材白書2014をプロマネ視点で読み解く - ぷろまねさん

とは言えその後の実体験からの「管理者不在での成功」は学ぶべきものがある。大炎上の末大失敗したサービスイン後、そのリカバリフェーズでは予算の都合で単価が高いマネジャーが切られたまたまエンジニアだけが残った、そしたら1ヶ月でリカバリ出来てしまった、とのこと。

その理由としては、管理者が作業者に対して「何をすべきか（WHAT）」の段階まで粒度を細かくして渡してしまうと、作業者はそのWHATに対して「どうやってすべきか（HOW）」、「なぜすべきか（WHY）」までさかのぼって考えるに至らず、自発的に動けなくなる。それがたまたま管理者がいなくなった状況では作業者たちで自発的にWHY / HOWから考えるので、適切な打ち手が打てるということ。

管理者側からしてもこれは（作業者もちゃんと頭の良い人々な現場という前提で）同意しないといけない内容だと思う。作業者にHOWの部分から振ってちゃんと考えさせる、考えるクセを付けさせることは必要なこと。一方ででは管理者は何をしていればいいのか？というのも大きな問いだと思う。これはまた別の機会に考えたい。

アドベントカレンダーやります

帰りがけに上手いことアドベントカレンダーのお誘いに引っかかってしまいました。

DevLOVE Advent Calendar 2014 「越境」 - DevLOVE | Doorkeeper

アドベントカレンダーという単語自体これまで知らなかったのですが、本来のアドベントカレンダーはクリスマスを楽しみに待つための1日ごとのお菓子入りのカレンダのことだそう。

エンジニアのアドベントカレンダーは何かのテーマに沿ってみんなで1日づつ記事を書いていくのだそう。

上記の通り、「越境」というテーマで12月5日に書くことになったようなので、それまでに考えておこうと思います。

Apple TVで作るワイヤレスAV環境

プライベートのほうが色々と忙しかったのでだいぶ空いてしまった。

ということで今回はそのプライベートでの作業の1つでもあった、先週行ったAV環境の再構築について。

Apple TV

今回の主役はこちら、Apple TV。 

Apple ハイビジョン対応 Apple TV MD199J/A

Apple ハイビジョン対応 Apple TV MD199J/A

 

 Mac miniを小さく黒くしたような製品だが、これをインターネットとテレビに繋ぐことによって

  • Youtubeなどのストリーミング再生
  • iTunesで購入した動画や音楽の再生

などが出来る。

しかし今回の主目的は上記のような単体での使用ではなく、AirPlayを使った各種端末からのワイヤレスオーディオビジュアル環境の構築。

これまでのAV環境と課題

これまでのAV・PC環境を図示すると以下の通り。

f:id:hnishim:20141103153500p:plain

ネットワーク自体は無線LANによってワイヤレス化出来ていたものの、AV環境がデスクトップPC依存になっている。

一方でコンピュータ端末はデスクトップPCの他にもMac book air、iPad、iPhoneといくつも存在していてそれらのどこからでもメディアにアクセスしたい。音楽メディアファイルはiTunes Match、動画などその他メディアファイルはQNAPのNASによってどの端末からでも引き出すことが可能になっているので、どこからでも鳴らしたり見ることは出来るのだけれど、それは各端末のスピーカやスクリーンからしか出力出来ないので、せっかくそこそこのテレビとスピーカがあるにも関わらずなかなか使わない。という状態。

ではデスクトップPCへのアクセスを出来るだけしやすくしようということで↓のワイヤレスキーボード＋マウスなどを取り入れてみたこともあったのだけど、やはり操作のしやすさはそれほど良くなく。

Lenovo ミニ・ワイヤレスキーボード N5902 0B44656

Lenovo ミニ・ワイヤレスキーボード N5902 0B44656

 

そもそもデスクトップPCが机のかなりの面積を（配線とともに）占めてしまっていることに対しても不満だったところで色々解決策を考えていたところ、「Apple TVがあればデスクトップPCなくせるな！」と思い立った。

Apple TVをハブとしたワイヤレスAV環境

ということで結果的には以下のような構成になった。

f:id:hnishim:20141103161256p:plain

Apple TVからはHDMI接続でテレビに、光（オプティカル）オーディオ接続でオーディオ・インターフェースに接続している。そしてオーディオ・インターフェースからはこれまで通りスピーカにアナログ出力している。さらにこのオーディオ・インターフェース、以前に音源制作で使用していたものなのでかなり入出力端子が多くあり、オプティカルオーディオ入力が2口ある。なのでテレビからの音声もこのオーディオ・インターフェース経由でスピーカから出力可能にした。

こうすると映像はテレビのみにいくためシンプルなのだが、音声のほうは結構複雑になる。

  • テレビの音声：テレビ自体のスピーカと、テレビ→オーディオ・インターフェース→スピーカの両方で出力される
  • iPhone等からの音声：
    • テレビが点いている場合：テレビ自体のスピーカと、iPhone→Apple TV→オーディオ・インターフェースの両方で出力される
    • テレビが点いていない場合：iPhone→Apple TV→オーディオ・インターフェースで出力される

つまり、Apple TVにHDMIとオプティカルオーディオの両方を接続した場合、必ず両方から音声出力される。これは設定の中に関連する項目はなかったように記憶している。当然、テレビとスピーカの両方から音が出てしまうと微妙な音ズレによって濁ってしまうので、どちらか（基本的にテレビ、リモコンで操作可能なので）を消音して使用するという寸法。

AirPlayでの操作

配線とApple TVの初期設定さえしてしまえばあとは非常に簡単。

音楽の場合は各端末からiTunesを立ち上げれば以下のようなディスプレイのようなアイコンが出てくるので、これでApple TVを選択すれば自動的に端末のスピーカからApple TVの（に繋がっている）スピーカに勝手に切り替えてくれる。Bluetooth接続のように複数の端末を繋げておくと前に接続していた端末を一度切り離してから別の端末を繋げる、というような面倒なことをしなくても、常に今使いたい端末からの操作だけで繋げてくれる。この辺りはさすがApple製品のエコシステムといったところ。

f:id:hnishim:20141103163028p:plain

映像の場合も基本的には同じ。iPhone、iPadからはブラウザで動作再生するだけだと端末側で映像再生、全画面表示にするとテレビのほうに自動的に映像が映ったりする。ここらへんは親切設計のようにも見えるし、使い方によっては好みが分かれそう。

いずれにせよ、どの端末からでもいつでもちゃんとしたスピーカから、大画面のテレビから音声・映像を映し出せる、しかも手間がかからずに、という環境が出来たことは大満足。Apple製品以外からが出来ないところが難点だろうけども僕の場合のようにApple製品だけしかなければ問題ではない。Chromecastもテレビに対しては同じことが出来ると思うけど、音楽再生環境を重視するのであれば現状Apple TVの代替製品はないかも。

セットアップで困ったところ

Apple TVのセットアップにはほとんど困らなかった。ただし、単体ではスクリーンもボタンもまったくない製品なので、設定をどうやってやるの？というのは説明書を読まないと一瞬分からない。テレビ等を接続すれば自動的に設定画面が出るし、付属のリモコン（最初の設定以外では全く使っていない）を使って設定を行うのだが、直感的にそれを理解出来る人はいるだろうか？ただ、これはそういう製品なので悪いところではないと思う。むしろ、ガジェット好きならば新鮮な感覚で楽しいはず。

それよりも今回難儀したのはオーディオ・インターフェースの設定のほう。まずそもそもこのオーディオ・インターフェースがスタンドアロンで動作することを確認し、今回の構成にすることにしたのだが、単に接続しただけでは音が出なかった。オプティカルオーディオ端子を使用したのが今回初だったというのもあるのだが、結果としては同端子はADATとTOSLINKという2つの規格を兼ねた端子だった。ADATはマルチチャンネル（8チャンネル）の音声信号を同時に流すことが出来る規格、一方でTOSLINKは通常のステレオ音声信号（たぶん）を扱う規格。このADAT/TOSLINKの切り替えをオーディオ・インターフェース側で行っていないとオーディオ・インターフェース側が信号を受け取ることが出来ず音が出ない、ということだった。

そもそもこのオプティカルオーディオ接続規格、Apple TVのようにオプティカルオーディオとふんわりした記述の仕方だったり、上述のADAT、TOSLINK、はたまた微妙に端子の形状の違うS/PDIFなどあったりしてなかなかややこしい。

その他

前述の通りデスクトップPCをなくしている。Windows環境がなくなること、またAcrobatなどWindows用に購入していたいくつかのソフトウェアが使用できなくなるわけだが、どうしても必要になればBoot Campなど使ってMac上にWindows環境を築けばいいだけ。

ただ、モニタがないのは少々不便。本当はThunderbolt Displayを買いたいところなんだけど、5K iMacが登場した今2011年からアップデートされていないこれを買うのは確実に負けな気がするのでアップデートあるまでは待とうかと。

APPLE iMac Retina 5K Display 27 (3.5GHz QuadCore i5/8GB/1TB Fusion/ AMD Radeon R9 M290X) MF886J/A

APPLE iMac Retina 5K Display 27 (3.5GHz QuadCore i5/8GB/1TB Fusion/ AMD Radeon R9 M290X) MF886J/A

 

 

アップル Thunderbolt Display(27インチフラットパネル) MC914J/B

アップル Thunderbolt Display(27インチフラットパネル) MC914J/B

 

 

いくつか試してみたMOOC

今週いくつかMOOC (Massive Open Online Courses)、すなわちオンラインで講座を受講できるサービスを試してみたのでそれをまとえておく。まだedXの講座しか受講出来ていないのでもう少しこなしてから更新したい。

1. gacco http://gacco.org

今回MOOCを試すきっかけとなったのがgacco。ドコモが出資？しているようで同社のTwitterで流れてきたので知ることとなった。日本でのMOOC自体がまだ盛り上がっていないのでどこもまだデファクト・スタンダードと呼べるサービスはないのだけど、その中では比較的充実しているのではないかな？（日本（語）でのMOOC情報はJMOOC http://www.jmooc.jp で横断的に探せるよう。）

受講予定の講座

今回受講申込をしたのは2講座。どちらも未開講のため聴講はまだ出来ていないですが。

  • 人とロボットが共生する未来社会 https://lms.gacco.org/courses/gacco/ga018/2014_12/about
    • カーツワイルの言うGNR（遺伝子、ナノテクノロジー、ロボット）革命。今後この3分野については基礎知識を付けていかなければと思っていたところだったのでちょうどちょうどいいなと。特にロボット技術は3分野の中でも一番ITと親和性が高い分野ですし。この講座はロボットを作る技術ではなく、ロボットと人間が共生するようになってからの社会についての哲学的議論を主題にしている、ということなので、『アンドロイドは電気羊の夢を見るか』や『イヴの時間』などのSF作品にも近しい題材であり楽しみ。今年12月から開講だそう。
シンギュラリティは近い―人類が生命を超越するとき

シンギュラリティは近い―人類が生命を超越するとき

 

 

「イヴの時間 劇場版」 [Blu-ray]

「イヴの時間 劇場版」 [Blu-ray]

 

 

アンドロイドは電気羊の夢を見るか？

アンドロイドは電気羊の夢を見るか？

 

 

アジャイルプロジェクトマネジメント

アジャイルプロジェクトマネジメント

 

その他、現在準備中の「マンガ・アニメ・ゲーム論」は趣味として聴講するつもり。

セカイ系とは何か ポスト・エヴァのオタク史 (ソフトバンク新書)

セカイ系とは何か ポスト・エヴァのオタク史 (ソフトバンク新書)

 
 

サービス

会員登録はよくある情報以外には最終学歴程度を入れさせるシンプルなもの。あとで分かったが後述のedXの登録画面に酷似していたり、サイト全体が同サービスをほぼそのまま日本語に焼き直した様子が伺える。しかしそれもあってサイトの完成度は高くNTT運営なのもあり安心感はある。講座数は終了したもの、未開講のものを合わせても25とやはり後述のグローバルサービスと比べると少数。しかし日本では今のところ最大の模様。

2. edX https://www.edx.org

ハーバード大とMITによって創設されたサービス。当然ほとんどの講座が英語だがキャプションも出るので何とかついていける。

受講中の講座

  • CS50x Introduction to Computer Science https://www.edx.org/course/harvardx/harvardx-cs50x-introduction-computer-1022
    • ハーバード大のコンピュータサイエンス入門講座。
    • 第1回（Week 0）のみ聴講してみたが、デジタル（0/1)の説明、アルゴリズムや基本的なプログラミング構文（if, for）の説明などさすがに基本的な内容。とはいえ僕は独学（しかも中学時代）でしかプログラミングも勉強していないし、コンピュータサイエンスを体系的に習っていないので、半分復習がてら良いかなと思っている。
  • CS188.1x Artificial Intelligence https://www.edx.org/course/uc-berkeleyx/uc-berkeleyx-cs188-1x-artificial-579
    • UCバークレイ校の人工知能の講座。2013年のアーカイブ済講座のため、ディスカッションだったりは出来ないがいつでも全講座聴講可能。
    • 第1回のみ聴講してみたが非常に面白い。AIの定義、AIで出来ること出来ないことなど第1回にふさわしい根源的な話をしてくれていた。こちらも超早口。
  • Introduction to Philosophy: God, Knowledge and Consciousness http://www.edx.org/course/mitx/mitx-24-00x-introduction-philosophy-god-2481#.VC_VPEstMds
    • MITによる哲学入門講座。「神」「知」「意識」の3つについて扱う模様。教授が凄いエモーショナル。つい先日9/30から開始なのでまだすぐにキャッチアップ可能。
    • 第1回を聴講したところ、これがものすごく面白い！「神がいる、またはいないということをどうやって議論によって証明できるか」という内容だったが、Lecture 2からのValidity, Soundness, Potential Convincingnessについての議論は論理学的な内容に始まりより実践的な内容まで深堀りしているので一見の価値あり。

受講予定の講座

これからの「正義」の話をしよう ──いまを生き延びるための哲学 (ハヤカワ・ノンフィクション文庫)

これからの「正義」の話をしよう ──いまを生き延びるための哲学 (ハヤカワ・ノンフィクション文庫)

 

 

繁栄　明日を切り拓くための人類１０万年史

繁栄　明日を切り拓くための人類１０万年史

 
 

サービス

会員登録は独自方式の他にFacebookアカウントもしくはGoogleアカウントとの連携でも可能。動画配信自体はYouTubeを使っている模様。動画を見るだけでなく講座によっては選択・記述式での小テストやディスカッションフォーラムも用意されているので理解度は高められると思う。ただ、講座の検索には難あり。キーワード検索が出来ないし、フィルタも後述のCourseraのように複数選択等も出来ないので探しにくい。講座数は300件ほどとかなりの数があるがCourseraには及ばない。ただ個人的にはCourseraよりも興味を引く講座が多かったように思う。

1. Coursera https://www.coursera.org

edXと双璧をなすメジャーなMOOCサービスがスタンフォード大中心のCourcera。

受講予定の講座

イノベーションのジレンマ 増補改訂版 (Harvard business school press)

イノベーションのジレンマ 増補改訂版 (Harvard business school press)

 

 

  • Paradoxes of War https://www.coursera.org/course/warparadoxes
    • プリンストン大による戦争学の講座。アーカイブ済講座のため全部聴講可能。
    • 『文明と戦争』という本を上巻だけ読んで結構面白かったんだけど下巻を積ん読したままな状況で、直近の興味の対象ではなくなってしまっているが人類の本質を知るにあたって落とせない領域ではあるはず。
文明と戦争 (上)

文明と戦争 (上)

 

 

  • Nanotechnology: The Basics https://www.coursera.org/course/nanotech
    • ライス大によるナノテクノロジ入門講座。アーカイブ済講座のため全部聴講可能。
    • 前述のカーツワイルのGNRの2つ目であるナノテクノロジ。これも入門的な内容は抑えておきたいなと。
  • Model Thinking https://www.coursera.org/course/modelthinking
    • ミシガン大によるモデル思考法についての講座。10/6より開始。
    • 基本的に「モデル」という言葉に弱いのであまり内容知らないまま申し込んでおいた。
  • Philosophy and the Sciences https://www.coursera.org/course/philsci
    • エディンバラ大による哲学と物理学・認知科学あたりの関係性についての講座。10/20より開始。
    • 科学が哲学を基にして発達したというのは多小学のある人であれば知るところだと思うが、その具体的な関連の仕方まではなかなか普通にしていたら知れない内容。単純に面白そう。
  • Introduction to Genetics and Evolution https://www.coursera.org/course/geneticsevolution
    • デューク大による進化と遺伝についての講座。2015年1月より開始。
    • なんとカーツワイルのGNRの3つともgacco/edX/Courseraでカバー出来てしまった。
  • Nonlinear dynamics 1: Geometry of chaos https://www.coursera.org/course/chaosbook
    • ジョージア工科大学によるカオス理論についての講座。2015年1月より開始。
    • カオス理論について、まったく予備知識はない。とりあえずこのあたりを読んでおいた。http://www.h5.dion.ne.jp/~terun/doc/kaosu.html ついていけるか分からないが聴いてみよう。
  • Artificial Intelligence Planning https://www.coursera.org/course/aiplan
    • エディンバラ大による人工知能による計画についての講座。2014年1月より開始。
    • 生産計画や配送計画など企業内システムで計画を担うアプリケーションは一般的だが、まだ完全にロジックを実装しての計画がまだ支配的だろう。もちろん検索アルゴリズムなどではもう人工知能は一般的なのだろうが、計画、特に企業内での計画という意味だとまだ余白のある分野だと思うので面白そう。
  • Introduction to Systems Engineering https://www.coursera.org/course/introse
    • オーストラリアのニューサースウェールズ大によるシステム工学の入門講座。2015年3月より開始。
    • コンピュータ科学とともにIT領域の学問であるシステム工学。両者の違いもイマイチ曖昧なため、その違いを知るためにも。

サービス

会員登録方法は名前、メールアドレス、パスワードのみのシンプルなもの、他のサービスとの連携はなし。まだ聴講していないので講座自体の良し悪しは分からないが、講座検索は非常に充実している。分野や言語でフィルタ出来たり、キーワード検索も可能。講座数は750件ほどとおそらく世界最大。とはいえ中国語での講座だったり、現在配信していない講座も結構多いよう。edXはほとんど学術的な講座に見受けられるが、Courseraの場合は実学（交渉術とか、馬の育成（笑）とか）や一般教養（ロックの歴史とか）的な内容も含まれている印象。