機内で観た映画

出張の帰りの飛行機の中で、久しぶりに邦画を見た。 普段絶対に見ないのだけど(昔は映画散々見たけど、今はほとんど時間の無駄だと思ってる)、今世の中でどんな映画が作られているのか、参考に知っておこうかなと思って珍しく見てみた。

はたして期待はしてなかったけど、これがほんとひどかった。 昭和時代の雑貨屋の店長が、悩み相談を手紙でやりとりするという内容なのだけれど、次から次へと、都合良く設定された感動させようとするだけの(感動の押し売り)ストーリーがオムニバス的に展開される。

こういう作品いっぱいあると思うけど、とにかく設定・プロット以外に何も伝わるものが無いんだよね。 『養護施設の子供を見舞ったらその晩火事になって、子供を助けるのとひきかえに亡くなってしまう。』 て書けば、もう映画を見たのと同じ。

見た後、どうしてこんなつまらない映画を作っちゃうんだろう、と考えた。

おそらく、原作はもっと描写のあるまともな作品なんだろう。 ヒットした原作を基にして、売れてる俳優そろえて、主題歌にいい曲持ってくれば映画はヒットする、と考えてるからなんだろうか。 何か伝えたいことがあって映画を作ってるんじゃなくて、映画を作って興行収入を得ることが目的。商業映画と言って片付けてしまえば、そうなのかもしれないけど。。

その時ね、ネットで見た小室哲也の引退のニュースを思い出した。

小室哲也のニュースは、引退とか不倫の話とかは全く興味無いけど、意外にも彼の話に共感した。 それは彼の、新しい音楽を作る自信が無くなった、枯渇したという告白だ。

売れていた時代は、ヒット曲をつくろうと思ってやっていたのではなく、好きな音楽をやっていたと。 それが、いつしかヒットメーカーのイメージとか、期待に応えなくちゃという意識の方が強くなってしまったんだろうね。

そして、今回自分が勝手に見た映画と結びつけたのだが、映画とか音楽とか小説って自己表現の場でもある、にもかかわらず、世の中のニーズに応えようとしすぎなんじゃないかと。

もちろん、今回のような商業映画は元々"売れる"ために作ってるのだから、売れさえすればOKなんだけど、 そうではなくて、いつの間にかそういうものに縛られてしまった人も多いんじゃないかと思う。

本来創作って、もっと自由であるべきなのにね。

ビジネスもそう。

マーケティングだの市場分析だの、競合分析だの、そういうものばかりやったところで、斬新で破壊的なビジネスは生まれない。

カイザースラウテルンより愛を込めて

研究目的の出張で、ドイツのカイザースラウテルン市に来てます。 今日が最終日、明日に帰ります。

移動を除くと滞在三日間という期間だったけれど、色々な刺激をもらって、思い出深い出張になりました。

今回の出張の目的の一つは研究開発のパートナー探しであって、議論を終えたあと、 『申し訳ないけど、今回の件はあなただけではなく、他の研究機関も候補としてあたっている』と自分が告げると、 教授はすぐにニコっと笑って、 『つまりうちのcompetitorがいっぱいあるって事だね。気にするな、我々は競争を恐れない』 と言ったんだよね。 あの言葉は凄く胸に響いたな。

翻ってうちの会社なんかはすぐに、競合がやっているから他の戦略を考えた方がいいだとか、ブルーオーシャンじゃないだとか、その業界に会社の強みが無いとか言って批判するんだけど。

本当に必要なのは、オリジナルな思想を持つことだと思った。

オリジナルというのは、必ずしもユニークである必要は無くて、でもそれは、ネットや本に書いてある戦略を真似したものなんかではなくて、 自分で考え、自分で手を動かし、自分で苦労して辿り着いた思想であること。

それがあれば、一度決めたことは簡単に揺らがないし、不測の出来事があっても、誰よりもうまくハンドルできるはず。

星野仙一死去

なんと星野さんが亡くなりました。病床という報道も無かったので驚きです。

昔、中日のファンだった友人が、星野が阪神の監督になった時に、星野が監督する間だけ阪神ファンになると宣言してその通りにしていた。それだけ魅力のある監督だったんだよね。 おそらく中日ドラゴンズが一番盛り上がったのも、1999年の優勝時でしょう。

自分は阪神ファンだけど、星野監督で一番印象に残ってるのは、1999年の優勝の年に山崎武司阪神戦でサヨナラHRを打って、ぐるぐる手回して、星野にどうだーってガッツポーズしたシーン。星野泣いてたし、阪神ファンの自分もジーンと来た。

その後、星野が阪神の監督だった2002, 2003年は本当に楽しかったな。阪神ファンをしていて、やっぱり一番盛り上がった時期。 野村監督から変わって思ったことは、全身全霊を掛けた真剣勝負って、こんなにも喜怒哀楽が出るんだってこと。

そして星野は2003年は絶対優勝すると宣言して、開幕戦を見に行ったら、応援団が配ってた歌詞の紙に、「阪神優勝シリーズ」って書いてあったくらい、みんな絶対優勝すると信じてた。 終盤戦の緊迫感なんか、試合見ているこっちにも、ものすごい伝わってきて、勝ったときはいつも矢野と同じ渾身のガッツポーズが出たよ。

中日、阪神楽天のファンはみな同じ思いを受け取ったでしょう。

星野さんには、一番熱く燃えていたあの時代をありがとう、とお礼を言いたい。

それにしても島野さん、星野さんと続いて、意外にも一番奔放そうな田淵が長生きとはね…

GoogleTestの使い方と仕組み

GoogleTestの使い方

(今回googlemockの説明はしません)

  1. GoogleTestのソースコードを持ってくる https://github.com/google/googletest

  2. GoogleTestをビルドする GoogleTestのビルド方法は二つある。あらかじめコンパイラしてライブラリ化しておく方法と、自分のテストプログラムと同時にコンパイルする方法。

    1. あらかじめビルドする場合は、CMakeを使ってGNU向けのMakefile、もしくはWindowsの場合はVisual Studioのソリューションを作り、ビルドしライブラリ(静的ライブラリの場合gtest.lib)を作っておく。 具体的には、GoogleTestのソースをクローンもしくはダウンロードした際の、トップディレクトリの下にビルド用のディレクトリを作り(buildとする) buildディレクトリに入って cmake ../と打つ。cmake-guiの場合は、ソースディレクトリにGoogleTest自体のディレクトリを、ビルドディレクトリにbuildを選ぶ。出来たMakefileVisual Studioの場合はソリューションファイル)を実行して作成。
    2. テストプログラムと同時にビルドする場合は、googletest/src/ にあるgtest-all.ccを、ビルドの対象に設定する。(その際には、googletest, googletest/includeをインクルードパスに追加することを忘れずに)

    個人的にはこちらがオススメ。この方法だと、特にWindowsのようなランタイムライブラリの整合のためにビルドオプション(GoogleTestのソリューションファイルでのランタイムライブラリを、マルチスレッドにしたりしなかったり、デバッグにしたりリリースにしたり)を変える必要がなくなるから。

  3. テスト用のメインプログラムと、テストケースごとのテストプログラムを作り、ビルドする。

テスト用メインプログラム

GoogleTestを使ったテストプログラムのメイン関数はこんな感じになる。

#include "gtest/gtest.h"

int main(int argc, char **argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}
テストケースの記述

テストケースの記述は、TESTマクロもしくはフィクスチャを利用する場合はTEST_Fというマクロを使い、以下のように記述する。

TEST([TEST_CASE_NAME], [TEST_NAME])
{
  // user defined test routine
}

TEST_F_([CLASSS_NAME], [TEST_NAME])
{
  // user defined test routine
}

とにかくこれを好きなだけ書くと、RUN_ALL_TESTS()によって、全てのテストケースを自動で探して実行して、サマリを出してくれます。 TEST_CASE_NAME, TEST_NAMEには好きな名前を入れられる(サマリに分かりやすく表示するためのもの)。フィクスチャの場合は、[CLASS_NAME]に、フィクスチャに使うクラス名を入れる。 細かい使い方については以下を参照。 http://opencv.jp/googletestdocs/primer.html

GoogleTestの仕組み

一度分かってしまえば簡単なのだけれど、最初はフィクスチャは何の為にどうやって使うのだろう、という人もいると思うのでに、初心者向けに簡単な仕組みを説明します。

まず、フィクスチャというのは、最も良く使われるのは、複数のテストを実行するときに、テスト間で共通に実行する処理だったり、同じデータや変数を共有したい場合に使う。 例えばあるデータを読み込んで、少し変更して保存(シリアライズ)するようなテストで、読み込みは同じなのだけれど、保存はデータ変更の種別によって別々のテストケースとして分けたい、といった場合に、データの読み込み部分は共通化したい。こういうケースである。

こういうテスト間で共通の処理をやりたいケースでは、以下のようにフィクスチャを使ったテストを作る。 つまりユーザーは、テスト間に共通して持たせたいメンバを持ち、共通して実行させたい処理をSerializeTestのSetUp(), TeatDown()メソッドに書く。最後にTEST_Fのテスト関数本体のマクロ引数の一番目として、フィクスチャクラス名を書けば良い。

class SerializeTest : public testing::Test {
protected:
  // member
  FooData foo_data;
  
  // method
  SerializeTest() : foo_data() {}
  ~SerializeTest() {}
  
  virtual void SetUp() {
    openData("name");
    readFooData(&foo_data);
  }
  virtual void TearDown() {
    closeData("name");
  }
};

TEST_F(SerializeTest, change_a_type) {
  foo_data.a_type_data  = new_a_type_data;
  writeFooData(&foo_data);
  checkSerialize(&foo_data);
}

TEST_F(SerializeTest, change_b_type) {
  foo_data.b_type_data = new_b_type_data;
  writeFooData(&foo_data);
  checkSerialize(&foo_data);
}

これでテストを走らせると、RUN_ALL_TESTS()が実行され、TEST_Fのマクロを使って定義されたテスト関数を実行するときには、TEST_Fの引数の最初のクラスがフィクスチャのターゲットクラスとして呼び出されるようになる。 このプロセスの中身は以下のようになっている。

inline int RUN_ALL_TESTS() {
  return ::testing::UnitTest::GetInstance()->Run();
}

この呼び出しを追っていくと、UnitTest::Run()の中で、UnitTestImpl::RunAllTests()が呼び出され、その中で各テストケースを実行するTestCase::Run()、そしてTestInfo::Run()が呼び出されている。 TestInfo::Run()の中で実際に、フィクスチャとして定義したクラスのインスタンスがまず生成され、その時にフィクスチャクラスのコンストラクタも呼び出される。 そしてテスト実行前にSetUp()が実行され、テスト実行後にTearDown()が実行される。

ではここで、どういったクラスのインスタンスが生成されているかは、マクロの内容を追っていくことで分かる。

まず、マクロによってフィクスチャとしてテスト共通で維持すべきクラスの名前が、test_fixture_test_name_Testのように決められて(#defineの中の##は連結。上記の例ではSerializeTest_change_a_type_Testというクラス名になる)、 フィクスチャの定義でユーザーが作ったクラスを親クラスとします(上記の例ではSerializeTestクラスを親クラスとして子クラスの定義が作られる)。

この子クラスの定義では、コンストラクタと、TestBody()メソッド、TestFactoryImplを使って、インスタンスを生成しTestInfo*を返すメソッドが定義される。

そしてマクロ展開の最後が、この子クラスのメソッドのTestBody()のシグニチャ部までとなっており、メソッドの定義が、ユーザーが書いたテストルーチンとなるようになっている。

void GTEST_TEST_CLASS_NAME_(test_case_name, test_name)::TestBody() <-- expanded by Macro
{
  // user defined body routine ...
}

まとめ

つまり、ユーザ視点で簡単にまとめると、各テスト毎にユーザーが書いたフィクスチャクラスがインスタンス化されて、コンストラクタ、SetUp()が実行される。 (テストケース毎では無いので、各テスト毎に毎回インスタンス化され、実行されることに注意。テストケースにつき一度しか実行したくない場合については、staticなメンバとメソッドを使う方法が上級ガイドに記述されている)

そして、テストクラスのTestBody()メソッドとして定義された TEST_F(test_fixture, test_name) の部分が実行され、最後にTearDown()が実行される。 これを全テストケースで繰り返す。以上。

マクロの定義抜粋

#if !GTEST_DONT_DEFINE_TEST
# define TEST(test_case_name, test_name) GTEST_TEST(test_case_name, test_name)
#endif

#define TEST_F(test_fixture, test_name)\
  GTEST_TEST_(test_fixture, test_name, test_fixture, \
              ::testing::internal::GetTypeId<test_fixture>())

#define GTEST_TEST_CLASS_NAME_(test_case_name, test_name) \
  test_case_name##_##test_name##_Test

// Helper macro for defining tests.
#define GTEST_TEST_(test_case_name, test_name, parent_class, parent_id)\
class GTEST_TEST_CLASS_NAME_(test_case_name, test_name) : public parent_class {\
 public:\
  GTEST_TEST_CLASS_NAME_(test_case_name, test_name)() {}\
 private:\
  virtual void TestBody();\
  static ::testing::TestInfo* const test_info_ GTEST_ATTRIBUTE_UNUSED_;\
  GTEST_DISALLOW_COPY_AND_ASSIGN_(\
      GTEST_TEST_CLASS_NAME_(test_case_name, test_name));\
};\
\
::testing::TestInfo* const GTEST_TEST_CLASS_NAME_(test_case_name, test_name)\
  ::test_info_ =\
    ::testing::internal::MakeAndRegisterTestInfo(\
        #test_case_name, #test_name, NULL, NULL, \
        ::testing::internal::CodeLocation(__FILE__, __LINE__), \
        (parent_id), \
        parent_class::SetUpTestCase, \
        parent_class::TearDownTestCase, \
        new ::testing::internal::TestFactoryImpl<\
            GTEST_TEST_CLASS_NAME_(test_case_name, test_name)>);\
void GTEST_TEST_CLASS_NAME_(test_case_name, test_name)::TestBody()

SONYの電子ペーパーが凄い

SONY電子ペーパー買いました!

www.sony.jp

ソニーストアの定価で8万円します。しかもソニーストアでは発売後ずっと品薄・入荷待ちの状態で、それ以上の値段で出回ってましたね。 ようやく定価に近い値段に落ちてきたのでついに購入したわけです。

結果、期待していた以上の素晴らしい製品でした!

ちにみに、この製品は思い付きで買ったわけではないんです。 ちょうど10年くらい前に、会社内の課題で新しい開発提案を持ってこいっていうのがあって、その時に自分が本当に欲しいものを作る、という意気込みでE-Inkを使った電子ペーパーの提案をしたことがあります。(今もその提案資料がある) PDFを読み込めて、手書きで追記が出来て、書き味が紙同等で、拡大して小さく書き込めて、星印を付けたところは後から検索できるってのも正に思い描いてた通り。 後は、定型フォーマットに書き込んだ内容を読みだすとか、プロジェクタにページ内容を無線で投げるなんて機能も考えていましたが、個人で使う機能に関しては、その時に欲しいと思って機能がこのRT-RP1ではほぼ余すところなく実現されてます。

しかも、書き味も経験した中では最も違和感が無くて、普段紙に書いている自分の最高速で書いてもちゃんと途切れず付いてきてくれます。 いやあ、いくらでも増やせるPDFの元データに書き込めるとか、手書きのカット&ペーストという単純な機能が、これほど便利だとも思わなかった。

電子ペーパーの恩恵
  • これでまず、自分は論文とか標準書とか読む時に紙に必ず印刷していたのが、必要なくなった。
  • どの論文を読んだか、読もうとしていたのか管理出来なくなっていたのが解決した。
  • ノート・雑記帳が必要なくなった。数式の計算とか証明とか紙に書いてたのを、電子ペーパーにすることで、いくらでも編集出来るし見返せるようになった。
  • 手帳・カレンダーが必要なくなった。(とはいえ、既にアナログ品は使っていなかったのでそれ程のインパクトでは無い)

やっぱり値段的には高かったけど、購入してほんとに良かった。 論文とか、標準書とか日常的に読む人にはオススメです!

サラリーマン経営の時代は終わった

NECに引き続き、富士通がパソコン事業をレノボに統合 https://www.nikkei.com/article/DGXMZO22892340Q7A031C1TJ2000/

かつて日本を支えた大メーカーは揃って苦境に立っている。次々に入ってくるニュースは不景気なニュースばかり。

ところが一方で、今まさに元気なメーカーもある。トヨタキヤノンファナック村田製作所日本電産…これらの会社は、創業者かその一族が会社をコントロールしている。 つまり、カリスマ経営者が、会社の成長戦略とか大型買収を、経営者が自らの判断でスピーディーに行えて、権力が強固なためにトップダウンで方針が行き届きやすいのが、生き馬の目を抜く今の時代に必要なのだろう。

それに比べて、一時はグローバル化することで年毎に売り上げを伸ばして、成長を続けてきた大企業がどうしてこうなってしまったのか?

サラリーマン経営者がコントロールする企業の欠点は明確で、そういった企業のマネージャは、ほとんどがジェネラリストで占められている。彼らの仕事は、組織が大きな問題を起こさないようチェックをすることであり、また部下の仕事が円滑に回るようにすることだ。治世はこれで良かった。製品に足りない機能を追加し、小型化し、コストダウンすれば驚くほど会社が伸びた。

管理・オペレーションの仕事を地道に行いながら、昇進するテクニックを駆使して昇りつめてきた役員達が、これまた同じような人間を引き上げて一派を作る。 結果的に、高度な専門性を持ち、自分で会社が進むべき道を決めるような人は、ほとんど会社の経営には参加していない事態に陥る。 今の日本のほとんどの大企業では、取締役も社員も含めて皆が自分の日々のルーチンワークをこなすことだけ考えていて、そうでないこと、例えば新しいビジネスを作るとか、革新的な技術開発だとか、企業改革は誰かがやってくれると思っている。 これを集合依存と言う。つまり、強い個が欠落した烏合の衆。

こうなると、上から下まで完全に乱世を突破する力を持っている人がいなくなって、イノベーションを起こすどころか、イノベーションのアイデアまでも踏みつぶしてしまうような組織になる。

だから、サラリーマン経営者達は会社を削りながら延命することしか出来ない。

これからは、スペシャリストが経営を担う組織でないと戦えない。

ネットニュースの闇

インターネットで政治ニュースって見ますか?見ますよね。 じゃあコメント欄って見ますか? 見る人多いんじゃないでしょうか。自分も昔は見てました。でも今は見ません。

コメント表示オフに出来るのはオフにするし、そもそもYahooとかコメント欄で集客するようなニュースサイトは見ないことにしてます。 特に政治関連のニュースとか見ると、コメント欄には誹謗中傷の嵐。 ネトウヨの人達もそうじゃない人も、自分と異なる考えの人を型にはめて、決め付けて、相手を攻撃することに執念を燃やしてる。 たった一つか二つの思想のみで人を二分するのも特徴だ。

最近林立しているニュースサイトは、記事自体も質が低くて、事実に基づかない短絡的で独善的な記事が多い。コメント欄と同レベル。

さて、せっせと書き込みしている人達は置いておいたとして、そういう記事とかコメントを見る立場で、みんなはどう感じているんだろう。 自分にとって気に入らない方が、誹謗中傷されているのを見てスカっとしているんだろうか。それとも、いいねボタンを押して応援して正義の味方気分を味わうのだろうか。

自分は正直にいって、誹謗中傷の記事やコメントを見るのに疲れました。 あれを読んでしまうと、ひとしきり見た後ぐったりしてしまう。

それにすごく時間の無駄だと思う。 本来の情報という意味での記事はそこで終わっているのに、客観的で精度の高い情報がほとんど増えないまま、延々と非生産的なやりとりが繰り広げられる。

こんなことに人生の貴重な時間を使うべきじゃないと思う。