TEAM OF TEAMS: 米軍による、最新ITを駆使した21世紀の組織変革戦略


この本は、イラクアフガニスタンで米軍の司令官を務めた将軍が記した、複雑で予測不可能な社会に対応するための、21世紀の組織論を書いた本です。

20世紀においては、事業部制に代表されるような、きれいに組織化され、作業を分割され、個人や部門が特定の作業に集中できるようにする効率化された組織が大成功を収めました。その集大成とも言えるものが、イラクアフガニスタンに派遣された米軍でしたが、装備や練度で大幅に劣るはずのAQI(=アルカイダ)に翻弄されていきます。その中で著者は、20世紀型のマネジメントに原因があると気づき、組織の構造の根本的な改革に取り組みます。そのときに着目したのが「チーム」という存在でした。

チーム単位の組織論は20世紀においても十分な進化を遂げていました。チームは互いを信頼し、全ての情報を透明性を持って共有し、硬直化した意思決定プロセスを捨てて誰もがアイデアを出していく、そのようなチームが成功を収めていました。その代表例は航空機業界におけるCRM(クルーリソースマネジメント)米国海軍のNavy SEALs などです。

しかし、当時の米軍では、チームレベルでは協調ができていても、組織全体は完全な縦割りで、組織の壁でコミュニケーションが遮られていました。「自分のチームさえよければ他のチームはどうでもいい」という感情は、チーム間の競争を生み、組織全体の目的よりも優先されてしまうこともあります。著者は、組織全体としてチームと同様の一体感を作るには、「チームの中のチーム(TEAM OF TEAMS)」が必要だと考えるようになりました。

ネイビーシールズのような、一体感を持ったチームを、部門横断でいくつも作ることで、全員が互いの顔を知らなくても、2-3ホップでチームとして繋がれるようなネットワークを組める、というのがアイデアの骨子です。では、それをどう実現するか?著者がそのときに採用した三つの施策が、情報統制の撤廃による透明性の向上、要員交換プログラムによる横の結束の構築、そして徹底的な権限委譲でした。

米軍では、オペレーションアンドインフォメーション状況報告、通称O&Iと呼ばれる会議が存在します。一般企業でいう進捗報告会議です。2003年の米国において著者が実施したことは、セキュアなビデオ会議の導入でした。

最先端の軍の装備と言われたら普通は兵器を想像するはずで、スカイプの拡大版だとは思わないだろう。(p.289)


Skype(最近ではZoomの方が一般的でしょうが)のようなビデオ会議ツールを、著者ははっきりと「兵器」と言っています。それだけではなく、「チャットルーム、ウェブポータル、そして電子メール(p.290)」、要するに今でいうところのグループウェアを導入していったのです。2020年の今となってはMSやG Suiteを導入するのは当たり前ですが、当時はまだ2003年です。その時代に、著者はグループウェアを組織変革のための「兵器」とみなしていたのです。

そして、著者はこの進捗会議を全員参加にするだけでなく、どんなに極秘な情報であっても全て公開情報としてこの会議で取り上げました。米軍のようなミッションクリティカルな領域においては情報を秘匿するのが常識でしたが、著者は共有する方がリスクよりもメリットがあると判断しました。

役に立つものは目に見えないが、漏えい事件は新聞のトップ記事になる。そのせいで、判断を誤ってはならない。…経験上確かなのは、情報を共有すれば膨大な数の命を救えるということだ。(p.300-301)


二つ目の施策は、要員交換プログラムでした。チーム間で人員を転属させる仕組みなのですが、部隊からは強い反発を受けました。長年の訓練で築き上げた強い結束を崩して他のチームと組むなど言語道断といった感じです。しかし、いざ命令が下りると、各隊は部隊代表としてエースを送り込み始めます。こうしたエースは他者との関係を築く才能があることが多く、新たなチームを作り出すことができます。それだけではなく、各チームからの代表がそれぞれのチームとのパイプ役となり、チーム同士の対立を避け、勝利のためのチーム同士の結束が可能となっていきました。

同時に、O&Iもチーム同士の結束に活用していきました。リソース(多くの企業でいうところのヒト・モノ・カネ)の部署間の取り合いはどの組織でもあることですが、このリソース配分会議をO&Iの最中に、すなわち部隊の全員が見ている中で行い始めました。これにより、部隊全員が全体像を把握することができるようになり、勝利を目指すためにリソースを譲るべきかどうかを判断できるようになりました。

最後の施策が、権限の委譲でした。部隊の司令官だった著者は、部下から作戦の説明を聞いて、それに対して承認する(日本で言うところのハンコを押す)だけの役割が多かったのですが、一瞬のチャンスを逃さないためにはそれは不要だと考えるようになりました。

現代の技術を使えば、戦場のあらゆる情報をリアルタイムに指揮官の元に集めることができ、また指揮官の号令は世界中どこにでも一瞬で届けることができます。しかし、それこそが、現場の自律的な活動を阻害する要因であると著者は気づきました。

(あらゆる情報がリアルタイムに集まる環境について)頭のなかに全体像を描くには素晴らしい環境だったが、そのせいで悪夢のような書類仕事と承認手続きが生じ、本当の問題を解決するために使えたはずの時間を奪われてしまった。…今では、最も優秀なリーダーですら、必要とされる判断のスピードと量に追いつけず、組織の下のものに権限を与えざるを得ない(p.364)


そして、著者は個別の作戦の判断をやめて、一連の流れを監督することに徹します。これにより、一ヶ月間の作戦行動を月あたり10-18回から、月あたり300回まで増やすことに成功したのです。

著者は、上記の体験を元に、これからのリーダー像についても論じています。従来型のリーダーは、英雄的リーダーでした。我々はリーダーに対し、高度で戦略的な先見性を求める一方で、些細な問題についても知っていることをリーダーに求め、知らないとなればなぜ知らないのかと追い打ちをかけたりします。しかし、そのようなリーダーはもはや成り立たないと著者は記しています。

リーダーは、自分が複雑な状況を理解し、予測できるような気になってしまう。しかし、変化が早く、相互依存的な環境においては、我々の目が届くスピードより問題が深刻化するスピードの方がずっと早い。(p.387)


ではリーダーは不要なのか?そうではありません。著者は新しいリーダーのあり方をこう記しています。

上に立つ者の役割は、糸を引いて人形を操ることではなくなり、共感によって文化を創造することになったのである。(p.388)

新たな環境でうまく機能するリーダーシップとは、チェスより菜園づくりに似ていると考え始めた。…組織を育て、構造や手続き、ひいてはその文化を改善し、配下の組織が「賢く自立的」に動けるようにする方が効果的なのである。(p.392)

より多くのことを決定する力を持ったまさにそのときに、自分の決断機会を減らさなければならないと気づいたのである。(p.394)


著者は、何を優先すべきかを話し合い、率先して手本を示すことでそれを明確化することで、部隊の関心をそこに集中させることが自分の第一の仕事だと認識しました。イントラネットに伝えたいことを、シンプルに、繰り返し記述し、行動とメッセージがぶれないように気をつけました。若いメンバーの意見は、たとえ知っているようなことが多かったとしても、聞いていたという姿勢を見せ、出来がよくなくても褒めることで、隊員に自信を与えていきました。

また、頭に浮かんだことを声に出して、思考プロセスを共有することで、部隊全体に考えを共有したりもしました。視察中は常に誰かとのコミュニケーションの時間に費やし、自分の考えを共有していきました。

テクノロジーは…従業員の働きぶりを細かく見張るためではなく、チームの一人ひとりにリーダーの姿をみせるために使わなければならない。リーダーは指示を出すよりも、自分の透明性を示さなければならない。これこそ新たなリーダーの理想像である。(p.405)


この本を読み終えたとき、私の脳裏に浮かんだのは、まだ200-300人の頃のClouderaでした。今でも私にとってはあの頃のClouderaが最高の組織だったと信じて疑っていませんが、それはおそらく、この本でいうところの「大きい1つのチーム」だったからだと感じました。創業者のMike Olsonは300人規模になるまで、全社員の最終面接を行っていたのですが、彼はそれが会社の文化を守るのに必要だからと確信していたからだと思っていたのは間違いありません。実際、当時のClouderaは、非常に透明性が高く、部門を超えて連携する、一つのチームとして機能していました。しかし、会社が大きくなってからは、One Clouderaという標語を明記するのに反して、部門ごとの縦割りが進んでいき、以前のような一体感を失っていきました。

唯一の例外はサポートチームで、サポートチームだけが初期のCloudera文化を引き継いだまま大組織化に成功しましたが、この本を読むと、おそらくサポートケースを対処するための部門横断チーム、すなわちTEAM OF TEAMSを作っていくことに成功したからではないかなと思いました。実際、初期の頃のClouderaでは、サポートケースに開発チームやポストセールス、営業などが書き込んでいき、お客様との対応を全員で行っていたのでそうしたTEAM OF TEAMSを作る土壌はあったように思います。

この本に書いてあることが本当に正しいか、まだ私は確信は持てていません。一つは、結局米軍は大統領、あるいは国から目標を与えられていく存在のため、自ら目標を作っていかなければいけない組織においては成り立たないのではないかという疑念があります。もう一つは、米軍は当然優秀で士気が高い精鋭集団のため、そこまで優秀ではなく士気も高くない組織でこの理屈が成り立つのかという懸念です。しかし、私が過去の経験から抱いた疑問にいくつかの解答案を示しているものであり、その意味でこの本は大きな価値があると感じました。

本書にもある通り、この本はノウハウ本のような「これをすればうまくいく」といった単純な内容ではありませんが、組織論としては面白い内容なので、そういうのに興味がある人は読んで損はないと思います。

ただ、前半250ページくらいは従来の事例の話が多く、組織論をある程度かじっている人は前半は読み飛ばして、O&Iの話あたりから読み始めればいいと思います。


(2020/04/27 追記: 細かいtypoの修正)

高い予測精度を有する専門家の特徴

今年の初め、新型コロナウィルスがこれほど世界的に流行するなど、私は全く想像していませんでした。しかし、このような事態になって、あらためて「超予測力」に書いてあったことが正しかったと実感しています。

超予測力の書評については、去年私が記事を書いているので、そちらも是非読んでみてください。

shiumachi.hatenablog.com

その記事の後半から一部を引用します。

2001年4月11日、当時の米国国務長官ドナルド・ラムズフェルドが、ジョージ・W・ブッシュ大統領とディック・チェイニー副大統領宛に、リントン・ウェルズ博士が執筆した、1900年から2000年までの、10年ごとの戦略的状況の分析メモを送付しました。

その内容は、10年ごとの戦略分析は「全て」的外れであるということを示していました。例えば、1930年の国防計画基準には「今後10年は戦争はしない」と記されていますが、実際には9年後に世界大戦が勃発しています。1960年の時点では、まだ米国国民の大半はベトナムという国を知らず、1990年にはインターネットという概念を国民の大半が知らない、という状態でした。
「2010年の状況は、我々の想定しているものとは全く異なるものだから、それを前提にして計画を立てるべき」とそのメモは締めくくられていました。

そしてその半年後、911が発生したのです。

もし、米国政府で今も同様のメモが更新されているのであれば、この新型コロナウィルスパンデミックも末尾に書き足されていることでしょう。

未来を予測できないからこそ、予測するというのが本書の目的の一つとなっています。


予測のテクニックは思った以上に難しく、我々一般人が真似をすることはかなり困難です。

しかし、他者の予測を評価する、すなわち予測リテラシーについてはある程度学ぶことができます。

本記事では、「超予測力」の3章を主に引用し、専門家達の予測の評価方法を紹介していきます。

デタラメ以下の専門家達

本書の3章では、専門家達の予測能力を図る実験を行っています。実験の内容を簡単に説明すると、政治に関するいくつかの予測を専門家達に行ってもらい、一定時間経過したあとにその結果を検証するというものです。

その結果に基づき、専門家達をグループ1(デタラメ以下の予測力)、グループ2(デタラメよりマシ)に分類しました。

グループ1には以下のような特徴がありました。

  • 自らの思想信条を中心に思考する。思想信条の内容そのものは無関係
  • 複雑な問題をお気に入りの因果関係のテンプレートに押し込もうとする
  • テンプレートにそぐわないものはノイズとして捨てる
  • 分析結果は非常に明快
  • 「そのうえ」「しかも」といった言葉を連発し、自分の主張が正しく他の主張が間違っている理由を並べ立てる
  • 極端に自信にあふれ、さまざまな事象について「起こり得ない」「確実」などと言い切る傾向が高い
  • 自らの結論を固く信じ、予測が明らかに誤っていることがわかっても、なかなか考えを変えようとしない

グループ1の思想信条は、予測の正確さを高めるどころかむしろ歪めていました。また、グループ1は、多くの情報を集めても、全てを色眼鏡で見るために活用できなませんでした。

しかし、メディアにおいてはグループ1は成功しています。メディアや一般大衆は、シンプルで好きのない明快なストーリーを好むので、自信にあふれ、確実であると言い切るグループ1は人気が高くなるのです。

(2020/04/20 追記) ここでいうメディアとは、旧来のマスメディア、すなわち、テレビや新聞などを主体に考えていることに注意してください。本文には明記されていませんが、個人が直接SNSで発信することは含まれておりません。

デタラメよりも予測精度の高い専門家達

一方、グループ2には以下のような特徴がありました。

  • 現実的
  • 直面した問題に応じてさまざまな分析ツールを駆使
  • できるだけ多くの情報源から、できるだけ多くの情報を集めようとする
  • 思考するときに頭の中のギアを頻繁に切り替える
  • 「しかし」「だが」「とはいえ」「それに対して」といった転換語が目立つ
  • 確実性ではなく、可能性や確率に言及する
  • グループ1に比べ、自らの誤りを認め、考えを変える傾向がある

グループ2は、メディアでは成功しません。グループ1ほど自信がなく、何かが確実あるいは不可能と言うことを避けます。「かもしれない」といったぼんやりとした表現を選ぶだけでなく、1つの問題をさまざまな視点から見るので、その説明は「しかし」や「一方」が多く、難解です。

聴衆は不確実性を好まないので、グループ2はメディア人気が低くなる傾向があるのです。

まとめ

今回のパンデミックにおいて様々な専門家達が意見を述べていて、どの意見を信じたらいいかは難しいですが、以下の言葉は参考になるかもしれません。

知名度と正確さには逆相関が見られたのだ。有名な専門家ほど、その予測の正確さは低かった。(p.109)

(2020/04/20 追記) ここでいう「有名」とは、テレビや新聞などの旧来型マスメディアに頻繁に登場する人だと考えてください。


当然ながらこの言葉は普遍の法則ではありません。しかし、何度もメディアに登場し、明確に「こうなる」と断言するような専門家の意見については、多少の警戒心を持って接しても損はないでしょう。


(2020/04/20 追記) タイトルが本文の内容を反映していないとの指摘があったため、タイトルを修正しました。

インビクタス「頭に訴えず、心に訴える」

昨年のラグビーワールドカップが盛り上がってた頃に、昔からのラグビーファンだった d1ce_ に勧められたので読みました。

インビクタスは映画の方が有名ですが、d1ce_ からは本の方がお勧めということなので本を読んでみました。映画は未視聴です。

インビクタス 負けざる者たち

インビクタス 負けざる者たち

優勝を手にした南アフリカ代表、スプリングボクスと、南アフリカの英雄、ネルソン・マンデラの話なのですが、話の中心はマンデラであり、スプリングボクスはその理想の実現を目指す実行部隊という位置づけの話です。

恥ずかしながらアパルトヘイトについての自分の理解は非常に浅く、「黒人に対する人種差別政策で、マンデラがそれを廃止した」くらいの知識しかありませんでした。しかし、本書を読むことで、当然ながらそんな単純な話ではありませんでした。

マンデラが政権を獲得するまでの苦難、そして、単に法律だけの話ではなく、白人も黒人も、心から一つにまとまるための道のり、そしてそのキーファクターとしてラグビースプリングボクスがどのように関わっていったかが本書で描かれています。

本書を通して特に印象深かったのが、差別側、特権階級側である白人コミュニティが抱く、被差別側、つまり黒人コミュニティに対する恐怖と、一方で自分達が世界から侮蔑の目で観られているということについての劣等感でした。

「差別は悪いことである」とは世界の誰もが教わる常識ですが、その差別をしている人たちもまた人間であるということは忘れがちです。悪意を持って差別している人ももちろんいるでしょうが、被差別層に復讐されるかもしれないといった恐怖から現状維持を求める者もいれば、単純に政治に対して無関心だったり、日々の生活に手一杯だったり(白人層にも低所得者層はたくさんいる)、変化に対して抵抗する人達の理由は様々です。

一方で黒人コミュニティも、白人に対する憎悪であふれている人も大勢いて、過激な行動に走ってでも自由を勝ち取るという意志を持つものも大勢います。

そんな黒人コミュニティの代表者であるマンデラは、27年もの間投獄されるという想像を絶する苦痛の中、憎悪に飲まれるのではなく、白人コミュニティを取り込んでいく上での黒人の解放を目指すという平和的な手段を選んでいきます。

マンデラは、類まれな魅力と会話術によって、収監中であっても看守や上司から、はては国家情報局長までを味方につけていき、最終的には大統領までも説得していって、とうとう釈放の許可をもらうことに成功します。黒人コミュニティからは熱狂的に、白人コミュニティからは不信と不満を持って迎えられたマンデラは、その後も地道な演説活動と要人への交渉を続け、最終的には2/3弱の投票を獲得して選挙に勝利します。しかし、白人右翼の40-50%は選挙へ行かず、それどころか、選挙の前週には空港などでテロを敢行し、21名を殺害するという凶行に走りました。マンデラは、白人コミュニティとさらに融和するべく、苦心することになります。一方で、白人コミュニティも、マンデラを擁立したはいいものの、本当に黒人コミュニティは復讐しないのか、その不信の念を拭い去ることはできていませんでした。

一九九四年の南アフリカは、歴史、文化、人種その他多くの面で、完全に分離した国でした。交渉、演説、制度の改正、これらをいくら積み重ねても、それだけで『南アフリカ人をつくること』はできなかった。国民の心を一つにする、なにかほかのものが必要でした。(p199-200)

そして、民族融和の手段として、ラグビーが選ばれたのです。

今でこそラグビー南アフリカの国技として世界的に知られてはいますが、当時のラグビーはあくまで白人コミュニティのものでした。黒人コミュニティにとって、スプリングボクスは差別の象徴であり、憎き白人の象徴でした。ラグビーそのものを嫌悪する人はもちろん、ラグビーを応援するときはスプリングボクスの対戦相手を応援することが当たり前でした。

ラグビーが白人コミュニティのものであることを象徴的に示す一例は、国歌と国旗です。当時の国歌だった「ディ・ステム」は、植民地開拓をした白人たちの歌であり、黒人コミュニティにとっては差別の象徴でした。ラグビーの国際試合では、黒人コミュニティからの要請にも関わらず、古い国旗が翻り、「ディ・ステム」が歌われ、白人コミュニティの抵抗を象徴する存在となっていました。

黒人コミュニティには、「ンコシ・シケレリ」という非公式の国歌がありました。多くの黒人国民は、この歌を国歌として制定し、「ディ・ステム」を不要としようとしましたが、マンデラは断固としてそれに反対します。

「みなさんが軽く扱った歌には、多くの国民の思いが詰まっています。…みなさんが署名ひとつで崩そうとしたのは、我々が築こうとしているものの、かけがえのない、唯一の土台 ―― 和解です」 (p.187)

最終的に、マンデラの案である、「ディ・ステム」と「ンコシ・シケレリ」を二曲続けて演奏するという案が採用されることになりました。

このときにマンデラが同時に言ったのが、白人コミュニティを味方につけるアドバイスでした。それは、たとえ数語でもいいので白人コミュニティの言葉を使って話しかけるというものでした。このときに、タイトルにある「頭に訴えかけてはいけません、心に訴えるのです」と言い残しています。

このマンデラの意志を理解し、実行のための強い意志を固めていったのが、スプリングボクスでした。黒人コミュニティの標準語であるコーサ語を学び、「ンコシ・シケレリ」を歌う練習も何度も重ね、自分達に課せられた使命、すなわち「国を一つにする」という使命を達成するために、必ず試合に勝利しなければいけないというプレッシャーの中、大会を勝ち抜いていきました。そして、ついに白人コミュニティと黒人コミュニティが一つとなり、あたらしい一つの国としてスプリングボクスを応援し、そしてチームは見事優勝していったのです。

この物語の全体を通して感じたことは、民族融和を目指すマンデラの根気、優しさ、強さでした。対立する2つのコミュニティを融和させるというのは並大抵の難しさではなく、単なる八方美人で終わってしまうことも少なくないでしょう。しかしマンデラは、国歌の選定を始め、必ず通すべきと思った意見は静かに、しかし確実に主張をしています。このとき、「相手の立場もわかってやってくれ」といったような妥協を促す説得を全くしていないというところも驚きでした。黒人はもちろん、白人に対しても理解を示し、いずれのコミュニティに対しても望む結果となるよう最大限の努力を続けていました。人種を超えた、南アフリカ国民を信じ続け、そして国民がそれに応えていったのです。

世間は、コミュニティの対立、個人の対立で溢れかえっています。自分が対立の当事者になることもあれば、対立を仲裁する立場に立たざるをえない場合もあるでしょう。片方に妥協を促すというのはよく行われる手法であり、マンデラと同じアプローチを取れる人は多くありません。しかし、「相手を理解する努力をし、相手の罪を許し、相手を尊重する」という彼が持っていたビジョンは、多くのこうした揉め事において、常に心に留めておきたいものだと感じました。口で言うのはたやすいですが……

株式会社オープンコレクターに転職しました

2020年4月6日付で、株式会社オープンコレクターのシステムアーキテクトとして勤務を開始しました。
https://open-c.jp/

この会社は、PythonやGo、React Native などの技術を中心として、認証基盤や決済システム、大規模データ処理アプリケーションやチャットボットアプリケーションなどについて、フロントエンドからバックエンドまでの幅広い開発、アーキテクチャ設計からシステムコンサルティング、さらにはCTOレベルの戦略的な技術コンサルティングまでをカバーする、少数精鋭の技術者集団です。
フィンテック関連企業でのプロジェクトを中心に、製造業、小売業、インターネットサービス業など、幅広い業界で実績を持っています。

オープンコレクターに所属するメンバーは、一流のエンジニアばかりです。

会社代表のmoriyoshiは、上記の技術を始めとして、文字通りあらゆるレイヤーの技術に精通した賢者のような存在です。
https://github.com/moriyoshi

Djangoで有名なtokibitoは、現在ObotAIのCTOとしても働いていて、いち技術者にとどまらない活躍をしています。
https://employment.en-japan.com/engineerhub/entry/2020/01/30/103000

Pythonのパッケージングで知らない人はいないであろうaodagもオープンコレクターの一員です。
https://www.slideshare.net/aodag/presentations

私よりひと足早く入社したwozozoは、フィンテック系のフロントエンドエキスパートです。
https://twitter.com/wozozo

このような錚々たるメンバーの末席に加わることは恐縮ではありますが、彼らに恥じない仕事ができるよう努力したいと思います。

特に担当があるわけではありませんが、得意分野である大規模データ基盤の設計やコンサルティング、データ分析や自然言語処理系のアプリケーションの開発などのプロジェクトを主に担当することになると思います。
今日から早速Hadoopの案件が始まります。
Hadoopコミュニティの皆様、思ったより早く戻ってきました。またよろしくお願いします。

お仕事のご相談は以下のサイトのお問い合わせフォームをご利用ください。
https://www.open-c.jp/contact

ルミノソジャパン合同会社を退職しました

2020年3月24日(火)は、ルミノソジャパン合同会社への最終出社日でした。退職日は2020年4月5日(日)になります。2018年12月3日(月)に入社したので、勤続日数は490日でした。

転職時の記事はこちら
shiumachi.hatenablog.com



この会社での仕事はあまり表に書くことがなかったので、どんなことをやっていたのかを簡単に紹介します。

一応少しこの辺で触れていました。
shiumachi.hatenablog.com
shiumachi.hatenablog.com



夏頃までは、プリセールスとポストセールスを半々くらいで仕事していました。デモを作ったりプレゼン資料を作る一方で、構築作業や技術サポートなどをメインに仕事していました。

夏以降はほぼポストセールスに専念する形になり、開発にもかなりの時間を割いていました。(余談ですが、同時に在宅勤務となり、夏以降はほぼ出社していません)

大体以下のようなものを開発していました。

  • サービスAPIを活用した各種ツール
  • サービスが生成したモデルを使った各種デモアプリ(先述の記事参照)

開発は全部Pythonで行っていました。書いたコードの行数はトータルで2万行いかないくらいです。
(Webアプリのテンプレート等は未カウント)

この会社での目標として、「お客様にとって本当に必要なものを、自分の手で作る」というものがありましたが、最終的に1年がかりでお客様の要望を整理し、プロトタイプを作成し、本社にプレゼンし、会社として開発を進めていく方向に持っていくことができたので、一定の目標は達成できたと感じています。

作ったツールについても、VPoEと古参エンジニアに「この品質ならそのまま製品化できる」と言ってもらえたのが自分としてはとても嬉しい成果となりました。

反面、自然言語処理の技術・知識については、そもそも製品がベクトルモデルを作るものである以上、原理の理解以上の応用部分はあまり関与せず、スキルとしてはさほど上達しなかったので、目標達成とは言えませんでした。(少なくともNLPエンジニアと名乗れるレベルの知識・技術は獲得できていない)


4月6日(月)からはまた新たな仕事が始まります。どのような仕事をするのかは次の記事で書くことにしましょう。

明日からしばらく何するの?

情報交換も兼ねて、色々な人に会いたいと思っています。といっても、昨今の新型コロナウィルス流行の状況もあり、世間でもリモートワークが急速に浸透しているので、今回リモートで色々な人と情報交換しようと思っています。既に何人かアポを取らせていただいています。もし、「久々に話したい!」という方がいましたら、お気軽にご連絡ください。リモートでアポとるとかなり詰め込めるのでいくらでも余裕があります!

今年こそは自宅で運動を始めたい人のためのFreeleticsガイド(2020年版)

2021年版のFreeleticsガイドができました!この記事より新しいので、そちらを参照してください。

shiumachi.hatenablog.com

新年明けて、心機一転してまた運動を再開しよう、という人がちらほら周りに増えてきたので、私が使い続けているトレーニングアプリ Freeletics について紹介します。

Freeleticsは、ユーザにとって最適なトレーニングプランを提供してくれる、いわゆるAIパーソナルトレーナーアプリです。数分単位の短い時間にきついトレーニングをこなす、いわゆる高強度インターバルトレーニング (HIIT) をベースにしています。

Freeleticsは、

  • 自宅でできる
  • 短時間
  • 自分だけのトレーニングメニューを作ってくれる

と、運動したいけど忙しい、という人に最適な特長を持っています。

このブログでも何度か紹介していますので、興味のある方は過去記事も読んでみてください。

shiumachi.hatenablog.com
shiumachi.hatenablog.com

購入方法

Freeleticsは有料のアプリです。年間1万円のサブスクリプションです。
3ヶ月プランや6ヶ月プランもあるので、続ける自信がないという人はこちらを購入してもいいです。14日間は返金に応じてくれるので、試しに買ってみて、合わなかったら返金しましょう。

Freeleticsを始めてみたいという人は、下記のリンクから購入すれば20%オフで買えます。 Coach と Nutrition (食生活改善)の二種類が出てきますが、Nutrition は自分は試していません。運動だけなら Coach で十分と思いますが、誰か Nutrition を試した人がいたら感想教えてください。

https://www.freeletics.com/r/124871187

インストール

購入したら自分のスマホにアプリをインストールして、ログインします。

Freeletics: トレーニング&フィットネス
Freeletics: トレーニング&フィットネス
開発元:Freeletics GmbH
無料
posted withアプリーチ

レーニングジャーニーを選ぶ

レーニングジャーニーというのは6週間あるいは12週間のトレーニングコースです。自分の目的に合わせて選んでいきます。途中から変更できるので、適当に選んでから後で変更してもいいでしょう。迷ったら「スタートストロング(男性)/スタートスマート(女性)」という6週間の初級コースを選べばいいです。

f:id:shiumachi:20200126172407p:plain

基本は自重トレーニングですが、去年からランニングを含むコースも増えました。自重トレーニングではなくランニングをしたいという人はこちらを選びましょう。逆に自宅でのトレーニングしかしないのであればランニングのないコースを選びましょう。私は自宅トレーニングしかしてません。

f:id:shiumachi:20200126172351p:plain

レーニングする

毎週のトレーニング日数を決める必要があるのですが、ここで重要なのは週5日を選ぶということです。週2日などにすると1日ごとの負荷がすごく高くなるため、きつすぎて続けられません。週5日を選んでおいて、日数調整は自分でやった方がいいでしょう。

f:id:shiumachi:20200126172429p:plain

1日のトレーニングは、ウォーミングアップ→トレーニング→クールダウンという流れで行います。1回のトレーニングは、初級だと20分程度、中級コースだと30分程度に調整されています。

フィードバックする

レーニングを行ったあとにフィードバックを入力します。この入力が次のトレーニングの負荷に影響するので正確に行う必要があります。「全く休まずできたら右端、休憩したけどなんとか完走したら真ん中、途中でリタイアしたら左端」くらいに覚えておけばいいでしょう。

新機能: 毎日のトレーニングでの微調整

2019年12月のアップデートから、レーニングの微調整ができるようになりました。その中で一番の目玉は、リングフィットアドベンチャーでいうところのサイレントモードの実装です。

Freeleticsを薦めたときに友人から一番多く言われたのが、「マンションなので階下に響く運動はできない」というものでした。確かにFreeleticsはジャンプ運動が入るために、そのままでは階下に響いてしまいます。

しかし、このサイレントモードを使えば、全てのジャンプ運動はスクワットとランジなどの静かなものに変わるため、静かにトレーニングすることができます。

レーニングの微調整は、毎日のトレーニングメニューを開いて、右下のCボタンを押して行います。

f:id:shiumachi:20200126172701p:plain

ここで、「静かにトレーニングする必要がある」を選べば、サイレントモードに変更することができます。

f:id:shiumachi:20200126172805p:plain

たとえば、この日の私のメニューは、クランチ(腹筋) と、マウンテンクライマー(四つん這いになりながら足だけ駆け足する)を交互に行うというメニューです。

f:id:shiumachi:20200126172950p:plain

これをサイレントモードにすると、プッシュアップ(腕立て)、クランチ、スクワットに変わります。

f:id:shiumachi:20200126174200p:plain

サイレントモード以外にも、「15分モード」や「筋肉痛モード」などもあるので、その日の状況に合わせたトレーニングを選ぶことができます。

先程と同じメニューを「15分モード」に変えると、ランジ(片脚づつ交互に膝立ちする脚の運動)、ヒールレイズ(四つん這いになってかかとを交互に後ろに上げる運動)、プランクニーズツーチェスト(四つん這いの状態から膝を胸につける腹筋と体幹の運動)が3セットだけに変わります。

f:id:shiumachi:20200126173239p:plain


また、その日のメニューが気分に合わないときは、「違うセッション」を選択することで、別パターンに切り替えることができます。

これも先程のメニューの例でいうと、スプロール(バーピーの簡易版の激しい全身運動)、パッシブハング(懸垂台でのぶら下がり)に変わります。

f:id:shiumachi:20200126174215p:plain

Tips

マットを買う

レーニングマットは必須といっていいレベルなので買いましょう。私はALINCOのマットを使っています。

レーニング回数は週5回を選択すること

上でも書いたことですが、これは強く推奨します。週2-3回のトレーニングを選択すると負荷が高すぎるためモチベーションが下がります。

レーニング実施日数にはこだわらない

アプリ上では何曜日にトレーニングするかを選択する必要がありますが、あまりそれにこだわらず、できそうなら毎日やった方がいいです。逆に気が乗らない場合はその日は思い切ってサボった方が長続きします。ただし、3日以上空けるとやる気がどんどん下がっていくので、休むのは1日だけ、多くても2日くらいにしておいた方がいいです。

シングルエクササイズを活用する

通常のトレーニングメニュー以外にも、特定の種目だけ選択できるシングルエクササイズモードがあります。

f:id:shiumachi:20200126173400p:plain

通常メニューをやる気がないときに、スクワット10回だけなど、ほんのちょっとだけでもやっておくとモチベーションの維持がしやすいです。
逆に通常メニューが簡単すぎて物足りない場合は、好みのトレーニングをいくつか追加していくといいでしょう。
私は通常トレーニングに加えて、軽めの運動を少し加えています。

レーニング開始前に水を飲む

水分補給は重要なので必ず飲みましょう。また、ルーティンとして組み込むことでトレーニングのやる気を上げる効果もあります。

ウォーミングアップ・クールダウンはサボらない

ケガの防止にもなりますのでサボらずやりましょう。

レーニング終了後にプロテインを飲む

ある程度運動に慣れてきたら、トレーニング後にプロテインを飲むと、ダイエットにも効果的です。お試し程度に買うのなら、Amazonで買えばすぐ届くのでまずは1kgくらい買ってみてもいいでしょう。

マイプロテインは公式サイトでは不定期(といってもほぼタイミングは決まっている)タイムセールを開催しているので、慣れてきたら公式サイトから買った方がいいと思います。ただし、海外発送のため時間がかかること、購入代金を調整しないと関税がかかってしまい逆に割高になってしまうことに注意してください。難しそうならAmazonで買ってしまった方が楽だと思います。

自分の成長の記録を見てやる気を上げる

過去の自分の記録と比較して、「以前これだけキツかったのが今これだけできるようになったんだ」というのを視覚化できると、達成感をえることができます。

気が向いたときに、プロフィール→ワークアウトから、過去のトレーニング履歴を眺めてみると楽しくなります。

f:id:shiumachi:20200126174623p:plain

ケガしたら無理せず(その部位だけ)休む

Freeleticsでは、筋肉痛のときにその部位を休めるという機能はありますが、ケガしたときまではケアしてくれません。

もし万一ケガしてしまった場合は、無理せず休んで病院にいきましょう。

とはいえ、全くやらなくなるとモチベーションが下がってやらなくなるだけなので、例えば肩をケガした場合はスクワットだけはやる、など、シングルエクササイズモードをうまく活用して、トレーニングの習慣だけは維持するようにしましょう。

公式サポートに質問する

アプリとしては比較的安定しており、落ちることはありませんが、インターフェイスが使いづらかったり、訳が間違ってたり、ほしい機能がなかったりなど、色々と気になることが出てきます。そんなときは公式サポートに質問しましょう。プロフィール→設定→お問い合わせから問い合わせできます。日本語も対応していますので安心して質問できます。

f:id:shiumachi:20200126173422p:plain

その他

実際にFreeleticsを使っていて気づいたこと、知ったことなどを共有しておきます。

SNS連携はInstagramしかない

SNS連携はかなり貧弱です。SNS周りを強化してほしい場合は機能要望をどんどん出していきましょう。

APIが公開されていない

個人的にこれはかなり残念です。サポートに問い合わせしましたけど現在提供予定はないとのこと。ほしい場合は機能要望を出しましょう。

プロダクトを作るということについて考える

こちら、pyspa Advent Calendar 2019の23日目の記事です。前日の記事は id:kutakutatriangle さんの34のおっさん(当時)が痔ろう手術するハメになって健康大切だと実感した思い出話(前編)でした。

お前誰?

Luminosoという会社でソリューションチームの一員として働いています。業務としては、製品のプロトタイプ開発のような作業が大半です。お客様の要望に応えるために、既存の自社製品だけでは満たせない拡張部分を作っていくのが主な業務になります。
そうした仕事を通して、プロダクトを作るということについて自分なりに考えたことを書いていきます。

できるだけ開発しない

既存の製品・機能でできることがあるのであれば、まずそちらを使うべきでしょう。開発は、既存のプロダクトではユーザのニーズに「応えられない」ことがわかった場合に初めて行うものであり、「応えられるかわからない」ときにやるべきではありません。できないことがわかるまで製品や既存のソリューションについて調べるべきでしょう。

ユーザの言葉を鵜呑みにしてはいけない

ユーザは技術的に何ができて何ができないかはわかりません。それどころか、自分たちが本当にしたいことは何かも把握できていないこともよくあります。「君のところが作ってる車で空を飛びたいんだ。空を飛ぶ機能つけてよ」と言われることを想像してみてください。厄介なのが、「空を飛べるようになるなら君のところの車を買うよ」と契約を盾にした要望で、この状態になると社内の営業チームはプロダクトの開発チームに無理を通してでもその機能をつけようとプッシュしてくるようになります。

この問題に対する有効な解決策は自分ではまだ見つかっていません。予防策としては、以下のようなものがあります。

  • マーケティング・プリセールスの段階で自分たちのプロダクトができることをはっきりさせておく。特にプリセールスの段階で「できないこと」をユーザにきちんとインプットするよう気をつける。(ただし、風呂敷を広げるタイプの営業はこのような説明を嫌う場合があるので注意)
  • ユーザからの要望が出てきた段階で、早期に課題を明確化するためのコンサルティングを行う。プリセールスがやるのが理想だと思うが、営業チームとして売ることが優先になっている場合は別チームの人間がやった方がいいかもしれない

ユーザのニーズを元にして開発をしなければならない

一方で、ユーザの話を全く聞かないというのも非常に危険です。開発者が思い込みだけで「こういうのが必要だろう」と思って作ったプロダクトや機能は、大抵の場合期待するほどユーザには受け入れられません。プロダクトの話になるとしばしば耳にする忠告なので、そんなこと本当にあるのかなと思っていましたが、現実にそうした事象を目にすると、とてもよくわかります。開発した動機だけを聞くと、それめっちゃクールだよね、確かにそういうの欲しいよね、と錯覚してしまいます。しかし、そうしたプロダクトを実際にユーザに見せても、お金を払ってでも欲しいと思わせられるかどうかは未知数です。

前職Clouderaでは、新製品のリリース時には必ずローンチカスタマーがついていました。これは、単にマーケティング的な効果をもたらすだけでなく、ユーザのニーズに基づいて開発することで、本当に必要とされるプロダクトに特化するということを体現していた証だったと思っています。

ユーザのニーズは(例え実現不可能であるように見えても)バックログにいれて管理しなければならない

「この車で空を飛びたい」のような、一見突拍子もないような意見であっても、そうした意見を眺めているうちに本当の問題や本当の解決策にいきあたる場合があります。特に、複数のユーザからそういう突拍子もない意見がでてきた場合は、その要望を再検討する機会はあってもいいと思います。

そのためには要望の管理が必要です。 GitHub Issues でも JIRA でも Trello でもいいので、とりあえず放り込んでおく、という先は用意しておいた方が後で便利です。

開発は常に保守性を考えなければならない

ソリューションチームにいると、複数のプロダクトを開発していくことは頻繁にありますし、数ヶ月特に保守する必要もなく安定して提供できていたプロダクトに急遽開発要件が生まれるということもあります。また、製品本体や外部ツールのバージョンアップによる非互換性への対応なども必要になります。こういうときに保守性を考慮した開発を行うことで、保守工数を削減するだけでなく、新規開発を素早く行うことができるようになります。

作成したソリューションやツールなどは、あくまで位置づけとしてはプロトタイプというだけであり、実際に製品化されるかどうかは決まっていません。場合によっては長期的に保守する必要があるため、保守性を高めておくことは重要です。

まとめ

ユーザの話を鵜呑みにせず、しかしきちんと話を聞き、その上で保守性を考慮して開発する、というのがこの一年でプロダクト開発について自分が学んだことでした。ごく当たり前のことしか書いておらず、知っている人にとっては目新しい話は何もありませんが、こうした知識を経験として体得できたというのが大きな収穫だったと感じています。

明日は @wozozo です。