検索

そもそも何なのかがよく分からなかった。iSCSIを実現してくれるようだが・・・
http://ja.wikipedia.org/wiki/ISCSI

以下の記事を読んでみたところ、多分、iSCSIとしてのサーバ（という表現で合ってるのかも分かんないけど）を、AWS側でAMIとして用意してくれていて、それでEC2インスタンスを立ち上げれば、IPアドレス指定でAWS EC2上からも、あるいはインターネット上からも、それをiSCSIのディスクとしてマウントできるようになる。らしい。

で、もう一つポイントなのは、バックアップディスク用途を主に想定しているため、上記のAWSが作りこんだAMIイメージでは、S3へのバックアップ機能が組み込まれている点。細かい仕様は調べてないので分からないが、ともかくこれにより、オンプレミス環境からもWWWまたはVPN経由などで、S3ベースの耐障害性を活かしたバックアップストレージをiSCSIとして利用できるようになる、というのがメリットらしい。

AWS提供のマシンイメージは、EC2以外にもVMware用のとかあるらしいので、オンプレミス環境のESXiとかに展開すれば、そこから直接S3にバックアップ、みたいな方式になるらしい。もちろん、S3への通信は暗号化可能。

• AWS Storage Gatewayでできること、使いどころのポイント （1/2）：CodeZine
  • http://codezine.jp/article/detail/7782
• AWS Storage Gateway入門 – とりあえず構築してみよう ｜ Developers.IO
  • http://dev.classmethod.jp/cloud/aws/storage-gateway-introduction/
• Storage Gatewayを設置する « サーバーワークス エンジニアブログ
  • http://blog.serverworks.co.jp/tech/2012/05/16/storagegateway-setup/
• Amazon Web Services ブログ: 【AWS発表】 AWS Storage Gatewayを使って仮想テープライブラリを作成しよう!
  • http://aws.typepad.com/aws_japan/2013/11/create-a-virtual-tape-library-using-the-aws-storage-gateway.html
• AWS上で使えるストレージ十番勝負
  • http://www.slideshare.net/c95029/aws-20829943

時々見かけるんだけど、どうやるのか・・・。

• S3のアクセスコントロールまとめ - Qiita
  • http://qiita.com/ryo0301/items/791c0a666feeea0a704c
• S3のアクセスコントロールが多すぎて訳が解らないので整理してみる ｜ Developers.IO
  • http://dev.classmethod.jp/cloud/aws/s3-acl-wakewakame/

ACL関連じゃなさそう。どうも、署名付きURLとかいうのらしい。

• AWS - S3 の事前署名付き（期限付き）URL を生成する - Qiita
  • http://qiita.com/inokappa/items/dc3ef8b564c7d1f63be2
• [AWS]S3の期限付きURLを生成する[node] ｜ Developers.IO
  • http://dev.classmethod.jp/cloud/aws/node-pre-signed-url/
• Amazon S3でアクセス指定かつ期限付きURLの生成 - 雑記帳(2012-01-24)
  • http://muramasa64.fprog.org/diary/?date=20120124
• S3 Presigned URL を使ってみる - funasaki memo
  • http://funasaki.hatenablog.com/entry/2012/11/20/134623

"事前"署名付きURLというらしい。S3のマニュアル見てると、何箇所かで説明されてた。

• 他ユーザーとのオブジェクトの共有 - Amazon Simple Storage Service
  • http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/ShareObjectPreSignedURL.html
• 署名付き URL を使用したオブジェクトのアップロード - Amazon Simple Storage Service
  • http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/PresignedUrlUploadObject.html
• REST リクエストの署名と認証 - Amazon Simple Storage Service
  • http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/RESTAuthentication.html

なるほどなー。

2014年末は慌ただしかったので年明けてから、ざっくりとまとめ。

• PythonとRubyの実行環境のセットアップについて復習したりした。
  • どちらも仕事で使うことになったので。
  • Rubyは、ぶっちゃけSencha Cmdで使うためだけに勉強した。
• JAX-RSをJersey使って勉強して、仕事で使うようになった。
• ExtJS勉強して、仕事で使うようになった。
  • ExtJSのファイルのデプロイで、RPMパッケージングを復習した。
• VirtualBox + Vagrantや、Ansibleなど、DevOps関連を勉強して仕事で使うようになった。

やっぱり仕事で使わないと覚えないっすね。
あと、統計処理やデータ分析、機械学習とかの勉強始めました。仕事で上手く使えるようになりたいっす。
趣味だと、仏教だけだとバランス悪そうなので、キリスト教にも入門してみました。欧米の文化圏の土台の一つなので、何かしらパクれるのではないかと目論んでます。

2014年は色々技術的なディテールで新しいのを入れるのにてんてこ舞いでしたので、2015年はもうちょいプライベートの時間とのバランシングを取れればなぁと思ってます。
あと、YakiBikiがいい加減、モダンPHPのメジャーバージョンとの乖離が大きくなってきたので、そろそろGitHubに移行して、すくなくともPHP5.2 or 5.3以降でのdeprecatedに対応できる状態にマイグレーションするのに着手したいです。

なんか最近のやたらと「成功」とか「結果」とか「成果」を強調するビジネス書とは趣が異なってたのと、業務上「チーム」周りのアレコレも入り始めたので参考に買ってみたところ、大変参考になりました。

チームとして「学習」をひときわ強調してるのが本書の特徴です。
環境の変化が激しい現在、初期条件で決まったルールや行動パターンをなぞるだけでは限界があるので、組織として学習し、それを活かす方向を模索する必要があるようです。
本書では組織的に学習を行い、実行に活かすための思想と、具体化する方法がまとめられています。
またもう一つ面白な、と思ったのが、どういう業務を行っているのかを「プロセス知識スペクトル」という表現で大きく3つに分類し、それぞれでどう具体化していけばよいのかをパターン分けして解説している点です。

単一の学習方法、実行方法でこれらすべてをカバーできるわけではなく、それぞれに応じた相応しいアプローチがある、という点で、実践的です。
特定業種によらず、汎用的な内容でまとめられてますので、広くおすすめできる一冊でした。

※この書籍の内容をANAが具体化すると、こちらの本に書かれているような内容になるのだと思いました：

医療関係者では無いのですが、Webの脆弱性の検査とかやってますので「診断」という技法それ自体は共通ではないかと思い、パクれる点は無いかな～と購入してみて、少しずつ、一年かけてゆーっくり読み終えました。

感想としては、おなじ診断業務ということもあり、いくつか参考にできそうな考え方がありました。
もちろん病気の鑑別とWebアプリの脆弱性の判定とで異なる部分も多々ありますが、著者の診断にかける真剣さや情熱は大いに共感できるところです。

ということで、いくつか「これは」と思った考え方やポイントを抜書きしてきます。さすがに業務内容に近い部分は書けませんが、一般論レベルで「診断ならこうだよな～」というのをコメントしてます。
なお、ここでのWeb脆弱性診断は基本的にブラックボックステストによる検査を想定してます。

System1(直観的診断), System2(網羅的・論理的・分析的診断), System3(ラテラル・アプローチ)

基礎的な診断戦略として、3種類が紹介されている。うち、System1(直観的診断), System2(網羅的・論理的・分析的診断)は昔からある戦略。System3が水平思考を活用した「ラテラル・アプローチ」で、最近出てきた戦略。

• System1(直観的診断) : 患者の見た目や訴える症状、実際に聴診や触診してみた結果など、すぐに分かる現象から診断につなげる。
  • メリットとしては迅速に行えるため、緊急性の高い外傷などで必要となる。また、すぐに鑑別できるような明確なものであれば、こちらの方が効率的。
  • デメリットとしては外部から見える・聞こえる・触れる現象のみを元にするため、診断員の思考にバイアスがかかり、誤った診断を下す可能性がある点。
  • 上記のような特徴から、主に経験を積んだ熟練者により運用される戦略。
• System2(網羅的・論理的・分析的診断) : 直観的な要素だけでは決めずに、漏れ無くロジックを組み立てて、この症状はどれに当てはまる・当てはまらないを緻密に判定していく。
  • メリットとしては網羅性が高いため、診断の抜け・漏れを抑えられる。
  • デメリットとしては十分な情報を集めるために過剰に検査をしてしまうなど、時間がかかる点。さらに集まったデータも膨大になりがちなので、データから鑑別に必要なものは何かを見抜く力も必要。
  • 上記のような特徴から、直観思考がまだ経験不足のため使えない、初心者が運用することが多い。
• System3(ラテラル・アプローチ)
  • 発想の転換で、今までとは違ったアプローチで診断に迫っていく。
  • 代表的な例が、直接患者に、何が原因だと患者自身は考えているのか聞いてしまう。
  • 患者に直接聞くメリットとしては圧倒的なスピードがある。
  • 患者に直接聞くデメリットとしては、患者の話にアンカリングされてしまい、バイアスとなってしまう。

System1/System2は、どちらかだけで診断を進められるというようなものではなく、System1で立てた仮設を検討するためにSystem2のフレームワークを使ったり、逆に、System2の結果からSystem1の直観的な思考がひらめくこともある。
System3は、上手くあつかうことで診断を効率化したり、System1/2とうまく連携できる。

System1(直観的診断)のポイント

1. 察知力 : KFD(Key fact for diagnosis)に気づく察知力
   1. 色々な初期状況のなか、どれが鑑別を決定するための決め手となる情報(KFD)かを見抜く直観力を育てる。
2. 姿勢 : 直観力を高めようとするマインドセット
   1. 失敗したからといって、「やっぱり直観力が無いんだ(´・ω・｀)」で終わらず、前向きに失敗を活かそうとうする姿勢。
3. 経験 : 量と質
   1. やっぱり経験値重要。また、他の同僚から話を聞いたりするなどして、知識を広げていくのもポイント。
4. フィードバック : 思考のバイアスで間違えてしまったことに気づけるか、気づいた後に、今後バイアスにはまらないようにするにはどうするか、など。
5. 試練 : この戦略を使わなければ切り抜けられないような状況への曝露。若いうちに苦労しておけ、という話。

経験とフィードバックについては、「診断エラーノート」というので診断の経験を蓄積していこう、というのが紹介されてました。

Web脆弱性診断の現場なら・・・

アプリの挙動から「このパラメータが怪しい」など見当をつけて、実際に検査するという、ヒューリスティック性の高い検査に相当すると考えられます。
パラメータの用途などを確認してから、それならこういう脅威は考えられないか？として、試すケースが多いと思います。

System2(網羅的・論理的・分析的診断)

直観的思考で上手く行かなかった場合に、System2の分析的思考の出番となる。

1. フローチャート、アルゴリズム、ディシジョンツリー
2. スコアリングシステム、診断クライテリア
3. Bayesの定理、オッズ、尤度比
4. 他のフレームワーク
   1. 階層型
   2. マトリクス型
   3. 時系列型
   4. グループ型
   5. 並列型

重要なのは分析的思考に切り替えるための質問、"Conquer BIAS" の語呂合わせ。

1. "Context" : 診断がその患者の病歴やバックグラウンドに沿っているか？
2. "Bias" : その診断仮説はバイアスがかかってないか？
3. "Input" : 情報のインプットは正しく、かつ十分か？
4. "Alternative/Additive diagnosis" : 他の診断ではないか？重複する診断ではないか？
5. "Script" : 診断の仮説でしっかりと説明できるか？

これらにより、バイアスを回避して、分析的思考と併せて診断の精度を高められる。

Web脆弱性診断の現場なら・・・

検査ツールなどを利用して、パラメータを網羅的に検査するのがこれに相当すると考えられます。
パラメータの値を不正な擬似攻撃用の値に改ざんして送信していきますが、パターンの質や量とサーバのレスポンスが、検査にかかる時間に直接反映されます。
また、ツールによる大量の通信結果を精査する必要があるため、ツールの検出特性や結果の見せ方(UI)が作業コストに影響してきそうです。

System3(網羅的・論理的・分析的診断)

患者に直接聞く、の他に、以下のような戦略が紹介されてる。

Pivot and Cluster Strategy(PCS) : ピボット・クラスター戦略

直観で鑑別した診断だけで終わらせず、臨床上の表現形が似ている他の診断を検討にあげ、その診断はありえないか検証する。
直観のスピードを維持しつつ、似たような表現形を持つ鑑別を漏らさないよう網羅性を上げることが出来る。
ただし、もちろん、ある症状から、それと似た表現形の病名を想起できないといけないので、相応の知識と経験は必要。

Horizontal-Vertical Tracing(HVT)

合併疾患をトレース、つまり水平方向での他の診断が一緒にできないか思考する。
さらに、疾患の原因に別の病気が存在するケースもあるため、垂直方向に疾患の原因を掘り下げていく。

Mesh Layers Approach (MLA)

上記までの複数の戦略を重ねて使い、絞り込んでいく。
さらに奥の手として、同僚や上級医に聞いてみる、ググる、など。

Web脆弱性診断の現場なら・・・

判定に直接結びつくわけではありませんが、レスポンスがひどく遅くなったりして、お客様にサーバの状況を確認するケースがあります。
また、もし陽性なら危険度が高いので指摘したいが、どうにもサーバの反応が曖昧で、白黒判別しきれない場合に、お客様に状況を伝えて、直接確認してもらうケースもまれにあります。
あまり遭遇したことのない独自性の高い機能で、どう脅威を考えれば良いのか分かりづらい場合、同僚や上級診断員と相談して知恵を借りる場合があります。

診断戦略をひらめく、イノベーション

• アブダクション : ふとしたきっかけで新しいアイデアがひらめく。
• 診断戦略カンファレンス : 診断事例や判定時の思考を共有するカンファレンスを開催する。
• 「なぜ」を日常的に考え、突き詰めて考える思考力を鍛えていく。
• 専門領域以外のことに目を向ける。別の分野の歴史や教養にヒントを得たりできる。
• 自分だけの時間を確保する。

Web脆弱性診断の現場なら・・・

• どうにもテストケースと脅威について思考が煮詰まってて、帰るために会社の扉を出た瞬間に「あ、あれってこういうことか！？」となることがよく有ります。
• あと、自宅でリラックスしてる時＝トイレやお風呂に入ってる時にアイデアが思い浮かぶ場合があります。
• 「なぜ」を突き詰めるのは、Webアプリの挙動を正確に把握するために必須です。また、どこからがわからないことなのか、をクリアにするためにも必要です。
• Webセキュリティの検査となりますと、やっぱりWebアプリの開発知識が必要になりますので、そちらの技術を追っかける必要があります。

病歴の技法

患者に病歴を聞くときの技法について、実践的なノウハウが紹介されています。

• 最初の30秒で患者の話を聞くときに集中し、患者に対する信頼感を醸成することに注力する。焦ってclose questionで鑑別に持ち込まず、open questionを駆使してKFDを引き出す。
• 患者の言葉を置き換えずに、他の医師と共有する。言い換えてしまうと、言い換えられた言葉で持って他の医師は思考を開始するため、患者の言葉ではなく、言い換えられた言葉の方に思考がアンカリングされてしまう。
• 患者に対する好奇心、「なぜ？」「どうして？」を大切にして、患者の理解に努める。
  • 信頼関係を醸成することになり、さらに患者からの情報提供が増え、KFDを得やすくなる。また、患者のメンタル面からの行動について納得が得られることが多く、それによる患者へのメンタル面でのケアにFBできれば患者の満足感も高くなる。

Web脆弱性診断の現場なら・・・

お客様のエンジニアと会話する場合に、こちらがセキュリティを監査する立場になりますので、上から目線になってしまったり、非難するような物言いにならないよう気をつけます。
お客様のエンジニアあってこそのセキュリティということですので、上下関係ではなく協力関係にある、という点をこちらも意識し、お客様にも意識させるような言葉遣いに気をつけます。

診断学の教育

こうした戦略を以下に駆使したり、思考力を鍛えるか。診断学の教育について、「カンファレンス」という形で部署内・院内などで知識や事例を共有するのが良いが、どのような運営の仕方をするか、によっても効率面で違いが出てくる。

• 知識共有型のカンファレンス：全員を一同に集めて共有するには、時間の拘束性と、人数が増えれば増えるだけ需要と供給のギャップが広がるなど、無駄が大きくなる。単に知識を得るだけであればネットの活用も進んでいるので、そちらに役割を移す方針もあり。
• 思考型カンファレンス：参加者に、実際に診断や鑑別について「自分だったらどうするか？」など考えてもらう形態。双方向的であり議論も引き出しやすいため、参加者を絞れば有意義なものとなりそう。

著者としては上記に加え、やはりベッドサイド教育、つまり実際に患者と相対して会話して思考していくのを推奨している。
さらに、診断に特化した部門を結成し、研修医の上に上級医を据えて監督した上で、ローテーションなどで事例を共有しつつ、診断技法を高めていく組織的なアプローチを考察している。

Web脆弱性診断の現場なら・・・

診断員の教育となりますと、最近ですとスキルマップが提案されたり活発です。
診断員自体が歴史の浅い職務ですので、これからどう教育や研修コースが整備されていくのか、これからの話になりそうです。

診断を困難にする"霧"への対処法

• ブイ(buoy)疾患：ある症状に対して、原因となる別の疾患が隠れているケース
• オッカムとヒッカムの切り替え：患者が若ければオッカムのルール、50代以降ならヒッカムのルールが当てはまりやすいが、例外もあるため、とらわれ過ぎない。
  • オッカムの剃刀：「説明に最低限必要でない余計な存在がある、そうしたものは不必要なものなのだからそぎ落とすべきである。」
  • ヒッカムの格言：「どの患者も偶然に複数の疾患に罹患しうるため、症状に対して複数の原因を探すべき」

Web脆弱性診断の現場なら・・・

ある現象にたいして、ある脆弱性を判定できたとして、じつは別の脆弱性でもあった、という合わせ技的な現象がママあります。
一個の脆弱性の判定で意識を止めてしまうと、さらなる問題の見当を見逃す場合もありますので、他の問題は無いか見当する必要があります。
例えば、エラーメッセージの詳細が出てるのでその問題を指摘してそこで終わりではなく、エラーメッセージの内容をよくよく見てみたらSQL文が含まれてて、それをヒントにSQLインジェクションを見つけられるケースが時々あります。

医療の診断現場と、Web脆弱性の診断現場ですが、かかるプレッシャーについては比べ物になりません。
とはいえ、プレッシャーの特性としての「網羅性の保証」や「漏れ・抜けに対するリスク」という特徴は似通っていますし、診断や検査という業務特性も似通っています。
そのため、よりプレッシャーの高い医療の診断現場の話は、Web脆弱性の診断に色々と応用が効きそうに思い、読んでみましたが、案外面白かったです。
著者の体験として、患者の訴えや聴診・触診結果、病歴などから思考を重ねて鑑別していくエピソードがいくつかありましたが、いずれも読んでいてワクワクしてくるような面白さを感じました。
恐らく当事者としても、患者と共同して診断を積み上げていき、治療を進めるのはやりがいと面白みのある部分なのだろうと推察いたします。

Web脆弱性診断の教育や研修を担当される方に、一読をオススメしたい一冊でした。

※なお、プレッシャー等についての心構えなどについてはこちらがオススメ。

読書メモ/「まんがでわかる 7つの習慣」と一緒に購入して比べ読みしようと思いましたが、ターゲットが違ってるので比べ読みできるような内容ではなかったです。
こちらは、ANAとしてチームで働くときに、どんな気遣い・しくみが必要で、実践しているのか、の紹介です。そのため、とにかくANAとしてはここまでやってます、という内容です。

ANAビジネスソリューション著となっており、HPを見てみますと人材派遣や教育・研修コースの開催などを外向けに提供していました。

• http://www.abc.jp/
• http://www.anajinzai.com/
• http://www.anakenshu.com/

面白いのが、 http://www.anakenshu.com/ の公開講座で医療現場の接遇研修を実施してる点です。航空会社がそこまでやってるんだな～と驚きました。

内容としては「なるほど、確かにそのとおりだなー」となる内容で、さすがANAといいますか、そこまでやってるのか、という内容です。
好感が持てたのが、「成果」「結果」「アウトプット」「成功」などというキーワードを全く（多分）使ってないところで、代わりに「お客様」というフレーズを中心に据えてる点です。
「お客様へのサービス」というのを目印としたほうが受け入れやすいんでしょうか。
あるいは、CA業務や整備業務は「成果」や「アウトプット」「成功」という単語でその結果を図れるものではなく、日々の継続の中で安全と信頼を積み重ねていくためでしょうか。
でも、こういう細かいテクニックやノウハウ、さらにそれを束ねた「お客様の安全と信頼」という芯は、個人的にはすんなり馴染みやすいアプローチに感じました。

注意点としては、これは人命が重要視される航空業界の業務で培われた、つまりある程度コストが高くなっても人命優先に振ってる業界の話である点、さらに万人の単位の従業員と各地に分散した勤務地という、非常に規模が大きく組織化された環境で培われたノウハウであるという点でしょうか。
そのため、そのまま適用しようとしても運用コスト面や業務形態の差でいろいろ衝突が発生しそうです。

これを参考に、自社の風土・文化的にはどうしていくのか、そこは自分たちで調理していくことになりそうです。

併せて読みたい：

「アメリカンな自己啓発書ってどんな感じかな～」とつまみ食いしてみるくらいの感じで購入してみました。

企業研修サービスなど提供している、日本法人があるんですね。上場企業などでの導入事例もあったり、研修内容も色々な世代・役職別にカスタマイズされてて、参考になります。

• ７つの習慣、リーダーシップ研修・セミナー｜フランクリン・コヴィー・ジャパン株式会社
  • http://www.franklincovey.co.jp/

ただ、どうもこういうのって、「成功」とか「結果」「成果」という単語を連呼するわりには、それって具体的にはどういうこと？という点について書いてくれてないんですよね。
今までは「結局お金のことかな？」と邪推してたんですが、今回マッピングしてみまして、あえて特定してないのかなーとも思いました。それにより、特定分野にしか通用しないわけではなく、仕事やビジネス、日常生活、人生など、色んなスケールで適用できる、という遊びを確保してるのかも、と今は思います。

仏教とを勉強中の身としては、「あ～、仏教でいうところのこれかな～」的なのが多く、ちょっとマッピングしたくなりましたので、そのメモです。最初に「ブッダの真理のことば・感興のことば (岩波文庫)」（中村元）からマッピングできそうなのを抜き出し（法句経）、続いて超ざっくりと現代のコンテキストならこういう解釈になる、というのと簡単にメモしてます。（一部、「ブッダのことば (岩波文庫)」（中村元）＝スッタ・ニパータからも取ってきてます。）

※マンガで思いっきりサマライズされた、入門書の内容を元にしてますし、自分の仏教の理解自体が危うい点もありますので、間違ってたらごめんなさい。

習慣1: 「主体的である」

「ささいな行動でも、感情的な反応に身を委ねたり、受け身で行動するのではなく、自分で振る舞いを選択する意識だ。」とマンガでは見出しにありました。

法句経1-5:

ものごとは心にもとづき、心を主とし、心によってつくり出される。もしも汚れた心で話したり行ったりするならば、苦しみはその人に付き従う。車をひく牛の足あとに車輪がついていくように。
ものごとは心にもとづき、心を主とし、心によってつくり出される。もしも清らかな心で話したり行ったりするならば、福楽はその人に付き従う。車をひく牛の足あとに車輪がついていくように。
「かれは、われを罵った。かれは、われを害した。かれは、われにうち勝った。かれは、われから強奪した。」という思いをいだく人には、怨みはついに止むことがない。
「かれは、われを罵った。かれは、われを害した。かれは、われにうち勝った。かれは、われから強奪した。」という思いをいだかない人には、つに怨みが止む。
実にこの世においては、怨みに報いるに怨みを以ってしたならば、ついに怨みの止むことがない。怨みをすててこそ止む。これは永遠の真理である。

法句経160:

自己こそ自分の主である。他人がどうして（自分の）主であろうか？自己をよくととのえたならば、得難き主を得る。

仏教では、「自分のもの」というのは感情も含めてありません、という話があります。無我とか。
視覚・聴覚・触覚・嗅覚・味覚などから入ってくる情報に対して、自動的に反応して世界を感じてしまっている。
そのため、「こんなことを言われて傷ついた」とか「なんであの人はこんなヒドイことを言うんだ」とか、あるいは「褒められて嬉しい」とか、そういうのは自分が意識的にそう感じたのではなく、感覚で入ってきた情報に反射的に沸き起こってきたものなので、それに振り回されることは無いですよ、というのがポイントになってきます。
一見、刹那主義というかニヒリズム的な感覚があります。
しかし「だから所詮～なんだ」と捉えるのではなく、仏教がこれを扱う本来の目的としては「平穏に心穏やかに過ごす」ことにあるので、この事実をもって、他人からの悪口や批判にいちいち感情的にムキーッとなったり、賞賛や褒め言葉に舞い上がってはいけませんよ、というのがポイントです。
その上で、他者に対する善行（布施）を積みなさい、となるわけです。

また仏教では実践による確認を推奨しています。上記の理論を頭でなぞっても、本当にそうなのか、試してみないと分かりません。じゃぁ実際に瞑想で感覚と意識について体験してみたり、日々の生活で実践してみて、何か改善されるものがあるか自分で確認してみましょう、というのが仏教の懐の広さだと思います。

さらに、仏教の説話で、お釈迦様が弟子たちに、「小石がごろごろ転がった歩きにくい道を歩くにはどうするか？」と問いかけ、弟子たちが「道路を鹿の皮で覆えば、裸足でも歩けるようになる。」と回答しますが、お釈迦様は「鹿の皮ですべての道路を覆うことはできない。自分たちの足を鹿の皮で覆う方が現実的」と応えます。
仏教における「鹿」とその皮を例えに持ちだした点についてはさらなる解釈が必要そうですが、重要なのは、世界を変えるのではなく自分を変えたほうが現実的である、という点に思います。
（これ、ひろさちや氏の著作には出てくるんですが、ソースとなる経典が今ひとつ不明なので、どの時代と系統に属する説話なのか不明であるため、コンテキストがちょっと危うい。）

まとめますと、仏教でも、他人からの悪口や褒め言葉に一喜一憂せず、自分が感じている世界に振り回されず、その上でより良い行いを自分がするにはどうすればよいか、考えていきましょう、と言ってるわけです。

ということで法句経1-5, 160 で、自分の心を細心の注意で扱えよ、というマッピングでした。

習慣2: 「終わりを思い描くことからはじめる」

わざわざ仏教説話にマッピングする必要はない位に、あちこちで言われてることだと思いますが、あえてマッピングしてみます。

法句経148:

この容色は衰えはてた。病の巣であり、脆くも滅びる。腐敗のかたまりで、やぶれてしまう。生命は死に帰着する。

法句経6:

「われらは、ここにあって死ぬはずのものである」と覚悟をしよう。このことわりを他の人々は知っていない。しかし、この断りを知る人々があれば、争いはしずまる。

「終わり」となりますと究極的には「死」です。仏教では生老病死を「四苦」として、生き物はすべからくこの４つの苦しみからは逃れられないとしています。そこから外れ、二度とこの四苦を味合わないために「悟り」を開いて「解脱」する、という流れです。（超サマライズしてます）
仏教には、生きてる中で、心を穏やかにして日々を平穏に過ごすことを目的とした技法が詰め込まれてます。
その中に、無我をキーワードとした瞑想法や修行法も含まれています。
ですが「無我」という思考フレームワークはあくまでも感情や意識の奔流に飲み込まれないようにするための道具なので、無我それ自体に拘ってもしゃーない、というのも仏教にはあります。
有名なのが毒矢の例えで、お釈迦様のもとにある弟子が、「世界は永遠なのか、世界は有限化、霊魂と肉体は同じものか、如来は死後にあるか、気になって修行に身が入らないからいい加減教えろ」と詰め寄ります。
お釈迦様は、「それは、毒矢を受けた人を前にして、その毒矢は誰が射ったものか、その矢はなんでできているのか、云々しはじめたら、射られた人は死んでしまうだけなので、まずその毒矢を抜き取るところから始めなさい」と応えます。
目的はあくまでも悟りを開いて解脱するところにあるのだから、まず煩悩を制御し、日々を平穏に過ごせるようにするのが重要、という実践重視の考え方です。

スッタ・ニパータ5:

無花果の樹の林の中に花を探し求めても得られないように、諸々の生存状態のうちに堅固なものを見出さない修行者は、この世とかの世とをともに捨て去る。蛇が脱皮して古い皮を捨て去るようなものである。

ということで、目的を定めて、そのためになすべきことをしていく、手段と目的と取り違えない、ということは仏教にもあります。
では「目的」や「なすべきこと」はどうやって決めていけばよいのか。これについても色々マッピングできそうなキーワードがあるんですが、ここでは「布施」をマッピングします。
布施は見返りを求めず、自らの人生を豊かにするために善行を積んでいく行いです（超サマライズ）。
ポイントとしては「1. 自分にできることの範囲でなにが出来るか考える」「2. 無理はしない」の2点があると思います。
究極の布施は、自らの命を投げ打って相手の生命を助けるという極限行為になります。しかし日々の生活ではそこまでのことは出来ません。
そのため、無理をしない範囲で、自分にできることはなにかを考え、それによる目的と手段の設定がポイントになります。
その時のガイドラインとして「自灯明、法灯明」という考え方があります。まず自分自身の考えや思考に注意を払い、それを根っことし、続いて釈迦の教え（法）を拠り所とせよ、という教えです。自分の価値観や考え方、良い点、悪い点を大切にしつつ、仏教のガイドラインを活用して善行を積んでいくわけです。

ちょっと無理があった感じがしますが、目的と手段の取り違えに気をつけなさいという教えや、「布施」「自灯明、法灯明」をベースとした人生の意味を見出す方法論など、しっかりと仏教にも含まれてますよ～という話でした。

ということで法句経6, 148で「死を想え」、さらにスッタ・ニパータの5で生きる目的について、というマッピングでした。

習慣3: 「最優先事項を優先する」

書籍の方では時間を4つの象限にわけて、「緊急で重要度の高い作業」の次には、「緊急でないが重要度の高い作業」に時間を振り分けると良い、というアドバイスしています。

法句経292：

なすべきことを、なおざりにし、なすべからざることをなす、遊びたわむれ放逸なる者どもには、汚れが増す。

仏教では・・・ちょっとマッピングに苦しみますが・・・瞑想とも関係しますが、「"今"に意識を向ける」というのがあります。
感覚・意識は自分のものにならない、というのを実感するために瞑想があったりしますが、体験方法の一つとして「自分が今しようとしていることを常に意識する」とい方法です。
自分を客観的に把握し、「自分は今、こうしようとしている」「自分は今、こういう事を考えている」と常に一歩後ろから見ていく訳です。
それにより、自分が自分だけで構成されているわけではなく、あらゆる外部環境からの入出力で成立している仮の姿であることを実感するわけです（ドヤァ）。

それはより日常的な感覚に落としこむと、「今を丁寧に生きていく」という表現に落とし込まれ、最終的に人生で一番大切と思われることを優先し、丁寧に生きていくという方法論になっていきます。
大切と思われることはなにか、というところまでは明確になっていませんが、仏教ではこのような、時間の使い方に関する思考フレームワークも提供しているという次第です。

ということで法句経292, 今やるべきことに意識を向けて、今を大切に生きましょう、というマッピングでした。

習慣4: 「Win-Winを考える」

法句経67：

もしも或る行為をしたのちに、それを後悔して、顔に涙を流して泣きながら、その報いを受けるならば、その行為をしたことは善くない。

法句経68：

もしも或る行為をしたのちに、それを後悔しないで、嬉しく喜んで、その報いを受けるならば、その行為をしたことは善い。

法句経201：

勝利からは怨みが起こる。敗れた人は苦しんで臥す。勝敗をすてて、やすらぎに帰した人は、安らかに臥す。

相手から奪うのではなく、自ら勝ちを手放し、相手に与えるというのは「布施」の考え方に近いと思います。
また、相手を傷つけてまで自分の利益を確保しようという行いは、将来に対する不安やリスクを増やし、結果として日々悩みを抱えて生きることになり「煩悩」となります。
その点からも、他者を傷つけたり貶めたりするなどの悪行を積んでまで、自らを利するような行いは仏教では止めたほうが良いとされています。
無理・無茶な要求を受け入れる必要はありませんが、誠実さや社会一般の良識にしたがって、自分と相手の両方で利益を得られるよう考えるのは、仏教でも十分推奨されるアプローチです。

ということで法句経67, 68, 201, 後で公開するような勝ち方はするな、勝敗自体を捨て去った大胆なアイデアでWin-Win目指そうぜ、というマッピングでした。

習慣5: 「まず理解に徹し、そして理解される」

法句経1:

ものごとは心にもとづき、心を主とし、心によってつくり出される。もしも汚れた心で話したり行ったりするならば、苦しみはその人に付き従う。車をひく牛の足あとに車輪がついていくように。

ちょっとマッピングに苦しみますが、これも無我の話に関連しそうです。
相手が話を聞いて欲しい、と話をし始めても、つい「自分が～」「自分なら～」と、自分を優先にして話をしてしまいがちです。
それは結局、相手を満足させたり理解したりすることにはつながらず、単に自分を一時的に満足するためだけになり、相手にとっては悪い印象しか与えません。
相手の話ではなく自分の話にしてしまうのは、耳で聞こえてきた相手の話に対して、反射的に自分の話をぶつけて自分の心を満たしたいという側面があります。
仏教的には、そこをまず押しとどめ、相手の話をありのままに聞いてあげて、相手の欲するところを汲み取って答えるほうが良い結果になりそうです。

ということで再登場ですが法句経の1, 心が感じた「俺が～自分が～」に反射的にしたがって話してもいいこと無いよ、というマッピングでした。

習慣6: 「シナジーを創り出す」

法句経63：

もしも愚者がみずから愚であると考えれば、すなわち賢者である。愚者でありながら、しかもみずから賢者だと思う者こそ、「愚者」だと言われる。

悟りを開いたお釈迦様であれば沸き起こる知恵でもって色々できるのかもしれませんが、日常を生きる自分たち一人ひとりにできることは限界がありますため、他の人と組んで生きていく必要があります。
仏教としてのポイントは、「自分ならこれくらい知ってる、これくらい出来る」と慢心したり天狗にならず、素直に他の人の良さ・力を認めて、助けを乞うのが良い、という点です。
ということで法句経63, 自分が知らない点を自覚して、素直になれよ、というマッピングでした。

習慣7: 「刃を研ぐ」

法句経296, 297：

ゴータマの弟子は、いつもよく覚醒していて、昼も夜も常に仏を念じている。
ゴータマの弟子は、いつもよく覚醒していて、昼も夜も常に法を念じている。

良い行動を習慣としておく話になりますが、仏教でも同様、善い行いを日常の生活の中で実践することが重視されます。
ということで、法句経296, 297で、仏弟子はいつも仏と、その教えに気をつけて昼も夜も過ごしてますよ～というマッピングでした。

前々から、欧米系の自己啓発などの考え方について、「これって仏教のあれだよな？」というのが気になってました。
今回が初のマッピングになりますが、案外、なんとか牽強付会すればこじつけできるもんですね。
一応現代のコンテキストでの解説を入れてみましたが、勉強中の身、そうとう間違ってる箇所もあるかと思います。
もし本気でマッピングを検証されたい場合は、以下を参考にしてみてください。てか、こっちを先にマッピングの参考にして、経典は中村元氏の著作から引用してきてます（汗）。

自分たちでソフトウェア製品・サービスを開発している著者が、人間的なスキルや考え方をリアルに照らし出してくれる絶好の良著。

注意点としては、自分たちでソフトウェア製品を開発している、というポジションからの話になっている点。
大規模システム開発のヒエラルキーや、動きの速いWebサービス開発、GoogleやMicrosoft, Appleなどの巨人達の開発現場の話では無いので、そうした現場に特有のノウハウは少ない。
しかしながら、内容的にはエンジニアが陥りやすい思考の罠や、実際に著者が体験したソフトウェア開発での成功談、失敗談など、普遍的なものが多い。
技術ではなく、人間としてどうソフトウェア開発を生業としていくかを考える際に、参考書として一読しておきたい書籍である。

以下、これはと思った箇所を引用して、自分なりのコメントをしてみました。

28p, 「現実は泥臭い例外の塊」

あまりにも汎用化・共通化をやりすぎてしまうと、例外的な処理を後から加えにくくなってしまうことがあります。
(中略)
最初からある程度ゆるく作っておくほうが、仕事では喜ばれることもあるのです。

「あるある」過ぎる。
プログラミングを真面目に勉強してると、「似てる処理は共通化」とか「汎用的な関数/構造体/クラス/メソッド設計」をやりすぎてしまうんですよね～。
特に十分ユースケースが揃ってない開発初期の時点でこれをやってしまうと、あとから、「え、そんなユースケース、この共通関数、想定してないよ～(T_T)」ということになってしまい、当初の「美しさ」はどこへやら・・・となりがちです。
かといって、数百～数千行単位で「1行しか違わない関数/メソッド」があっても後々のメンテナンスで＼(^o^)／ｵﾜﾀしますので、バランス感覚が求められるところですね。
ソースコードにアクセスできる人数が制限されてる、数人で開発しているのならまだしも、ある程度の人数や役割分担が始まる中規模以上の開発だと、一旦作ってしまったものは中々動かせないというのもありそうです。

これに対する教育プランとしては、やっぱり「一度は火傷してみる」ことは重要かなと。自分で「しまった、これは凝り過ぎた・・・。現実的じゃなかったんだ・・・。」となり、次回以降に役立ててもらうことがバランス感覚を育ててくれそうです。
あとは、例えば似たような処理が出てきても焦って共通化したりせず、一旦コピペ＋テストコードを書いておく。これにより、後々「やっぱりこの処理は共通化できる」となった場合でも、テストコードにより共通化するまえの処理と同じことを保証でき、共通化することによるエンバグに効果的に対応できます。

37p, 「自分が考えているほど、相手は気にしない」

ここの部分も自分は「あ～、あるある」と大いに頷いてしまいました。
わりとソロ(あるいはピン)で直接クライアントと仕事してると、プログラミングや技術的な精緻さを狙うよりは、妥当な時間でクライアントが望む最低限度のものを提供したほうが良かった、というケースがあります。
ただ一点、注意事項があって、突貫工事したあとはちゃんと整理しましょう、あるいは、整理する余裕が無ければ、メンテナンスを意識したシンプルなコードにしておきましょう、という点が注意事項だと思います。
あまりにもオレオレ流儀だったり、場当たり対応詰め込んだ突貫工事のソースコードだったりすると、後のメンテナンス（運用・保守フェーズ）で泣きが入ります。
そのためにも、コメントやテストコードなどで、後で自分以外のエンジニアが保守するときにもある程度思考の道筋をトレースできて、ブラックボックス化を防げるような施策を打っておくことが大切かと。
結局、これは「お客の時間」と「技術的な妥当性」と「運用・保守のコスト」のトレードオフやバランスになります。「今回はこっちを重視したので、そっちがおろそかになった」という歴史・物語・文脈をどこかに保存しておき、後で別の人が振り返って納得できるような施策だけは打っておきたいところです。

60p, 「理想はすべて詰め込んだ、けれど完成しない・・・」

これも「あるある」で、というのは、これ、「人月の神話」に出てくる「セカンドシステム症候群」そのまんまなんですよね。
システムの「二代目」を新規に開発する際は、「初代」からのフィードバックを全部取り込もうとしたくなる気持ちはよくわかります・・・。
しかし、それをやろうとすると大体、初代からのソースコードが使えなくて結局スクラッチからになり、初代で得たフィードバックを組み込もうとすると結局どんどん汎用性を求めることになり、プログラムも、ソフトウェアの使い勝手もどんどん複雑化していき、最終的にお客が求めるものは完成できなかった・・・という・・・。

多分、こういうケースでは初代からのフィードバックに真正面に取り組むのは悪手で、むしろ「なんでこんなフィードバックが得られたのか？それは○○な機能があったからだ。じゃぁ、そもそもその機能を削るか、別の機能で代替できないか？見せ方を変えられないか？」てきな検討が必要なのかもしれません。

87p, 「なぜ、コミュニケーションがうまくいかないのか」

（中略）

原因はじつはたった1つしかないと考えています。

「議論の基本や背景に関する共通認識が不十分なまま、相談を進めているため」

これも「あるある」でした。やっぱり、自分の意見の裏側には自分が体験したり獲得した背景知識・思想などが控えていて、ついつい、その点を意識できずに話を始めてしまいがちです・・・。
これに気づくには、話がこじれてきたときに「相手はなんでそういう態度を取るのか？もしかして、重要な前提知識や背景、文脈が欠けているからでは？」という思考フレームワークを使う必要があります。あったとしてもすぐに持ち出せるものでも無いんですが（反省）。
エンジニアであれば、「同じエンジニアならこれくらい知ってるよね？」というのを相手に期待しがちです。しかもその期待が裏切られると、「なんだ、これくらいのことも分かってなかったの？」という流れに陥りがちですので、そこは十分気をつけておきたいところです。そういうの、言葉の節々に出てきてしまって、結局相手の心を閉ざし、有意義な会話をできなくなる原因ですので・・・。

134p, 「付加価値の高い仕事をするための8つのポイント」
8つのポイント、概ね「なるほどなー、確かに」とうなずけるのですが、少しだけ気になる点があったのでコメントします。

周囲を巻き込みながら進める（特にテスト）

これ、こういう進め方をすること自体をネゴしておかないと、トラブルになるだけなのでそこは十分気をつける必要がありそうです。
特にある程度組織化された人たちと仕事をするとなると、相手のスケジュールや負荷、準備期間などの調整が絶対に必要になります。また、周囲へのアピールや理解も下準備しておかないと、いきなり振られても「そんなの聞いてないよー」となり、信頼関係が失われます。巻き込まれる相手に対する説明責任があることを忘れないようにしたいです。

自分で作ったものは完璧にサポートできてあたりまえ

これ、自分「だけが」サポートできる状況にしてもナンセンスです。もしそういう状況にしてしまうと、自分が休めなくなり、変に苦労や気苦労を背負い込むことになり、仕事が進んでいくとどんどん重荷になる一方です。
ブラックボックスやスパゲッティコードを放置せず、モダンな開発技法を駆使して、開発当初は自分一人だったとしても、3ヶ月後の自分を含めて、後々の運用保守で「自分だけしか」という状況を作り出さないような施策が必要そうです。

138p, 「「自分たちの製品を作ろう」として失敗するパターン」

一応完成したと思っても、だれも見向きもしてくれない製品になってしまった。

・・・えー、その、自分もYakiBiki作りましたが、まさにこのパターン・・・。自分が唯一のユーザです・・・。

173p, 「価格設定をどうするか」

「安価なのは、安価である理由が」「高価なのは、高価である理由が」それぞれあるんだなぁ、と感じました。

201p, 「3年は種まきをして、失敗を積み重ねてはじめて見えてくる」

焦っても成果が出るものではないんだななぁ、と感じました。

223p, 「一生、プログラマとしてメシを食っていくには」

"プログラマ"というと読み手によっては想定スキルがバラつきそうですので、"ソフトウェア開発でメシを食っていくには"の方が良さそうに思いましたが、内容としては「なるほど、確かにその通り」と頷いてしまうものです。

感想というかふと思ったことですが、ソフトウェアの世界って、数年～10年前は難しいと思われてたことがあっというまにコモディティ化してしまう世界です。
ただ、コモディティ化するといっても結局値段や技術的な深さの点で、幅ができていきます。
一昔前はHTML+CSSでUIと見た目を両立させたHPデザインを行うのは、Webデザイナの牙城でした。しかし、Bootstrapなどのデザインテンプレートが台頭したことにより、それの流用である程度のデザインも可能になりつつあります。
イラストの世界もそうで、かつては限られた教育環境や制作資材の中、人間の手に依存した技能が参入障壁となっていました。しかしペンタブレットやイラスト作成ソフトの改良と、裾野の拡大による教育資料の広がり、SNSなどでの制作物の発表舞台の拡大により、イラスト製作者の絶対数や幅も圧倒的に広がっています。
ソフトウェア技術は、その時点で「難しい」「出来る人が少ない」と思われた分野を、数年～10年のスパンで「ある程度までなら簡単」「出来る人が多い」分野に変えていく性質がありそうです。
そうなってくると、「難易度が高い技術を出来ること」を売り物にしても、遅かれ早かれ陳腐化する危険があります。

そのような状況でやりくりしていくためには、いくつかのパターンが考えられます。

1. 技術の深さでは勝負せず、移り変わりに合わせて活動舞台・ツール・客層を変えていく、流動性の高い広さ重視パターン
2. コモディティ化しても、そのトレードオフとして深さが犠牲になっている。誰も到達できないほどの深さを極めて、そこで特定の分野とターゲットを狙って長くやりくりしてく、深さ重視パターン（この本の著者がそのパターンで上手く行ってそう）
3. 変化自体を引き起こし、変化のプラットフォームとなることを狙う、プラットフォーム戦略パターン
4. ITの変化それ自体は重視せず、ビジネスの道具として利活用していくパターン(自社のシステム開発など)

どれを選ぶか、むずいっすね・・・(ヽ´ω`)

• [ Prev ]
• [ Next ]
• [ 技術 ]

history API のサンプルとメモ。

練習サンプル：

• HTML5 hisotry API exercises
  • https://gist.github.com/msakamoto-sf/ae34b967c43eea371f6e

参考：

• Manipulating the browser history - Web developer guide | MDN
  • https://developer.mozilla.org/ja/docs/Web/Guide/DOM/Manipulating_the_browser_history
• Ajaxと組み合わせて便利なHistory APIを使おう - BREAK TIMES
  • http://breaktimes.hatenablog.com/entry/history-api
• History API - Dive Into HTML5 (日本語訳)
  • http://myakura.github.io/dih5ja/history.html
• 十二章第三回　History API — JavaScript初級者から中級者になろう — uhyohyo.net
  • http://uhyohyo.net/javascript/12_3.html
• HTML5 History API を徹底的に試してみる | nacika's blog@技術ネタ多し
  • http://nacika.com/entry/2013/01/18/003325/
• web帳 | HTML5 History APIについて
  • http://www.webcyou.com/?p=4329

• [ Prev ]
• [ Next ]
• [ 技術 ]

• [ Prev ]
• [ Next ]
• [ 技術 ]

Antプロジェクトのインポートについて、Eclipse 4.2 Juno SR2 で実験メモ。(2014-12時点)

→ 新規プロジェクトの作成で、"Java Project from Existing Ant Build File" を選択して、既存のAntプロジェクトのbuild.xmlを選択する。
この際、javacタスクが含まれてるbuild.xmlを選択すること。
※複数のプロジェクトに分割してて、トップのbuild.xmlにはjavacが無い場合は、個別にimportしてくしか無さそう？

上記のインポートだと、必要最低限のクラスパスやビルドパスしか調整してくれないので、プロジェクトに応じて微調整が必要。

参考：

• java - importing ant build.xml in eclipse - Stack Overflow
  • http://stackoverflow.com/questions/3880350/importing-ant-build-xml-in-eclipse

• [ Prev ]
• [ Next ]
• [ Up ]
• [ 技術 ]