回避型愛着スタイル
はじめに
私は
- 共感能力に低い
- 他人に共感されることを避ける
- 「共感されたい」という欲求を過小評価する
性質があります。 世の中では、これを「回避型愛着スタイル」と言うようです。 エンジニアにはこのタイプが多いように思います。
今わかっている範囲の情報を書きます。
愛着障害
精神医学の分野には「愛着障害」という障害があります。 他人との「愛着」を安定して築けないため社会生活に困難がでる障害です。
○○型愛着スタイル
「自閉症」や「発達障害」と同じく軽い人もいれば重い人もいます。 軽い人は一見社会生活に全く支障がない人もいます。 そういう人に「○○障害」とつけるのは引っかかるので、ここでは「○○型愛着スタイル」と表現します。
原因
発生する原因は、両親(育成者)との間に「愛着」を上手く築けないから起きるようです。 わかりやすい例は幼い時の親との死別や、一定期間預けられていた場合などです。 他にも親の愛着スタイルが安定していない場合も起きるようです。
不安定型、回避型
大別して不安定型と回避型の二種類があります。
不安定型は十分な愛着が得られなかったために、愛着を過剰に求めたり、愛着を失うことを過剰に恐れます。 回避型は十分な愛着が得られなかったために、愛着を求めることをやめてしまいます。
不安型はラオウ、回避型はサウザーと思えばわかりやすいと思います。
共感
共感されたい
回避型愛着スタイルの人は「共感されたい」という欲求を過小評価します。 これは、以前から自覚がありました。
ずいぶん昔の話ですが、当時お付き合いしていた女性から「相手をしてほしい」アプローチをされたときに逃げ回っていました。 逃げると、相手からの「相手をしてほしい」アプローチが強化され、辟易して破綻しました。
当時の実感としては「めんどうくさい」でした。 今思うと、「相手をしてほしい」感情に共感できていなかったのだと思います。 さらに共感したように振舞うこともできず、どう反応してよいのかわからず戸惑っていたように思います。
共感できない
「相手をしてほしい」感情に共感できないのは、「自分の考えや感情が共感されるわけがない」と思っているからです。 「回避型愛着スタイル」の人が考える、共感される予想確率は限りなく低いです。 例えれば「空から女の子が降ってくる」確率と同レベルです。 このため、「共感されない」不満は「自分のところには空から女の子が降ってこない」不満と同レベルに思えます。 最初から失敗しかないチャレンジに失敗して、何が不満なのかが理解できません。
社会生活
共感能力の低さは、社会生活に影響が出ます。学生時代はあまり上手くいかなかったように思います。 共感できないため、ウェイウェイ出来ません。 ウェイウェイ出来きない人間がスクールカーストの上位に入ることはないので、中学高校は暗黒時代です。 ウェイウェイしなくてもよい仲間が見つかると楽しく生活できます。
社会人になると、社会生活への影響は少ないです。 会議であれば、論理的な説明さえできれば成り立ちます。 飲みニケーションなどで共感を求められることもありますが、拒絶さえしなければ、共感しないからといって迫害されることはありません。
共感能力が低くて、嫌われることもありませんが、特別好かれることもありません。 いわゆる人望に欠けます。ポジションによっては不利になるかもしれません。
個人的な対応
私は外見上は、実際どう見られているのかはわかりませんが、人の感情が読み取れないようには見えないと思います。 せいぜい愛想がないぐらいではないでしょうか?
共感能力がある人がどうやって人の感情を感じているかはわかりません。 私の場合は、心理学のように感情の原因を推測して理解しています。 たくさん本を読んだせいか、脳内にある人間の感情の原因リストは長いです。 そのうちで、現在の状況に一番近いものをパターンマッチして推測しています。
これは有利な面と不利な面があります。 誰かが怒っている時に、「口で言っている怒りの原因と真の原因が違いそうだ」と推測ができることがあります。 問題解決には有効です。 一方で、怒っている人は「とにかく怒っている感情を受け止めてほしい」と思っているようですが、 これに対しては「受け止める is 何?」となります。
おかげさまで対面でのコミュニケーションより、文章でのコミュニケーションの方が得意になりました。
治療?
治療が必要な性質のなのかはわかりませんが、共感能力を育てることはできるようです。
共感能力が低いといってもゼロではありません。 まれに共感出来ることがあるようです。 また「共感された」経験が少ないため、「共感されたい」という欲求を過小評価します。これは他人に共感することを放棄する原因になっています。
自分が他人に「共感する」「共感される」体験を繰り返すことで、共感能力を育てることはできるようです。 *1
典型的な例
1年前に ledsun.hatenablog.com で「生きる技法」を読んだと書きました。
いまの知識で思えば、著者の安冨さんは「強迫性パーソナリティ」でかつ「回避型愛着スタイル」でした。 「回避型愛着スタイル」の人間が感情を論理的に解釈しないと理解できない好例だと思います。
参考文献
愛着障害の克服 「愛着アプローチ」で、人は変われる
愛着障害一般の話です。愛着障害の不安型と回避型を両方取り扱った本です。 過去の文豪や心理学の大家の愛着障害の例がふんだんに載っています。
回避性愛着障害 絆が稀薄な人たち
上の本と同一著者です。回避性愛着障害に焦点を当てています。 回避性愛着障害をいくつかのタイプにわけて説明しています。 心理学の人には回避性愛着障害の人が多いようです。 共感能力の低い回避性愛着障害の人は、心理を論理で整理せずには居られないのかもしれません。
異性の心を上手に透視する方法
恋愛をテーマに、回避型愛着スタイルの男性と不安型愛着スタイルの女性がくっつきやすく、かつ上手く行きにくい理由が書いてあります。過去の経験がもろに該当していました。自分以外でも、該当する組み合わせは見かけるので、自分が当てはまるかもしれない人は読んでおくと心の準備ができて良いかもしれません。
タイトルは半分ぐらい詐欺です。特定の組み合わせのカップルが、お互いと心が全く噛み合わない理由を説明しています。
*1:世の中にはもっと良い方法があるでしょう。確実なことは専門家に聞きましょう。
サービス開発チームの拡大期におけるリーダーのレスポンシビリティ移譲に関する1アイデア
開発組織に関するポエムです。
背景
常駐や請負で、サービス開発チームのお手伝いをしたことがあります。 私に依頼がくる時は、サービスは売れていて、開発チームは拡大期にあります。 その時、開発者の人数は増えているが、開発リーダーの負荷は減らず、逆に増え続けるという現象を観測したことがあります。 過去に2件、目撃しました。
課題
開発リーダーはすべての「問い合わせ」と「機能拡張の意思決定」に参加する必要があります。 おまけに自分の実装タスクも持っています。 必然的に労働時間は伸び、「いつ寝てんだこの人?」という働き方をしています。
はたから見ていると、何年も続けられる働き方はないので、いつか破綻しそうな危機感があります。 実際、2件のうち1件の開発リーダーは退職しました。
果たして、我々はこの状況に対して何かできるでしょうか?
経験談
開発メンバーの視点
開発メンバーからはリーダーが大変なことはわかります。 ただ、どんな問題を抱えているのかはわかりません。 この立場でできることは
- 要件を一度でなるべく細く聞き取る
- リファクタリングを避けてレビュー工数を減らす
- 修正点を最小にしてレビュー工数を減らす
などでした。このためには、受け入れるタスクを小さくする必要があります。 タスクが大きいと、リーダーとの相談量が増え、リーダーへの割り込み量が増えます。
アウトプットが少ないと評価されるのを覚悟で、手戻りにリーダーを巻き込まない強い心が必要です。 実際は、これができる人とやっている人は、とても少ないように思います。
開発リーダーの視点
今年の9月から11月に掛けて、炎上プロジェクトのリーダーをやりました。 立場は違いますが、共通する点もあるかもしれません。
炎上中のリーダーは手を止めることができません。 次のいずれをやめても、プロジェクトの進捗止まります。
- 各機能の仕様や実装方針の意思決定
- ボトルネックになる機能の実装
- 進捗の把握
- 顧客への進捗の報告とスケジュール調整
特に困るのがタスクを切り出す作業です。 タスクとして切り出したものは、開発メンバーにお願いできます。 問題をどのように解決するか、考えタスクに落とす部分は一番負荷が高いです。 一方で、それまでの経緯などコンテキストへの理解が必要であり、簡単に移譲はできない部分です。
また、プロジェクトの遅れに責任を感じているリーダーから、「プロジェクトを一度停止して体制の修正をしたい」とは言い出しづらいです。
方法の一つとして、リソースプランナー役の人に入ってもらって
- 進捗の把握
- 顧客への進捗の報告
を巻き取ってもらうと、だいぶ楽になります。 経験するまでリソースプランナーは要らない役職だと思っていました。 実際はすごく頼りになります。 ただし、感覚としては20%ぐらい楽になるぐらいです。 すでに120%以上の稼働に達している場合は、それほど効果がありません。
問題
- 開発メンバーからはリーダーの本質的な課題が見えない
- 開発リーダーは作業を止めることができない
開発チームからボトムアップで状況を改善することは難しそうです。
アイデア
ワイガヤやったらいいのではないかな?と思います。
この手のコミュニケーションのミスマッチは、「サービスに対する熱意の差」みたいな誤解に基づいている気がします。
- リーダーは、俺がこんなに頑張っているのにメンバーのやる気が足りない
- メンバーは、俺も頑張りたいのに、どう頑張ればリーダーの役に立つのかわからない
熱意とかやる気は、見た目に差があっても内部的に差があるかはわかりません。 一方で、サービスに対する興味のある点や価値観は、開発メンバー全員が違うはずです。 今のフェーズに、たまたま価値観が合っている人が「熱意がある」ように見えているだけではないでしょうか?
そんなわけでワイガヤです。 サービスの開発を数日止めて、 二泊三日の合宿でサービスに対する思いを表明しあってはどうでしょうか?
- 次の施作案
- 既存の気にくわない点
- 俺の感じるかっこよさにマッチする点、マッチしない点
- どんなユーザーに使わせたいか
色々なアイデアがあると思うので、決めるためでなくて、「みんな、そんなこと考えてたのかよ!」と思うための会をとことんやるといいのではないかな?と考えました。
参考:「ホンダ流ワイガヤ」実践のコツと方法を、元ホンダ 本間 日義氏にインタビュー |ビジネス+IT
実践したことはないので、与太話です。
うまくいけば
すくなくとも開発リーダーの気持ち面で時間は稼げそうです。 その隙に、「雑用タスク何でもできるマン」*1を投入して、開発リーダーの持っているタスクまで落ちていない作業をタスク化。 チーム内に振りまいていけばなんとかなるでしょう。 開発リーダーの稼働が80%ぐらいまで落ちれば、もともと優秀な人ですから、あとは自分で改善できるはずです。
*1:例えば、私。ただ、目に見えるアウトプットは、通常の開発者とは違うので、そういうjob descriptionの元でないと怖くてできません。
MacBook Proの代替えWindows PC調査状況報告
背景
- MacBook Proが望まない方向に進化している
- いっそのことWindows PCの方が良いのではないか?
要件
- US配列キーボード
- 16GB以上のメモリ
- 256GB以上のSSD
- 通勤時に利用できるノートPC
結論
の二択
候補
- VAIO Z
- Surface Book
- Panasonic レッツノート
- NEC LAVIE
- ASUS ZENBOOK
- 先代Macbook Pro
ゲーミングPCは調べていません。
VAIO Z
全ての条件がクリアできる唯一の日本製PC
Surface Book
Microsoftの誇る最強のWindows PC。日本ではUS配列キーボード モデルが発売されていません。
Intel Core i7 + 16GBメモリ + 512GB SSD + GPU で¥345,384(税込)は勇気がいる価格です。
Panasonic レッツノート
Japanが誇るノートPCブランド。光学ドライブなしモデルはメモリが8GBまでしか積めません。
US配列キーボードは選べません。
NEC LAVIE
軽さに定評のあるLAVIEシリーズ。メモリが8GBまでしか積めません
US配列キーボードは選べません。
ASUS ZENBOOK
ZENBOOKシリーズ | ノートパソコン | ASUS 日本
メモリが8GBしか積めません。US配列キーボードは選べません。
テキストより複雑な構造のデータを扱うWikipediaを作る
モチベーション
専門性を持った不特定多数のユーザに協力してもらい、個人では作り得ない大規模なデータベースを作りたいことがあります。
例えば、Wikipediaは、(記述の正確性や公平性における問題は抱えているかもしれませんが)規模の点で成功しています。
Wikipediaのエディタはオンライン百科事典のエディタとして特化しています。百科事典ではないデータを扱うデータベースの場合、Wikipediaのエディタは機能が合いません。
必要なもの
複雑な構造のデータを扱うたデータベースを作るには何が必要でしょうか?
ブラウザ上で動くビジュアルエディタが必要です。
なぜでしょうか?
インストール不要
インストール不要なため、編集環境を構築するコストが低いです。 編集用のアプリケーションをダウンロードして、個人のPCにインストールするのはボランティアで参加してもらうにはコストが高いです。
エディタの学習コストが低い
編集内容をビジュアルで表現すれば、エディタの操作が直感的になり、操作方法の学習コストが下がります。
データを直接編集する学習コストは高いです。 例えばDBPediaの情報を編集するには、DBPediaのデータフォーマットに関する専門知識が必要です。
つまり
ブラウザで動作するビジュアルエディタを提供することで、不特定多数のユーザーが編集に参加しやすくなります。
先行例
一般消費者向けのアプリケーションも作られるようになりました。
どうやって作ればいいのか?
技術要素は、2005年に公開された、Google Map変わっていません。
- HTML
- CSS
- JavaScript
ただし、10年間で各要素はそれぞれ高度化しました。 一つのビジュアルエディタのJavaScriptファイルが数千行に達することは珍しくありません。
難しさ
複雑なソフトウェアを、要件に合わせて適切に設計・実装できる、ソフトウェア開発技術者が必要です。
ビジュアルエディタの場合は、次に挙げる難しさがあります。
- わかりやすい操作方法の設計
- 選択状態の管理
- 編集途中状態の管理
- UNDO/REDO機能
- データの依存関係に応じた編集
- パフォーマンス
- テスト
わかりやすい操作方法の設計
わかりやすい操作方法は、編集したいデータ形式や、想定するユーザーによって変わります。
一般的な指針はあります。例えば、
- 編集の敷居を下げるには、ヘルプを参照せずに、マウスまたはタップ操作のみで編集を完了できると良い
- PCに慣れたユーザーはキーボードショートカットがあると便利に感じる
- ショートカットは世の中の既存のエディタと共通の方が良い
しかし、独自のデータを扱うアプリケーションを作る場合は、アプリケーション毎に試行錯誤が必要な部分は残ります。
選択状態の管理
「マウスまたはタップ操作のみで編集が完了」するには、編集対象のオブジェクトを選択する必要があります。 選択できない場合は、idや座標で編集対象のオブジェクトを指定して編集します。
オブジェクトが選択できると
- 選択している時だけ編集可能にする(切り取りボタンを有効にするなど)
- 編集機能やエディタの状態によって選択可能/不可能を切り替える
必要があります。
複数のオブジェクトが選択可能な場合は
- 複数選択の操作方法の設計(例えばCtrl押しながら、Shiftを押しながら)
- 編集機能やエディタの状態によって複数選択可能/不可能を切り替える
- 異なる種類のオブジェクトを選択した場合の動作の設計
が必要です。
オブジェクト生成時に自動選択
オブジェクトの生成後に自動選択したい場合があります。その場合、
- データ上のオブジェクト作成
- DOM上のオブジェクト作成
- データ上のオブジェクト選択
- DOM上のオブジェクト選択
の順序を制御する必要があります。 VIrtualDOMで表現できないビューを扱う場合は、モデルの操作とビューの操作が交互に行うため、原始的なMVCでは監視コントローラーパターンが使えません。 監視コントローラーパターンを使うには、MVPパターンを導入し、選択状態の管理をコントローラーから分離します。
編集途中状態の管理
エディタでは編集途中状態を扱います。
たとえば、テキストエディタは編集した文章を保存せずに終了することができます。 エディタを閉じる際に次の動作をしたいことがあります。
- 未保存データがある旨の警告表示
- 自動保存
- 下書き状態として保存
ブラウザのonbeforeunloadを使って、これらの動作を実装します。
UNDO/REDO機能
エディタはUNDO/REDO機能があると便利になります。
VirtualDOMを使っている場合など、ビューがデータの射影として表現できれば、データのスナップショットをとっておくことで実現できます。
次の要件がある場合
- メモリの消費を減らしたい
- ビューの更新ロジックが複雑
データ操作を一度コマンドオブジェクトとして生成し、履歴として保存しておく必要があります。 各コマンドで
- UNDOの実行
- REDOコマンドの生成
ができれば、UNDO/REDOは実装可能です。
データの依存関係に応じた編集
データ構造によってはデータの依存関係があります。
例えば、ツリー構造の場合は親データを削除した時には子データも削除します。 ビューをDOMのツリー構造として構築していれば、データの親オブジェクトとDOMの親要素を消すことを対応付けることができます。
UNDOがある場合は、親オブジェクトが削除する時は、削除前に持っていた子を保存する必要があります。 UNDO時には保存情報から親オブジェクトと子オブジェクトを両方復元します。
パフォーマンス
DOM操作のパフォーマンスを出すには独特のテクニックが必要です。
DOMへの要素追加のタイミングを気をつける他に、リフローと呼ばれる現象を防ぐ必要があります。
DOM要素の「幅、高さ、位置」を取る場合、ブラウザは描画内容を再計算します。 DOM要素の「幅、高さ、位置」取得と、「幅、高さ、位置」設定を個別に繰り返すと、ブラウザの再描画計算が大量に実行されパフォーマンス低下を招きます。 これとリフローと呼びます。
参照したい全DOM要素の「幅、高さ、位置」取得をまとめて行い。 「幅、高さ、位置」設定をまとめて行うと、リフローが防げます。
テスト
ビジュアルエディタの機能では見た目が重要です。 テストをする際にも見た目の確認が大きなウェイトを占めます。 機能を満たしても、使いにくかったり、使い方が直感的にわからなかったりすれば、要求は満たせません。
一般的な、業務アプリケーションの業務ロジックのテストとは異なるアプローチが必要です。 人間が手と目を使って繰り返しテストすることが、非常に有効です。 テストケースの作成とテスト実施には、忍者式テストというテスト手法が有効です。
実績
作成したビジュアルエディタです。
1on1ミーティングのやり方
1on1ミーティングに備えるアンケート - しるろぐ を読みました。 大変参考になりました。お礼の代わりに、弊社のやり方を書きます。
前提条件
弊社は20人以下のSIerです。 受託開発や技術支援がメインです、プロダクトを中心とした面談ではありません。
インタビュワーとインタビュイーの組み合わせはプロジェクトに閉じていません。 総当たりで組み合わせています。
面談をはじめたのは退職者対策としてでした*1。 インタビュワーの負担が個人に偏らないように、ベテランエンジニアが全員インタビュワーになります。
やり方
人数
インタビュワーは6人います。ベテランエンジニア5人と営業1人です。
インタビュイーは8人います。 1年目は毎月、それ以外のエンジニアは2ヶ月に一回実施指定います。
組み合わせ
もっとも長い期間面談をしていない組み合わせで実施します。
組み合わせは、モンテカルロ法で抽出します。 そのために GitHub - ledsun/interview-lottery: The lottery for interview を作りました。
その他
弊社には遠隔地の拠点があります。 Skype等のビデオ会議で面接を行います。
面談の議事録はインタビュワー間で共有します。
質問内容
面談を円滑に進めるために聞く内容のテンプレートを作ってあります。
- 最近うまくいっていること(やっていること)
- うまくいっていないこと
- (仕事をやりやすくするために)ほしいもの
- 個人のビジョン(どうなりたいか?)
KPTを元にしています。
「うまくいっていること」は言いづらいことが多いようです。その場合は、「やっていること」を聞いています。
「ほしいもの」はTeam Geekからパクリました。
「個人のビジョン」は「時々、(自分の)中長期的な将来のことも考えてみてね」ぐらいのノリで聞いています*2。
実施方法
各インタビュワーに任せています。統一した方法等はありません*3。
個人的には、ほぼKPTです。 インタビュイーに聞いた内容をホワイトボードに書きながら、質問を掘ったり、各項目を関連付けたりして進めます。
若手のエンジニアはメタ認知*4が苦手なので、KPTを一緒にやるとそれなりに効果があると思います。
お互いの負担を減らすために30分という時間制限を設けています。 個人的にはインタビュイーに話したいことがある限り延長しています。 最大で2時間半ぐらいでした*5。
やってよかったこと
会社ハックのきっかけに
個人的に一番面白いのは、会社の仕組みをハックするきっかけが得られる点です。 社内の制度に関する質問をもらえると、仕組みを整理するきっかけになります。
ビジョンの時間変化
「個人のビジョン(どうなりたいか?)」に対する答えが、時間とともにに変わることがわかりました。 こまめに面談をしていないと、一年前に聞いたビジョンに今でも同じように興味があると考えてしまいがちです。 経験を重ねるにつれて興味のある分野が変わるのは、ふつうのことだと思います。
若手の成長を実感
ビジョンの変化と一緒です。 課題と思うことや、興味のあることが変化しているのを通して、若手の成長が実感できるのはうれしいです。
やってわるかったこと
エースエンジニアの時間が取られることです。 人によって得意不得意があります。面談が不得意なエンジニアがインタビューするのは負担が大きいようです。
主観でプログラミング言語7種類をあっさり解説
k16's note: 主観でプログラミング言語5種類をあっさり解説を読みました。 なるほど、そういうのもあるのか。
個人的に馴染みがあるプログラミング言語を7つ解説します。
JavaScript
ブラウザで実行できるので、動作を確認しやすい点が良いです。
圧倒的なライブラリ数です。
一方で、動作環境が多すぎます。
- ブラウザ
- Node.js
動作環境によって使用可能な文法、APIが違います。 参考資料が、どの環境を対象としているのか、判別するのに苦しむかもしれません。
C#
強力なIDE、Visual Studioがある点が良いです。 Visual Studio Communityは無料で使えます。
一つの言語で、いろいろなアプリケーションが作れるのが魅力です。
- Windowsアプリケーション
- Webアプリケーション
- コンソールアプリケーション
C# によるプログラミング入門 | ++C++; // 未確認飛行 Cという強力解説サイトがあるのも心強いです。
開発にWindowsが必要なのが、少し悪い点です。 やろうと思えば、Visual Studio Codeを使って、MacやLinuxでも開発可能です。
Ruby
Rubyコミュニティが日本にあることが良い点です。 会いに行ける言語の実装者です。
言語仕様やライブラリ仕様が複雑です。ハードルがちょっと高いです。
VBScript
Windowsでの作業を自動化することができます。
大抵のWindowsに最初から入っています。追加アプリケーションが必要ありません。 他人のPCで動かすスクリプトを作るときに、インストール済みのアプリケーションを気にしなくて済みます。
言語仕様が独特です。他の言語と知識を共有できなく辛いかもしれません。
シェルスクリプト
LinuxやUnixでのコマンドライン作業を自動化するのがとても簡単です。 基本的にはコマンドを並べるだけです。
関数を使ったりループを回したり、ちょっと複雑なことをしようとすると、シェルによって文法が変わるのが難点です。
Java
クラスベースオブジェクト指向を知るのに最適です。 オブジェクト指向における再利用のためのデザインパターンをマスターしたいときにおすすめです。
Androidアプリの開発にも使えるらしいです。
C
スタックとポインタを意識してプログラミングしたいときにおすすめです。 実行速度が速い点も良いです。
コンパイラと実行環境によって言語仕様が変わるのが気難しい点です。 gccとVisual Studioでは使える文法が変わります。 OSによって使えるAPIが変わります。
日本でアジャイルが流行らない理由
ポジション的なもの
個人的に、アジャイルは「(あんまり未来や遠くのことを考えるのをやめて)目の前にある問題を解決しよう」という思想と認識しています。
現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは? と、思います。
キーワード「エンタープライズ」が出てきているので、業務システムの話をします。
情けないぞアジャイルコーチ
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。
サム・グッケンハイマーの一言
の方が
「ウォータフォールは一切メリットがないので止めておきなさい」
といったそうです。まあ、ポジショントーク。 マイクロソフトは、これから日本で、Azureを使ったDevOpsを売りたいですよね?
自分の本当の心の中
統計を見ても、2015年のVersion One のサーベイを見るとワールドワイドで95%の企業がアジャイルを導入しているが、日本だと、同年のPMIの統計によると 31%が導入済みに過ぎず、明らかに遅れをとっている
うしおさんがMicrosoftの中の人である以上、ポジショントークとして扱うのが良いと思います。特に、この画像にde:codeのロゴ入っているのが、ひっかかります。
マイクロソフトの面接での出来事
彼は面接の最初にちょっとびっくりした声で私に聞いた Tsuyoshi、日本でアジャイル導入があまり進んでないって本当か?
DevOpsを売るに当たって、前提として「アジャイルが流行っていない」のどうしようか?みたいな、状況でしょうか? エンタープライズ向けに売ろうと思うと、由々しき事態だと思います。 上司の方の危機感の認識は日本市場に合っているのではないでしょうか?
最近ソフトウェアに詳しいアメリカの女性と話した時にウォータフォールの話をしたら「まだ日本ではウォータフォールなんてやってるの!そんなの誰もやってないよ!」と本当に驚いていた
なるほどー、そうなのかもしれません。 人類に達成可能である証拠なので、アジャイルを導入したい、自分にとっては朗報です。
ウォータフォールは起源から異なっていた
ウォータフォールの起源はどのようなものか?というと、Winston.W.Royceが書いた MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS という論文が起源になっている
私も、そうだと思っていました。久しぶりに見直した日本語のWikipediaに・・・
初めて「ウォーターフォール」という用語を用いたのはT.E.BellとT.A.Thayerによる1976年に発表された論文「Software Requirement」であり、B.W.Boehamが1981年に出版した本「Software Engineering Economics」においてウォーターフォールモデルのオリジナルはRoyceだと述べ、ウォーターフォール・モデルの起源がRoyceであるという誤解を広めた。
まじかよ!本日、最大の驚き!!
ウォータフォールを前提とするのが本当に日本のためだろうか?
1日に10回も100回も本番にデプロイできるようなオートメーションがなされたり、データセンターレベルで抽象化が進んで自動回復を行えるまでの環境が出来てる。Infrastrucute as Codeの対応をしている2200台のサーバーのセキュリティパッチをたった一人が15分で当て終わるような時代だ
1日に10回、本番デプロイする必要がある、業務には、どういう業務を想定されているのでしょうか? 個人的には思いつきません。
個人的な経験では 「1日待ってもいいから、ちゃんとテストして、バグで毎日の業務が止まらないことを保証してから、リリースしてください。」 と要望されることが多いです。
1日に10回、本番デプロイできる環境では、業務システムを使って業務を行う方たちも
- バグったらシステム管理者に連絡
- 再リリースまで休憩
な、やり方に慣れるのでしょうか? 米国に、そういう事例があるのであれば、是非知りたいです。
開発する立場としては、「とりあえず勘で直してリリースした。直ったかどうか、確認して」と言えたら、とても気楽だなと、思います。 正しいやり方かはわかりませんが、緊急回避手段が増えるのはありがたいことです。
自分の恥ずかしい体験談 私はインターナショナルでは無価値である
彼らは日本では体験できないほどアジャイルについて深く理解しており、私があげたどの想定課題も既に体験・解決済みだった。例えば、受け入れテスト駆動開発の話題を振っても彼らはそれを導入した時の事、発生した課題、どう解決したか?みたいな話をしてくれた
これは、うしおさん個人が、アジャイルな現場での開発技術についていけていない話な気がします。 現場で手を動かすのをやめるのが早すぎたのではないでしょうか?
アジャイルコーチのジョークに「もう何年もプログラムを書いていない」みたいな話があった記憶があります。 そのイメージです。元ネタを失念しました。
最も深刻なことは、「経験」を積めないこと
2003年の時点の私の経験は、米国でも価値のあるものだったと思う。では日本で経験を積んだ私が無価値になってしまった
は
私は外資系、できれば海外に住むことをターゲットに仕事を探していた
という目的に対しては、残念とは思います。
だけど、あなたの積んだ「経験」は、絶対に他人が詰んだ経験とは異なります。 異なる経験は異なる状況では価値があります。普遍的に無価値ではありえません。
「自分の経験は無駄だった」はただの思い込みです。無駄なのでやめましょう。
日本はソフトウェア開発の後進国
ChefのAlexが日本のソフトウェア業界が8年遅れだと言っていた。Samは5年遅れだと言っていた
これは間違いないです。日本人のGithubのリポジトリをWatchしたことがありません。 本場で自分の力を試してみたい人は行けばいいと思います。 個人的には食の面で、移住には魅力を感じません。
海の近くで魚介が美味しくて、山の近くで水が美味しいと、食べ物は美味しいです。 シリコンバレーは割と食べ物がおいしいかもしれません。
自分が目指すビジョン
私のここ数年のビジョンは、日本と米国の技術やプロセスの導入スピードを同じにすることだ
なぜでしょう?
Samの野郎に、「日本は今や米国と同じスピードで遷移している」と言わしめたい
遅れていると言われるのが嫌だからでしょうか?
うーんと・・・「ファッションアジャイル野郎が!」と言ってみたいですね(汗
エバンジェリストに期待すること
「遅れている」や「遅れがもっと広がる」という、脅しは必要はありません。 FUDは嫌いです。
を伝えて欲しいです。
事例さえあげてもらえれば、あとは我々SIerが発注者に売りこみます。
日本でアジャイルが流行らない理由
個人の考えです。
- 予算確保にシステムの仕様が必要
- システムの発注が請負契約
- 発注企業のシステム担当者が、一つのシステムに専任していない
- 発注企業のシステム担当者が、コンピューターサイエンスの知識を持っていない
- 発注企業の業務担当者が、システム開発に専任していない
予算確保にシステムの仕様が必要
95%の会社がアジャイル開発やっているなら、これ教えて下さい。本当に。 システム開発を始める際に、会社内でプロジェクトの期間と目的と予算は決めているはずです。
どういう風にプロジェクトを初めて、どういうときに中止するのか。 リスク管理のやり方が真似できれは、日本の企業もアジャイルな発注ができるはずです。
公共案件の予算管理にも適用できると、大手SIerもアジャイルに移行できるのではないでしょうか?
システムの発注が請負契約
よく言われます。これは分割納品にすれば割と回避できます。
ただし、最終納品では揉めることがあります。 発注時の仕様と違うものを納品するには、発注会社のシステム担当者が社内を説得する必要があります。 できなかった場合に、納品のためのごちゃごちゃした作業が必要になります。 プロジェクトは炎上します。
社内を説得できる人は、とっくに「アジャイルのようなこと」をやっています。
「予算確保にシステムの仕様が必要」と同根です。 発注会社(のシステム担当者の上司)はアジャイルなプロジェクト管理をする方法がわからないのです。 開発側の技術や環境の問題ではありません。
発注企業のシステム担当者が、一つのシステムに専任していない
アジャイルなプロジェクトで1週間に1回リリースすると、発注企業のシステム担当者の時間が足りなくなります。 毎周、検収して次の週のストーリーを考えるのは無理です。
これは、発注企業のシステム担当者が、一つのシステムに専任していないからです。 他の業務に追われています。
この状況では「1日に10回本番デプロイ」魅力にはなりません。 DevOpsを使いこなすためには、発注企業は、システム開発の費用にシステム担当者の人件費をもっと増やす必要があります。
検証環境に「1日に10回本番デプロイ」できると、ソフトウェア開発者にとっては便利です。 手で受け入れ試験を回せるので、システムの理解が捗ります。
発注企業のシステム担当者が、コンピューターサイエンスの知識を持っていない
- ディスクは遅くて、ネットワークはもっと遅くて、メモリはちょっぱや
- 1万レコードは問題ない。10万レコードはちょっとおもい。100万レコードは重い。1億レコードは色々頑張らないと無理
みたいな感覚を持っていてもらえると、コスト感が通じやすくて嬉しいです。愚痴です。
端から見ていると、業務システムのプロダクトマネージャーは、とても難しい仕事に思えます。
- 商売の理解。システムをどう活用すればもっと儲かるのか
- 業務の理解。どういうシステムなら業務がまわるのか
- コンピュータサイエンスの理解。どういうシステムなら低いコストで作れるのか
すべての知識を持ったプロダクトマネージャーは、非常に稀有に思えます。 数千万円程度の投資をして、外部から登用するか、社内で育てる必要があるように思えます。
それで商売上の価値があるのかは、私にはわかりません。
発注企業の業務担当者が、システム開発に専任していない
日本では当たり前です。業務担当者は、
- 開発初期のインタビュー
- 開発終盤の受け入れ試験での確認
ぐらいに参加。システムが稼働し始めてから、本格的に使って混乱します。 慣れてくると、本当の要望が出てきます*1。
米国では、「業務設計担当者とアジャイルに開発して、現場の人はマニュアルにしたがって操作するだけ」なのでしょうか? 気になるところです。
「システムを段階的に導入して、現場の業務担当者のフィードバックを生かして、システムを育てていきたい」 と、常々思います。 受託開発では、納品後はシステムはソフトウェア開発者の手を離れます。 「現場の業務担当者のフィードバック」を受ける機会はあまりありません*2。
とてか04に参加しました #toteka
椎葉さんの発表がぐっときた
すごかった。 「失敗したチームメンバーがいた時に、笑ったらいかんよ」と説明すると言っていました。 「そこまでやるのか。やると意味があるのは想像できるけど、自分ではできない」という意味ですごかったです。
懇親会で聞いてみました。
実際の説明はもう少し丁寧に「悪気がなくても、思っているのとは違う伝わりかたをするので気をつけてね」 とするそうです。
なんでそこまでやるのか? 「自分が抜けた後も、走る続けられるチームを作りたい」からだそうです。 自分とは立場が違うので無理して真似る必要はなさそうです。
(「チョットデキル人に訊け!」の話題と関係しています。)
track8さんの発表が面白かった
想像できない使用環境に起因するバグをどうやって想像すればよいのか?という話でした。 純粋に楽しめました。
「チョットデキル人に訊け!」が興味深い
「すごいなー」と思ってどうするの?
勉強会ですごい人の話を聞いて「すごいなー」と思ったときにどうすればよいのか、というご相談。
チョットデキル人の回答は忘れちゃいました。 その後自分で考えたことを...
自分が真似できない理由は8割が「自分がその問題に直面していないから」の気がします。 能力が足りていないのは2割ぐらい。
自分の「忍者式テスト」体験を振り返ります。
- 10年ほど前に「忍者式テストすげー」と思った。そのときは品質保証の手段だと思っていた
- 5年ほど前に、真似してみたがうまくいかなかった。このときは人力テストハーネスとして使っていた。が、テスト量のコントロールとテストのアップデートができていなかった
- 2年前に「忍者式テスト」を上手くできた。開発者がテストしたので、集中できないほどのテストはやらなかった。つまらないテストもやらなかった。
10年近く真似できなかった、一番の原因は「忍者式テストで解決したい問題」を扱っていなかったからでした。
(その間にリファクタリング力が上がったのも多少は関係していると思います。)
というわけで、「すごい人のすごい技」はそのうち使えるシチュエーションにぶつかるので、心のメモ帳に書いておけばOKです。 使えるシチュエーションにぶつかっていないのに、真似するのは
ハンマーを持つ人には、すべてが釘に見える。 (アブラハム・マズロー)
です。気をつけます。
テストがうまくなりたい
「テストが上手くなりたいモチベーション」が、チョットデキル人が三人とも違って面白かったです。
秋山さん:
プログラマーの頃は上手くなりたいとは思っていなかった。テストを専門にやるようになって、よりチームに貢献するために上手くなりたくなった。
関さん:
上手くなりたいなんて思ったことはない。必要だからやっている。
関さんの、仕事とプライベートをきっちり分けて、仕事に対しては、かっこよさやファッションを持ち込まずに、ひたすらプラグマティックに振る舞うのがすごいです。
和田さん:
最強のプログラマーになりたいので、テストも上手くなりたい。
和田さんはさすがの厨二力です。感嘆しました。 和田さんは、相手のレベルに合わせて、誤魔化しなしの正しい説明をリアルタイムでするのが、すごいです。
モカ・マタリ・アールマッカ
モカ・マタリ・アールマッカというブランドのコーヒー豆を調べたメモ
モカとは
イエメン産とエチオピア産のコーヒーをモカと呼びます。 モカの名称は港の名前に由来します。
モカ とは、イエメンの首都サナアの外港であるモカからかつてコーヒー豆が多く積み出されたことに由来する、コーヒー豆の収穫産地を指すブランド
モカの港からは、イエメン産のコーヒー豆の他、対岸のエチオピア産の豆も一緒に輸出されたため、両国産のコーヒー豆を合わせて「モカ」と呼んでいる
モカ港
今はモカ港からコーヒーは出荷されていません。
現在、コーヒー豆集散地の機能は無く
豆の特徴
モカ香と酸味が特徴のようです。
モカ香: イエメン、エチオピアのコーヒーのみが有する独特の香りです。ヨーロッパではワインフレーバーと表現されますが、少し違う、と感じながら的確な表現が見つかりません。
味: 柔らかい酸味が特徴。深めに焙煎しても柔らかい口当たりの苦味になります。
生豆の品質はあまりよく良く無いようです。焙煎者の手間(ハンドピック)によるところが大きそうです。
外見: 粒(小粒のものが多い)と色が不揃いで、高級品でも欠点豆が多数混入し、一言で言えば貧相なコーヒーです。
モカ・マタリとは
モカの中でも、モカ・マタリは耳なじみが良いです。コーヒールンバの歌詞に登場したためのようです。
「コーヒールンバ」に唄われていたためか、日本でも人気が高い
それは素敵な飲みもの コーヒー モカマタリ
産地
イエメンのバニーマタル地方で生産された豆をモカマタリと呼びます。
イエメンのベニーマタール地区で産出される最高級銘柄
イエメン国内でも、昔から最も優良なコーヒーを産出する地方
アラビア語で「バニー」は「子孫」、「マタル」は「雨」を意味します。 直訳すると「雨の子孫達」となり、名前からも雨に恵まれた地方であることが想像できると思います
「モカ・マタリ」は、本来、このバニー・マタル地方で採れたコーヒー豆のことだけをいいます
「モカ港から輸出されるバニー・マタル」の「マタル」が名詞化して「マタリ」となり、「モカ・マタリ」と呼ばれるようになった
豆の特徴
モカ香がなく、フルーティな酸味とスパイシー香が特徴のようです。
味は、甘みが特に豊かで、フルーティーな酸味があり、柔らかく、下にまとわりつくような脂肪感があります。香りは若草の爽やかな香り(特にニュー・クロップが強い)や色々なスパイシー香があり、一般にいわれているモカ臭はありません
「醗酵層の歴史が独特の酸味を産む」伝説があります。
モカマタリ独特のフルーティな香りと,甘酸っぱい味わいの秘密は収穫から珈 琲豆に加工される工程で,醗酵層に入れられるところで発生するようです。
イエメンのばあいはアラビカ種であっ ても自然体で天日乾燥(アン・ウォッシュト)され,脱穀機で乾いた果肉部分が削ぎ落 とされます。 果肉の下にはパーチメントという薄くて堅い皮があって,それを剥ぐ手段として醗 酵層に入れられパーチメントが醗酵によって柔らかくなるまで待ちます。 柔らかく名った時点で取り出され,精米機のように豆同士で擦り泡さてパーチメント と豆の表面にこびり付いているシルバースキン(銀皮)という薄皮が剥がされ珈琲豆と いう製品になる
イエメンでは醗酵層が100年前の状態のまま使 われているので,永年積もり積もった発酵菌が繁殖して独特の香りを付けるのだという 報告を聞きました。あのモカマタリの独特の甘酸っぱい香りと味わいは,醗酵層100年の歴史なんです
モカ・マタリ・アールマッカとは
欠点豆のおおいモカの中では選別が厳しく、扱いやすい豆が揃っているそうです。
現地で豆の大きさの大きいものだけを手作業で選別した極上豆をアールマッカと呼びます
イエメンで最新式のイタリア製選別機を所有する輸出業者が、原料の買い付け後、標高2700メーターの清涼な気候の丘陵地帯で保管と選別を丁寧に行っています
10月から2月にかけての収穫期に、3~4回程度、完熟チェリーのみを手摘みで収穫しています。そののち、各家庭の屋根で1週間ほど天日乾燥。そのチェリーはエリアごとの集売・脱穀業者に買い取られ、それを輸出業者が買い取ります。アールマッカを供給している輸出業者は買い取ったチェリーを最新の選別機でしっかり精選
商品のご案内|自家焙煎珈琲豆の製造直売・通販・卸「みずむら珈琲」
マタリの最高級品の一つとして流通している。イエメンの特徴的な短形の豆で、粒もかなり揃っていて、欠点豆も少ない。酸味も綺麗で味の濁りもなく、モカとしては扱い易い優れたコーヒー。ボディは強いが、なぜかモカ香は弱い。あまり徹底したハンドピックはしない方が良いかも
価格
焙煎後で、100g 660〜850円で流通しています。
中間業者を中抜きすると受発注者はWin-Winになるか? 事例:クラウドワークス
結論
中間業者を中抜きは不可能。よりよい中間業者による代替えを目指そう
事例:クラウドワークス
にて、受注者側から見たクラウドワークスの問題点が挙げられています。
クラウドワークスは発注者のためのサイト
クラウドワークスとは、そもそもエンジニアの為に作られたサイトじゃなく、むしろクライアント(発注者)がエンジニアを安く買い叩くためのサービスに過ぎなかった
また
発注する側の手数料は一切かからず、仕事を請けた人間のみが手数料を徴収されるというシステムも印象が良くない。「クラウドワークスが発注者の為のサービス」だと言われる所以
中間業者中抜きへの期待
クラウドワークスにおいては、クライアント(発注者)とエンジニアは直結する。現実世界では、クライアント(発注者)とエンジニアの間に、仲介会社やエージェントなど「余計なもの」が入る。それなら、現実世界ではピンハネされている分だけ、エンジニアの取り分が増えても良さそう
よくある期待です。自分も意味がありそうに思います。
先人の失敗
絵や音楽
プロのクリエイターが、Gumroadで直接取引したときは、既存の流通業者を挟むより値段が安くなりました。
1回目は初速がすごかったけど。2番目のは今日(アップロード当日の2月21日)の夕方までに16人。前のは57人。2枚合わせて、トータルで108ドルくらい。 とりあえず9000円くらいは儲かったよ
トップクラスのプロイラストレーターでこれです。
伝統工芸
伝統工芸でも起きました。こちらはどこで読んだか覚えていません。
問屋を飛ばした結果
- 受注が安定しない
- 安い仕事も受ける
- 高い仕事も単価が下がる
という話だったと記憶しています。
価格維持力が失われる
実際には期待に反し、価格維持力が失われています。 なぜでしょうか?
中間業者が必要な構造
クラウドワークスの価格低下構造
クラウドワークスでの、価格下げ圧は
- 受注側:新規参入者が技術力が低い分安く受ける
- 発注側:新規参入は価格と品質のバランスがわかりません。価格で受注者を比較して安い受注者を選ぶ
が考えられます。 この結果、(平均した)案件価格は下がります。
受注者は増える
受注者が少ない市場では案件価格があがるため、新規参入者が増えます。 労働市場は常に受注者が過多になる圧力があります。
受注者が極端に多い市場になると、案件価格が下がります。
価格下げ圧が強すぎると市場は縮小
価格下げ圧が強すぎると、安さを見込んで新規参入の発注者が増えます。 取引される案件の優良率が下がり、経験のある受注者がいなくなります。
まさに
割に合う案件がない
経験のある受注者がいなくなってしまうと、発注者は安く発注できても納品されないリスクを負います。 リスクの高い発注は本業には使えません。 お遊びや片手間の案件なら使えます。 案件の価格は下がります。
案件の平均価格が下がれば、市場は小さくなります。
中間業者の機能1 参入障壁(受注者のフィルタリング)
受注者が増える圧力を止める必要があります。 そこで、中間業者を挟んで受注者を一定以上のスキルにフィルタリングします。
これは同時に価格の維持にもつながります。 受発注者が直接つながるよりwin-winになります。
中間業者の機能2 案件のバッファリング
データフローが安定化のために queue を必要とする、みたいな話なんだろうと思うけど、グラフのノードでしかない個々のプレイヤーに俯瞰的な視点を持てと言っても難しいしねぇ。 https://t.co/dDQt9oOcHV
— Yuta Okamoto (@okapies) 2016年2月27日
伝統工芸など、市場規模が成長しない場合は、発注の波を受注者が吸収するのは厳しいです。 中間業者による発注のバッファリングが必要です。
クラウドワークスさまへのご提案
クラウドワークスさまが、受発注者を幸せにするために必要なこと
- 受注者を精査して技術が低すぎる人をフィルタ
また、質の良い受注者を集めるため
- 発注内容を精査して価格が低すぎる案件をフィルタ
しかし、この作業は案件が増えると、必要な労働力が増えます。スケールしません。
前々からクラウドソーシングの会社が自身の仕事をクラウドソーシングするようにしたところで、方針決定するような仕事は残るはずで、「ここはクラウドソーシングしてもうまく行きません!」みたいなメッセージを出してくれたら労働の付加価値の再考になるしおもしろと思って期待してる。
— 渋川よしき (@shibu_jp) 2016年2月27日
そうだ、クラウドソーシングで外注しよう!(笑
参考リンク
人はなぜ憎しみを抱くのか
要約
なぜ憎しみを抱くのか
- 幼少期は親が居なくては生きていけない
- 自分の感情と親の意向が矛盾することがある(お腹が空いて泣くvsうるさい)
- 生きるために親の意向を尊重する
- 親の意向と矛盾する自身の感情を良くないものとして認識する
- 感情豊かな人を見ると、自身の感情を思い出す。抑えられなくなる
- 憎む
なぜ親は子を憎しみを抱くように育てるのか
- 社会のルールや規律を守ることが子供のためと信じている
- 子供の感情を直視して相手できない時がある(子を愛する能力に欠けている時がある)
- 信じる価値観や、それを守る良い親像を作るために「お前のためだ」と理由付けする
(権威主義的な親に育てられた)憎しみを抱いた子はどうなるか?
なぜドイツではナチスが支持を得たのか
- 権威主義的な教育(シュレーバー教育)がドイツで流行った
- 多くの子が憎しみを抱くように育てられた
- (無意識に)憎しみを共有できる人が増えた
- 憎しみを肯定する(攻撃の理由付けをする)強いリーダーが求められた
シュレーバー教育は、本書に記載なし。以下を参照してください。
19世紀末、徹底的に子供をしつけるというシュレーバー教育がドイツで流行していた
感想
精神分析学一般の話として読むとピンときませんでした。 ドイツでナチスが流行った理由の分析として読むと興味深いです。
著者のアルノ・グリューンはドイツ生まれのユダヤ人です。 ナチス時代のドイツに住み、迫害を避けデンマーク経由でアメリカに亡命しました。 ドイツを蔑んで(旧東ドイツでの極右団体による外国人排斥活動など)、アメリカを持ち上げる傾向があります*1。
訳者の方が心理学または精神分析学の人でなく、文学の方です。「自分の中の他人」や「親からのテロ」などの訳語が、心理学または精神分析学方面としてふさわしいのかよくわりません。個人的にはわかりにくいと感じました。
単著に見えますが、インタビューをまとめた本です。 体系化されているわけではないので、論理としてはわかりにく点があります。
そもそも古い本です。「権威主義的な教育を受け傷ついた青年が、オイディプスコンプレックスを解消するために、極右活動に参加する」というのは、少しステレオタイプな感じを受けます。 現代の精神分析学でどのような解釈をされているのか気になるところです。
経緯
「生きる技法」の参考文献
本当は「才能のある子のドラマ」を読もうと思ったのですが、その時あまり良い出品がなかったためこっちにしました。
「生きる技法」を読んだ理由
何年も前に羽生田栄一さんが串田幸江さんにオススメしているのを見て、アマゾンのWishlistに入れていました。 誕生日にもらったので読んでみました。
*1:アメリカにも、差別的な活動をする人は、それなりにいそうなものです
日本Kindle化計画 その3
バックエンドサービスの選び方
日本Kindle化計画ではストレージにRedisを使っています。 公開するために、どのサービスのRedisを使うか決めたいと思います。
なぜRedisか?
以下の理由で、Redisを選択しました。
- セットとハッシュぐらいのデータ構造で十分
- 今の所1KB程度使っている。100倍使っても大したデータ量にはならない
Redisのホスティングサービス
無料の一つ上のプランの価格で選びました。
予算見積もり
日本Kindle化計画の予定する収入源はAmazonアフィリエイトです。
大きな収入は見込めません。 無料で始められ、仮に負荷が増えた場合もなるべく安いランニングコストで解決できるサービスがほしいです。
サービス本体はHerokuで動かす予定です。Heroku add-onも調査に含めています。
Redis To Go
老舗
- $7/月 Redis To Go
- $5/月(Heroku add-on版)Redis To Go - Add-ons - Heroku Elements
Redis Labs
知名度No.1
- $6〜7/月 Redis Labs Enterprise Cluster, Redis Cloud & Memcached Cloud Pricing
- $10/月(Heroku add-on版はなぜか高い) Redis Cloud - Add-ons - Heroku Elements
Heroku Redis
Herokuの公式add-on
15$/月 Heroku Redis - Add-ons - Heroku Elements
Amazon Elasticache
AWSで使うなら
$18/月
選んだサービス
Herokuで使うならRedis To Goが良さそうです。
東京Node学園祭2015に参加しました #nodefest
本編短評
Node Discussionがめっちゃくちゃ面白かった
- @domenicさんはbabelが好きじゃない*1。moduleはもっと好きじゃない*2
- Node.jsにES6 moduleサポートが入る目処は立っていない。そもそも仕様が決まっていない。
- power-assertはNode.jsのコアに入らない。コアのassertはNode.js自身のテスト用という位置付け。Node.jsは標準ライブラリを持たない方針なので、標準ライブラリにも入らない。
講演
- Paypalでは800人のNode.jsエンジニアが働いている(!)。NASAでも使われている!!
- npm preversion/postversion便利そう!
- @kosamariさんがクソかっこよかった!Node学園祭は女性の発表が毎年パワフル
- 来年のNode学園祭にはDouglas Crockfordさんが来るかも!?(Paypalの中の日本人が交渉してくれるらしい)
懇親会で
@t_wadaさんに聞いた情報
babel6が結構、大変らしいです。
プラグイン機構が変わりすぎてプラグインの対応に11月中ぐらいは時間が掛かりそう。 それが終わっても、プラグインの実行順序を定義する方法がないので、プラグイン間で衝突が起きそうらしいです。
power-assertなどを使っているbabelユーザーの人は、しばらく5のまま様子を見た方が良いのかもしれません。
二次会で
@fossamagnaさんに聞いた情報
最近Node.jsを始めたそうなので「コールバックなAPIはどう?」と聞いたら 「マルチスレッドの設計するよりはマシ」的な回答をいただきました。
なるほど、言われてみれば、スレッド間のシーケンス設計は面倒臭かった思い出があります。 それに比べればコールバックヘルは面倒くさいだけなので良いのかもしれません。
@rvaggさんに聞いた情報
正確には会長(@yosuke_furukawaさん)に通訳してもらって聞いた情報です。
Node.jsにコントリビュートするにはFLAKYテストの修正が取り込まれやすいそうです。 FLAKYテストというのは、成功したり失敗したりするテストのことです。 どのテストが対象かは、下をのURLを見るとわかる
- https://github.com/nodejs/node/blob/master/test/sequential/sequential.status
- https://github.com/nodejs/node/blob/master/test/parallel/parallel.status
よっしゃ、コントリビュートのチャンスや!
帰り道
Podcastを確認したら、本当にNodeUp: A Node.js Podcastから@dshawさんの声が聞こえました。 @dshawさんの英語は文末が跳ねるから、聞き取りやすいです。 それでも聞き取れませんが。
飛び込みLT
めちゃくちゃ受けなかったけど、顔とアカウントが一致していない人に話しかけてもらうきっかけになったので良かったです。 こういう道具は常に用意しておくのが良さそうです。
道具としてのプログラミング、目的としてのプログラミング
プログラミングの学習曲線
Ruby on Railsはプログラミングではない! | それでも人は夢を見るの話です。 Ruby on Railsの有料講習を受けたが、受講前にイメージしていたプログラミングと、受講後の自信の能力のギャップに驚いている方の話です。
これは学習曲線の問題な気がします。
自分がプログラミングの勉強を始めた頃の話です。 入門書を読みながら、Perlをぽちぽち入力して掲示板CGI動かしてみました。 ですが、その次にどうすれば、イメージしているプログラミングに近づけるのかわかりませんでした。(その時は)挫折しました。多分、元記事の方も同じような状態なのだと思います。
一つの課題をクリアしたものの、次に何をすれば理想のプログラマに近づけるのかわからず戸惑っているのではないでしょうか?
プログラミングで世界を変えるということ
その後、自分がどうやってこの壁を越え、プログラミングを道具と認識したのかを振り返ってみます。
大学の授業や新人研修でのプログラミングの勉強はしました。課題を解くことはできました。それでも、コンソールに表示するプログラミングと、世間に溢れている(当時は今ほど無いけど)WEBやGUIのプログラミングが遠すぎて、やはりプログラミングが何かよくわかりませんでした。 結局、仕事で3000行ぐらいのプログラム書いたときに、やっとプログラミングが何かわかった気がします。
何が本質的な課題なのでしょうか? あるいは量でしょう。基本的な文法に悩まなくなった時に、プログラミングで解決したい課題に悩むことができます。
おそらく、もっとも重要なことは
現実に存在する課題を解決するプログラミングを書くこと
でしょう。練習問題を解いても、世界は変わりません。現実の課題を解くと、世界をプログラミングでちょこっとだけ変えることができます。
世界を変えることは、小さな変更を繰り返すことです。
職業プログラマのすすめ
プログラマとして就職すると、絶えることなく「解決すべき現実の課題」を提供してもらえます。 しかも、プログラミングスキルに合った規模に分割して「ここだけ書いて」と教えてくれるので、ハードルがぐっと下がります。
ある若者は、自分で書いたプログラムを、実際に使って喜んでいる人を目の当たりにして、プログラミングに対する意欲がガラリと変わりました。これは「自分がプログラミングで世界を変えたこと」を実感したからではないでしょか?先輩技術者と一緒に、現実の課題を解決するのはおすすめです。
他人の課題を解決するのに飽きたら、自分で好きな課題を見つけて解決すればいいのです。それはもしかすると、世界を大きく変えるかもしれません。
Ruby on Railsの複雑度が問題?
Railsはプログラミングでは無いのか | サークルアラウンド株式会社ではRailsの抽象度の問題と解釈してSinatraをすすめています。
なるほどSinatraの方が少し簡単ですし、過去にSinatraの方が簡単なのにと愚痴ったこともあります。 Railsは覚えることが多いので「プログラミング初心者には大変だなぁ、Sinatraの方がまだ良いなぁ」とは思います*1。
また、課題を取り組みながら仕組みを、わかりやすく説明してもらえれば、Ruby on Railsの使い方だけでなく、Webアプリケーションの仕組みやデータベースを使う意義などを理解できるかもしれません。
それでも、言われた通りにプログラミングするのと、現実の課題を解決する道具としてプログラミングするのはちょっと違うような気がします。
プログラミング研修の限界
研修課題には解決できない(かもしれない)問題は出せません。また、現実の課題をプログラミングで解決可能な形に解釈するには、独特のコツが要ります*2。
現実の課題を解決する形でプログラミングを学んでいくコースを、2ヶ月18万円で提供するのはちょっと難しそうです。
一ヶ月90万を半年間払っていただければやります。人によっては60万円ぐらいでやってくれるかもしれません。 ただし、ゴールは対象者の資質によって大きく変わりそうです、保証できません。 こういう条件で申し込んでくる人はいなさそうですね。 そんなわけで、ビジネスとしては成り立ちません。
まとめ
プログラミングで世界を変える最短経路は
- 職業訓練と割り切ってRuby on Railsの勉強をする*3
- プログラマとして就職する
- お仕事としてプログラミングする
- インターネット世界の構成要素を知る
- 世界を変える
以上です。身も蓋もありません! プログラミングを楽しんでね!