無気力生活 (ノ ´ω`)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

tmuxセッション中でHomeキー、Endキーを有効にする

ここ数日ブロクへのアクセス数が妙に増える現象が発生しておりまして、不思議に感じてました私です_(:3 」∠)_

WSLで「普通」にDockerが動くようになっていた話(しかしdocker-composeは動かない) - 無気力生活 (ノ ´ω`)ノ ~゜

まあ契機としてはおそらくこの記事ですかね。やはりみんな興味ある話題なんですね、WSLでDocker使う方法。



さて、先々月くらいから本格的にtmuxを使い始めたのですが、結構困っていたことがあり。 まあタイトルに書いてあるとおり、tmuxのセッション中だと、Homeキー、Endキーが思ったとおりに動いてくれなかったんですよね(´・ω・`)

そのうち解決しようと思って放っておいたのですが、さすがにキャレットの移動が辛くなってきたため、今のうちに対応してしまおうかと思い立ったわけです。 自分の環境はこんな感じ

  • Terminal: Hyper
  • Tmux: 2.7
  • $TERM: xterm-256color

すごく簡単に原因だけ書くのですが、tmuxのセッション中だと、Home,Endのエスケープコードが変わってきます。 (Hyperを使っている場合、Ctrl+vしてからキーをタイプするとわかります)

macOS(bash, zsh)

home:    \e[OH~
end:    \e[OF~

tmux

home:  \e[1~
end:   \e[4~

mac側のコードの場合は別途.zshrcにbindしてましたが、tmux側のコードは未指定でした。 結論、こうすればtmuxでもHome, Endが動くようになります。

bindkey '\e[1~' beginning-of-line
bindkey '\e[4~' end-of-line

結構ピンポイントな情報がなく、探すのに苦労したのでメモ。

参考

https://wiki.archlinux.jp/index.php/Home%E3%82%84_End%E3%82%AD%E3%83%BC%E3%81%8C%E6%A9%9F%E8%83%BD%E3%81%97%E3%81%AA%E3%81%84#Readline

WSLで「普通」にDockerが動くようになっていた話(しかしdocker-composeは動かない)

Twitterを見ていたら、こんなネタが流れてきました。

qiita.com

これは!!(`・ω・´)

これまで、自環境のWSL上でDocker使おうと四苦八苦しておりまして、一旦WSLからDocker for Windows(+Hyper-V)側をコールして使ったりしていました。しかし、この場合だと-itオプション付きで起動してもttyが全く応答を返さなくなるという問題があったわけです。
なので、諦めてVagrant環境を別に作ってそこでDocker動かすというよくわからない運用をしていたんですよね(´・ω・`)

ただ、今回流れて来たQiitaの記事通りの手順でやったところ、普通にWSL上でDocker使えました(`・ω・´)

# docker run -it ubuntu bash
root@d83774f69c10:/#

とても良さげ。Docker for Windowsも不要になるので、Hyper-Vも不要でいけそう。



さて、dockerが使えた所でdocker-composeを使ってみることにします。 Qiitaの記事と同じ方法でDockerをインストールした際は、docker-composeついてきません。なので自前で入れる必要があります。 wslでUbuntu使っているのであれば、sudo apt install docker-composeで何も考えずにインストールできますが、かなりバージョンが古いです。

docker-compose version 1.8.0, build unknown
docker-py version: 1.9.0
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016

公式のやり方に合わせて入れましょう。

docs.docker.com

# sudo docker-compose version
docker-compose version 1.21.2, build a133471
docker-py version: 3.3.0
CPython version: 3.6.5
OpenSSL version: OpenSSL 1.0.1t  3 May 2016

OK

バージョンまで確認できたので、おもむろにsudo docker-compose up叩きます

# sudo docker-compose up
Creating network "etl_default" with the default driver
ERROR: Failed to Setup IP tables: Unable to enable NAT rule:  (iptables failed: iptables --wait -t nat -I POSTROUTING -s {ip}/16 ! -o br-e9ec09beb9a3 -j MASQUERADE: iptables: No chain/target/match by that name.
 (exit status 1))

エラーで死ぬ。なんでや!(:3」∠)

調べてみたところ、他の方も同じような問題にぶち当たっているらしく、全く同じエラーが出ているようですね。

www.scriptlife.jp

どうもwslのネットワーク周りの対応がまだ完全じゃ無い模様。 うーん、これで完全に行けそうな雰囲気あったんですけどねー。もうちょい様子見ですね。

TokenSkyへ参加してきた話

ここ数日の暑さには辟易しますね(ヽ´ω`)暑さと湿気で夏バテ気味です。本当にこんな状態で東京オリンピック開催して大丈夫なのでしょうか?という心配をするこの頃です。
とか書いてたところ、記事清書中に西日本で記録的な大雨と来ましたか…

最近は気候の変動が大きく、大事になることが増えてきたように感じます。被害に遭われた方には心よりお見舞い申し上げます。

さて、2018/07/04と、2018/07/05で、TokenSkyというブロックチェーン関連のイベントが開催されました。

www.tokensky.net

2日通して参加し、興味あるセッションを聞いて回っていました。参加してみて感じた印象ですが、こんなところです。

  • エンジニアリング的な話はほぼなし。プロダクトの紹介や法規制的な話が多かった。
  • セッションは中国語が多め。一部翻訳がないセッションもあり、全く理解できぬ...(´・ω・`)つらみ
  • 参加者は、日本人より海外から来た人が多かった印象。平日だからね、しょうがないね。
  • プラットフォーム、プラットフォーム、プラットフォーム。どこもプラットフォームを構築している印象。暗号通貨関連はまだ黎明期だと感じた。
  • 「それブロックチェーンじゃなくても良くね?」プロダクトが多々見られた。投げ銭チャットアプリとか、イラストの途中経過を購入できるサービスとか。使ってみました感がぬぐえないものがチラホラと。



自分が参加してきたセッションの内容メモや、感じたことをサクッと書いていきたいと思います。(`・ω・´)ゞ

1日目セッション

暗号通貨専門コワーキングスペース「コインキャンプ」の紹介

www.coincamp.jp

暗号通貨のプロダクト開発用のコワーキングスペースを絶賛作っているそう。日本国内で暗号通貨を盛り上げていくことを目的として、イベントスペース大きめ。
50人入る箱を計画してており、ミートアップ等に使ってくださいとのこと。

暗号通貨のコワーキングを作った理由としては、働き方が「会社から個人へ」変わっていくと感じているからだそうです。
会社に出勤して時間だけ働いて帰る。これまでの時間に縛られる働き方から、個人が出した成果に基づく働き方に変わる。そのために必要な「場所」に対するニーズが高まりを考えた結果、コワーキングスペースを作るに至ったとのこと。

場所は六本木になるらしいので、近くを通りかかったら見てみたいと思ってます。(`・ω・´)

価値の移転で革命を起こす!CROSSプロジェクト

https://cross.technology/

物々交換にブロックチェーンを使って解決しようとするプロジェクト「究極の物々交換プラットフォーム」、「世界中のありとあらゆるものをデジタル資産にして、だれもが便利に利用できるサービスを提供する事」を目標としているようです。トークンはXCR。

結構な資金調達がされており、プロダクトもリリースされているので、実態のあるICOですね。すでに「伊良部島リゾート開発」なるものが動いており、実際にこの仕組みを使って物件をトークン化して販売する、実需が望めるプロジェクトになっています。

感想としてですが、安全で取引所付きのウォレットに惹かれています。ホワイトペーパーを見る限り、電子割符を用いた暗号鍵の分散や、位置情報の制限といったセキュリティが高い仕組みを採用しており、ハッキングリスクが抑えられている点とてもよさそう。後は、分散取引所もやるらしく、2年で世界5位の取引額にまで育てたい、という目標を持って進めているようです。

次世代デジタルコンテンツ保護流通プラットフォーム 「ASOBI COIN」

asobimo.io

デジタルコンテンツの二次流通を目指すプロジェクト。要は電子データのリセールですね。

電子データはコピーが容易なため購入したものをリセールすることはできなかったのですが、ブロックチェーン技術でのDRMを実現して問題を解決しようとしているようです。ゲームアイテム売買も視野にはいっているらしく、RMT議論がまた勃発しそうな雰囲気ありますが如何か。

現在はまだ取引できるプロダクトはなく、直近はアソビモがリリースしているゲームアプリで使用できるそうです。

ただ、日本でICOする場合、「暗号通貨交換業者」の登録が終わってないとできないんですよね。ただ登録に必要な条件が厳しく、なかなか審査が通らない。
なので、アソビコイン、定義上は暗号通貨ではない扱いにして(取引所に上場してない等)、前払式支払手段として運用しているそうです。前払式だと、流通額の供託義務がでてくるので大変そうですね。

ICOの法規制関連についてはここが詳しいです
http://topcourt-law.com/virtual_currency/ico_regulations_financing

イデアとしてはとても価値があると考えていて、今後需要も大いにあるプロジェクトだと思います。こちらも継続してウォッチ(`・ω・´)

アスリートとファンを繋ぐSNS「KIZUNA」

kizuna-athletes.jp

らしいです。アスリート支援はクラウドファンディング等が活用されていた印象ですが、個人ユーザーが簡単に支援できる仕組みはあんまりなかったので、ニーズは高いかと思います。

個人的には「それブロックチェーンじゃなくてよくね?」プロダクトの1つ。 ただ、講演聞いていて、「その手があったか」という気づきを得られたので、うまく動けばとても有望なプロダクトだと思っております。

ブロックチェーンが指し示すプラットフォームとテクノロジの未来

佐々木俊尚さんの講演。

モノを作って消費者に売る時代、からモノを用いたフロー(体験)を売る時代へ変わっていく旨のお話。
講演では例として自動車会社のビジネスについて語られてました。

これまでは自動車を作って売ることだけやっていればよかったが、例えばUberの自動運転のように、自動運転 × 高度な配車を組み合わせた「移動を売る」時代が生まれてきた。

その一例として、トヨタ自動車の「e-Palette」が紹介されました。 newsroom.toyota.co.jp

リンク先にあるコンセプト動画を見るとよく分かるかと思うんですが、この車、運転席がないんですよね。あくまでサービスを消費者の元に持ってくるコンセプト。
モノを売る企業の代名詞でもあったトヨタ。そのトヨタがモビリティサービスに本腰を入れる動きをしている。これこそハードからフローへ至る萌芽である、という話です。

さて、講演の中でフロー社会を実現するために不可欠なもの、として3つを挙げられました。

モビリティサービスであれば、IOTでのデータ収集は渋滞や道路状態などを計るために使われますし、そのデータを利用するためにAIでの自動化が必要。また、すべての端末が同じデータを公開・共有するためにブロックチェーンを利用する。

自分が感じた印象としては「インダストリー4.0」と同じような話ですかね。超スマート社会の実現を目指してる動きで、おそらくフロー社会とはこのことを言っていると思います

http://www5.cao.go.jp/keizai3/2016/0117nk/n16_2_1.html

暗号通貨規制状況の話

弁護士である増島雅和さんの講演。暗号通貨関連のスライドが多々公開されているので見たことある人も多いはず。

www.slideshare.net

この講演では、海外事業者が日本市場を目指している話が語られました。

まず前提として、これまで日本は暗号通貨関連の法規制を先んじて進め、ビジネスをリードしていく立場だった。ただ、あることを契機に急に締め付けが加速しビジネスし辛い市場になったとのこと。ええ、コインチェック事件です。

コインチェック事件が起こった後、厳しくなった規制で、暗号通貨事業者が整理されました。国内でサービス提供していた事業者は大方処分を食らっています。さらに、海外事業者の取締が厳しくなりました。有名な海外の取引所が日本人向けサービスを止め始めたことは記憶に新しい。

その結果何が起きるか。法規制が厳しくなって海外からサービスを提供できなくなる一方、暗号通貨市場における日本人の需要はかなり大きい。となると、「日本に会社を作り、正式な暗号通貨事業者登録を行った上で事業を行う」動きが発生していきます。

さて、そんな日本の法整備の状況ですが、これがまた動きが鈍い。

金融庁が管轄してはいますが、その金融庁の研究会では実際に提供者側の人間が入っておらず、金融庁自体が暗号通貨市場をしっかり理解できているとは言い難い状況のようです。 金融庁が絵を描けない状態で行政やっているため、暗号通貨関連法の制定がグダグダになっている現状があるとのことでした。 業界は自主規制機関を作り始めてはいますが、その自主規制機関も主導する立場ではないため、しばらく日本で関連法がしっかり整備されるのは時間がかかりそうですね。



増島さんは暗号通貨に詳しい弁護士であるため、スタートアップセクターの事業者から、「どうすれば規制の多い日本でビジネスができるのか」みたいな相談がよく上がっているそうです。

増島さん的には「何言ってるんだ」感があるらしく、例えば中国では暗号通貨全面的に禁止されており、日本より厳しく制限がかかっています。彼らは香港やアルメニアと行った暗号通貨関連の規制がゆるい地域まで越境することで、暗号通貨事業の主導権を握るまでに成長しました。

日本で暗号通貨事業がうまく進まないのは法規制だけが問題ではなく、事業を進めるために海外に出る覚悟をもって進めることが、今後日本で暗号通貨事業を引っ張っていくために必要なことである。そう話されていたことが、とても印象に残っています。

モバイルデバイスのストレージを活用してマイニングできる「Module」

https://modltoken.io/

暗号通貨マイニングと聞いて何をイメージしますか?

最近よく聞くのは、計算のための電力で国何個分の電力を使っている、みたいな話ですね。実際そういったイメージが多いかと思います。 いわゆるPoW(proof of work)というアルゴリズムを使ったマイニングですね。ビットコインを始め多くの暗号通貨で使われているやり方です。これは確かな計算結果を求めるために膨大な電力を消費することからよく批判されます。

Moduleは、モバイルデバイスの空いているストレージをクラウドストレージとして提供して対価を得る、PoSTT(proof of space time and transaction)というシェアリングエコノミー的なアルゴリズムを採用しています。電力を回して計算させるのではなく、実際に使われた容量に応じて利益が出るもので、資本力のない個人でを利益を挙げられることを目指し、様々なデバイスに入れてもらうことを狙っているらしいですね。

クラウドストレージとして使うときは、データ自体を暗号化した上で幾重にも分割して配信するという仕組みを取るらしく、ストレージの持ち主が中身を閲覧することができない仕組みになっています。またブロックチェーンの特性を生かし、あるデータを複数の端末に配信して、読み出せるところから読み出すことで高い可用性を実現しているそう。

個人的には、今回のTokenSkyに出展しているプロダクトで一番期待しています(`・ω・´) プレセールが2018年7月16日から開始され、実際にユーザーが触れる状態になるのが2018年12月くらいだそうです。

これはぜひプレセールに参加したい温度感。
家に転がっている古い端末を再活用する場ができそうでワクワクします。


さて、これにて参加したメモが終了となります。

色々と期待できるプロジェクトを知ることができたので、個人的にはとても身になるカンファレンスでした(`・ω・´)
上で書いた期待するプロジェクトを応援するとともに、自分でもなにかブロックチェーンを使ったプロジェクトを進めていきたいところですねー。

突発的な障害対応のいろは

皆様、夜分遅くいかほどお過ごしでしょうか。
株主優待が届き始めるシーズンですね。私めのところにも商品券がいくつか届き始めるので、この時期だけ外食が豪華になったりします。 はい、完全に余談ですね_(:3」∠)_



さて、はてブを巡回している時に、障害対応について書いている記事が上がってきていたので、私めのやっている障害対応方法について書いてみたいと思います。

「いろは」とかいいつつ、早速他人頼りになってしまうのですが、

qiita.com

うん、自分が基本的にやっていることもこれと非常に近しいですね。若干の違いはあるので、以下後述していきます。

なにはともあれ、まずは報告です

障害対応で真っ先にやる必要があるのが、「すでに着手しているよアピール」です。
焦っているので割と忘れられがちですが、チームとして何かサービスを運用している場合、エンジニアだけの話では収まりません。サービスの責任者や、実際にユーザーと向き合っている問い合わせ担当といった、後で障害のケツを拭くメンバーがいるわけですね。彼らにとっても自分の仕事に直結するため、実際に着手されているかわからないと不安ですよね。

なので、まずやることは障害発生の報告です。この時点ではまだ何もわかってないので、「障害が発生している模様。調査中」みたいな感じで簡潔に伝えます。

最近だとslack使っているところ多いと思うので、障害用のチャンネル作っておいてそこで連絡すると良いです。窓口が一元化されているとすごく便利(障害のこと書いていい場所があると、気づいた他の人が報告してくれる副次的なメリットも大きいです)

サービスメンテナンスの判断

常に実施するか微妙なケースもあるので、あえてこちらを最初のタスクには書きませんでしたが、例えば。「サービスが全然応答しない」、「決済に不都合が生じている」みたいな重大な事象においては、報告と同時にサービスメンテナンス入れてください。

メンテナンスには、問題あるサービスを使わせないことに加え、「ユーザーに問題が起きている」ことを伝える意味があります。
ローディング出したまま固まるみたいな現象が起きると、一部のユーザーはまず再起動なり、アプリの場合であれば再インストールを行ったりします。「あなたの方には問題ないですよ」を早めに伝えてあげる。運営者も不安ですが、サービスを利用しているユーザーはもっと不安です。早めに対応中であることを伝えて安心してもらいましょう。 これやらないと、さらに問題が複雑になったり、問い合わせ窓口が爆発して後処理がクッソ面倒くさくなります。

なので、止めなきゃいけない事象であれば、さっさとメンテやりましょう。1コマンドでやれる環境を常に用意しておくことを推奨します。やつらは突然やってくる。

前職ではbastionサーバーでcap maintenance:inで、nginxの管理化にmainte.html配置。ファイルが存在していれば、すべてのアクセスをそこに飛ばす設定にしていました。この辺参考になるかと思います。

hacknote.jp

原因調査

ここまでやってから、原因調査を開始します。一番頭痛くなる時間ですね。
まずは発生している問題から何が起きている可能性があるか仮説立てます。闇雲に動いても大体ロクな結果にならないので、アタリを付けて。冒頭で挙げたQiitaの記事にもありますが、見なくてもいいものを削っていくアプローチの方が効率がいいです。かつ検証可能性が高いものから潰していきます。

ある時間から急に発生しているのであれば施策開始やデプロイが起因していることがほとんど。エラーを検知する仕組みがあるとわりかしスムーズに進みます。ないところはさっさと立てましょう。エンジニアが死にます(´・ω・`)

まずはエラーログを見る。ここで要因がアプリ側なら、ディスクを見る。メモリを見る。CPU負荷を見る。デプロイされているコードバージョンを確認する。DBの可能性が疑われるなら、接続できるかを見る。スロークエリを見る。データ不整合を見る。

だいたいこの過程で「何が問題でサービスが機能していないのか」がわかります。 サーバーの状態は時系列で追えるといいですね。サービス運用するならモニタリングできる環境は必至です。仮にモニタリングしてないところがあれば今すぐ https://mackerel.io の門を叩きましょう
(自前でやる気があるなら、 https://prometheus.io/ が良さそうです)

mackerel.io

prometheus.io

なお、調査で調べたことがあれば都度報告するようにしましょう。「DBみた、つながる」、「クエリ詰まってる感じなさげ」、「APPのメモリが普段よりスパイクしてる」みたいな雑な感じでいいです。 他エンジニアに対する報告と、エンジニア外の人へちゃんと対応してる感が出てればOKで、整える時間があるなら調査に回しましょう。

障害対応

原因がわかりましたね?では次は障害を解消していくフェーズになります。

ここで重要なのが、「この障害はどこまで解消しているべきかのか?」を真っ先に詰めることです。
サービスにもよるのですが、止まっていることで不利益が生まれるのですばやく再開することが重視されるものや、完全に対応完了して事後対応まで要求されるものまで、対応のスコープが異なります。

この辺は事業責任者と話をして真っ先に決めましょう。エンジニアだけで判断するのはリスクが高いので必ず責任者巻き込んでください。稀に責任者と連絡つかないケースも生まれますが、事前に、この障害が起きたらこう!みたいなユースケースを責任者と握っておくと連絡取れないリスク減らせるので、ぜひやってください。

ゴールが握れていれば、後はそこに向かって作業するだけです。ここまでくれば後はうまいこと解消できると思います。



あとはほぼQiitaの記事と同じ流れですね。起きた障害を記録する、起きない対策を入れる、起きない環境を作る。ここ非常に大事です。もれなくやっていきましょう。

長くなってしまったので、今日はこのへんで。後日気が向けば「障害対応できるエンジニアの育て方」みたいなエントリ書いてみたいと思います(`・ω・´)

Dockerでタイムゾーン指定することについてメモる

mariaDBのイメージ触っているときにタイムゾーン指定で困ったことがあるので調べました。(jessie:Debianの場合。alpha linux使っている場合はこれじゃできないので注意)

最近の開発として、appだけのコンテナ1つで済むことがあまりなく、DBなりKVSなりのデータストアがある前提で作ることが多いです。なので基本的にdocker-composeを使っています。



docker-composeタイムゾーンを指定したい場合、方法として2つあります。

  • docker-compose.yml側に書いて管理
  • Dockerfileでそれぞれ直接指定して管理

docker-compose.ymlで指定する場合

environment:
    - "TZ=Asia/Tokyo" 

Dockerfileで指定する場合

ENV TZ='Asia/Tokyo'



まあどちらでもできるんですよ。
で、ちょっとした悩みとしてあるのが、DockerFileに書くか、docker-composeに書くか。「イメージ単体として完成されているべき」と考えるのであれば、Dockerfileに書くのが妥当だと思うのですが、複数のイメージ前提のシステムであれば、全てで統一されていることが必須になるわけですね。

うーん...正直どちらでもいい気が...タイムゾーンってそんなに変更するものではないですしね(´・ω・`)

考えた結果、冒頭で書いたように、ベースとするイメージによって指定方法が変わってくることもあるので、イメージ単位で指定できるDockerfile側に記述することにしましょう。

アウトプットの重要性についてぼやっと考えてみた

遡ること2009年くらいからブログ書き自体はやってきました。2012年まではBiglobeで、記事だけで移行しております(画像リンク切れ...)

しかし、結構前からやっている割には。はい、全く数がありません。

気が向いたときだけ書く、みたいなスタイルでやっていると、いつまで経っても書かない。そんな私のような面倒くさがりな方、いますよね?ね?
とにかく書くこと面倒なんですよね。これは人によっても異なるのですが、

  • 書きたいものが特にない。『書くものないしやらなくても』
  • 自分が書かなくても誰か書いているでしょう、という需給が気になる。『書く意味あるの?』
  • 書いた内容に対するツッコミが面倒なので書きたくない『マサカリこわい』
  • 読めるに値するものを書こうとすると時間がめちゃくちゃかかる。『他にやりたいこと優先するわ』

大方こんなところでしょうか。ちなみに私の場合だと「他の人が書いてるから書く意味ないのでは?」が多かったと思います。



仕事から離れて、思考する時間が多くなったこともあり、「アウトプットするメリットはどこにあるのか?」をぼやっと考えてました。 散々一般論として言われていることに収まりますね。大きく3つあるかと思います。

  • 思考の整理能力が向上する。文字として言語化することで、自身の理解が進む。
  • アウトプットの練習として。普段から書くことで文書の基礎体力が養える。
  • アウトプットのためにインプットする量が増える。やはりマサカリは怖いので、事前のインプットには力が入る。

今回改めて実施するメリットを見た限り、書く意味について考えるより、思考の整理や鍛えることを意識する。こっちのほうがやっていけそうなイメージあります。

正直、私言語化得意じゃないです。むしろ苦手。うまく意図が伝え切れないことがよくあります。
やはりアウトプットを行うための基礎体力を鍛えた上で、思考をうまく整理できる能力を身に着ける。意図がうまく伝えきれない、を解決するには地道に鍛えていくしかなさげです。



どうでもいい内容であったとしても、書くこと自体が力になる。これから意識してやっていければな、と思う私でした_(:3」∠)_

※ちなみに本内容書くのに30分掛かっています。スピード上げたい...




studyhacker.net

リレーションシップ・クライシス

私、現在転職活動中で、いろんな企業の方と話すことが多くなっていたのですが、
とある会社さんで、「リレーションシップ・クライシスを起こさない自発的な組織を目指している」といった話を伺ったのです。

リレーションシップ・クライシスとはなんぞや?と後で調べてみたのですが、"relationship crisis"で検索した限りでは、結婚相手とのコミニュケーション不全的な話がヒットしました_(:3」∠)_
ちがう、たぶんこれじゃない。



日本語のものだとこの掲載分くらいしか見当たりませんでした。文脈としてはこれっぽそう。

なぜ組織は「迷走」するのか
http://mag.executive.itmedia.co.jp/executive/articles/1010/18/news029.html

はじめは単なる意見の食い違いだったものが、状況が深刻になるにつれて、根深い感情的な対立にまで発展し、その結果、組織が崩壊状態になる」というパターンです。
このような関係性の問題が、事業上の危機にまで発展していく現象を、わたしたちはリレーションシップ・クライシスと呼んでいます。


おお、これは私が前の会社辞めたのと似たような話ではないか(´・ω・`)

自らの職責でできる範囲なんとか数値の落ち込みを防ごうと四苦八苦してましたが、他の人との温度感や考え方の違いに直面して諦めてしまった経験があるだけに、ずっしりくる内容ですね。

たしかに業績が順調だと表面化しませんでしたね...じわじわ数値が落ちてきて「対策たてないといけない」雰囲気が作られた際に、やる気のある古参がポロポロ抜けていくことに繋がりました。



具体的に、社内にこんな兆候があると、リレーションシップ・クライシスに陥っていると言えるそうです。

  • うちの会社にはビジョンがない
  • 上司のマネジメント力が低い
  • エンジニアはコミュニケーション力が低い
  • 営業は商品・サービスを全く理解していない
  • うちの会社は、評論家ばかりで他責・他者批判姿勢になっている

つまりは組織に対するグチですね(´・ω・`)問題そのものへの意見ではなく、他人への文句であるというところがポイントです。
これが行くところまで行くと、社内で小競り合いが活発に起き、都合の悪いメンバーの排斥だったり、疲れて心を病んだり、退職していくといった地獄絵図となります。

私が考えるに、結局は「問題を自分事と捉え、行動できるか」で解決できると考えています。

主体的に問題に取り組める人はそういません。なぜなら、問題に取り組むということは大変めんどくさく、なるべく避けたいと思うのが人間です。
また人によって思考も熱意も異なります。問題に対する考え方も異なります。「その問題を皆が同じ問題と捉えているか?」で統一されていない限り、考え方の違いで揉めます。

仕事はチームでやるものなので、皆が同じ問題意識を持たない限り進めることはできませんよね。



この問題にどう立ち向かっていくか、は同じ著者が書いたこの掲載が参考になりそうです。
http://mag.executive.itmedia.co.jp/executive/articles/1101/07/news005.html



この辺うまく解決してそうに見える企業は、エモい会社のビジョン・行動規範があり、吸い上げた意見を実際に実行するなど、「現状を変える覚悟」を持つ進め方をしている印象。

ノセてアゲるが自然にできている組織はめちゃくちゃ強い。各々がやるべきことを理解している訳で、結果尋常じゃないスピードで動ける。

問題をかき分け跳ね飛ばし、全力で走ることができる組織であれば、「リレーションシップ・クライシスを起こさない」ことができると、私はそう思います。