上司からの指示が気持ちよかった
今日上司からある指示を受けたのだが、それがとても気持ちよかった。決してそういう趣味が有るわけではない。しかし気持ちよかったのだ。何が気持ちよかったか、上司からの要求が整理されているからだ。
大体こんな順序だった（内容は結構変えている）。なんかこう、最小限の要素で物事を伝えている様に、美しさすら覚えた。
「機能の洗い出しをして欲しい。いまiOSにあってPCにない機能が多くなっていて、一度統制する必要がある。その洗い出したものをもとに機能の取捨選択を行う。ログイン前とログイン後、というカテゴリで洗い出してくれれば、それ以外のフォーマットは問わない。メンバーは〇〇とあなたで1/12までに行って欲しい。何か質問有りますか？」
それぞれが曖昧で無く、意味を持っている。私はこういう話し方がしたい。ダラダラ長い話をする人は苦手だ。自分もそうだから、会話や要求は疲れる。省エネがしたい。
それぞれがどういう意味を持っているのか？
先ほどの指示を要素ごとに書き出してみた。なんだかストーカーみたいな作業だが、決してそんな趣味はない。
・機能の洗い出しをして欲しい（要件）
して欲しい指示の要約
・いまiOSにあってPCにない機能が多くなっていて、一度統制する必要がある（理由/背景/目的）
問題になっていること、それをどうすれば解決されるか。
・その洗い出したものをもとに機能の取捨選択を行う（用途）
自分の成果物が、目的達成の為にどういう用途で使われるか
・ログイン前とログイン後、というカテゴリで洗い出してくれれば、それ以外のフォーマットは問わない（ポイント）
その作業をする上で絶対に外してはいけないポイント。ルール。
・メンバーは〇〇とあなたで1/12までに行って欲しい（メンバー・納期）
補足情報
・何か質問有りますか？（質問）
最後にお互いの認識の摺り合わせをする
それぞれがないとどうなるのか？
ある意味を考えたが、今度は無かったらどうなるか考えてみた。
要件がないとどうなる？
・そもそも何をすればいいかわからない。
・相手の解釈にブレが生じる
理由や背景・用途がないとどうなる？
・背景を共有されないため、全体を理解できない。
・原因がわからないと、その方法が適切かどうかという議論ができない
・そもそもやらされている感がでて、やる気がでない
ポイントがないとどうなる？
・各自がそれぞれの認識で仕事を行ってしまい、良い成果とならない
・そもそも正確な評価基準がない。
メンバーがないとどうなる？
・誰に相談すべきかわからない
納期がないとどうなる？
・問題の重要度が共有されていないため、後になって揉める
・スケジュールが立てにくい
質問がないとどうなる？
・意識の摺り合わせができない
・言われなかったから、そういう話が出なかったから、という感じで後になっても揉める
書き出して思ったが、当たり前だけど、いろんな角度から共有することが大事なんだなと思った。その大まかな要素が、要件、理由、用途、ポイント、メンバー、納期、質問みたい。もっと他にあるかもしれないけど、今日思ったのはそんなところ。
誠実な人って常に「自分は誠実じゃない」って思っている人だと思う
タイトルの通り。
よく「事故を起こさない人は、いつか自分は必ず事故を起こす、と常に自分を疑っている」と言われるがその原理と一緒だ。
本当に誠実なひとなんて存在しないんじゃないか
誠実とは
（ 名 ・形動 ） ［文］ ナリ
偽りがなく、まじめなこと。真心が感じられるさま。 ↔ 不誠実 「 －な人柄」 「 －な対応」［派生］ －さ （ 名 ）
・偽りがない
・真面目
・真心が感じられる
これらほとんどが相手からの視点だ。自分でコントロールできるとすれば、偽りがない位だが、偽りが無くとも相手が真心を感じなければ、それは誠実とは言えない。相手に依存するものである以上100%誠実でいることなど不可能だ。「僕は誠実だ」と抜かす人間はそいつを誠実だと思った数％以外の大多数の人間を認識すら出来ていない。今日誠実だった奴が明日誠実とは限らない。アイツに誠実だった奴がコイツに誠実とは限らない。
でも誠実な人間に近づけることは出来る
僕が思う誠実な人間は
・今の自分が出来ることを
・無理がない状態で
・100％他者に行える
人間だと思う。
そのためにいつも自分を疑っていないと、今本当に相手に出来ることなどみつからないと思う。無理がない状態で、と入れた理由は、自分が無理をする状況は誠実とは言えないような気がするからだ。度が過ぎるとそれは押し付けになってしまう。結局は物事はバランスなので一言では語れないのが常だ。しかし大事なのは「今の自分は本当に誠実か？」と疑うことだ。そうすることで誠実な人にはなれずとも、それに近づくことが出来ると思う。
ドキュメンタルという番組で松本人志が「世界一おもしろい人って面白くないんですよね」と言っていた。なんとなくそれに近くて、「他者の解釈に依存するものは自分でコントロールすることは不可能なのですが、それに近づけて行くことで自然とそうなっていくんじゃないですかね」ということでした。
まあ、一番言いたいのはドキュメンタルはとても面白いということです。
どうすれば深い議論ができるか考えた
仕事で何かを議論しているとき、どうも深い議論にならないことがよくある。「こういうお問合わせが来ているんだけど、なんで起きたんですかね？」などという話から、深まりがなく、沈黙が起きてしまうことが少なくなかった。
最初はそれに対する前提の知識が薄いからだと思っていた。確かにそれはあるかもしれないが、時間が経つに連れて、一番の原因は、問題をシンプルに纏める作業をしていなからだと思うようになった。
問題をシンプルにまとめるってなんだ
考えた。
問題がシンプルになっている状態とは？
・その問題の原因が分かる状態
・その解決策が明確になっている状態
・問題の概要を短く要約出来る状態
いろいろあるだろうが、悶々考えた結果
評価軸が明確である状態 ＝ シンプルな状態
だと思う。何をもってそれが良い、悪いとなるのか。それがどうなるかによって、結果がガラリと変わるもの。原因や解決策はその後の手段であり、概要は評価軸を決める為に必要なものだ。それを会話の中で行うことによって議論が深まるように感じる。
例えば、あるウェブサービスを運営していて、利用ユーザーからお問い合わせが来たとする
A「〜というお問合わせが来ていたようです」
B「原因は〜じゃないですかね？」
A「調べてみましょうか」
B「そうですね。もしそうだったら再発しないように〜しましょう」
これが普通の流れだと思う。しかし、この会話からは深みがないように感じる。それは原因を中心に話しているからだ。もちろん何か問題が起きていたら原因を調査し、解決しなくてはならないが、これではマイナスを０にしているだけで、将来的なプラスはない。
そこで評価軸を中心に話してみる
A「〜というお問合わせが来ていたようです」
B「原因は〜じゃないですかね？けどこれは修正するのに時間がかかりそうだ（人的コスト）」
A「けどこのお問合わせって〜の人にも迷惑がかかっていそうですね（ユーザーの満足度）」
B「それだと売上にも影響がありそうですね（直接的な売上）」
こんな感じで〜という評価軸だったらどうか、を挙げていく作業を行う。選択肢を洗い出していくイメージだ。ただそれだけだと逆に問題が複雑になるだけだ。
その中でじゃあ一番大事な評価軸ってなに？という話に移る。それはチームによりけりではあるが、これを（自分だけでも）意識して行うだけで、一つのお問合わせを修正しただけで、サービスのの理解が一層深まる議論が出来るはずだ。もちろん評価軸はどんどん変わってかまわないと思う。話せば話すほどブラッシュアップされるからだ。
上記の会話は例に過ぎないが（実際この3つに優先順位を付けるのは大変だ）実際に自分が考えたことであるので、ちゃんと自分で試していきたいと思う。
まずは声を大きくするところから始めよう。。。
「いつまでも幸せに暮らしましたとさ」とか物理的に無理でしょという話
佐伯だ。「です・ます」調と「である」調の使い分けに迷っている佐伯だ。
最近考えていることは、幸せでいることは普通に無理だということだ。
人間は誰しも幸せになりたい、と思っているはずだ。でも幸せってなんぞや。
宗教のような話になるのはよろしく無さそうなので、端的に
幸せ＝現状に価値を感じていること
と定義することにする。
例えば今の仕事、収入、住んでいる家、交友関係、恋人などそれぞれを総合して、それらに価値を感じている状態、と言えると思う。いい家に住んでいればそれはそれで幸せだろうし、収入も多いに越したことは無いし、綺麗な彼女なんかいれば最高だろう。
ただ、今回私が言いたいのは「それらは相対的に認識するもので、状態をささない」ということだ。大切なものは失ってから気づくとよく言われるが、まさにそういうことだ。認識の仕方は大きく２つ（過去に比べて）得たか失ったか、だ。
得た
・彼女が出来た
・何かを達成した
・何かを買った
・宝くじが当たった
etc
失った
・彼女に振られた
・お金を落とした
・失業した
・身近な人が亡くなった
etc
この得た、失ったという変化を感じているだけで、それを幸福、不幸だと読んでいるだけなのである。そんな当たり前のことを思ったのだが、それを踏まえ、幸せでありつづけることは不可能じゃん、と思うわけだ。だって自分の身の回りは常に変わり続けるのだから（宗教ではありません）。幸せを求めて自分の基準を上げる努力をすれば、少なからず幸せを感じることが出来るだろう。しかしその維持はとても困難で終わりがない。下がったときの不幸は計り知れない。
ここからは態度の話になるが、その中で僕が考えるよりよい態度が２つある。それが
・今、この状態を幸せだと思う
・そもそも幸せを求めない
である
今、この状態を幸せだと思う
変化を認識するのが幸せであるならば、それは些細な変化でもかまわないのではないか？という考え方である。要は感受性を上げることである。しかし自らの感受性を変化させることはとても困難だし、それまでは「今が幸せだ」と半強制的に思い込ませるということになりかねない。なんだかそれは人間的で無い気がする。
そもそも幸せにこだわらない
もはや悟りの境地である。自ら幸せになるような行動を行わず、変化に身を任せる態度である。幸せを求めず、不幸を嫌わない。良いことがあれば喜び、悪いことがあれば悲しむ、という受動できな態度である。
これらは決して相反するものではないと思う。
幸せを求めながら ＋ 今の状態に幸せを感じ ＋ 過度に幸せにこだわらない
などという複合的な態度も可能だし、それはそれで超人だ。
いずれにせよ、穏やかに生きれればいいよね、という話でした。
あれ？この話し宗教っぽい
現役プログラマーの僕が選んだ格好いいプログラミングTシャツ5選
佐伯です。好きな飲み物は水です。
プログラムを仕事で書くようになってもうすぐ一年。そろそろ歴代のプログラマが必ずしも通るある欲求が抑えられなくなってきました。
プログラマーっぽいTシャツ着て、コード書けるアピールしたい
あれ？みんな思わないですかね
こんなのとか
こんなのとか、シンプルでかっこいいじゃないですか
かっこいいじゃないですか（二度目）
ということで、個人的に欲しいシャツを挙げていきます。
それではどうぞ
１．バグじゃないです。仕様です。Tシャツ
生けとし生きる全てのエンジニアが欲しいであろうこのTシャツ。
これで責められることはありませんね。
２．それはバックエンドの問題ですTシャツ
クライアント側のエンジニアが安全に生活するために役立ちます。
私も欲しい。
３．万能になった気がするTシャツ
４．挫折しそうな僕を助けてくれそうなTシャツ
成功するまで続けよう、というニュアンスですね。日本語訳にいちいち味を感じます。
５．子供との意思疎通の為に
抱っこしているときは授乳しろ。そうでなければ遊べ。
肝に銘じます。子供居ないけど。
学問とドラマは最悪の組み合わせだと思う
どうも、佐伯です。
個人的にびっくりしたニュース。141 万部の大ベストセラー、アドラー心理学を解説した入門書【嫌われる勇気】が2017年1月のフジテレビ木曜劇場（木10）にて刑事ドラマとして放送されるらしいです。入門書が刑事ドラマです。なかなか新しい組み合わせですよね。むしろそこに勇気を感じます。
https://www.amazon.co.jp/exec/obidos/ASIN/4478025819/pp2203-22/
【嫌われる勇気】を半ページに要約するとこんな感じ
この本、僕の思い出の1冊でもありまして、今の自分に大きく影響を与えた本なんですね。ある哲学者と青年の対話形式で進んでいくもので、ざっくりまとめると「人は今この瞬間から幸せになれる。幸せとは、人に嫌われること（を恐れない自分の態度）だ」って感じです。誤解を招きそうな表現なので簡単にポイントを上げると
原因論ではなく、目的論を推奨する
原因論：過去が自分を決定づける
目的論：今の自分が過去に意味を付ける
過去の出来事によっていま自分が〜できない、という考え方では、事実として永遠に過去に縛られることになる。なので目的論に基づき、過去の出来事を自分を守る盾にせず、今の自分が何をするかに焦点を当てたほうがよいとする。
すべての悩みは人間関係
他者との比較やコミュニケーションの問題＝すなわち人間関係が悩みのもとであるということ。それを解決するために以下の3つで構成される人生のタスクという概念と向き合い続けることが大切
・仕事のタスク：仕事上の人間関係
・交友のタスク：友人との距離
・愛のタスク：恋愛、親子関係
対人関係のスタートは課題の分離
↑に向き合うため、対人関係の入り口として課題の分離という作業が必要。「自分の課題」と「相手の課題」を分けて、相手の課題には絶対に介入してはならない。
対人関係のゴールは共同体感覚
共同体感覚は以下の3つの概念で構成されている
・自己受容：今の自分をそのまま受け入れる
・他者信頼：無条件に相手を信じる
・他者貢献：他者や、共同体（社会などの集団？）に貢献すること
共同体感覚をもつこと＝幸福であるということ。
「私は誰かの役に立っている」という主観的な感覚こそが、貢献感（＝幸福）となる。
人生の嘘ってのがある
人生のタスクをから目をそらさせる外的要因を人生の嘘と呼ぶ
・他者の課題に介入しようとすること
・原因論
・承認欲求など
・嫌われることを恐れる
これらの嘘に惑わされず、今この瞬間を生きる（人生のタスクと向き合い続ける）勇気を持てば、事実上（定義のうえでは）今この瞬間から私たちは幸せになれる。
ものっそいざっくり書きましたが、幸せ、自由、人生っていう凄いふわふわしたバズワードを、ロジカルに言語化してくれた本は僕にとっては初めてで、内容的にも腹落ちできる本でした。一読の価値はあるとおもいます。おすすめ。
学問と物語は相容れないと思うんす
このドラマ化の話、知ったのは最近なのですが、知ったときからものすごくモヤモヤしてたんですね。最初は「好きな作品が実写化されたときのあの憂鬱な感じ」だと思ってたのですが、なんかそれとは近くとも何か違うことに気づきました。単純に表現方法としてドラマ（物語化）ってそぐわないと思うんですよ。
嫌われる勇気のもとになった「アドラー心理学」。名前の通り学問なんですよね。どの学問でもそうだと思うんですが、学問って終わりの無い歩みみたいなもんじゃないですか。
数々の人間が何百年もの間、議論と検証を重ね、こうすれば社会良くなんじゃね？という知恵を断片だけ抜き取って、「これでドラマがハッピーエンド（バッドエンド）になった〜」っていうのは、ちょっとあんまりだと思うんです。進研ゼミの漫画じゃねえんだし。
そんなこと言ってたら何も見れないよ〜って意見もわかるんですけどね。。。
やっぱり好きな本だからかな。銀魂ファンもこんな感じなんだろうか。
おわります。
Type ‘ViewController’ does not conform to protocol ‘UITableViewDataSource’のコンパイルエラーで必要なメソッドを入れたも関わらず改善されないとき
佐伯です。
UIPickerViewのコンパイルエラーの直し方のメモです
UITableViewDataSourceに必要なメソッドをコードに書いていても下のコンパイルエラーが出るときがあります。
Type "myViewController" does not conform to protocol UIPIckerDataSource
import UIKit
class myViewController: UIViewController, UITableViewDelegate, UITableViewDataSource {
var myUIPicker: UIPickerView!
var array = ["hoge1","hoge2","hoge3"]
override func viewDidLoad() {
super.viewDidLoad()
self.myUIPicker.delegate = self
self.myUIPicker.datasource = self
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
}
//datasourceに必要なメソッド
func numberOfComponentsInPickerView(pickerView: UIPickerView) -> Int {
return 1
}
func pickerView(pickerView: UIPickerView, numberOfRowsInComponent component: Int) -> Int {
return array.count
}
}
これは、必要なメソッドを書いていないよ、というエラーなのですね。
いや....
書いてるし？？？？？
Xcodeさん目ン玉無いんすか？？？？
ということですごく激情困惑していたのですが、下記リンクに答えが書いてありました。
Swift3から非推奨の書き方みたいです。
以下で通りました。
import UIKit
class myViewController: UIViewController, UITableViewDelegate, UITableViewDataSource {
var myUIPicker: UIPickerView!
var array = ["hoge1","hoge2","hoge3"]
override func viewDidLoad() {
super.viewDidLoad()
self.myUIPicker.delegate = self
self.myUIPicker.datasource = self
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
}
//datasourceに必要なメソッド（ココを修正！）
func numberOfComponents(in pickerView: UIPickerView) -> Int {
return 1
}
func pickerView(pickerView: UIPickerView, numberOfRowsInComponent component: Int) -> Int {
return array.count
}
}うまくいくはずなのに通らないときは、非推奨じゃないか疑おうと思いました。
