Agile Japan 2015 愛媛サテライトに参加して楽しかった

Agile Japan 2015 サテライト＜愛媛＞「自分につなげるアジャイル」

昨年は私の地元徳島で開催していただいたご縁もあり、今回は「いくぞ！」と意気込んでいた所に、パネルディスカッションのご依頼もいただき意気揚々と参加してきました。

仕事のプロジェクトのピーク週でもありその週ほとんど寝れてなかったのですが、居眠りすることなく懇親会二次会までとても楽しい時間を過ごさせていただきました。

運営の皆様、一緒にお話いただいた皆様、本当にありがとうございました！！！！！！

以下、感想やら。

午前の部（東京の中継）

徳島からの移動中だったので中継は見れなかったのですが、実践アジャイルテストの方だと聞いていたので、超楽しみにしていたのですが、結果内容は分散リモートの話だったということで、もっと聞きたかったという残念な結果に。。。

ただ、「全てを共有する」「気遣いがすべて」というキーワードを教えてもらい、なんかそれだけで結構ぐっときた。

平鍋さんがスライドを共有してくださっていて感謝です。

agilejapan-2015 - An Agile Way

午後（サテライトオンリー）

「アジャイルに取り組んでみえた気づきと課題」

株式会社エイチビーソフトスタジオ の 影浦 義丈さん のお話。

社長さんだったり、JAWS-UG愛媛 の支部長だったりと、いつもいつ休んでるんだろうと思っていたのですが、会社の詳しいお話を聞くのは初めてでした。

月額定額の受託開発 を実践されているお話がメインだったのですが、そういう新しい契約形態のチャレンジは失敗例の方が多く耳にしていたので、四国でそういう先端的な事例を聞けるとは正直なところ思っていませんでした。

定額にすることによるメリット

月額ながら、一週間のタイムボックスで成果物をお客さんに見せるというサイクルにしているようです。

月額定額なので、自然と月にできる作業量は決まってくるため、当然一週間での作業量もある程度顧客と共有できます。（と書きつつ、ここはすごく苦労されたそうなので後述します。）

よって、要望や不具合修正も全て、「タスクの優先順位の変更」という形で調整する事ができるため自然と無茶な要望が出にくくなったそうです。 開発側としてもできる作業量が決まっている以上は「それは本当に必要ですか？」と顧客にとって不要なものを作らなくていいように提言することもできたとか。

作業量の認識合わせ

上述した苦労点についてですが、契約開始当初は顧客も開発側も手探り状態だったため、明らかに金額よりも仕事をし過ぎてしまったそうです。

当然ながらそのペースは持続しないので、顧客からしてみれば進捗が落ちているように映ってしまい、そこは正直なところで話し合い、半年程かけて金額に見合うペースにもっていけたそうです。

仕事のやり方にもよりますが、最初に進捗だそうとがんばってしまうのはすごく分かるので、結構難しいなぁと。ちゃんと見積もる事が大事なのだなと。

仕様書はいらない

バッドノウハウぽく聞こえそうですが、そこは開発側も顧客側も担当者をこれまで一度も変えずにやってこれたことで、コンテキストの共有が高いレベルでできているので新機能追加は細かい仕様書を作る必要が無かったようです。 また、開発が終了した機能に関してはきちんと仕様書を残されているとか。

来るべき引き継ぎに備える意味でも、なんだかんだ必要ですよね。

変化すること

月額定額にしろ、作る前に仕様書を作らない事にせよ、 なぜ必要か？ をまず考える事を怠らないそうです。 少数精鋭で、かつ時短勤務の女性も数人居るチームであるため、いかにそのメンバーで最大のバリューを出すかを考える、すごく大事なことだなと思います。

とりあえず人数増やし続ければ開発速度は上がるというのは、まあ無いですよね。。 制約があるから、ツールにせよ、やり方にせよ工夫が生まれるというのは素敵だなぁと思いました。

とりあえずやってみる

やってみないと分からない事が多いので、動き出せないよりは、まずやってみて失敗してみようという事を仰っていました。 本だけ読んでも分かんない事多いよねと。

よくあるこういうケースでダメなのは、「やりっ放し」だそうですが、そこは「タイムボックスを決める」「必ず振り返る」という事を決めているそうです。

会社レベルでやり始めた事を振り返るって経営サイドの体裁もあるしフラットに振り返るのはすごく大変だと思うので、どんな雰囲気でやってるのかすごく気になる。

見える化する

社内社外両方にとって、 目に見える のはすごく大事だそうです。 ただ、習慣化するには時間がかかると。

ただ適当にログを残すと、共有するってまた違いますものね。

Pivotal Tracker や　Chatwork、 Cybozu Live 等を使い分けているそうですが、タスクについてはお客さんも出来る限り一緒にツールを使ってもらって、一緒にみてもらうようにしているようです。

ツールを使うのは、勤務体制が多岐にわたって来ている中で、社内に居る時間を短くするためには、壁の付箋では限界が来たからだそうです。 お母さんエンジニアが居る会社ならではだなーと感心します。

管理しない

なんと影浦さんは、こうやって月額定額の話しをしつつも、実際にその業務の事は最低限の事しか把握していないそうです。

見るべきものは見えるようにしておいてもらうが、あえて報告させたりはしないと。なんというか、すごく高度な情報共有が実現できているなぁと思います。

正直、私の現場ではツールも意識もバラバラで結局「報告してください」が氾濫している気がします。 これって、上司や部下の怠慢ではなく、単に情報共有の仕組みを作ったつもりになってるだけなんですよね。

見えてきた課題

情報共有や管理不要の組織体制ができたことで、「自己組織化」や「自分たちでプロジェクトをドライブする意識」ができてきたそうですが、一方で属人化も進んでしまい、「チームとして」の動きが取りづらくなってきた側面もあるそうです。

「変化への対応を」

ツールやプロセスに縛られず、常に変化に対応できるように、というメッセージをいただきました。

私が感じたのは、

  • 正しく、恐れず今の悪い状態を直視し
  • それに対して現状の延長線上では無い解決策を模索し
  • それをまずやってみて
  • 正面から結果を振り返り
  • 改善をし続けてきた

という事なのかなと。どれを取っても難しい事だと思います。特に決して余裕がある訳ではない状況で上記を実行するのは、覚悟と危機感があってこそなのだなと。

今こう書いていても、胸にぐさぐさ刺さります。。

なんか結果だいぶ自分の解釈がメモに入ってしまっていた気がする。。言ってない事書いてしまってたらごめんなさい。。

「アジャイルなリモートワークをどう実現するか - リモートワーク実践者と推進者の座談会 -」

◆話し手
岩井 克之さん 合同会社ネクストコード
團 洋一さん　 Sansan株式会社
早瀬 潤也さん フリーランス
◆聞き手
懸田 剛さん　 合同会社カルチャーワークス

私もパネラーの一人でお話させていただきました。

なんか自分も話してたのであまりメモが残ってないのですが、覚えていることを。

早瀬さんのお話

受ける仕事の依頼元どこの地方かでの単価の話しはリアルでした。地方に仕事が無いどうこうもあるけど、仮に選択できてもそれだけ単価が違うとどうしても首都圏の仕事を受けてしまうかもなぁと。

在宅勤務でのリモートワークのお話は、自分の体験とも被る部分があって、なんというか自分だけじゃないんだと安心しました。

ただ、「チーム」という形態はやはり異なるので、そこにはメリット・デメリットあるなぁと思いました。 ただ、組織に所属するか否かは、個人の適正や気分にも依る部分があるので、一概にどっちがいいとかは無いのかなぁとは個人的には思います。

岩井さんのお話

岩井さんは過去の４拠点開発でのお話だったのですが、かなりエクストリームで、全員日本にいるのに活動時間がまるで違ったり、結局最後まで顔をみることなく終わったり、それでもとても上手くいったりと。

成功した要因は、

  • 参加メンバー全員がデキル人だった(リモート慣れもしてる)
  • Agile に進めていけたので、後半での手戻りや仕様変更がほぼ無かった

みたいな感じだったらしいです。なんか夢のリモートチームーって感じです。

ただ、現在は自社の社員は全員同じオフィスに集めているそうです。 受託開発もやりつつ、自分たちでのアイデアベースの開発も積極的に進めているため、創発的な活動はやりやすいと。 他には、メンバー間でのツール等の共有等が、ディスプレイを覗くだけでできるので、技術力の向上等にも役立っているとか。

確かに、教育とかそういう面も考えると、リモートはまだまだ課題がありますよね。自分も教えられる側でしたが、似た経験があります。

ただ、岩井さんの会社自体は勤務体制もかなり自由で、リモートでなくとも、勤務時間も自由なので、遠隔でもなければそもそもリモートワークを許可する制度自体必要が無いという、またまたエクストリームな面があるようです。

Basecamp の例なんかみても、まあわざわざ制度っていうよりは、そういう社風なら自然にそうなるって感じなんですかね。

雑談

懸田さんから、 雑談 に関する問いが投げかけられました。

この点に関しては、私個人としては「組織的な解決」と「個人的な解決」の２つがあると思っていて、私は前者には限界があるので後者が大事かなと思っていました。後者は、まあローカルコミュニティ等を大事にしようって事ですが。

ただ、ソニックガーデンさん Remotty の例等を見ても、前者に対する機運も高まっているのかなというのも感じます。 この辺はリモートワーカーがマイノリティではない会社になると、そういう意識が高まるのかなぁという、現状感想です。

「もっと身近にスクラムを！」

上田 和亨さんがファシリテーターとなって、紙飛行機ワークショップをおこないました。

わかったこと

「品質を作りこまなくては、生産性を上げたところで、成果は上がらない！！！！！！」

きっとエンジニアの方なら、紙飛行機で難しいことが、ソフトウェアで簡単になるはずは無いということがわかっていただけると思います。

正直、紙飛行機作りで、ペアワーク、品質保証の話しまで飛躍するとは思いませんでしたが、すごくいいワークショップだなぁと思いました。「品質は絶対落としていけないんですよ」ということがここまで体感して理解できるとは。

懇親会とか

ここ最近の疲れが吹っ飛ぶ、とても楽しい飲み会でした！！東京とも神山ともまた違う、すごいエネルギーがある場所だなと改めて感じました。

岩井さんのお誘いで翌日はネクストコードさんのオフィスで半日仕事させて貰ったりお話させてもらったりで、充実した松山遠征となりました。

ネット上でしか知らなかった人にも会えたりして、いろいろと出会いも多くありがたかったです。

まとめ

東京会場は有料にも関わらずすごい人数が集まったり、島根も 50 人ぐらい集まったとか聞きましたが、愛媛サテライトは規模こそコンパクトでしたが、内容のめちゃ濃い会場だったと思います！

関連

いくつかレポートが出ておりました。

CsvHelper を使って CSV 文字列を生成

公式のサンプルにも似たようなのあるんだけどうまくいかなかったので。

JoshClose/CsvHelper

CsvHelper は

普通に StreamReader/StreamWriter を受け取って動作するので、その辺りが分かっている人にはなんてことはないと思います。

コード

using (var memoryStream = new MemoryStream())
using (var streamWriter = new StreamWriter(memoryStream))
using (var streamReader = new StreamReader(memoryStream))
using (var writer = new CsvWriter(streamWriter))
{
    writer.Configuration.RegisterClassMap<Hoge>();

    writer.WriteRecords(hogeList);

    streamWriter.Flash();

    // Position = 0 でも大丈夫ぽい
    memoryStream.Seek(0, SeekOrigin.Begin);

    var csvStr = streamReader.ReadToEnd();
}

公式のサンプルコードには Flash の記述がなくてウンウン唸っていたというお話でした。。

第六回 tokushima.rb に参加してきた

第六回tokushima.rb＆新年会 | Facebook

参加したいしたいと思いながら、予定が合わず参加できていなかったが、第六回にしてついに参加できた。（飲み会は日曜ということもあり参加できず。。）

当日の参加者は 10 人いなかったぐらいでしたが、大きめのテーブルを全員で囲みながら、基本はもくもく会スタイルでした。

IntelliJ Ruby plugin 使いとの遭遇

もくもく中に Twitter を眺めていると以下のツイートが流れてくる

「あれ、この人、目の前に座ってる人じゃないか？？」と声をかけてみるとやっぱりそうでした。

自分の職場では RubyMine 使いは自分だけで、後は Vim, Emacs, Sublime, Atom と様々。初めて（ほぼ）同じエディタ使いの人に合えて嬉しい。

割りとコンソールを行き来している自分とは違って、RSpec もデバッグも、Git までも IDE 上で完結させてて、かなり良い感じでした。真似したい。

地域のコミュニティに貢献する人達

参加している人達のコンテキストまでは分からなかったけれど、他の勉強会の企画を進めようとしていたり、Code for Tokushima の話しをしていたりとコミュニティ活動に積極的な人が多かった。周りの人も「あの人声かけてみようか」「場所はあそこが使えるかも」とか協力的な人が多かった。

講義型の勉強会では無いため、そういうコミュニティの中心に近い人達が集まっているんだなと思う。横で聞いてて感心しきりだった。

地域のコミュニティと地域の仕事

私は東京の会社の仕事をリモートワーカーという形でやっている訳ですが、最近はもう少し地元の仕事をしたいとも考えてる。というか、地元の人たちと仕事がしたいのかもしれないとも思う。 東京に居ると感じなかったが、「地元」というコンテキストの中で、そこに居る人と仕事をするのは楽しそうに感じた。

一方で、それはリモートワークに多少行き詰まりを感じていたのかもしれないとも気づいた。性格的にも経験上もどうやら自分には小さなチームが性に合っているようで（大きな声だすの苦手だし、承認フローみたいな筋を通してやるのがすごい苦手。。）、現在中規模のチームでたった一人のリモートワーカーをやる事に多少しんどさを感じているような気がする。 チームにはすごく協力的な人もいるし、上司も理解があるので、環境がどうこうとかではないので、たぶんこれは自分の性質への気付きでしかないのかなとも思う。

かと言って、東京で仕事をするというイメージはもう無いし、地元に何か貢献できればと思ったりする。神山町は農業支援にも力を入れているし、他にもいろんな仕事はあると思うし、全部 IT じゃなくて、一部 IT みたいな仕事ができればなーと思ったりする。（IoT とか流行ってますし）

今日の場に出ててみて、例えば、仕事で「コード書いたー」みたいな環境に無くとも、コミュニティやプライベートのプロジェクトでプログラミング欲は満たせればみたいな希望を持てた気がするし、地元の技術コミュニテイの素敵さを感じることができた。

ホントにもくもくと集中する中でも、いろいろと気付きにもなった良い会でした。またお邪魔します！

/dumped

土壌の基礎知識 第一章 を読んだ

図解 土壌の基礎知識

図解 土壌の基礎知識

特にこれを選んだ理由も知識もない。私が世話してる畑なんて、畳３枚分ぐらいしかない。

ここ半年ぐらいであった生産者の方々は以下のような方が多かった。

  1. 畑をキレイに保って、石灰や肥料等で土のバランスを整える人
  2. 自然農法（？）で、雑草や土は比較的自然なままにしている人

1 の人たちは「肥料をやらないから作物が病気になる」といい、2 の人たちは「自然じゃないものをやるから作物が病気になる」という。正直良くわからないけれど、どちらの人も自分たちが正しいと思っているから、結構強く言われたりすることもある訳です。

実際自分が本格的に農業をするかどうかはさておき、ちゃんと土について理解して、見聞きする事を少しぐらいは理解したいなと思い読んでみる事にしました。

第一章 土と土壌

考えた事も無いが、「土」と「土壌」は異なるものらしい。

「土」となると、単に岩石が風化したようなものも土と呼べる。よって、月面上にも土があると言えるらしい。

一方で「土壌」となると、生物によって作られ、生物の生育を支える事ができるというものになるらしい。

土と土壌のライフサイクル

これは結構驚きで、土・土壌のそれぞれにライフサイクルがある。

土は前述の通りで岩石が風化したり削られてできる。その前に岩石自体はマグマが地表で冷えてできたり、火山噴火したものが堆積してできたりするらしい。また、地震等で地殻変動し、隆起してくるケースもある。

地表に現れた岩石は崩落や雨水で削られたりで「土」になる。土はその後、雨や風で流されて低地に蓄積して後述するが「土壌」に変化する。

さらにその土壌もいずれ流亡したり老化し、再び堆積し岩石となって土ではなくなる。この周期が実に数百万年から数億年周期で起こっているらしい。なんというか途方も無い。。

土壌は土のなかに微生物が活動してくる事で植物生育に適する環境に変化していくことで土壌化していくようです。

土壌はそこに生育する植物や微生物によって、徐々に肥沃になっていくものの、数千年単位でその肥沃度は低下し老化していくらしい。

老化と一口にいっても、土壌の階層化、上層のミネラルの溶脱、鉄やアルミニウムの下層での蓄積と成分レベルでの変化のことを指すようです。

興味深かったのは、農耕地は化学肥料の施用で土壌が酸性化することで土地の荒廃が進みやすいとのこと。

酸性化すると、アルミニウムが活性化して作物の根の生育を害するとか、リン酸を作物に吸収されない形で固定化するとか、難しい事も書いてあった。。徐々に理解していきたい。

感想

自然土壌と畑や水田の土壌での土壌の変化は、「連作はダメ」とか「石灰をまいて中性にしないと」といった事の理解に繋がった。

「農業機械踏圧での土に耕盤が作られる」とか何言ってるのか分からないが、土壌は実に多くの要因で成立していて難しいという事がわかった。。先は長いぽいです。。

FabLife 対談1 と 2章の②まで

対談1

アムステルダムとボストンのファブラボの話しがメイン。

一章の内容以上にファブラボのコミュニティの側面が伝わってくる。アムステルダムでの世界ファブラボ会議での、いきなりレシピと材料を渡されてみんなでディナーを作る様子やコンペでボートを作ったり、なんでもありの会議の様子はすごく楽しそう。

その他だと、

  • 世界のファブラボのネットワークの繋がりの重要性
  • ファブラボは個性があるが、振り返ってみると運営している人の顔や人柄が思い出される
  • ファブラボは、個性、自発性、多様性に支えられたネットワークであることが魅力

とかが気になりました。

スペースや道具、直接の知識の共有は１つのファブラボでできるけど、それだけじゃなくて、世界中のファブラボと共有できる仕組みを思案しているらしい。

会社という組織にいても暗黙知だらけになるのに、世界の会ったことも無い人達との情報の共有に情熱を燃やせる事はすごいなーとか。もしかすると、ある程度距離感があった方がちゃんと共有とかするんだろうかとかリモートワーカーは思ったりする。

２章①②

MIT のなんでも作れるようになる授業は前から知っていて詳細知りたいなーと思ってたので読めて嬉しい。

  • 30 名のスキルも人種も年齢も違う人が集められ
  • とにかく How （どう作るか）を叩きこまれ
  • アイデアが新鮮なうちにとことん作らされる

ラピッドプロトタイピング

本には IDEO の例も乗っているが、最近は何かを作るにしても LEAN がなんだ、仮説検証のサイクルがなんだ、学びがなんだ、ピボットがなんだと、なんかちょっと個人的についていけてない。たぶん、（スタートアップにしろ違うにしろQCD を考える）経営者としての観点では、理にかなっているんだろうけど、個人的に性に合わない感じがずっとあったりした。

なんとなく、面白い事を思いついたら週末で荒くても全部作ってしまいたいのが昔からの性分なのだと思う。（だからコード汚いのだと思う）

アイデアが新鮮な間に、その期待感とともに「もの」に外化できることが重要だ というのは、すごくいいなーと感じた。

もちろんお仕事でもスパイクして見積もってーみたいなプロセスを踏む事もあるから似てるかもだけど、まあ、それが自分にとって期待感のあるアイデアかどうかだけみたいなものか。

でも最近ホント、わーと作る力が衰えてきて辛い。本にも書いてあるけどただただ勉強不足なのだ。

/dumped

FabLife 一章だけ読んだ

最後まで読んでからと思うと、だいたい時間空きすぎて忘れてるのでとりあえず一章で。。

一章はファブラボの歴史みたいなものと、世界各地のファブラボやそこでどういう事が行われているかが説明されています。

私のファブラボのイメージは、書籍にも出てきますが、鎌倉や渋谷にあるファブラボのイメージで（最近だと秋葉原の DMM のもそう呼べるのかな？）コワーキングスペースの延長みたいなもんかと思ってました。

でも、読んでみると全然違って、工房であり、学校であり、カルチャーセンターであり、遊び場でもある、そんな感じでした。ソフトウェアの話に置き換えるとハッカソンを年中やってるスペースがあるような感覚なんだろうか？

Make 系のイベントや場は（まだ東京に居た頃の） 2 年前の MAKER Fair Tokyo に行ったことしか無くて、あれはカンファレンスな感じだったので、たぶん全然空気感みたいなものを分かっていなかったんだと思うけど、それでも、そこで話している人や聞いている人もすごく楽しそうで羨ましさを感じたのを覚えている。（もちろん、ソフトウェア業界がそうではないとかではないけど、なんとなくです）

残ったキーワード

パーソナル・ファブリケーションとは、大量生産に向かう前の時代の精神を現代の眼でとらえ返し、いまの技術環境の上にアップデートしていくことでもあるのだ。この技術がときに「新しいようで懐かしい」といわれる理由は、おそらくそこにあるのだろう。過去を捨てて未来へ突き進んでいくのではなく、過去を未来へ繋げる手段なのだ

なんとなく「ラダック 懐かしい未来」を思い出した。

僕は山村に住んでいても、テクノロジーに頼って生きているし、ヒッピーのような生活がしたい訳でもない。それでも、手作りのものが好きだし、テクノロジーも自分たちに寄り添ってくれるレベルのものでなんとかできないかと思ったりする。 そういう事をいうと、「前時代的」「技術者なのに何を言ってるんだ」と言われそうだけども、少なくともパーソナル・ファブリケーションは技術を自分たちに取り戻そうとしている点ですごく共感できる。（とはいえ、MIT Media Lab でやっているような、未来ぽい取り組みはすごく好きなので激しく矛盾はしておりますが。）

「世界の周縁の人こそ、先端技術を真に必要としているのだ」（ニール・ガーシェンフェルド教授）

一昨年まで東京に住んでいて、今も東京と山村を行き来していたり、東京の仕事をしていたり、テクノロジーのニュースを見ていると、東京にコレ以上何が必要なんだろうと思うことがあったりなかったり。

とまあ、都会は都会ゆえに不便になる部分があったり、生活が過密になったりするので、そこを解消したり効率化したりというのはあるのは分かるので必要は必要なんだと思います。（実際、私も住んでてそう思いましたし）

私の住んでる山村なんて世界の周縁とは言えないですが、少なくとも日本の周縁ではあると思う。田舎はホント良くも悪くもいろんな前提が通じなくて、驚く程に 人 が有効に機能している。（逆に人が機能しないところは、かなり辛い）

また、いろんなものがコンパクトであるがゆえに、大型の機械や自動化がされていない部分がたくさんある。（人でやった方がコストが安いから） 加えて、土地によって条件が異なるため、カスタマイズ無しにしては辛いものがあったりする。

たまに地方の課題解決系のハッカソンみたいのを見かける。素晴らしい取り組みだと思うし、現地の人の話まで聞いて出てくるソリューションは有用なものになるかもしれないと思う。 ただ、最終的には、ファブラボのようなものが地域に根付き、高度にローカライズされて、最終的にはパーソナライズされる事で、役立つものが仕上がるのではないかと思ったりする。（そんな事はないかもしれない）

そして、そういう場所で利用されるのは実は東京から遅れたものではなく、先端技術なのではないかというのは、なんとなく感じる。

「ファブラボのクリエイティブな雰囲気をつくるのにいちばん大事なのは、いい音楽（Good Music）とおいしい料理（Free Food）だよ」（ファブラボ・アムステルダム アレックス）

まあ、均一に机が並べられたオフィスではないってことだけは分かる。

とは別に、ポートランドに旅行に行った時も、いろいろお店回ったり、現地のガイドの人にスタートアップの話を聞いて思ったのも似たようなことだった。（ポートランドはビールだったけど）

なんか自分も、せっかく山村の一戸建てをオフィスにして働いてるんだから、いい音楽と美味い飯の中で仕事すれば、もすこし楽しめるかなと思ったりした。（クリエイティビティが求められる仕事ではないけど。）

/dumped

Yosemite にした後に出た Ruby と Homebrew の問題の対処

たぶん Yosemite だけじゃなくて、他のセキュリティアップデートとかも絡んでたり自分のやり方の問題もあったと思う。

bundler が動かない

Ruby は 2.1.2 を rbenv 経由で使っていたのですが、急に Symbol not found: _SSLv2_client_method (LoadError) を含むエラーが出るようになりました。

事象、解決策ともに以下と同様で、インストールしなおしたら大丈夫でした。

ついでに恒例の therubyracer でハマる。。

なんか以前もこのサイトにお世話になった気がします。

置き換えまでしなくても、一時的に参照する先を変える方法も見たよという同僚情報があったことも付け加えておきます。

Homebrew が動かない

明らかに何の関係も無い気がしますが、なぜかついでに brew update で失敗してgit の変更が残ってる的なメッセージで絶望感を与えてくれました。

とりあえず、brew のディレクトリに移動して、変更を無しにしようとし git stash とか打ってみたら権限無いと怒られる始末。。

brew doctor 大事。。

結局は以下で大丈夫でした。

$ cd `brew --prefix`
$ sudo chgrp staff .
$ sudo chmod 775 .
$ git fetch origin
$ git reset origin/master --hard
# 上記の git の操作は git stash && git clean -f でもいいのかも

ぶつかった問題の記録を残してくれている先人に今日も感謝です。