読書の話
今，「フェルマーの最終定理」という文庫本を読んでいます． これは，「フェルマーの最終定理」が解かれるまでの歴史，紆余曲折について書かれている本です．
数学的に高度な話は出てきませんので，気軽に読めますが，数学の面白さについてはきっちり書かれています！．
社内向けの日記からネタを滉ってやろうかとお持ったんだけど．
それは最後の手段ということにして，明日はちゃんと書くよ！と表明して，今日は寝よう．
ワギャンランド！！！
今日は，懐かしい話をしようと思います．
皆様，ワギャンランドはご存知でしょうか？ そして，ワギャンランドのしりとりをご存知でしょうか？．
これは，画面に現れた幾つかの絵の読み方でしりとりをするというものです．
例えば，「家」の絵があったとします，でもこれは，「ひらやいっけんだて」とも読むことができます．
また．「くじら」の絵は，「まっこうくじら」と読めたりします．
こういう，「え，これこんなふうに読めんの？マジで！？」を駆使して，相手を追い詰めていくのがこの絵でしりとりをすることの 面白さであったりします．
この，ワギャンランドのしりとりが，iPhone アプリになりました！！
こちらになります！．
ref : https://itunes.apple.com/jp/app/wagyan-shiritoride-sheng-fuda!/id1085676559
ワギャンランドのしりとりで熱くなった人はぜひ！ぜひ！ぜひ！．
属人性とスループットの関係性
用語の定義から
スループットってなに？
wikipedia によると，
コンピュータの、単位時間あたりの処理能力を指す
のことだそうです．
今回の場合だと，
人の単位時間あたりの処理能力
ということになりそう．
属人性とは
ノウハウやスキルが人に属してしまうということ．だと思う．
属人性とスループットの関係性
属人性とスループットを独立した概念として扱いたい
属人性を下げるために，アウトプットの品質を下げて，誰でも理解できるような属人性の低い状態にするということを避けたい． そのために，個人の成長によって属人性を排除していきたい．
属人性を下げる必要があるのか
専門性と属人性
これらには，相互関係がある． 専門性が高ければ．属人性は高いし．専門性が低ければ属人性は低い．
社会や会社という大きさで物事をとらえた時．専門領域があることは必要だ． 誰もが，医者である必要はないし．誰もが上級エンジニアである必要もない．
また，期間の長短で見た時も同様のことが言える． 中世の人間と比較すれば．僕らは十分高度で専門的な医療知識を持っている．
期間の長短で見た時，短い期間であれば専門性が高くなり属人性が高くなることはしょうがない． しかし，ある一定水準以下の知識は，コモディ化され誰もができるようになっていることが望ましい．
専門性が高くなることへの対処
社会や会社という大きさで属人性・専門性をとらえた時，ある大きさ・ある期間に於いては専門性が高くなることは仕方ないと述べた． では，専門性を持たない愚かな我々はどのように専門領域に属する問題を解決すればよいのだろうか？．
専門領域のカプセル化
例えば，僕が病気になった時，診察を受ける． 同じように，何か専門領域に属する問題を解決しなければならない時には，専門家を利用すればよいだろう．
病院に行って診察をうけるためには一定のプロトコルがある． 同じようなプロトコルを専門家と愚者の間で整えて，相互にコミニュケーションを行えば良いように思う．
より身近な話にすれば，ある高度な問題を解決する方法をクラスやコマンドと言ったレベルで表現して，それを利用するための手順を 最小限のドキュメントで表現する，などということだと思う．
専門領域に属させる大きさと長さ
どのレベルの問題は専門領域だろうか，そして，どの程度の期間，専門領域においておいて良いだろうか？
小さなチームでは最低限持っていなければならない知識を，定めて，それを一定期間で更新していくことで， 属人性・専門性がある一定水準に抑えられる気がした．
結論
属人性と専門性は連動して上下する，専門性が高ければ属人性も高い． そして，必ずしも属人性を０にする必要はない．
また，属人性・専門性は時間が経てば，低くなる． ある一定の期間がすぎれば，コモディ化され誰でもできるような状態になる．
そこで，どの程度の期間や大きさの問題を専門領域に置くかが問題になる．
小さなチームでは，最低限持っていなければならないスキルセットを，一定期間で更新していくことで 属人性が高すぎもせず低過ぎもしない状態を維持できるのではないだろうか．
また，専門領域に属する問題を解決する人は，問題を解決するための何かが，それを専門にしない人間にも利用しやすいよう インタフェース・プロトコルを定めると良いのではないだろうか．
技術的な負債を返済するための挑戦の話
技術的負債を返済するために
今，僕が所属しているチームで，技術的な負債を返済していくために，最低限，必ず，毎週金曜日の一時間を当てることにしました． これは，僕がチームに配属されてから，技術的な負債についてまとめられているタスクボードからタスクが減らないことに危機感を感じたことがきっかけて，提案しました．
そして，抱えている技術的な負債のリストを洗い出し，幾つかの方法で分類し，とりかかるべきタスクを決定していきました．
その中で得た幾つかの知見・考えたこと，感じたことについてまとめていきたいと思います．
技術的な負債を効果と工数で分類する
まず，技術的な負債を効果・工数の２つで分類しました． 効果が高く，工数が低いものから順番に消化していこうという動機です．
しかし，残念ながら，この方法ではうまく行きませんでした． 後から考えると，当たり前なのですが，効果の高い側に付箋が集まりすぎて，分類があまり意味をなしませんでした．
重要でないタスクについては，そもそも提案すらされないということですね，当たり前っちゃあ当たり前です...．
ただ，工数の大小については，分類していくことができたため，更に．「効果」というものに対して考察を加え， 分類を繰り返しました．
効果とは何か
さて，改めて，「効果」とは何なのかについて考えてみましょう．
効果には複数あります．
- サービス非荷室に対する効果
- セキュリティに対する効果
- 生産性に対する効果
ぱっと思いつくだけでも，上記の事がリストできました． これ以外にでも，いくらでも思いつくことができるでしょう．
では，どの「効果」がよくなるタスクについて，最初に，とりかかるべきでしょうか？．
結論としては，「生産性」にフォーカスし，改善していくことにしました．
生産性とは？
さて，では，生産性とは何でしょうか？． 簡単に調べてみたところ，生産性とは
生産性=アウトプット/インプット
で，あるそうです． であるならば，インプットを減らすか，アウトプットを増やすかすればよいわけです．
インプットについては，おそらく，時間でしょう． アウトプットは，タスクごとにまちまちなように思います．
少なくとも，「何らかのインプットが減り，何らかのアウトプットが増える」改善に最初はフォーカスしよう．
結果，生産性を高めることで，余剰ができた時間で，その他の改善ができればよいのではないだろうか，こう考えて， 次に取り組むべき改善を見つけました．
まだまだ，この挑戦を行ってからの時間が浅いので，どのような効果があったかについては，未知です． いずれ，ある程度の結果が出たら，ここでまとめて報告をしたいと思います．
ErgoDox Ez のキーボード配列
最終的に，下記のキーボード配列に落ち着きました． 復帰戦なので，短めです．
* ,--------------------------------------------------. ,--------------------------------------------------. * | = | 1 | 2 | 3 | 4 | 5 | LEFT | | RIGHT| 6 | 7 | 8 | 9 | 0 | - | * |--------+------+------+------+------+-------------| |------+------+------+------+------+------+--------| * | TAB | Q | W | E | R | T | L1 | | L1 | Y | U | I | O | P | \ | * |--------+------+------+------+------+------| | | |------+------+------+------+------+--------| * | CTL | A | S | D | F | G |------| |------| H | J | K | L | ; | ' | * |--------+------+------+------+------+------| LGui | |Backsp|------+------+------+------+------+--------| * | LShift | Z | X | C | V | B | | |ace | N | M | , | . | / | RShift | * `--------+------+------+------+------+-------------' `-------------+------+------+------+------+--------' * |Grv/L1| '" |AltShf| App | LGui | | RGui | Alt | [ | ] | ~L1 | * `----------------------------------' `----------------------------------' * ,-------------. ,-------------. * | ESC | L2 | | L2 | ESC | * ,------|------|------| |------+--------+------. * | | | Home | | PgUp | | | * | Space| Tab |------| |------| Tab |Enter | * | | | End | | PgDn | | | * `--------------------' `----------------------'
ABC #36 の C について
今，僕が所属している会社では，「インフラエンジニアたちが Ruby を勉強する会」が毎週開催されています．
今回から，ABC(http://atcoder.jp/，この中で，beginner 向けのもの) を説いてきて，それらをレビューしてもらおう，という活動が始まりました．
今回は， ABC #36 がお題に挙げられていて，その中の，「座圧」の話をします．
この問題に，僕はドハマリして，2 ~ 3 時間ぐらいかかりました．
問題文としては，下記の URL のようになります．
ref : http://abc036.contest.atcoder.jp/tasks/abc036_c
まず，ハマった，難しかったポイントの一つ目です．
問題文の意味がわかりませんでした，日本語なのに． マジで．
なので，問題文が何を意味しているのかを把握する必要がありました． 不親切なことに(問題，なので当たり前ですが)，入出力例は一例しか与えられていません．
まず，この例が，問題文の条件をみたすことを確認しました．
そして，次に，同様の条件を満たすように適当な，値の列を幾つか作り，共通点を探しました．
この作業を繰り返すうち，どのような条件を満たす値の列を作成すればよいかが，把握でき，コードに落としこむことができました．
次に，この問題には，入力から出力までにかかる時間に制限が設けられていました．
これが，満たせませんでした.. .． 結局，配列の走査にかかる時間が問題でした．
配列の走査をする箇所を最小にし，利用できる箇所は Hash を利用することで，制限時間をクリアできました．
以上が，問題を解くまでの流れです．
この問題は，簡単 です．少なくとも，AtCoder はそう言ってます．
ですが，この簡単であるはずの問題も，僕はまともに解けませんでした．
しかし，解いてみた感想としては，このレベルの，あるいは，もう少し上の問題に対してなら訓練で対処できるかもしれない， ということです．
年々，頭も悪くなっています，集中力もなくなっています，でも，そのまま何もしなければ，そのままなのです． 意識高く頭を使っていきたいと思います．
がんばる．
このくらいの問題ならさっと解いてしまう，若者の存在が怖いよぅ．
