TAMINIF’s blog

大阪在住のWebエンジニア。iOSアプリもやってます。勉強会にも参加してます。最近はマネージャー色強め

「サボタージュ・マニュアル」1時間で読んだ

サボタージュ・マニュアル:諜報活動が照らす組織経営の本質

サボタージュ・マニュアル:諜報活動が照らす組織経営の本質

東京出張の新幹線の中で読んだ。タイトル通り1時間程度でサクッと読めたので気になった人はぜひ読んでみてほしい。

この本を読んだきっかけ

サボタージュ・マニュアル自体は下記のブログで読んだことがあって知っていた。

chikawatanabe.com

会社の人がこの本を買っていて、軽く読めそうだなということで読んでみることにした。

どういう本か

CIAの前身であるOSS(米国戦略諜報局: Office of Strategic Services)が、敵国に対してスパイ活動を行うために作られたマニュアルがサボタージュ・マニュアルであり、それが公開されていて解説されている本である。
物理的な破壊工作の方法から、組織のコミュニケーションの際に行うことで混乱を引き起こす方法まであり、その中でも組織のコミュニケーションを焦点に、何をすることで組織は停滞するのか具体的な事例と合わせて説明されている。

読んでみて

「会議に必ず5人以上出席させよ」や「チーム内で衝突させろ」など、実践することで組織が悪くなる内容が書かれているので、アンチパターンとして参考にするべき本だった。

この本は組織を停滞させる手段が書かれていることから組織運営の本のように見えるが、実際には組織を作る人ではなく組織に所属する人にできるだけ読んでもらいたいと思った。
その理由は

  • サボタージュ・マニュアルはスパイ活動のためなので、組織の中にいる人がやることである
  • なので、自分一人が意識しても限界があり、各個人が意識してやらないようにしないといけない
  • チーム内に一人でもこのマニュアルの内容をやってしまうとそれだけで影響が出る

ためである。

以下の二つは、わかっていても特にやってしまいそうなことをまとめた。

集団は個人の活動を封じ込める

「三人寄れば文殊の知恵」というが、「三人集まってから課題を解決する」よりも「それぞれが解決策を考えてきてから集まる」方がより的確に課題を解決できたという研究結果が出ている。
また、集団になることで以下のマイナスのメカニズムが発生する。

  • 社会的手抜きの法則
    • 自分一人で仕事をするときはその評価が自分で確認できるが、集団で仕事をするときは個人の成果が見えにくいので人は手を抜きがちになる
  • 評価懸念による発言の抑制
    • 会議の場面では、人は課題解決よりも自身の評価を気にする。そのため、ベストな解決方法を知っていても、自分の意見が間違っていたら、間違っていることで上司から悪い評価をつけられたらと考えてしまい、自由な発言ができなくなる。
  • 沈黙の螺旋
    • A案とB案があった時に、自分はB案が良いと思ったがA案が多数を占めている場合、多くの人はB案の素晴らしさを主張するよりも黙る傾向にある。そして、A案の素晴らしさの主張はハードルが下がる。
  • 同調
    • そうして会議では多数派の意見しか発言が出なくなり、腹の探り合いが発生してしまう。
  • 調整損失
    • 会議で一番時間を使うのは、発言のタイミングを伺うことになっていないか、これは会議の人数が多くなるほど発生し、個人の時間を奪ってしまう。

そうして集団は個人の能力を封じ込める。
みんなで決めるという民主主義が、チームのスピードを遅くする。

「黒い羊」効果を生じさせよ

黒い羊効果とは、自分たちの所属する集団にとって都合の悪いものを阻害して排斥するような現象をさす。これによって組織内のいじめなどが発生しやすくなる。黒い羊を意図的に作り出すことで、集団内に問題を発生させることができる。
また、排斥されたメンバーが集団の活動を阻害するための攻撃を自発的に仕掛ける場合がある。これも組織内で大きなリスクになりうる。
組織のパフォーマンスが低下、場合によっては崩壊する可能性もある。

まとめ

本を読んで、こうやって書評を書いたことで特に意識してアンチパターンとして扱わなければならないと思った。
この内容を知らず、やってしまっている人はスパイになってしまっていることになるので、やっている場合は止めないといけない。
組織に所属する人は、一度手にとって読んでもらえるとチームが阻害される可能性が少なくなるので、
すぐ読めるものでもあるのでぜひ読んでみてほしい。

起業のファイナンスを読んだ

たまたま同じ日に読んだ記事の中で同じ本が紹介されていて、興味を持ったので読んだ。 まだ私の知識レベルでは全部を理解することはできなかったけど、とっつきやすくて面白かった。

最も印象に残った「計画する」ということ

第3章「事業計画の作り方」にあった、必ず計画を立てる話について書き残しておきたい。

未来を予測することは不可能

事業計画は事業がうまくいくように計画を立てることである。どれだけ計画を立てようが未来を予測することは不可能だが、それでも計画を立てる必要がある。
それはなぜか、計画を作ることができるということは計画を作れるレベルまで考えがまとまっているということであり、その事業を説明することができるためである。
エレベータ・ピッチと呼ばれる、エレベータの15秒で事業の魅力が語れるようにしておいて、常にチャンスを逃さないようにしておくことが大事である。

事業計画書はパワーとなる

  • 事業計画に要点がきちんと考えられていれば、それを読んで興味を持ってくれる人が出てくる。
  • 事業計画は事業に関係する人たちをやる気にさせられる「パワーの源」になる。
  • 根性や情熱で事業を始めることはできるが、継続させられる保証はない。

計画を作ることでリスクに立ち向かえる

計画が「いける!」というものになっていれば、それが「勢い」になる。「勢」というのは、すなわち、状況に応じて臨機応変な対応が行えるということ
孫子「計篇」参照

孫子では、戦を行うときに相手と自分を見てどちらが各方面において準備ができているか、戦力差を理解できているか、勝つ見込みがあるかを判断する。
勝ち目があると正しく判断できているのであれば、不思議と勝てるものである。
二ヶ月くらい前にたまたま孫子を読んでいたこともあってこの章はよく理解することができた。

事業計画は投資家へのコミットメント(約束)の一部を形成することにもなりえる

  • 「こうやれば100%成功する」なんて道筋はないから、状況に応じて変化することは必須で、事業計画が進捗を縛るものであってはならない。
  • 「絶対成功する」事業計画が立てられる訳ではないけど「明らかにダメ」な計画はわかる。
  • 計画が間違っていたり成功する可能性が低いことが見えているなら、その計画は成功する可能性は低いのでやらない方が良い。

まとめ

近いうちに一度事業計画を書いてみたいと考えていたこともあって、この章だけでも読む価値はあった。
今まで会社のことを勉強したことはなかったので、会社員でいる間でもなぜそうするのかを理解するためにも勉強してよかったと思う。
理解できていないことも多いので、他の事業計画を読んでみて事例を元に勉強したい。

ピープルウエアを読んだ感想と書評を書くことについて

トム・デマルコの「ピープルウエア」を読んだので、書評を書いて残しておくことと
今までは読んだ本全部で書評を書いてなくて、今回書くかどうか迷った時に考えたことを残す。

ピープルウエア 第3版

ピープルウエア 第3版

読んだ感想

組織の問題の解説とどうすれば良いかについての本で、以前からお勧めされていたのをようやく読んだ。
結論としては読んでよかった。エンジニアが働きやすい組織は昔から変わってないんだなと思った。
特によかった点を詳しく書く。

生産性の高いチームを育てる話

チームを殺す方法

チームを結束させる方法をあげることができないから、逆にアンチパターンをあげて
それだけはやらないようにすることが書かれている。
具体的にはメンバーに対してマイクロマネジメントをすることや、マニュアル通りに動かすこと、チーム内で競争させること、複数のチームに所属させることで、この中では競争させることがアンチパターンというところは驚いた。

共同作業でチームを結束させる

本の中ではチームメンバーでスパゲティディナーを行い、その中でマネージャーは何も手伝わないという例で書かれていた。
マネージャーが指示しなくても、メンバー同士で考えて動くことでチームワークは出来上がるという話で、
チームでやることは別に開発に限ったことでなくても、一緒にやることでチームを良くすることができるので、
一度こういうこともやってみたいと思った。

目標を提示してメンバーに任せる

マネージャーはメンバーを画一的にするのではなく、メンバーの個性に寛容になりながら
目標意識を植えつけて、任せてやることで特別意識を持たせて活動的にさせるものということが書かれていたが
特に印象に残ったのは、「いずれにしても部下はコントロールできるものではない」というところで、これは強く認識していきたい。

文化を醸成する話

メソドロジー(方法論)は悪

メンバーのやり方を決めて動かすことは、メンバーに責任を持たせないこととなり
責任を持たないメンバーは自分の意識で動かなくなる。
これはマネージャーが崩壊する未来しかないので絶対にやってはいけないと思った。

変化を嫌う人は成長できない

変われない人は進歩できないと書かれていて、自分も他人から与えられる変化には敏感になることがあったと思って
自分の進歩を止めるような行動ややらないようにしたい。

仕事を楽しくする

コミュニティ

自分の場所を楽しい場所にするためには居心地の良いコミュニティが必要で、コミュニティは仕事だけで生まれないので、自分で作り上げなければならない。
今まで意識して作っていたことはなかったけど、確かに自分から動いて出来たコミュニティは楽しいと感じることが多いので、仕事をする中でコミュニティについても意識するのは良いのかもと思った。

問題はみんなで共有すればみんなの問題

一人で行動しても変化はほとんど起こらない。でも問題をみんなに共有して共感してもらえばそれはみんなの問題になるということは、チームで働く上で本質だなと思った。
問題と感じているところはオープンに共有して、一人で解決するのではなくチームで解決していきたい。

書評を書くことについて

今回も書評を書こうかどうか迷ったときに、「明日の自分に書く」ということを考えた。
コードを書くときは必ず「明日の自分は他人で、他人はそのコードの意図がわからないかもしれないから明日の自分のためにコード(コミットコメント)を書く」と言っているのに、書評は書かないは矛盾しているんじゃないかと思った。これは未来の自分が読んだことを忘れた時のための書評だ。
なので今後も読んだ本で覚えておきたいものは書評を書くようにしたい。

まとめ

いきなり全部やることはできないしこの本にもおそらく一つだけしかできないだろうと書かれていたので、まずは一つやっていくことから意識していきたい。

WordPressの管理画面にログインできない問題の原因がDBだった

WordPressの管理画面にログインできない問題が発生し、解決まで完了したのでブログに書く。正確に事象を説明するとログイン画面は表示されて、正しいログイン情報を入力してログインボタンを押した場合にリダイレクトが発生しログイン画面が表示されるという無限ループが起きた。
調べても出てこないケースの問題だったのと、なかなかに怒りが発生したのでそれをモチベーションに今書いている。

動作環境

WordPress4.7(バージョン関係なし)
AWS EC2
MariaDB

TL;DR

ディスク使用量が100%になるとDBに書き込みできないので、ディスクに空きを作る。

どう調査したか

まずは画面で調査を行い、何が起きているかを確認したところ、ログインボタンを押した時に
POST wp-login.php 302->GET wp-admin/admin.php 302->GET wp-login.php 200
とリダイレクトしていることを確認した。

wp-admin/admin.phpのどこでリダイレクトしているか調査したところ、auth_redirect()wp_validate_auth_cookie()でfalse判定になっていることでログイン状態の判定がされないことがわかったので、なぜfalse判定となるのかを調査。

https://github.com/WordPress/WordPress/blob/master/wp-includes/pluggable.php#L1044

ここからが長かった。
$manager->verify( $token )がfalseになっていることはわかったが、これがなぜfalseになるのかがわからない。

https://github.com/WordPress/WordPress/blob/master/wp-includes/pluggable.php#L675

このセッションがどこに保存されているか、このセッションがどういう情報が入っているのかも知らない状態から調べ始めたのでこれが何もわからない。
ようやくwp_usermetaテーブルにセッション情報が入っていることまで確認したが、もともと入っているデータがどうなっているのかもわからない。
そもそもいつ更新されるかもわからなかった。
これを一つずつ調べるのにすごい時間がかかった。

wp_usermetaテーブルが更新されない

$manager->verify( $token )はwp_usermetaに入っているsession_tokenから、Cookieに格納されているトークンを使って一致するキーから情報を取得するのだが、ここにトークンと一致する情報が存在しないからログイン判定がなされない。 ここに一致する情報がないと絶対に解決しないことがわかったので、どうやって格納しているかを調査する方向に転換した。

調査をしたところ、ログイン成功時にトークンを発行し、それをセッション(DB)とCookieに格納していた。

https://github.com/WordPress/WordPress/blob/master/wp-includes/pluggable.php#L877

Cookieが格納されていることは開発者ツールで確認している。なのでセッションに格納されないことが原因だと判明。

https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-session-tokens.php#L151

トークンは生成時にセッションに格納している。

https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-user-meta-session-tokens.php#L98

この処理でセッション(DB)に格納している。
update_user_metaを調査。

https://github.com/WordPress/WordPress/blob/8f5d82df7b0b5b2fbaed8ca4c2ad49876f8175df/wp-includes/meta.php#L268

DBにQueryを実行し結果を返している。まさか。
update_user_metaの実行結果を出力してみる。
falseが返ってきた。

DBの更新処理が失敗している!!!

原因が判明。あとはなぜDBの更新が失敗しているかを調査し、実際にDBに入って更新処理を実行してみたところ同じように失敗 Disk Full 〜と出力されたので、DBを抜けてdf -hを実行、100%となっていることを確認。。。

解決方法

容量を圧迫しているファイルを探し、今回はログファイルを圧縮することでログインできるようになった。

怒りポイント

ソースコードを読むのが辛い

とにかくソースコードを読むのが辛い。ログイン処理とかどこで書き込みしているのかわからない。

https://github.com/WordPress/WordPress/blob/master/wp-login.php

そして、一つの関数の内容が多すぎる。どうみても一つの責務だけを担当していない。
関数のコードが大きいということは、関数内の何で問題になっているかから調査しないといけないので、その労力がすごく大きい。

DB処理失敗時に何もしない

今回の原因となったDBの更新処理について、失敗した場合にfalseを返すだけなので、ログも残らないし処理も終了しない。
DBの更新に失敗ってWordPressだと致命的だと思うので、せめて例外を投げて処理を終了してほしい。
解決したあと、そりゃわからないわと思ってしまった。

まとめ

多分ここで愚痴るよりPR投げた方が早いが、多分WordPressは大きくなりすぎてしまったんだと思う。
自分もこのブログにWordPressの記事を書くことになるとは思わなかった。
もう少し平和に過ごしたい。

RedashのDatasourcesにMySQLがなかった場合の対処法

はじめに

RedashのDatasourcesにMySQLが出てこなかったので、その調査と解決策です。

TL;DR

PythonMySQL用ライブラリ(MySQL-Python)をAPサーバにインストールする

何が起きているか

Redashでは、Datasourceごとにクライアントライブラリが存在するかをチェックし、存在しないDatasourceは新規作成時に表示されません。

Redashの環境構築を行う際、docker-compose.ymlを使用してDocker上で全て完結する場合は全てのクライアントライブラリをインストールするpipコマンドが実行されるようDockerfileに記載されています。(requirements_all_ds.txt
ただ、こちらの記事にある開発者向けの環境構築手順では、Datasourceをインストールする手順が省略されているため、いくつかのDatasourceは表示されません。

何もしなくてもいくつかのDatasourcesが使用できる理由

環境構築で必要なライブラリだからだと思われる。
例えば、Postgresqlはライブラリがimportできるかのチェックすら行なっていない。これはおそらくPostgresqlをRedash自身が使用するため、ライブラリは確実にインストールするためだと思われる。
他にも、MongoDBやAmazon Athenaは、Redashのユニットテストで使用しているため初期から表示されている。

MacMySQL-Pythonをインストールする

pipでインストールするだけでは動きませんでした。

pip install MySQL-python

また、全てのDatasourceをインストールしようとしても失敗しました。

pip install -r requirements_all_ds.txt

インストール失敗時に表示されたエラーメッセージを読み、こちらの記事を参考にしました。 stackoverflow.com

まとめ

Docker Composeで構築した場合と自分で構築した場合で表示されるDatasourcesが違ったり、いくつかのDatasourcesは最初から利用できることから
最初はとても戸惑ったけど、中を読めばわかる内容だった。
ドキュメントではLinuxでの環境構築が書かれており、Macで環境構築しようとすると少し手間が必要になる。
他に同じような内容で困っている人がいればこの記事が参考になると幸いです。

わからなくても読む。いずれ理解することを目指す

導入

最近、設計について解説されている本や設計パターンの本をいくつか読んでいる。
そんな中、このツイートとこの話題を取り上げているブログをいくつか読んで、自分は今読んでいる設計の話が本当に理解できているんだろうかと不安になった。

私自身、本を読んだだけで理解できたとはまったくもって言えないし、理解するのにまだ時間がかかると思っているけど
そんな状態でも読むことに意味があるんだと信じたいのでブログでまとめる。
読む対象は本だけではないです。ブログとかのインプットするもの全般です。

まずは用語だけでも目に入れておく

今回のケースは、本を読むことである程度理解できる人ではなく、
なんとなく、主張はわかるけど実際にどうやれば良いのかわからないという人がテーマになる。
私もそういうタイプの人間で、すぐ理解できなかったり、その場では理解できるまで読み込むようなことをしないタイプだけど、それはそれで良いと思っていて
まずは用語を目に入れて、どこかのシーンで「見たことある」というようにしておくことを心がけている。
そうすることで、他の記事を見かけた時に少しずつ前提知識がついていって理解が進むようになると思う。

自分が携わるシステムに触れる時に読む

業務でもプライベートでも、どこかでシステムに関わる機会はあるはずで
そのシステムが自分一人だけで作っているものでない場合、最初に作った人や大きな部分を構築した人の思想というのは絶対に入っているので
それを読んで、システムの理解だけでなく背景や思想まで読み取るような習慣をつけると、思いがけず過去にみた事ある設計パターンの理解に繋がることがあると思っている。

実体験してわかることもある

プログラミングを始めた頃、「オブジェクト指向」や「MVC」について、何を言っているか全くわからなかった。
設計図を作るから何?再利用できるなら関数で良いんじゃないの?って考えてたけど、ちょっと経験を積んで、有名なフレームワークソースコードを読んでみると
ああこれがMVCか、なるほどこうすることで綺麗なコードになるんだと理解できるようになっていた。
なので、いきなり全てを理解できることはなくて、実際に使用されているシステムのコードを読むだとかその中で開発するという経験はあると理解が進みやすいと思います。
そういう意味では、一つのサービスだけではどうしても触れる領域というのは限られてくるので、小さいアプリを作ってみるとかOSSに参画してみるとかで機会を増やす方が良いと思います。

まとめ

ある意味、一つの勉強法の話かもしれないなと思いつつ、思ったことを書いた。 今回は設計の話で思ったことだけど、これって設計に関わらず全ての事象で言えることだよなーと思ったので、タイトルに設計というワードは入れなかった。
事前にちょっとずつ入れようという話ではあるんですが、別の考え方も持っていて、これってYAGNIの原則とは離れた考え方だよなと思った。
なのでそこは、完全に理解するのは必要になるまで不要ということで結論としたい。

「ファクトフルネス」読んで最後まで感動した

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣
読んだ。最初のきっかけはTwitterだったかブログだったか忘れてしまったけど、最初は「ビル・ゲイツアメリカの大学を卒業した学生のうち、希望者全員にこの本をプレゼントしたほど」という触れ込みに興味を持った程度だった。ただ、読み終わった今は読んで良かったと思っている。とても良い本だった。
最初から書いてしまうんだけど、「終わりに」の文章まで最高だった。この本を書いたハンス・ロスリングという方が、本を書き始めて約半年で余命宣告をされて、それからこの本を書くことだけために余生を費やしたこと、それでも最後は完成させる前にこの世を去ったこと、救急車で運ばれた時も原稿を手にしていたこと、この本を妻と子供が最後まで完成させたことが2ページ程度に書かれていたのだが、偉大な人がまさに人生をかけて書いた本ということがすごく伝わった。素晴らしい内容だった本が、より感銘を受け感動した。もしあなたがこの本に興味があるのなら、必ずこの本は読んだ方が良いとお勧めできる本である。

「ドラマチックすぎる世界の見方」は正しくない

あなたは、世界は悪くなっていると考えているだろうか?戦争・暴力・災害は減ることはなく、貧富の差は広がっていると考えていないだろうか?
少なくとも紛争は減っているし、災害発生時の支援や救助は年々整備されている。だからその見方は正しくない。だけど、人間はそういう見方をする生き物だ。
「ドラマチックすぎる世界の見方」を変えるのは難しいが、ドラマチックな本能は抑えるべきだ。

ファクトフルネスと事実の見方

どうやって「ドラマチックすぎる世界の見方」を抑えるか、それは、世界を事実で見るようにすることだ。
先ほどの紛争や災害発生時の被害者は、年毎のデータを見ればわかることだ。データを見れば、「ドラマチックすぎる世界の見方」をすることはなくなる。
この本は、ファクトフルネスの方法を習慣化するための手助けをしてくれる。

10の本能と、それを抑える方法

この本では、「ドラマチックすぎる世界の見方」をしてしまう10の本能について紹介されている。

  • 分断本能
  • ネガティヴ本能
  • 直線本能
  • 恐怖本能
  • 過大視本能
  • パターン化本能
  • 宿命本能
  • 純化本能
  • 犯人捜し本能
  • 焦り本能

どれも世界の見方を曇らせるもので、どういうものかとなぜそうなってしまうのか、その回避方法が説明されている。それをここで全部書いてしまうとただの本を写すだけになってしまうし、ちゃんと文章で理解してもらえる内容を私に書く力はない。
この本を読んでその通りだなと思ったことはいっぱいあって、一例を出すと、どんなに勉強をしている人でも一度手に入れた知識をアップデートすることは少ないと思う。この本はそれについても言及されていて、過去の知識を元に考えてしまうことがあると思う。それが不変なものなら問題ないが、世界情勢が不変なことはありえない。
世界は常に変わっている。だから、今の知識をデータで見て、アップデートすることが必要だ(宿命本能)

まとめ

10の本能はひとつひとつ読み応えがある内容なので、ぜひ買って読んでいただきたい。
この本を読んだ後、世界に希望が持てるようになるとのことだったが、確かに読む前と読んだ後で世界の見方が変わった気がする。
自分もクイズの正答率はチンパンジーより悪かったし、事実を見れていなかったので反省している。
ファクトフルネスの10のルールは写真に撮っておいたので、なんども見返しながら実践していきたい。