読者です 読者をやめる 読者になる 読者になる

ざっくんのブログ(仮)

面白く生きるためのブログ(思いついたことや気づいたことを書いたり)

振り返り6ツール比較!! 〜YWTとKPTとPDCAの違い(あとLAMDAとか経験学習モデルとか)〜

f:id:yoshitsugumi:20170203105642j:plain

こんにちは。ざっくんです。
最近は記事の更新頻度がめっきり少なくなっていました。その辺の、習慣化なのか自制・意志の強さなのかとかの振り返りはまた今度記事にするとして。
今回は前々からまとめようと思っていた「振り返りツール」的な奴らの話をしたいと思います。いろんな種類があって、どれがいいの?とかってなることが多いと思うので自分の中の整理も兼ねて。

この記事の要約
◆それぞれのツールをいい感じにまとめるとこんな感じ
概要 f:id:yoshitsugumi:20170203122846p:plain 思考(実行)の流れとの対応 f:id:yoshitsugumi:20170203113038p:plain

◆「こんな時はこれを使え!」ってやつははっきり言ってない。目的に合わせてカスタマイズして使うといいと思う。ただまぁ一応、オススメの使い方はこんな感じ。
毎日の個人の振り返り:YWT+経験学習モデル+α
イベントの運営振り返り:YWTかKPT
イベントでの参加者の学びを深める振り返り:経験学習モデル+グラフィックハーベスティング
チームの改善KPT
TOC現場コーチとしての計画と振り返り:LAMDA+YWT

◆振り返りやると日々成長してる感が半端ないのでみんなやったほうがいいよ。

迷った時はYWT

それぞれのツールってそもそもどういうものなの?

ということで今回まとめる対象にしようと思っている「振り返りツール」をあげておきます。

  1. YWT
  2. KPT
  3. 経験学習モデル
  4. 4行日記
  5. PDCA
  6. LAMDA

この6つですね。SECIモデルも似てると思うんですがとりあえずよく分かんないんで対象外。また、「振り返りツール」という言葉にもしかしたら違和感があるものもあるかもしれませんが、ここでは「よりよくするために、計画したり、振り返ったり、次の対策を練ったりすることを支援するツール」的な意味合いで「振り返りツール」という言葉を使いたいと思います。

それでは早速各ツールの説明をしていきたいと思います。

YWT

まずはじめにYWT(わい だぶる てぃ)です。

YWTとは、JMACの研究開発・技術開発コンサルティングの中 から生まれた概念です。Yが「やったこと」、Wが「わかったこと」 Tが「次にやること」という意味です。この概念は、世の中で一般 的に言われているマネジメントサイクル=PDCAサイクルに対抗 する概念として生まれてきました。

JMAC 株式会社 日本能率協会コンサルティング http://www.jmac.co.jp/mail/hrm/161mboywt.html

私が最初にYWTにであったのはとあるコンサルさんに、会社に来ていただいていた時で、3年くらい前だったと思います。その時は4-5時間くらいぶっ続けで濃い議論をした後、「やっと帰れるわー」ってなった後に、「じゃ、YWT(M)やりましょう!」って言われてました。それでプラス30分されるのが結構辛かったです。

ですが、思い返すとかなりいい流れだよねと思います。これやってないと、疲れて次やること忘れちゃって何も進まないとかになりがちだったので。皆さんもそんな経験ありません?
ちなみに、YWTの正式名称なのかどうかはわかりませんが、私たちが最初に聞いた時は以下の通りYWTMという名前でした。

  • Y:やったこと
  • W:わかったこと
  • T:(わかったことを活かして)次にやること(の候補)
  • M:(次にやることをやる)そのメリットは?

この M:メリット を書くことが T:次にやること を実行する原動力になるということだったと記憶しています。でも、あんまりこれをやることはないし、YWTMとして紹介されているサイトも多くはないですね。

個人的にMを書かない理由としては、「そもそもやりたいことを達成するための活動の振り返りだからわざわさMを書かなくてもTを実行する」というのが一番大きいと思います。

逆に言えば、みんなで何か活動をやっているときに、「実はあんまり乗り気じゃないんだよなー」「そのTってなんでやる必要があるの?」って人が多そうな時はMまでやったほうがいいんじゃないかと思います。

また、Tの所を次にやること(候補)としているのは私(なのか私の周りなのか)の独自運用です。とりあえずブレストでやったほうがいいかなーと思うことをいっぱい出しておいて、次やるときの計画で取捨選択する的な使い方。

ちなみにYWTはこんな感じで、継続していく活動(継続しない活動があるのかはさておき)に対して、つなげて見ていくこともできます。

YWTのフォーマット、運用方法

ヒビノメモ http://yu-hi.babymilk.jp/wp/work/post-9969/

ただ、実際これを本気で運用するとかなり大変だったりであんまりできていない。
精神的には、Tに書いたことをたくさんYに入れたくなる(やりたくなる)とか。
物理的には、Excelのシートが横長になるし、各行の行数が固定じゃないので、行が合わなくなってフォーマットが崩れてきたりとか。

そういう意味だと、KPTやLAMDAのほうがその、活動の継続的な意味合いでは使いやすいのかもしれません。

KPT

次はKPT(けぷと or けいぴーてぃー)です。今更説明する必要もなさそうですが一応。

行ってきた仕事や活動を振り返る際に、「継続」「問題点」「挑戦」の3つの視点で整理するフレームワークのこと。

ミーティングでは、ホワイトボードなどに「K:keep=今後も続けること」「P:problem=問題なので、やめること」「T:try=今後、試してみたいこと」の項目を用意し、メンバーが行ってきた活動報告の内容を「K」と「P」に振り分けていく。その後、「P」に対する解決策や新しいアイデアや企画を「T」欄に書く。

情報マネジメント用語辞典 http://www.itmedia.co.jp/im/articles/0905/19/news143.html

ちなみにフォーマットは配置が変わったり、表形式になったりすることもあるけど、だいたいこんな感じです。

KPTの書き方一例 ナカシマガジン http://hisa-magazine.net/blog/ref/kpt2/

基本的にはKPTとはこういうものです。ただ、ちょっと補足というか、個人的にこれだとしっくりこない部分がいくつかあるのでそれを書いておきます。

1.Keepについて

Keepを直訳すると「継続」でまさしく引用にある通り「今後も続けたいこと」を出す所になります。ただそれだと、「ちょーーっとしたいいこと」とか「(もう同じことはないと担当者が勝手に思っている)いいこと」が出てこない気がするんです。単純に言えばKeepのハードルがやけに高い。

自分もそうなんですけど、「良かったことはなんですか?」とか言われても「できて当たり前じゃない?」って思ってることってあんまり出さないんですよね。自分の期待値を上回る出来の時にやっと出すとかそういうイメージ。皆さんそんなことないですか?私の周りにはそういう人多いです。

ってことでKeepのハードルを下げたいので、Keepは「今回、何かできたことはなんですか?」「良かったことはなんですか?」「どんな些細なことでも結構ですよ」的な雰囲気でやるようにしています。

2.KeepとProblemの振り分けについて

引用文にはこうあります。

メンバーが行ってきた活動報告の内容を「K」と「P」に振り分けていく。

実は、KPTって個人的にはあんまり好きじゃなくて、その理由はこの辺にあります。この辺ってどの変かってことなんですけど、私の理解ではKPTは「やったことの思い出し」と「良かったか悪かったかの判断」を同時にやっているって認識です。頭の中のマルチタスク。なので、思考に集中できない。

  1. 「あれー、今週(今回、今日)って何やったっけー?」
  2. 「良かったことってなんだろう?」 or 「悪かったことってなんだろう?」

この二つを同時にやっているんです。そしてもっと言うなら、だいたいKPTはみんなで付箋を使ってやると思うので、自分が考えている時に他の人が「これ良かった」とかって言って付箋を貼りだして話が始まったりする。その瞬間、自分が何を考えていたか忘れるか、その人の話は聞いていないかのどっちかになる。

ってなるといい感じの振り返りに差し支えると思っています。なので、KPTをやるときは、「思い出しの時間」を別に取るとか、「個人でKeepやProblemを書く時間」と「貼りだしてみんなと共有する時間」をしっかり分けるとかそういう施策が必要なんじゃないかと思っています。

理想的かなーと思うKPTのまわしかたはこんな感じです。 f:id:yoshitsugumi:20170203105714j:plain

経験学習モデル

経験学習モデル(けいけんがくしゅうもでる)についてです。
この章は書きたくないなぁ。プロの人に怒られそう。笑

このへんを読むと、本当に意味するところは「経験学習モデル」なのか「経験からの学習論」なのかその辺の混成体なのか微妙な気がしてきたのですが、とりあえず説明しやすいので「経験学習モデル」で説明します。まぁ「学習における経験・実践」「経験の内省」の2つを重視するって意味でだいたい全部一緒なんじゃないのって感じなので実務上は気にしなくてもいいんじゃないかなぁ。だめ?

経験学習モデル概要

f:id:yoshitsugumi:20170203105711p:plain

だいたいこんな感じ。それぞれの箱の中身は人によってちょっと呼び方が違ったりするけど原典的には「具体的経験」「内省的観察」「抽象的概念化」「能動的実験」が正しいっぽい。

もうちょっと詳しく

自分が実際に経験したことから学びを得ることを「経験学習」と呼ぶ。経験から学ぶといっても,人は単に経験しただけで学べるわけではなく,経験を次に活かすためのプロセスが重要である。そのプロセスを理論化したものが,組織行動学者デイビッド・コルブによって提唱された「経験学習モデル」である。

コルブは、「経験→省察→概念化→実践」という4つの段階からなる経験学習サイクルを提示している。

学校法人 産業能率大学 総合研究所 http://www.hj.sanno.ac.jp/cp/page/10423

それぞれどういう意味かというと?学術的には

具体的経験:学習者が環境(他者・人工物等)に働きかけることで起こる相互作用
内省的観察:ある個人がいったん実践・事業・仕事現場を離れ,自らの行為・経験・出来事の意味を,俯瞰的な観点,多様な観点から振り返ること,意味づけること
抽象的概念化:経験を一般化,概念化,抽象化し,他の状況でも応用可能な知識・ルール・スキーマやルーチンを自らつくりあげること
能動的実験:経験を通して構築されたスキーマや理論を,実際にアクション(実践)すること

経験学習の理論的系譜と研究動向 http://www.jil.go.jp/institute/zassi/backnumber/2013/10/pdf/004-014.pdf

わかるようなわからないような。もう少し平易な言い方をするとこんな感じ。

経験:具体的な経験をすること。
経験:経験を多様な観点から振り返ること。
概念化:他でも応用できるよう概念化し自分の未来や、他の人が使えるように教訓にすること。
試行:新しい場面で実際に試してみる。

有限会社 テオリア http://www.teoria.co.jp/004/02/index.html

YWTやKPTなんかとの違いというか、特徴的なところは「抽象的概念化」ではないかと思います。私がこのモデルを使う時には、上の定義に書いてあるような、「他の状況でも応用可能なルール・スキーマ・ルーチンを作る」なんてところまではやってません。

じゃあどんな時に、どんなとこまでやってるかというとこんな感じ。
どんな時:個人の振り返り
どんな風に:抽象的概念化→どうしてそれに気づいたのか?どうしてそれが起こったのか?

概念化というより、気づきの深堀りをしているイメージです。  

気づきの深堀をするということは、「なんでそれが起こったのか?気づいたのか?」を考えることですし、それを考えると「どういう時に同じようなことが起きそうか?気づけそうか?」にも到達しそうです。そうすると、「お、こういう時はこうしたほうがいいんじゃないの?」っていう抽象的なルールパターンランゲージパターンみたいですね。)みたいなのも出てくるかもしれません。

で、毎度毎度パターン化するまで考えるとか日々の振り返りでは無理なのでちょっとした深堀くらいにとどめているイメージ。そして、たまにすごくヒットする気づきとかがあればパターン化してるとかそんな感じでしょうか。

4行日記

4行日記(よんぎょうにっき)についてです。まず概要。

4行日記というのは、言葉通り4行で完結する日記のことだ。FFS理論で有名な小林惠智氏によって考案され、多くの人に支持されている。書く内容は至ってシンプル。「事実」「気づき」「教訓」「宣言」の4項目を4行に分けて書くのだ。

U-NOTE http://u-note.me/note/47486698

4行日記の書き方について。

  1. 事実
    ここには今日合った出来事を振り返り、一番印象に残っていることやアンテナに触れたものを一つ選んで書き出す。
    (例)4行日記を始めた。
  2. 気づき
    ここには事実から得られた発見や感想などを書く。あまり深く考えすぎず自分が直感的に思ったことを書く。
    (例)日記を書き続けることで成長することができる。
  3. 教訓
    気づきからどのようなことを学んだのかを3行目に書く。自分に起こった出来事から学んだことを一般化、抽象化するとどうなるかが教訓だ。
    (例)継続は力なり。
  4. 宣言
    最後に自分がありたい姿を宣言して日記は終わりだ。ここでの書き方としては、自分がなりたい姿を現在進行形でなれていると仮定して断定することがポイントだ。
    (例)私は計画性を持った人間です。

U-NOTE http://u-note.me/note/47486698

ってことでなんとなく先述の経験学習モデルと似てる気がしませんか?実際はどうなの知りませんが、私はほぼ同じものとして考えています。一応、違うんじゃないかなーと思う点としてはこんなところでしょうか。

  • 4行日記のほうが毎日の振り返り用に簡単化されている点
  • いくつか書き方にルールがある点
  • 「宣言」の書き方に「心理効果」を持たせようとしている点

PDCA

みなさんご存知PDCA(ぴーでぃーしーえー)です。

PDCAサイクルとは

PDCAサイクルPDCA cycle、plan-do-check-act cycle)は、事業活動における生産管理や品質管理などの管理業務を円滑に進める手法の一つ。Plan(計画)→ Do(実行)→ Check(評価)→ Act(改善)の 4 段階を繰り返すことによって、業務を継続的に改善する。

Wikipedia https://ja.wikipedia.org/wiki/PDCA%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB

社会人なりたての頃はよく「PDCAが大事だ!」って言われましたが最近はあんまり言われない気がします(そんなこともないのかな?)。今回あげた6つのツールもPDCA以外の奴は「経験から学ぶ」系のやつです。対してPDCAはどちらかといえば「計画に重きを持った理論」と捉えられがちな気がします。

PDCAの利点は、計画を意識することだが、それゆえに振り返りが浅くなることがあるという話もあるし、【計画⇒実行⇒点検・評価⇒学習(振り返りと概念化)⇒処置改善】とすれば、PDCAサイクルに経験学習が上手に溶け込むという話もあるしで。

個人的には、なんとなくPDCAは他の振り返りツールより一個上の概念なのかなぁってイメージです。また、本当に初めてやること、新規開拓系だとPをいくらやってもどうかな?って話があるので「とりあえず経験・実行だろ」的な話がよくされてるのかなって感じで。

とはいえPDCA(ないしはPDSA)は素晴らしいモデルで今でも十分生きているモデルだと思います。

LAMDA

最後にLAMDA(らむだ)です。

PDCAサイクルの発展版「LAMDAサイクル」 PDCAサイクルの「発展版」として、LAMDAサイクルという概念を紹介したいと思います。このサイクルは、MITにてトヨタ製品開発を参考に「リーン生産方式」を体系化したアレン・ウォード博士によって開発されたものです。

LAMDA(Look−Ask−Model−Discuss−Act)サイクル

LAMDAサイクルとPDCAサイクルの比較を端的に言うと、以下のポイントに集約できます。

  • 机上で考える前に現場に赴いて「現地現物」を確認すること
  • 一人で考えるのではなく、他者との「双方向コミュニケーション」を通じて問題の所在を明確にすること
  • 抽象的に考えるのではなく、無理矢理でもいいのでサービスや商品を具体的な「プロトタイプ化」すること
  • その具体的なプロトタイプに対する他者(含む顧客)からの「フィードバックを吸収」し、知恵として取り込むこと

つまり、PDCAの裏側に「現地現物」「双方向コミュニケーション」「プロトタイプ化」「フィードバックの吸収」という4つの行動原則をセットで持つことが、現場のミドルリーダーにとってより効果的なPDCAの実現につながると言えるでしょう。

東洋経済ONLINE http://toyokeizai.net/articles/-/9724?page=7

これだけだとわかりづらいと思うのでもう少し引用します。
まずLAMDAはPDCAの発展版ということなので、PDCAのどこと対応するものなのかを図示するとこんな感じらしいです。

The PDCA and LAMDA
f:id:yoshitsugumi:20170203105719p:plain
The Triz Journal
https://triz-journal.com/lamda-and-triz-knowledge-sharing-across-the-enterprise/

ちょっと自分なりに説明してみます。
PDCAではPが最初に来ます。このPの段階で現場を見ないでずーっと計画を練っているだけだとどうしても机上の空論になる可能性が高くなり、動き出しも遅くなったりします。そこでまず「現地現物」ということで実際に見に行こうということです(Look1)。  

そしてその実際に行った先で質問をします(Ask1)。そこでの質問とはこの2つです。

  1. What do we already know about this?
    (私たちはすでにこれについて何を知っているか?)
  2. Why?
    (なぜか?)

The Triz Journal https://triz-journal.com/lamda-and-triz-knowledge-sharing-across-the-enterprise/

場合によってはここでなぜなぜ5回で深堀りします。

次はこの質問、なぜ、で知りえたこと、考えたことをシンプルにモデル化します(Model1)。メンタルモデルっぽいですね。physical models, like prototypes or visual models,such as sketches, pictures, charts and graphs(プロトタイプやスケッチや写真、図表、グラフなどの物理モデル)がこれにあたるらしいです。でも実際、我々は製造業ではないのであんまり物理モデルを作るってことはなく、文章でまとめることのほうが多いです。改善ボードの運用方法や朝会の運営なんかは物理的なものを見ながら考えたほうがいいかもしれませんね。

そしてここまで考えたことを関係者、ステークホルダー(実際にそれを行う人も含む)で議論します(Discuss1)。これによって、実行アイデアが洗練され、実行に対するハードルも下がります。

で、実行する(Act1)。

ここまででPDCAのPDまでです。CAはPDと一緒ですね。要はこういうことです。 1. PD:(現地現物で)仮説を立てて試す 2. CA:実験結果の確認を(現地現物で)行い、必要に応じて計画を調整し、再度計画を実施する

要は上で引用している通り、重要なのは

  • 何はともあれ現場。現地現物で考える。見に行く、実際にやる。
  • 考えるだけじゃなくてモデル化する。書く。作る。演じる。
  • 他者からのフィードバックをもらう。修正する。

ってところです。

ちなみに実運用上はこんな感じに表形式にして、シーン(Lookしたとき)毎に気になったこと、考えたことをずっと書いていくという使い方をしています。

No. 記入日 Look(場面) Ask(質問、課題) Model/Discuss(解決の方向付け、議論) Act(実際の適用、その結果)
1 2017.02.03 朝会へ訪問 質問や入力が形式的なものだけで、形骸化しているように見える 朝会目的は明確か?リーダーは把握してる?メンバーは?たまたま今日だけ?いけてる朝会のやり方がイメージできてないだけ?どうやって対応する?次回訪問時にxxxをアクションする?その前にxxxとメールする?→メール+訪問時のアクションxxx。  

各ツールのまとめ

各ツールのことを少しまとめておきます。

概要 f:id:yoshitsugumi:20170203122846p:plain

思考(実行)の流れとの対応 f:id:yoshitsugumi:20170203113038p:plain

こうやって書き出すと、やっぱりPDCAとLAMDAは、それ以外のやつとちょっと違った感じがしますね。計画のところ。

また、今回は「振り返りツール」ということでまとめていますので、「1.目標を設定する」はちょっと毛色が違うかもしれないですが、あえて書いています。なぜなら振り返りって、「そもそも何を達成するための振り返りなの?」ってところがないと、なかなか機能しないと思うので。

ここの、目標設定についてもいろんなツールがあると思うのでいつかまとめるかもしれません。

各ツールを使うシーン

正直なところ、上の説明とかを読んで、好きな時に好きなやつを使ってみて、違うなーと思ったら変える(他のツールに変える、ツールのフォーマットを変える、運用を変える、伝え方を変えるとかとか)ってやってもらえるといいかなと思っています。

が、それだけだとあんまりに手探りな感じもするので、一応私がどんな時にどんなツールを使っているかを書いておきます。

毎日の個人の振り返り

YWT+経験学習モデル+αでの振り返り

一応、毎日個人で振り返りをすることにしています。(できない日も多いのですが…) 夜に振り返るようにすると飲み会やら疲れてるやらでもっとやらないことが多かったので、朝、前日分を振り返るようにしています。

仕組み的なとこでは、IFTTTで毎日朝5時に、Evernoteに振り返り用noteを作る設定にしてる感じです。

フォーマットはこんな感じ。

  • 【事実】 今日あったこと、やったこと
  • 【気づき】 気づいたことは何ですか?起きたことは何ですか?
  • 【分析】どうしてそれに気づきましたか?どうしてそれが起きたのですか?
  • 【教訓】明日から何ができそうですか?
  • 【宣言】明日から何をやりますか?
  • 【今日の気持ち】(Good、まぁまぁ、うーん)

ベースは4行日記っぽいですが、実際はYWTです。対応はこんな感じ。

  • 【事実】→Y,具体的経験
  • 【気づき】→W,省察的観察
  • 【分析】→W,抽象的概念化
  • 【教訓】→T,能動的実験
  • 【宣言】→T,能動的実験
  • 【今日の気持ち】→なし

YWTだと、Wの深掘りが足らなくなるのでそこを分割している感じというか。【教訓】って言葉があんまり好きじゃないのと、いきなり教訓が書けないので、【分析】というところを追加してるというか。まぁそんな感じです。いろんな変遷があってこの形に落ち着きました。

ちなみに【今日の気持ち】は、コンテントに向きがちな自分の、プロセス(特に感情面)の内省を促すために残しています。そう、振り返りって気持ち大事。【気づき】のトコにも気持ちをちゃんと書けるようになると、今まで見えなかったものがたくさん見えてくるようになるよーと。偉そうに言ってみたり。

イベントの運営振り返り

YWTかKPT

どっちでやることもあります。自分主体でやるときはYWTが多いかな。周りに任せるときはKPTが多いです。KPTのときもできるだけ「思い出し」のために、写真を見るとか、アンケートを読むとか、アジェンダやスライドを見返すとかするように働きかけています。

イベントでの参加者の学びを深める振り返り

経験学習モデル+グラフィックハーベスティング

新しい言葉が出てきましたね。グラフィック・ハーベスティング。ちゃんと説明するとまた長くなっちゃうんで簡単にだけ。この写真みたいに、イベントの内容をスレンチボードや模造紙、ホワイトボードなんかに絵や文字を使って書いていく手法を「グラフィック・レコーディング」と言います。 f:id:yoshitsugumi:20170203105706j:plain

そしてこのグラフィクを用いて、「その場(イベント)の対話」を「行動につなげる」ための「考え方」が「グラフィック・ハーベスティング」になります。まぁグラフィックを使って内省、気づきを増やす深めるってことでだいたい合ってます。

イベントでは、リアルタイムにその場の流れだけでなく、感情などのプロセスもかいていき、途中で参加者に「みなさんの中でこんな話がありましたね」とか「私はこんな風にこの場を見てましたよ」とかっていうフィードバック(ハーベストバック)をしていきます。

そしてだいたいイベントの最後で「気づいたこと、わかったこと、思ったこと」「明日からやれそうなこと」などを付箋に書いてもらったり、リフレクションシート(経験学習モデルを平易な言葉で表したシート)を書いてもらったりします。

これによって、イベントをただ「楽しかった」「いろんな人と話せて良かった」という次元で終わらせないような工夫をやっています。

チームの改善

KPT

チームでは予定表というか、みんなの状況がわかるようにしてある物理ボードを立てて見える化をしているんですが、その中に「いつでも書けるよ」っていう位置付けのKPTボードがあります。

「これってなんだかなぁ」とか、「これ良かったよ」ってことをその場その場で書いていく感じ。いつみんなで確認するかというと、急ぎのやつは朝会だし、そうでもないのは週一回の全員集まるミーティングで確認するって運用になってます。

でも今これ書いてて思ったのは、そういえばやっぱりうちのチームも「これ良かったよ」ってのはあんまり貼られないなぁと思った。周囲の「良かった」を見るスキルをあげないといけないのかもしれない。

TOC現場コーチとしての計画と振り返り

LAMDA+YWT

TOC現場コーチって、まぁアジャイルコーチみたいなものだと思っています(知らんけど)。
TOC(全体最適理論)などを使って、現場を良くしようってのが一応メインの仕事のうちの1つなんですけど。

現場を良くするのって誰なのよっていうと、うちらじゃないんですよね。現場です。もちろん、現場とうちらを合わせて「私たち」と呼ぶことはあるんですが、基本的には現場で物事は動いていくし、いつもそこにうちらはいることはできないです。

なのでね、遠い離れたところで「あーでもない」「こーでもない」とかって考えてるとそれこそ机上の空論で、変な方向で話が進んじゃったり、なぜか現場を悪者にしちゃったりとかなっちゃう。

だからまずは現場だろうということでLAMDA。Look重要。

そして大きなくくりではLAMDAを使って考えて、一回一回の訪問はYWTで簡単に記録、振り返りするってのが定番になっています。そう、YWTって結構、議事録というか、記録的な意味合いも大きいんですよね。

最後に

みなさんいかがだったでしょうか?振り返り6ツールのまとめ。
私なんかは元々、「やる」ところに意識が向いてしまってなかなか「振り返る」ってことをしてきませんでした。「振り返り」って後ろ向きなイメージじゃないですか?復習とかも一緒なんですけど。「一回やったことをもう一回やる」みたいなのが無駄に思えていて。

しかし、やってみるとたくさんの気づきを得られて、成長を実感出来るものなんだなということがわかりました。決して後ろ向きなものではなく「次につなげる」「より良くなる」ためのものなんだなというのがよくわかりました。

ツールがたくさんあって、どれを選べばいいかわからないという方、とりあえずYWTが一番オススメなので、これで始めてみて「違うな」と思ったら何が違うのかを振り返りつつ、より良いやり方を見つけてみてください。

では、より良い振り返りライフを!

awsにdockerを入れてWekanを動かしてみた

今朝は5時に起きました。
それでいつも通り走りに行き、帰ってきて前日の振り返りをしていたのですが、どうも冬の休み期間中に目標にしていたAWS上でbootstrap3で遊んでみるとか、サーバーサイドアプリを作ってみるとかそういうのが難しいのでは?と考え始めました。

そもそもが、「冬休み期間」っていつまでやねんってところだったですし、あんまり考えなしにやりたいことをリストアップして、毎日ちょっとづつやるスタイルで始めていたのでまぁそうなるよねって感じなんですが。

やっぱりここはTOCの人としては作業管理だろうと思いまして。
作業管理っていうか、作業のリストアップと見積もり、優先順位付けをして実績と比較して次の計画を立てる的なあれです。

ということで、「カンバン フィボナッチ」で検索。

こちらのサイトが面白そうだったので参考にさせていただきました。
Namiking.net オープンソースのかんばん式管理ツールを3つほど試してみた

TAIGA
https://taiga.io/
Wekan (旧LibreBoard)
http://newui.libreboard.com
Restyaboard
http://restya.com/board/

TAIGAは以前ちょっと使ってみたことがあります。
そしてWekanは会社の先輩がdockerに入れて現場に提供していた記憶があります。 Restyaboardは知りません。

ということで導入と使用方法が比較的簡単そうなWekanをAWSにdockerを入れて使ってみようと思いいろいろやりました。

dockerのインストール

AWSのイメージはUbuntuなのでこれを参考にdockerをインストール。
https://docs.docker.com/engine/installation/linux/ubuntulinux/

OSのリリース番号を調べる

$ uname -r
4.4.0-57-generic

4.4.0とかそういうやつですね。新しい。

パッケージ情報の更新と、「https動作」「CA証明書のインストール」確認

$ sudo apt-get update
$ sudo apt-get install apt-transport-https ca-certificates

GPGキーのローカルキーチェーンへの取り込み

$ sudo apt-key adv \
               --keyserver hkp://ha.pool.sks-keyservers.net:80 \
               --recv-keys 58118E89F3A912897C070ADBF76221572C52609D

GPGキーについてはこちら を参照。

対応するリポジトリを探す

Ubuntu version Repository
Precise 12.04 (LTS) deb https://apt.dockerproject.org/repo ubuntu-precise main
Trusty 14.04 (LTS) deb https://apt.dockerproject.org/repo ubuntu-trusty main
Wily 15.10 deb https://apt.dockerproject.org/repo ubuntu-wily main
Xenial 16.04 (LTS) deb https://apt.dockerproject.org/repo ubuntu-xenial main

この表の中から自分の環境にあったリポジトリを調べておきます。
私の場合は一番下のXenialですね。
ちなみに$ cat /etc/lsb-releaseUbuntuのバージョンを調べられます。

dockerの取得先を定義して読み込む

echo "<REPO>" | sudo tee /etc/apt/sources.list.d/docker.list

このの部分を↑で見つけといたリポジトリに置き換えて実行する。
ちなみに私の環境だとこうなりますね。

echo "deb https://apt.dockerproject.org/repo ubuntu-xenial main" | sudo tee /etc/apt/sources.list.d/docker.list

で、この定義したファイル(/etc/apt/sources.list.d/docker.list)を読み込む。

sudo apt-get update

Linuxカーネルのパッケージを追加する?

sudo apt-get install linux-image-extra-$(uname -r) linux-image-extra-virtual

ちょっとよくわからないんですがaufsストレージドライバー的なものをdockerが使えるようにするために「linux-image-extra-$(uname -r)」「linux-image-extra-virtual」とかが必要と書いてあるのでそのまま実行。
前後でdpkg -l | grep linux-imageを実行してちゃんとインストールされたことを確認しました。

dockerのインストールと起動

$ sudo apt-get install docker-engine
$ sudo service docker start

やっとですね。これでdockerが動き出しました。

ユーザーをdockerグループに追加

$ sudo usermod -aG docker $USER

毎回sudoをつけてdokerを操作するのが面倒なので、普段操作するユーザーをdockerグループに入れます。

docker-composeの導入と必要なdockerイメージを取得する

ここからは主にこちらを参考に。
Namiking.net Wekan on Dockerでお手軽かんばん式プロジェクト管理

docker-composeってどうも、複数のdockerコンテナを使ってサービスを提供する場合なんかに、一個ずつ立ち上げるの面倒だね、とか立ち上げる順番が関係する、とかいろいろあるらしくその辺を定義ファイルに書いておけばコマンド一つで複数のdockerコンテナが立ち上がる というものだと理解しました。間違ってたらごめんなさい。誰か教えてください。

docker-composeのインストール

$ pip install -U docker-compose

これでインストールできます。ちなみに私の環境にはpipがなかったので事前にsudo apt install python-pipを実行しておきました。

必要なdockerイメージを取得する

$ docker pull mquandalle/wekan
$ docker pull mongo
$ docker pull busybox

この辺りが必要そうだったのでpullで取得。

docker-compose.yml 設置

data:
  image: busybox
  volumes:
    - /data/db

mongo:
  image: mongo
  volumes_from:
    - data
  restart: always

wekan:
  image: mquandalle/wekan
  environment:
    MONGO_URL: mongodb://db
    ROOT_URL: http://example.com:8080
  links:
    - mongo:db
  ports:
    - "8080:80"
  restart: always

カレントディレクトリの下にdocker作業用のフォルダを作って、その配下に、上記内容でdocker-compose.ymlを作成。(作成場所ってこんなところでいいんだろうか?)
ROUT_URLは自分のAWSのURLにしました。適宜修正してください。
ちなみに最初は「http://localhost:8080」と書いて動かしていたんですが、一部(カンバンにカードを追加した後のカード詳細入力画面)でURLがおかしくなってしまって動かなかったのでAWSのURLに書き直しました。

そういえばこの時、一度作ったdockerコンテナを全部削除(docker stop, docker rm)したのでWekanで作ったユーザーとかも消えてしまったんだけど、必要な部分だけ修正してデータを残すなんてっことはどうやったらできるんだろう?

Docker起動

$ docker-compose up -d

これで、docker-compose.ymlで定義した3つのdockerコンテナが動きます。

動作確認

http://(SERVER_IP):8080/

動作確認します。以下画面が表示されれば成功です。
f:id:yoshitsugumi:20170103150040p:plain

カンバンの画面

f:id:yoshitsugumi:20170103150057p:plain こんな画面でタスクの管理をやっていくみたいです。

最後に

aws上にdockerを入れてWekanを動かしてみるというのをやってみました。
意外に短時間でできたので興味ある方はやってみてはいかがでしょうか?
私の場合はdockerのことも知らな買ったし、ubuntuもほぼ触ったことないしでいろいろ調べながらで4時間かかりましたが、次からは数十分でサービスを構築できそうな気がしています。

ちなみに、当初の目的だった作業の見積もりや優先順位付け、実績との比較みたいなのがWekanではできないみたいです。(ぱっと見できなそう。工夫すればできるかもだけど)
全く目的は達成できなかったけど、よくわからない達成感は感じてしまっているこの状態。
ダメですね。頑張ります。

AWSのアカウントを作った目的

先日AWSのアカウントを作成しました。
yoshitsugumi.hatenablog.com

そもそもなんで作ったのって話なんですけどね。実はこれです。
yoshitsugumi.hatenablog.com

この記事のこの部分。

2.awsにいろいろ公開する
3.bootstrap3を触ってみる
4.java,phpなど?でサーバサイドのアプリを作る
5.google maps api v3を触ってみる

そう、java,phpなどサーバサイドアプリとか、bootstrap3とかjquery,css3,html5,google maps api v3とかとか。いじった結果をブログに載せたいので、その公開先が欲しいなぁと思って。そしてawsの無料枠でできそうだしアカウントもう一回作り直そうと思ってやっていた感じです。

ちなみに2年ほど前に作った前のアカウントは自分のブログをwordpressとかで作りたいなーとか、当時ちょっとサービス化したいアイデアがあったのでそれを公開しようかなとか思ってたんですが、hallo woldで面倒くさくなって放置してたって落ちです。

AWS上のインスタンス作成状況

今の所こんな感じの作業を終えたところです。

  • 固定IPアドレスの取得
  • SSHでのリモートログイン設定
  • ホスト名設定
  • タイムゾーン設定
  • NTP設定
  • 日本語環境の導入
  • 仮想トンネルでのリモートログイン設定
  • apache2のインストール
  • ドメインの取得(もともと取得していたものの使い回し)

この後、ドメインの設定やphp,tomcatなんかをいろいろやってから画面やらサーバやらでいろいろ作ってみようかなと思っています。

ちなみにapache入れた後から仮想トンネルでリモートログインすると、結構すぐ画面が固まるんだけど理由がわからない。
困った。

英語学習メモをgitで管理し始めました

英語学習をやっています

最近、ずっと英語を勉強しています。
目的としては一応、2年後くらいの海外移住に向けてということで。
今現在の自分の実力はこんなところです。
f:id:yoshitsugumi:20170102161434p:plain

これ、12月上旬に受けたんですけど実は自己最高記録だったりします。
会社でTOEICの講座(TAC)をやってくれていまして、それを10月くらいからだったかな?それを受講しています。そのおかげなのか点が昔よりだいぶ伸びた感じがします。
LISTENINGはほぼ横ばいだったんですがREADINGが50点くらい上がった感じです。
195点でそれって、元はどれだけあれだったんでしょうね。

自宅での英語学習方法

今までいろんな方法で英語を勉強しました。
f:id:yoshitsugumi:20170102161457p:plain

  • 英文丸暗記&シャドウイング(ダイアローグ1200全部と1800を途中までやりました。)
  • 中学校の英語教本を覚える(途中で挫折。)
  • NHK英語講座(3ヶ月分くらいやった気が。)
  • 英語小説を読む(村上春樹や帰ってきたヒットラーを。2pageくらいでやめてます)
  • and more

ということであんまり何も続けられていない状況だったのですが、とりあえず今はTACの講座だけは全部やってやろうかと思ってやっています。

で、これ、自宅学習用のWeb動画があるので、それを1日数個やろうと思ってやってました。↓こんなやつですね。
f:id:yoshitsugumi:20170102161515p:plain

疑問

とそんな時ちょっとした疑問が湧いてきました。
「あれ、英語勉強しだしたのってTOEICの点数上げるためじゃなかったわ。この勉強方法で大丈夫なんだろうか?」と。

この自宅学習用のWeb動画って結構、TOEICのコツみたいなことを教えてくれたりするんですよね。

  • 最後の選択肢を読むまではマークしない
  • 長文読解のやつは1番目が簡単、2番目が一番複雑で、3番目はわりかし解ける可能性がある。
  • 500点とるにはPART何なにで何点取らないとダメ(500点突破のための講座なので)
  • 説明が読まれてる時に次の問題を先読みする

とかとか。まぁそれも点数取る上では大事なテクニックなんでしょうけど、今の自分の優先順位的には低いなぁと。テクニックに頼らない、英語の底力みたいなのをあげたい、そのためにたまたま継続できそうな「TAC」の講座を受けていたんだ、と思い出しました。

それでどうするか?

ということで、「TAC」の講座で提供してくれている中から、自分が海外移住するために必要そうなエッセンス部分を抜き出して重点的に勉強することがベストだと考えました。 その結果、たどり着いたのが以下2点。

1. vocabularyと言い回しを覚える
2. 英語の音が聞き取れるようになる

ええ、たいそうな感じにずっと書いてきましたが当たり前のことです。
TACの講座でもこれは大事と言われているのでまぁ共通するところですよね。
TACではこれにもう一つ「文法」が入ってくるんですが、まぁそこはとりあえず後回しに。
多分ですけど、海外(東南アジアだと特に)そーこまで文法あってなくてもなんと無くやっていけるんじゃないかと思うんですよね。probably。

で、gitって?

そう。それでですね。
「2. 英語の音が聞き取れるようになる」こっちはもう、得意のシャドウイングですね。聞き取れない文章とか口が追いつかないところを重点的にシャドウイングして、スラスラ言えるようになるまで頑張る。それしかない。それ以外の勉強方法を知らない。(なんかいいのがあったら教えて欲しいです。)

そしてこっち。
「1. vocabularyと言い回しを覚える」
この、単純暗記みたいなの昔から超絶苦手なんですよね。単語カードみたいなの作るところで飽きちゃうとかしてて昔からあんまり覚えてこなかった。
ここにgitを使おうかと。

今は、そのTACのWeb動画とかテキストをやっていて、わからない単語や表現があると、PCに打ち込みながらメモをとっています。
で、これって読み返すのか?というとあんまりそうでもなかったりして。だから「わかんない」ってメモったやつってよっぽど印象に残ってるやつ以外は「あーそんなのあったわ」とか「????」状態になるんですよ。

ってことでやっぱりここは初心に戻って「復習」「反復」だろうと。
そしてそのためにはいつ何をやったかの履歴みたいなのがあるといいかなと。
履歴といえばバージョン管理。バージョン管理といえばgitやね。ってことでやっとgit。

ちなみに、今PCメモへのまとめ方として、「テキスト」「単語」「問題集」に分けて記入していることや、前にやったところに追記したりすることもあるというのが差分をわかりにくくしている要因でもあったりします。

sourcetreeを導入

コマンドラインからgitで管理してもいいんですが、あんまりgitにまだ慣れていないのでGUIベースでやっていきたいなと思ってsorcetreeを導入しました。

https://ja.atlassian.com/software/sourcetree

インストールと設定方法はこの辺りを参考にしたようなしてないような。
http://qiita.com/naoki85/items/c7660d70347e9e70b201

で、markdownファイルをまとめているフォルダ全体をローカルリポジトリに指定して管理を開始。
最初ちょっと戸惑ったのが、コミット対象のファイルをステージング(add)する方法がわからなくて。結果、ステージングしたいファイルを選択して右クリック、「indexに追加」でできるっぽいことを発見。
f:id:yoshitsugumi:20170102161536p:plain

でコミット。を繰り返す。
今の履歴はこんな感じ。 f:id:yoshitsugumi:20170102161550p:plain

ってことで明日はこの今日の差分のところを重点的に復習して、そして明日分の勉強をするってのを繰り返して、単語とか表現を覚えていきたいなと思っています。

今この記事を書きながら気になったこととしては、ブログ投稿用のファイルもローカルリポジトリに入れてしまったので(ってかmarkdownでのメモ全部)英語学習の差分コミットだけ抜き出してみるの面倒だなってこと。
コミットにタグみたいなのつけられないのかな?
ちょっと調べてみよう。

AWSのアカウントを作成する

はじめに

タイトルの通りです。
実は2年くらい前に作ったアカウントを持ってたりしますが、今回新しくもう一個アカウントを作ろうかと。
なぜならばもう一度最初からAWSのアカウントの作成方法をおさらいしておきたいからです…!
(本当は無料期間を優に超えている旧アカウントから、新規に作成したアカウントに乗り換えたいから) 

 

手順

というわけでアマゾンのサイトにアクセスします。

aws.amazon.com

サインアップ

f:id:yoshitsugumi:20161231151558p:plain

 まずはともあれサインアップをクリック。

f:id:yoshitsugumi:20161231152707p:plain

こんな感じの画面になるので、連絡を受け取ったりしたいアドレスを入れて「私は新規ユーザーです。」を選択してサインインをクリック。

ログイン認証情報の入力

f:id:yoshitsugumi:20161231153002p:plain

初期状態では2行目のEメールアドレスに前の画面で入力したアドレスが入った状態になっているので、その他を入力してアカウント作成をクリック。

このアドレスはアマゾンからの連絡用(お金が発生し出すと請求書を送ってきたりする)のものなのであんまり見ないなーってアドレスにしているとふと気付いた時やばいことになってる可能性も。

ちなみに名前は本名じゃ無くてニックネームでも可です。

連絡先情報の入力

f:id:yoshitsugumi:20161231153158p:plain

アカウントは今回の場合は「個人用アカウント」を選択です。
その他記載の通りに入力してください。

余談ですけど、この「セキュリティチェック」って一発で通ったことないです。わかりにくくて何回か「イメージの更新」をした後に入力しても間違ってたり。これ得意な人とかいるんですかね?

最後にカスタマーアグリーメントを読んで同意したら「アカウントを作成して続行」をクリック。

支払情報の入力

f:id:yoshitsugumi:20161231162527p:plain

f:id:yoshitsugumi:20161231162527p:plain

無料枠内で使おうとしているのでいらない気もするんですが必須なので入力します。

先にも述べましたが、実はもう一つAWSのアカウントを持っていて、何もしてませんが月々5ドルほどアマゾンさんにお支払いしています。その支払いと同じクレジットカードを入力しても、新アカウントは無料枠が適用されるのか?という疑問があるのですがアカウント作成後3日目の今は特に何も言われてないので多分いけると思います。

入力し終わったら「次へ」をクリック。

本人確認

f:id:yoshitsugumi:20161231154924p:plain

また来ましたね…。セキュリティチェック。ここでも3回ほど間違えました。何回以上間違えたらダメとかあるんでしょうか?なんか他のサイトとかでは一定時間以上待ってからもう一回やれ的なことを言われたようなそうではないような。

それは置いといてセキュリティチェックの文字を打ったら、「すぐに連絡を受ける」をクリックします。うまくいったら次の画面の状態になります。

f:id:yoshitsugumi:20161231155032p:plain

これと並行して、連絡先に指定した連絡先に女の人の機械音声(日本語、非通知)で電話がかかってきます。

f:id:yoshitsugumi:20161231155457p:plain

「キーパッド」にしてWebの方の画面に表示されている4桁のPINを入力しましょう。すぐに認証が完了します。

ちなみに、私はせっかちなので電話がかかってきてすぐにPINを入力したら「違うからもう一回入力しろ」と言われました。読み取り開始のタイミングみたいなのがあるっぽいので、確実さを求めるなら、アナウンスで「今から入力してね」って言われてから入力しましょう。

f:id:yoshitsugumi:20161231155556p:plain

認証が完了するとこの画面になるので、「続行してサポートプランを選択」をクリックします。

サポートプランの選択

f:id:yoshitsugumi:20161231161100p:plain

ベーシックです。これを選択しましょう。
まぁ他のを選んでもいいんですが、awsの人に聞家内とできないようなことをする予定はないので。

選択後、「続行」をクリック。

アカウント作成完了

f:id:yoshitsugumi:20161231161312p:plain

やりました!念願のアカウントが作成できました。

退会

ちなみに、この記事を書くためにもう一回アカウントを作成したので、この時点で計3つのアカウントを持っている状態になっていました。ということで1つ削除。

f:id:yoshitsugumi:20161231161618p:plain

アカウントをクリック。すると別タブで画面が開くので一番下までスクロールすると解約部分を発見。

f:id:yoshitsugumi:20161231161709p:plain

チェックして、「アカウントの解約」をクリックする。

f:id:yoshitsugumi:20161231161809p:plain

再確認を促すダイアログが出てくるので「アカウントの解除」をクリックします。

f:id:yoshitsugumi:20161231161900p:plain

すると、ブラウザの上部に緑色の文字で「アカウントは解約されました」と出るのでこれで解約完了です。

変なアンケート書かされたりとか、こんなメリットあるよとか、Yes/Noの配置を逆にしてみるとか、退会用の紙が送付されてくるとか無くて非常にスムーズですね。

どこかの携帯事業者や通信事業者にも見習って欲しいです。

次は中身のいろいろ設定をやっていこうかなと思います。

atomパッケージについてあれこれ

英語の勉強をしていて結果的にatomのpackageについて勉強できたのでそのまとめ。

経緯

今日はいつも通り朝5時に起きてランニング。
風呂、朝ごはんと来て英語の勉強をしていました。
(今日始めた習慣だけど)

それで単語の勉強やらなんやらやってたんですよ。
英文を聞きながらタイピングしたりとか、見ながらタイピングしたりとか。
(効果あるのか?)

それで、最近ブログ投稿用やらメモやらにAtomを使っているのでそこに文章を打ち込んでいました。
こんな感じ。
(赤枠の所が入力してるところ。markdownで記載。右側はそのプレビュー)

f:id:yoshitsugumi:20161230152309p:plain

で、わからない単語とかもあるじゃないですか?
chromeとかだと英文選択すると、翻訳結果が出るように設定してるんですが、Atomではどうやってやるのかわからなかったので、とりあえず「atom 翻訳」「atom 辞書」とかでググってみました。

そこで見つけたパッケージがこれ。
[英和/和英の辞書を引くためのAtomパッケージ]
https://github.com/hokaccha/atom-japanese-dictionary

いつも使っているWeblioにも対応しているしええやんってことでインストール。
で使ってみたらこんな感じ。

f:id:yoshitsugumi:20161230152326p:plain

ん?右のペインにweblioの画面が出てきて、選択した単語が検索されているけどなんか高さが足りないぞ?
どこかの設定でいけるかと思いきやなさそうなのでパッケージをいじってみることにしました。

パッケージの場所

Atom > 環境設定 > 設定フォルダを開く でパッケージたちがいる場所にいけます。

f:id:yoshitsugumi:20161230152332p:plain

ここをクリックすると、新しいウィンドウが立ち上がってこんな感じになります。

f:id:yoshitsugumi:20161230152328p:plain

インストールしたパッケージたちはここに入ってるんですね。
ちなみに、このルートの.atomフォルダはホームディレクトリ?の直下にあるのでfinderでも普通に開けます。

パッケージの中の構成

f:id:yoshitsugumi:20161230152312p:plain


パッケージの中身はこんな感じになってました。
なんとなく多分、それぞれこんな感じ。

  • keymaps
    ショートカットコマンドを定義するところ。
    CSON(CoffeeScript-Object-Notation)
  • lib
    パッケージの中身。メインの内容。
    coffeescript
  • node_modules
    ライブラリ集?いろんなファイルが入ってます。
  • styles
    見た目の定義とかを書くところ。
    less(Leaner CSS)
    このフォルダは私が追加したものです。後述しますが、結果的にこのファイルを追加することでweblioの単語検索結果画面を大きく表示するように修正しました。
  • package.json
    最初に読み込むファイルを記載したり、ファイルの読み込み順を指定したりっぽい。詳細は以下を参考に。
    http://qiita.com/k2works/items/1d25888fb3a05058e48f

だいたいこんな感じ。

パッケージの中身

このjapanese-dictionaryには「ダイアログボックスによる英単語検索」「選択範囲のテキストの英単語検索」の2つの機能がありまして、lib配下の2ファイル「japanese-dictionary-dialog.coffee」「japanese-dictionary.coffee」に対応しているみたいです。

ダイアログボックスからの検索は使わないので、とりあえず「japanese-dictionary.coffee」を見てみます。

japanese-dictionary.coffee

JapaneseDictionaryView = require './japanese-dictionary-view'
Dialog = require './japanese-dictionary-dialog'
{CompositeDisposable} = require 'atom'
url = require 'url'
 
module.exports =
  config:
    service:
      title: 'Service'
      type: 'string'
      enum: ['weblio', 'alc']
      default: 'weblio'
 
  activate: ->
    @subscriptions = new CompositeDisposable
 
    @subscriptions.add atom.commands.add 'atom-workspace',
      'japanese-dictionary:open-by-selection': => @openBySelection()
      'japanese-dictionary:open-by-input': => @openDialog()
 
    @subscriptions.add atom.workspace.addOpener (uriToOpen) =>
      try
        {protocol, host, pathname} = url.parse(uriToOpen)
      catch error
        return
 
      return unless protocol is 'japanese-dictionary:'
 
      new JapaneseDictionaryView(word: decodeURIComponent(pathname.slice(1)))
 
  deactivate: ->
    @subscriptions?.dispose()
 
  open: (word) ->
    return unless word
    word = encodeURIComponent(word)
    atom.workspace.open("japanese-dictionary://word/#{word}", {
      searchAllPanes: true
      split: 'right'
    })
 
  openBySelection: ->
    editor = atom.workspace.getActiveTextEditor()
    @open(editor.getSelectedText())
 
  openDialog: ->
    dialog = new Dialog(onConfirm: (text) => @open(text))
    dialog.attach()
 

ふむ。なんのこっちゃ全くわからん。
ということで「atom パッケージ 作り方」とかで適当に検索してヒットしたサイトを見て解析する。
http://qiita.com/geek_duck/items/654919124d24fa74a0d3

おお、なんと無くわかったような。
てか画面の定義みたいなのはこっち「japanese-dictionary-view.coffee」のファイルを見たほうがよさげ。

japanese-dictionary-view.coffee

{View} = require 'atom-space-pen-views'
 
module.exports =
class JapaneseDictionaryView extends View
  @content: ->
    @div class: 'japanese-dictionary-view', =>
      @tag 'webview'
 
  getTitle: ->
    "#{@word} - #{@service}"
 
  constructor: ({@word}) ->
    super
    @service = atom.config.get('japanese-dictionary.service')
 
    atom.commands.add @element,
      'core:copy': => @webview.copy()
      'core:paste': => @webview.paste()
      'core:cut': => @webview.cut()
 
  attached: ->
    console.log "With CSS applied, my height is", @height()
    word = encodeURIComponent(@word)
    @webview ?= @element.querySelector('webview')
    @webview.src = switch @service
      when 'weblio' then "http://ejje.weblio.jp/content/#{word}"
      when 'alc'    then "http://eow.alc.co.jp/search?q=#{word}"
 
  destroy: ->
    @element.remove()
 

なんと無く読み取れるのはこんなところ。

  • viewというのを継承したクラスである
  • @content にhtmlのdomみたいなのを特殊な書き方で書く
  • getTitle はgetって書いてあるけど多分タイトルの設定
  • @tag 'webview'から、divの中にchromeのwebviewを配置してるっぽい
  • @webview.src = switch @serviceから、設定で選んだ方のwebに接続してるっぽい。その次の行のところでurlに選択した単語を引っ付けている

つまり見た目に関する定義が何もない...。

当たりをつける

ってことで、さっきのurlをよーーーく見てみる。

CSS、デザインを修正する

f:id:yoshitsugumi:20161230152333p:plain

なんかデザインっぽいことが書いてある。
そしてstylesってフォルダの配下にlessってファイルがあるぞ、と。

ってことで他のパッケージ見たらstylesってファイルがあって、lessってのはどうもcssのいけてるやつっぽいことが判明。

ってことでjapanese-dictionaryにもstylesフォルダをつくって、lessファイルを作成。
中身はこんな感じに。

japanese-dictionary.less

@import "ui-variables";
div.japanese-dictionary-view webview {
  height: 100%;
}

その後、ターミナルでパッケージフォルダに移動してapm installを実行後atomを再起動。

するとなんということでしょう!

f:id:yoshitsugumi:20161230152313p:plain

ちゃんと高さが出るように表示されました。
実際、これをやるのには2hくらいかかったんですが、このブログにまとめるほうにももう2hくらいかかりました。
なんというか、効率化していきたいですね。
はてなブログでcodeに行数表示できるのかどうかとかで結構詰まってしまった。挙句表示するのを諦めるっていう。

ちなみに、この修正って開発者に知らせてあげたほうがいいんだろうか。
githubの使い方わかんない。まぁとりあえずいいっか。

lessとかcoffeescriptとかもおいおい勉強していこうと思います。

では。

習慣化するために

yoshitsugumi.hatenablog.com

ということでほっといても何もしないパターンか、ちょっとだけやって習慣化しないパターンな気がしたのでいくつか施策を考えました。

結論から書くと以下6点をやります。多いな!

  1. 記録をとる(紙で)
  2. 飲まない
  3. 早く寝る
  4. やる時間を決める、やる気が起こらなくても準備する
  5. toggl timerを使って集中する
  6. Wunderlistを使ってやること管理する

記録をとる

そのままの意味。
webのツールも幾つか考えたけど(coach.meとか)、でもやっぱこういうのは紙だろうと思って。
見えるところにあったほうがいいよ多分。
f:id:yoshitsugumi:20161229184000j:plain

ついでに勉強結果なんかはblogに毎日アップすることで、こう、なんというかちゃんとやるようにする的な感じで。1日2記事をノルマに。

やる時間を決める、やる気が起こらなくても準備する

だいたい朝にいろいろやろうと思います。
- 5:00 起床,歯磨き
- 5:30 run
- 6:30 風呂
- 7:00 食事
- 7:30 英語
- 9:00 web系の勉強
- 12:00 食事
みたいな。冬の休みの間はこれでやってみよう。とりあえず。

早く寝る

朝にいろいろやるために早く寝ようと思います。
10時に布団に入る方向で。
そして寝ながらスマホをいじらない。

飲まない

飲むと良い睡眠が得られない気がする。少量なら大丈夫だろうけど。
そうなると朝からの活動が厳しくなる。
ということで禁酒(減酒)

ニュースアプリ削除

結構気になるものがpushで通知されてきて注意を削がれる。
SmartNewsとかグノシーとか。
通知されないようにっていう手もあるだろうけど、無くても死なないと思うのでとりあえず削除。
削除前
f:id:yoshitsugumi:20161229183954j:plain:w300

削除後
f:id:yoshitsugumi:20161229183957j:plain:w300

集中時間の割り込みを排除する

集中時間ってのは英語の勉強とか、web系の勉強の時間とかそういう時。
とりあえず、maciPhoneの通知を切る。
具体的にはおやすみモードにする。
f:id:yoshitsugumi:20161229183950j:plain:w300
f:id:yoshitsugumi:20161229184244p:plain:w500

http://timetoenjoy.info/archives/543#i

そして、toggl timerを使って集中時間を測って、割り込みというか、横道にそれる罪悪感を出す。 http://www.ttcbn.net/no_second_life/archives/35025

ちなみにこの記事を書くのに要した時間はこれだけ。結構かかるんだねーー。 f:id:yoshitsugumi:20161229183952j:plain:w300

やることを管理する(順位付け、段取り)

思いついてすぐやり出すことを防ぐために、思いついたやりたいことはとりあえず一旦書き起こしてリスト化する。
で、今やってることや、やろうと思っていたことなんかと照らし合わせてやりたいことなのか(やるべきことなのか?)を考えて何をするかを決定する。

多分、文章化する段階で、「どうすれば良いんだろう?」みたいなのは書けなかったりするので、だらだら初めてよくわからんかったぜ的なことも防げるんではなかろうかと思ったり。

ツール的には以前から使って良いるWunderlistを使おうかと思います。 https://www.wunderlist.com/ja/

そんな感じでやっていきます。