
所属会社が CTO 協会主催の[Thanks Giving Day 2022](https://eventregist.com/e/gmxATLNsi1KK)にスポンサーとして出展したので、スポンサーとして講演してきました。

久々のオンラインイベントだったことや、基調講演から非常に熱い話が聞けたので、終始熱気に包まれた雰囲気の良いイベントだったと思います。主催の CTO 協会と当日運営されていたメンバーの方々、本当に素晴らしいイベントでした。感謝しています。

今回は、基調講演の小林議員の話が非常に印象的だったので、その辺りの熱気が冷めないうちに記録にのこしておこうと思います。

## 基調講演の感想

基調講演は藤本理事・小野理事・小林議員の特別対談ということで進められました。

正直なところ、議員が基調講演すること正直あまり期待していなかったんですよね。
しかし、実際の話を聞いてみるとデジタル庁でやっていることや、今後の日本の未来のためのアイデアがビジョンの話など
想像以上に面白く、また、アプローチ自体が非常にプログラマ思考で進められていて感心しました。

話の内容としては、小林議員がデジタル庁でおこなっていることが中心でしたが、どれも非常に興味深い内容でした。

- 日本は公共インフラが老朽化してきて問題となっているが、実は下のインフラ（法律・制度・さまざまな商習慣。以下、ソフトインフラ）が実は老朽化していて、新しい取り組みを行う際に障害になっている。
- ソフトインフラのボトルネック箇所をすでに特定し、そこをリファクタする取り組みをしている。
- 法律のコード化に取り組んでいる。コード化することで、法律を変更した際にどこに影響があるか、それぞれが矛盾しているか検知することが可能。これにより影響についてコンピュータ上でシュミレートができる。また、コード化することで A と B がどちらが良いかなど、実際にものを見て議論ができるようになる。
- 国として自治体共通のインフラを整備しようとしている。将来的にマーケットプレイスのようなものを設立し、調達のコストや期間、サービスの多様化などを促す。
- ソフトインフラに縛られた理不尽な要求がある、その場合、もっと上流に行ってルール（仕様）を書き換える必要がある。

最後に、「**みんなで上流に行ってルール（仕様）を書き換えよう**」という強いメッセージをもらいました。話を聞いているうちに、自分の中で何かが熱くなるのを感じました。

久々に日本の未来について希望が持てる話でしたし、デジタル庁がしっかり仕事をしているんだなと認識しました。デジタル庁がんばれ！

そしてこの基調講演はイベントの空気を決定し、イベント全体が非常に熱気があるものとなりました。

## 「これからのエンジニア採用・育成のあり方」　スポンサーセッション

![](https://blog-mitsuruog.s3.ap-northeast-1.amazonaws.com/images/2022/cto-1.png)

小賀理事との対談形式でした。「これからのエンジニア採用・育成のあり方」というテーマでいろいろと話をしました。会場は満員でかなり緊張したことを覚えています。また機会があったら挑戦してみたいです。

![](https://blog-mitsuruog.s3.ap-northeast-1.amazonaws.com/images/2022/cto-2.JPG)

個人的には、セッションの準備の過程で、自社のプロダクトの理念や強みなどを改めて知る機会になって、非常に良かったです。

## 最後に

CTO 協会主催の Thanks Giving Day 2022。私自身も多くの CTO と直接お話する機会があり、想像以上に収穫が多かったイベントでした。

自身も含め、多くの人がデジタル庁や CTO 協会に貢献したいという気持ちを抱くようになったのではないでしょうか？

日本にはオードリー・タンのような人は現れないのかと巷では嘆かれているが、実はすでに存在してて、それなりに成果も出ているようでした。なぜ日本のメディアはこのことを取り上げないで、ネガティブな情報ばかり発信しているのか不思議に思いましたね。

「**みんなで上流に行ってルール（仕様）を書き換えよう**」

そんな気持ちになるいいイベントでした。


CTO協会主催のThanks Giving Day 2022に行った感想


（まぁ。たまには技術と関係ないこと書いてもいいかな。）

個人のライフログみたいなものです。
プログラマになる前は家具職人だったので、家にある大きめの家具は自分で作ったりしています。

今日は IKEA で買ったテーブルのリメイクです。
天板がかなり古くなってきたので買い換えようかと思ったのですが、足の部分はまだ使えそうなので、天板だけ張り替えることにしました。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table1.jpg)

天板は、[マルトクショップ](https://shop.woodworks-marutoku.com/)のゴムの集積材(厚さ 30mm)を使います。マルトクショップは、少し前に作業机を作成した時に初めて利用したのですが、いい仕上がりの仕事する木材屋だったのでリピート買いしました。

ではまず、天板を取り外します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table2.jpg)

取り外してみました。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table3.jpg)

元々天板を支えていた溝がそのまま新しい天板を支える梁として使えそうだったので、近所の DIY ショップでカットした木材をはめ込みます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table4.jpg)

おっと。ここで痛恨のミス。
元の天板は折りたたみ式だったので、天板を支えていた梁の部分が平行ではありませんでした。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table5.jpg)

> そんな父の苦労も知らず、YouTube ばかり見ている娘よ、宿題さっさと済ませなさい。。。。

仕方ないので、片方の溝だけ使うことにします。
当初の計画とは違いますが、こんな感じで梁を取り付けました。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table6.jpg)

反対側はこんな感じでビス止めしています。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table7.jpg)

よく見ると天板と接触する面で平らじゃないので、カンナを使って平らにします。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table8.jpg)

ここまでできたところで天板の裏面と、足の部分をヤスリで仕上げて、足の部分はほぼ完成です。

天板に足を乗せて、天板と足を繋ぐ場所を決めます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table9.jpg)

天板とのジョイントには「鬼目ナット」を使います。
(たぶん一度ジョイントした天板と足を離すことはないと思いますが。。。)

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table10.jpg)

天板の裏側に鬼目ナット用の下穴を開けます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table11.jpg)

下穴の準備だできたら、ボルトで天板と足をジョイントします。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table12.jpg)

これで、テーブルの天板を張り替えできました。
ここから仕上げに入ります。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table13.jpg)

仕上げの前に、天板の角や上面を**丁寧に**やすりがけします。
続いて塗装ですが、いつも「尾山製材株式会社 木工用みつろうクリーム 200 ｇ」を使います。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table14.jpg)

以前はオイルステインを使っていたのですが、値段が高いのと、準備片付けが面倒なので、最近はこのクリームがお気に入りです。

このクリームを布にとって木に塗り込みながら、仕上げの不十分な部分をヤスリで仕上げてまた塗る。これを繰り返すと完成です。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table15.jpg)

重量感があってしっかりした仕上がりになりました。
(今回の木材は若干暗い色の木材が多かったかな。)

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/table16.jpg)

ゴムの集積材は価格が割安ですが、重量感があって作業机など割とハードに使う部位にいいと思います。


IKEAのテーブルの天板を張り替える


（完全に自分用のメモです。）

いくつか翻訳のプロジェクトを GitHub 持っているのですが、更新が年単位の間隔が開くことも珍しくないので、自分のために作業のワークフローを残しておこう。

- Airbnb の JavaScript スタイルガイド
  - <https://github.com/mitsuruog/javascript-style-guide>
- Clean Code For JavaScript
  - <https://github.com/mitsuruog/clean-code-javascript>

## アップデートのワークフロー

## 1. 翻訳する本家のコミットのスナップショットを記録する

まず、翻訳する本家のコミットのスナップショットを記録します。

本家のコミットは翻訳用のリポジトリに`upstream`と言う名前でリモートリポジトリを追加します。

```sh
git remote add upstream <リポジトリURL>
```

> `upstream`が慣例のような気がする。

結局のところ、文書のフォーマットが Markdown なので、オリジナル文書と翻訳したものが混在してしまいます。うまく Diff を取ることが難しいため、オリジナル文書の差分を手動でコピーして、翻訳を追加していきます。

## 2. 以前のスナップショットとの差分を抽出する

 さて、前回の  作業から数ヶ月が経ちました。やっと重い腰をあげて翻訳をアップデートするとします。

 翻訳用のリポジトリの`upstream`と、本家の差分を抽出します。

これは GitHub 上の GUI で作業できるので、 翻訳用のリポジトリ「New pull request」画面に移動して「compare accoss forks」の画面へ移動します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/translations1.png)

ここで本家から翻訳用のリポジトリの`upstream`へ pull request を作ります。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/translations2.png)

(左側に翻訳用リポジトリ。右側に本家です。)

> 実際の pull request:
>
> - <https://github.com/mitsuruog/clean-code-javascript/pull/4>

これでファイルの差分がわかるので、地道に  文書をアップデートしていきます。ちなみにここでマージした`upstream`が次回アップデートするためのスナップショットです。

## まとめ

以上が簡単なワークフローのまとめでした。

スクリプトとか組めばもっと格好のいい形になるのかもしれませんが、それほど頻繁にやる作業ではないので、これくらいゆるい感じがちょうどいいのです。


翻訳プロジェクトのアップデートワークフロー


この記事は[ファシリテーター Advent Calendar 2018 \- Adventar](https://adventar.org/calendars/3052) 16 日目の記事です。

## はじめに

（たまには技術系じゃないことも書いてみようかな。。。）

私は 11 月までグローバルチームで働いていた隠れファシリテーターです。
現在は普通に日本企業で働いています。

内容は、ほぼこちらの本の読書感想文のようなものです。
タイトルに惹かれて買ってみたのですが、読み終わって何か世界が変わったような気がしたので紹介します。

[敵とのコラボレーション――賛同できない人、好きではない人、信頼できない人と協働する方法](https://www.amazon.co.jp/dp/4862762638)

たまにはこういう記事もいいかな。

## 自分が今までやっていたファシリテーション

自分が今までやっていたファシリテーションとは、開発チームの中で問題解決方法や将来の計画を決める上で、メンバー間の意見を聞き、相互理解を深め合意形成を行うようなものでした。

例えば、特定の問題に対しての共通認識を醸成し、メンバーからの意見を促し、それぞれの意見について長所・短所などの意見が出されることを促し、最終的になにかの「落とし所」に最終合意するような感じです。

自身も開発メンバーの一人であったため、完全に中立の立場で参加することはほとんど不可能でしたが、専門のファシリテーターがいない開発組織でよくある関わり方だったんではないかと考えています。

## この本からの気づき

まず、この本では**従来型のコラボレーション**と**非従来型のコラボレーション**という形で 2 つに明確に別れて説明しています。

読んでて思ったのですが、自分がやっているファシリテーションとは完全に従来型のものでした。
従来型の特徴とは、「**チーム内の調和を重視する**」「**取り組みに対して明確な合意がある**」ようなものが挙げられています。

### 全体は一つではない

さらにチームとしての調和を重視するということは、チーム全体の利益を優先することで、より小さなチーム（個人）の利益を下げることだということが書かれていました。

チーム全体の利益を支持しながら合意形成を促す行為は、ほとんど自分の利益の為に合意形成を促しているようなもののようです。
過去の記憶を思い出しながら背筋が冷たくなったことを今でも覚えています。

### コラボレーションは唯一の選択肢ではない

この本の中で印象的だったことは、問題の対処法について「**離脱・適応・強制・コラボレーション**」の 4 つを提示していて、コラボレーションは唯一の選択肢ではないということを明言しているところでした。

自分でもコラボレーションのつもりが、ほとんど強制になっていたんではないかと不安に思いました。

まぁ、この本を読んでいると、今まで信じてきたものがとにかくガラガラと音を立てて崩れて行きます。

## 最後に

この本を読んでからファシリテーションすることが不安に感じることが多くなった気がします。
ただ、強制とコラボレーションの違いが認識できたことで、これからは強制はもっと強引に進めてもいいと勇気をもらった気がします。

> これまでは強制の場面で、コラボレーションのようにチームの合意形成を重視して遅くなる傾向がありました。

正直この内容を即実行できるわけではないですし、おそらく従来型のコラボレーションを続けながら、時々にこの本の内容を思い出すような気がしています。
まだ心は揺れまくっていて、まだ一つのところに収まっていない感じがします。

だた、この本から不安定・不確実・複雑・曖昧な状況下でも、自分が立っている場所を見つけることができそうなヒントをもらえました。

普段からファシリテーションを大切にしている人にこそ読んでほしい一冊です。


この本を読んでからファシリテーションするのが不安になった話


2017 年も終わるので、今年どうだったかということを振り返りたいと思います。

## CODEPREP な一年

今年を一言で言い表すと

「**[CODEPREP](https://codeprep.jp/)**」

の年でした。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/react-typescript1.png)

> 「CODEPREP」はプログラミングを書いて動かしながら学ぶ実践型のプログラミング学習サービスですが、残念ながら「**2018 年 3 月 26 日**」でサービスを終了してしまいます。

今年の 2/1 のリニューアルオープンから、8/1 の有料化、そして 12/4 にサービス終了のお知らせまで、まさに怒涛の一年でした。

自分は、リードフロントエンジニアとして関わっていて、ユーザーが触る部分の実装をほとんど一人でやらせてもらっていました。CODEPREP はアクセス数が多いサービスなのですが、フロントエンドはかなり安定して運用できたこともあり、個人的にはいい仕事ができて近年でももっとも充実した一年でした。

- [React と TypeScript で半年間サービスを走らせてみてよかった点を振り返って見る \| I am mitsuruog](https://blog.mitsuruog.info/2017/08/look-back-react-typescript-after-half-year)

それとは別で CODEPREP の「ブック」と呼ばれるオンライン学習コンテンツを作成にも関わっていて、主にフロントエンド関連の学習コンテンツの企画・作成などをやっていました。

今数えてみると、コンテンツで自分がメインで関わっていたものは合計で「**38 ブック**(※1)」ありました。
2/1 以降の統計情報をちょっと出すと、**合計 3 万人**くらいの人に読まれているみたいです。

- 読まれた数: (約)30,000 人
- 最後まで読んだ数: (約)17,000 人

> 2018/1/4 から無料解放するので、この数字はもう少し増えるんじゃないかと思います。

以前からエンジニア教育には興味があったので、多くの人に自分の書いたものが届いてダブルで充実した年でした。

本業のフロントエンジニア業としては CODEPREP 以外にもう一つ別のサービスも回していたことと、コンテンツライター業の二足草鞋で、とにかく忙しくも充実した日々を遅れていたので、まさに「**完全燃焼**」できた素晴らしい一年だったと思います。

(※1)自分で書いたもの、リニューアル時に古いプックを書き直したもの、自分で企画して他の人に書いてもらってレビューしたものも含む。

## 今年やった新しい試み

今年始めた新しい試みとして、「**プライベートコンサルティング**」があります。

これは、
「今のフロントエンド事情を知っているフロントエンドエンジニアを採用できないスタートアップ企業向けに
週 1 回程度フロントエンドに関連する技術課題についてコンサルティングを受けることで
自社のフロントエンドについての課題抽出・ロードマップ作成・モブプログラミングを通し
健全なフロントエンド技術スタックを手に入れ・維持できようにする」
と言ったものです。

現在のところ 1 社だけですが、やっているとかなりコストパフォーマンスが良くて、需要と供給ががっちりマッチしているコンサルティングだなと感じています。

昨今のフロントエンドは変化が早すぎるので、ざっくばらんに相談できるフロントエンドエンジニアの参謀がいるだけでも、フロントエンドエンジニアを採用できないスタートアップ企業としては頼もしいのではないかと感じています。

## で？来年はどうしよう

まず、ちょっとまったりしたい。

それから、フロントエンドで SPA を作ることに関しては割となんでもできるようになってしまったので、次の「**強み**」を見つける一年にしたいです。

現場からは以上。みなさんも良いお年を。


2017年を振り返る


この記事は[筋肉 Advent Calendar 2017 \- Adventar](https://adventar.org/calendars/2143#list-2017-12-12)20 日目の記事です。

（たまには技術系じゃないことも書いてみようかな。。。）

私はグローバルチームで働いている隠れ細マッチョです。

最近はプログラマでトレーニングしている人も増えて来ましたねー。
私は 8 月からジムに通っているのですが、4 ヶ月間ジムに通って得たものについて紹介します。

## きっかけ

ちょうど 1 年前くらいから右肩が上がらなくなりました。

もともと肩こりや腰痛がひどかったのですが、去年ちょうど 40 歳になったこともあり、当時は間違いなく「**四十肩**」というやつかなと思っていました。

いくらマッサージや接骨院などに通っても、良くなる兆しはまったくなく、とにかくリックを背負うのがしんどくて、思い返せばいつも右肩を庇って生活していた一年でした。

ところが、今年の夏休みに海に行った時の事。
4 日間連続、娘の浮き輪を引きずって海遊びをした結果、起きたことは。

「**肩こりが消えてる!!**」

肩こりをまったく感じません。右肩も上がります！
もうとにかく信じられない状態でした。

そこで確信しました、今の自分に必要なのは、**受け(マッサージ)ではなく、攻め(トレーニング)**だったんだと。

## トレーニング方法

という訳でジムに通い始めたのですが、今のところ会社帰りにジムに寄るというスタイルで続けています。
ペースは月に 3 回くらいの軽めです。
会社が加入している健保でスポーツジムの割引があったのでこれを利用しています。

トレーニングは調整系をメインに、スタジオとマシントレーニングを 2 時間くらいかけて行ってます。

- ランニング(10 分)
- ヨガ(60 分)
- マシントレーニング(60 分)
- 風呂(30 分)

最近嬉しい事といえば、10 分で 1500m を走りきることができるまでに回復したことですね。若い頃は 1.5 倍くらい速かったので、次は 8 分台を目指したいです。

## そして得たもの

まだジムに通い始めて 4 ヶ月目なのですが、これまでに得られたものを書いて行きます。
特に肩こりなどの緩和は最近になって効果が現れて来たので、辛抱強く続けて良かったと思います。

- 四十肩が気にならなくなった
- 肩こり腰痛がなくなった
- 歩くとき体が弾むように感じる
- macbook pro を毎日持ち歩いても重く感じない
- 座る姿勢がよくなった(正しい姿勢で長時間いられる)
- 鏡を見るのが楽しい
- 子供と妻が体に触ってくる

たまに困ること

- トレーニング後の電車が辛い
- トレーニング翌日の仕事が辛い
- 無性に肉が喰いたくなる

肩こりが緩和されたのは本当に奇跡に近い体験です。これからも自分のペースで続けて行きたいと思います。

## まとめ

最近始めたジム通いについて書いて見ました。
個人的には、無理せず、少しずつ変化している自分を見るのを楽しむことが長続きの秘訣かなと思います。

> 正直、来年も続いているか怪しいが。。。

最近は長生きする人が増えて、「**人生 100 年時代**」とも言われているので、健康には気をつけていきたいですね。

ちなみに、この記事は 3 年前にデブサミに一緒に出た知り合いが、最近マッチョになっていくのを Facebook の TL で見てインスパイアされて書いたものです w。

- [筋トレを始めて半年経ったので振り返ります \- ニクニクドットミー](http://blog.nikuniku.me/entry/2017/12/18/141807)
- [デブサミ 2014 で 35 歳からフロントエンジニアにキャリアチェンジして 35 歳定年説を覆した話をしてきた \| I am mitsuruog](https://blog.mitsuruog.info/2014/02/20143535.html)


4ヶ月間ジムに通って得たもの

この記事は[ファシリテーター Advent Calendar 2017 \- Adventar](https://adventar.org/calendars/2310)7 日目の記事です。



## はじめに

（たまには技術系じゃないことも書いてみようかな。。。）

私はグローバルチームで働いている隠れファシリテーターです。
今日は、私がミーティングを発起する際に事前に注意しているポイントを並べていきます。

ちなみに、ここでのミーティングとはソフトウェア開発において、何らかの決定するような種類のミーティングで、アイデアを出す種類のオープンなミーティングではありません。

それでは、Here we go!

## 目次

## いいミーティングをデザインするための心得

### 事前にアジェンダと資料を共有する

この目的は、**ミーティングの時間を短くする**ことと、**参加者の目線を合わせる**ことです。

アジェンダはどんなトピックを議論するのか、資料はそこで提案される内容など事前に知ることができます。
ミーティングが始まってから資料を共有することもあるかと思いますが、この資料に目を通すだけでも時間がかかってしまいますので、この時間を節約する上でも有効です。

よくあるパターンとして時間ギリギリまで長い文字だけで書かれた資料作成して、始まってから共有するということがあります。
この場合は読んで理解するプロセスが必要で時間もかかりますし、そのプロセスを省略した場合、そもそも議論が頭に入ってこなくなったりします。

人によっては少し考えて意見を言いたい人もいますし、代替え案を提示するために準備の時間が欲しい人もいるでしょう。
事前にいろいろと共有することは、それだけでもミーティング開始時点から議題に集中して議論できる可能性が高くなるので有効だと思います。

### 時間内に収まるサイズにアジェンダを設計する

ここで「**設計**」という言葉を使いましたが、アジェンダの作成はミーティングの「場」がどうなるかを予測しながら組み立てる、まさしく「場の設計」という作業だと思います。

人は終わる見込みが到底ないものには諦めて手を抜いてしまいがちなのに対し、もう少しで終わりそうというものには、無理をしてでも終わらせようとする傾向があると思います。

私はアジェンダをこの「ギリギリ終わる」か「少し余裕がある」状態に設計するようにしています。

どうしても収まりそうにない場合は、事前にメンバーに関連する質問をチャットなどでしておいて、議論の核心でないものをそぎ落してスリムにしておきます。
この過程で、そのまま結論に至りミーティングをしないということも多々あるので非常に有効な手段だと思います。

### アジェンダにはタイムスケジュールを載せる

アジェンダを作成する際に大事なことは、**タイムスケジュールをあらかじめ決めておく**ことです。
アジェンダで議題だけ列挙しただけでは、どの議論がどのくらいの時間を使って議論されるかを予想できていません。
これでは特定の話題で話が盛り上がったときに、この先順調にミーティングが推移しているのかが判断できません。

私はタイムスケジュールをあらかじめ決めておいて、特定の話題で時間がオーバーしそうな場合、参加者に対して議論を続けるか、ひとまず結論を出して次の話題に取り掛かるか問いかけるようにしています。

### 時間を守ること

**時間通りに始まり、時間通りに終わる。**

当然のことですが、ミーティングはそれぞれの参加者の時間を奪って成立しています。
時間通りに始まり終わりましょう。

特に海外のエンジニアは「**時間＝有限な資源**」という当たり前の感覚をしっかりと持っているので、ミーティングの時間が伸びてプライベートな時間に食い込むことを本当に嫌がります。

個人的にはミーティングに**タイムキーパー**を専任で置いた方がいいと思います。

### 決まらないことを恐れない

ミーティングを時間内に納めようとした時に起こるのが、アジェンダを最後まで消化できなかった時や、議論が迷走して結論に至れなかった時です。

そんな時は無理に延長せず、「決まらない・合意できない」ことを合意しましょう。
そんな時はまた仕切り直しです。

## まとめ

個人的に気をつけていることをつらつらと書いてみました。

私の英語力はそれほど高くないので、話があまりややこしくならないように、事前準備を入念にする必要がありました。
が、あまりグローバルに限ったことではないですよね。。。はは。

個人的には最終的にミーティングをしないことが「最高のミーティングデザイン」だと思います。

グローバルチームをファシリテートして気づいた「いいミーティング」をデザインするための心得とは

Google tag manager を使った小ネタの紹介です。



## 想定ユースケース

特定のリンクをクリックした時に Google tag manager に  何か特別な値も一緒に送りたい。

Google tag manager のクリックイベントハンドラでは、ページの URL・遷移先 URL・リンクのラベルなどの基本的な情報は取れます。
しかし、それだけでは分析する上で十分ではない場合が多く、もう少し送信できるデータの種類を増やしたいと思うことは多いのではないでしょうか。

そんな時に利用できるのが、今回紹介する小ネタです。

## 手順

### リンクに Custom Attribute を設定する

対象のリンクに次のように Custom Attribute(今回は`data-ga-custom-value`)を設定します。Attribute 名は任意ですが、次のステップでも同じ値を利用する必要があります。

```
<a href="/jump/to/cool/web-site"
   data-ga-custom-value="何かのキャンペーンコードとか">Click</a>
```

### Google tag manager 上でユーザー定義変数を定義する

次に、Google tag manager 上でユーザー定義変数を定義するのですが、少しテクニックが必要です。

#### 変数のタイプは「カスタム JavaScript」とする

まず、変数のタイプは「カスタム JavaScript」とします。
これを設定することで、Google tag manager 何かのイベントを検知したタイミングで任意の JavaScript を実行して、その結果をユーザー定義変数に格納します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/gtm_1.png)

#### Custom Attribute を取得するコードを設定する

続いて、Custom Attribute を取得するために次のコードを入力します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/gtm_2.png)

実際のコードはこちらです。

```
function() {
  var el = {{Click Element}}
  var data = el.getAttribute("data-ga-custom-value");
  return data;
}
```

`{% raw %}{{Click Element}}{% endraw %}`は、Google tag manager 上のビルトイン関数で、クリックした Element の Object を返します。

そのあとは、通常の JavaScript の世界なので`getAttribute()`を使って Custom Attribute の値を取得すれば OK です。

### Google tag manager のタグにカスタム変数を設定する

最後に、Google tag manager のタグの設定の際に、ユーザー定義変数を利用すれば OK です。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/gtm_3.png)

変数のリストの中に含まれています。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2017/gtm_4.png)

## まとめ

自由にデータが送信できようになるので、やって見ると結構感動的でした。

「こんなことできたらいいなー。」と思っていたのですが、なかなか日本語の情報が見つからなかったのでまとめてみました。

- [Google Tag Manager event tracking using data attribute elements](https://www.thyngster.com/google-tag-manager-event-tracking-using-data-attribute-elements/)

リンククリック時にカスタムデータをGoogle tag managerに送信する

~~当ブログで使っている画像を Dropbox の public フォルダから、Cloudinary に移行した話です。
画像に限った話では、Dropbox の代替先として Cloudinary は結構いいんじゃないかと思います。~~

(うそです)

> 結局、Bandwidth が無料枠をオーバーしてしまったので、S3 にしました。(2017/06/15)



## はじめに

当ブログの画像は Dropbox の public フォルダを使っていたのですが、2017 年 3 月から有料化しないとそのままでは使えなくなってしまいました。
長らく代替先を検討していたのですが、この度 Cloudinary を使ってみることにしました。

Cloudinary とは、画像/動画専門のクラウドホスティングサービスで、画像をアップロードしてブログなどで使うために利用できます。

> ~~フリーでも 75,000 枚の画像や動画を保存できるので、まぁ普通に使っている内は大丈夫でしょう。。。~~

> （だめでした〜！！）Bandwidth が 5GB/月なんですが、結構アクセス多くってオーバーしてしまいました。結果、S3 に移行することにしました。(2017/06/15)

- [Cloudinary](http://cloudinary.com/)

## 移行方法

移行方法は至ってシンプルで、Dropbox の画像 URL を Cloudinary のものに置き換えて行きます。

```
// Dropbox
https://dl.dropboxusercontent.com/u/<YOUR_ID>

// Cloudinary
https://res.cloudinary.com/<YOUR_COULD_NAME>/image/upload/<YOUR_ID>
```

### 画像 URL の一括置換

手作業では面倒なので、次のスクリプトでフォルダの中のファイルを一括置換します。(あ、ちなみに Mac の場合です)

```
find . -name "*.ext" | xargs sed -i "" 's/置換前/置換後/g'
```

### 移行時の URL に関する注意点

URL に関しては、ファイル名に空白が含まれる場合は注意が必要です。Cloudinary 上にアップロードしたタイミングで空白が`_`に置き換わるようです。

```
// 元ファイル
Image 01.png

// Dropbox
Image%2001.png

// Cloudinary
Image_01.png

```

## まとめ

普通に画像読めているし、https も使えるので、Dropbox の代替先として Cloudinary は結構いいんじゃないかと思いました。

> Bandwidth が 5GB/月の中に収まるのであれば大丈夫だと思います。

Dropboxのpublicフォルダが使えなくなったので、画像をCloudinaryに移行してみた

4 月から Web サービス会社にフロントエンドエンジニアとして Join しました。
新卒で就職して以降、多くの時間(※)を SI として過ごしてきたので、今回は大きなチャレンジとなりそうです。

ちなみに、この文書は 5 年後の自分に当てたポエムです。



(※)途中、料理人と家具職人を 4 年ほどやっていました。

## 5 年後のなりたい自分になるために転職を決意した

御年 39 歳。

昨年の 5 月に転職したばかりなのですが、振り返ると「 **人は何のために働くのか？** 」ということで悩み続けた 1 年でした。

悩んだ末の結論は、年齢や立場で左右されることなく、純粋に「やりたいことをやり続ける」というものでした。

前回の反省から学んだことは、やりたいことをやり続けている方が幸せで、幸せを感じていないと周囲にいい影響を与える続けることはできないということでした。
私は、周囲を幸せにするため、あえて自分のエゴを通し自分を幸せにする道を選びました。

やりたい事とはもちろんフロントエンドの仕事です。

## これから何をするのか？

これからはフロントエンドエンジニアとして、サービスのフロントエンドの開発を取り仕切る立場となります。

それ以外で目標としていることを、未来の自分のために書きます。

### エンジニアの成長をサポートする

自身の持っているスキルを必要とする人がいて、それを教えることで、人の人生を豊かにできる可能性がある。

私は、フロントエンドの技術を習得する過程で多くの喜びや達成感を味わい、かけがえのない仲間と知り合うことができました。
これからもハンズオンなどを通じて、人の成長をサポートしていきたいと考えています。

エンジニアの成長を支援するサービスを作成している会社なので、自身のやりたいことの延長を仕事にすることができそうです。

### グローバルに活躍する

言うまでもなく、これからは英語が必須ですね。

とにかく英語のアウトプットの機会に飢えていました。
今いるところは海外のエンジニア多く、普段のやりとりはすべて英語となります。そういった環境に飛び込んで、英語を徹底的に鍛えたいと思いました。

人生一度しかないので、1 回くらい家族を連れて海外で仕事をしてみたいです。まだまだ人生チャレンジしないと損ですね。

### これまでの「べき論」を捨て、新しい自分になる

35 歳でフロントエンドエンジニアを志して、4 年でここまで来ることができました。

振り返ると様々な困難や不安、焦りに対してたくさんの「 **べき** 」を積み重ね、自分を奮い立たせて来たように思います。
その過程で、自分の思考に偏りができてきたように感じており、過去に遡ると正しい判断ができてなかったなと思うことが多くなってきました。

おそらくこの転職を決意できた背景にも、いろいろな **べき** を捨てたからこそできたと思います。

私は今回の転職を機に自分の中のたくさんの **べき** をリセットし、今後は不用意な **べき** を利用することを避け、不用意な **べき** で自分を縛り不幸にしないようしたいと思います。

## 最後に

今回無事に転職ができたのは、自分のことを心配し見守って、手を差し伸べてくれる素晴らしい知人に恵まれていたからです。

今後は自分が関わる人への感謝を忘れず、自身が幸せであることを保ち、お互いが支え合える関係を維持していけるよう努力し続けたいと思います。

5 年後はどうなっているかな。
頑張れ自分。

SIを辞めてWebサービスに転職しました

あけましておめでとうございます。  
昨年は 5 月に Salesforce 界隈の会社に転職しました。  
多くの新しい出会い刺激を頂き有意義な 1 年でした。今年も引き続きご指導のほどよろしくお願いします。



## 2015 年の振り返り

昨年は、幾つか新規 IoT 案件に関わることが出来ました。

（前職）団体旅行向けの Beacon を使った点呼サービス。管理画面を Angular で作成したのは、懐かしい記憶です。

近距離無線：みんなのてんこ  
http://service.cresco.co.jp/tenko.shtml

（現職）建機の稼働監視。D3.js を使って建機の稼働状況を可視化。D3.js 辛かったですｗ。

News ＆ Trend - 東急建設が「建機 IoT」、環境対策と配置効率化目指す：ITpro  
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/083100328/

前半は少しフロントエンドっぽいことできたのですが、  
後半は社内で最も大所帯のチームでリーダー業(仕様の伝書鳩)をやっております。  
フロントエンドとは関わりのないこともあり、苦難の連続で大変貴重な体験をさせてもらってます。

他には、いくつか知り合いの勉強会の手伝いをしたり、社内勉強会でフロントエンド系の話をしたり、現職では会社初の社外勉強会を行ったりしてました。

express 実践入門  
https://gist.github.com/mitsuruog/fc48397a8e80f051a145

Angular2 で Todo アプリを作るハンズオン  
mitsuruog/angular2-todo  
https://github.com/mitsuruog/angular2-todo

第 1 回 FlectMeetup MEAN スタック＋ Heroku で Web サービスを作ろう！ - Flect | Doorkeeper  
https://flect.doorkeeper.jp/events/29804

それから、Airbnb のスタイルガイドの翻訳を ES6 版に更新したり、いくつかの OSS リポジトリにパッチを送ったりしてました。  
個人的にはプロダクトにも Babel を使うようになり、一気に ES6 化した年でしたね。

Javacript-style-guide by mitsuruog  
http://mitsuruog.github.io/javacript-style-guide/

## 2016 年の抱負

2016 年どうしようかと思ってた矢先に TL に流れて来たのがこれでした。

あの有名な「生きがいを見つけるためのベン図」はどこから来たのか？  
http://giantech.jp/2015/06/04/what-origin-is-the-purpose-diagram/

図を拝借します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2016/purpose_venn_diagram_ja.png)

あーそれそれ。「生きがい」求めてた。  
いままでモヤモヤしていたものが言語化できてスッキリした瞬間でした。

今年こそは「生きがい」を感じれる場所、見つけたいですね。

2015年の振り返りと2016年の抱負

今年も最後となりましたので、自分の 2014 年の活動について振り返ってみます。去年の振り返りは[こちら](http://blog.mitsuruog.info/2013/12/2013.html)です。  
それから「来年こそはもっと質の良いアウトプットしたいと思います。」と締めくくってますね。果たして私は今年、何をやっていたのでしょうか。。。



今年も[html5j エンタープライズ部](http://www.html5biz.org/#/)を中心にたくさんのエンジニアとめぐり合うことができ、大変有意義な一年でした。支えていただいたたくさんの方々、本当にありがとうございました。来年も引き続きご指導のほどよろしくお願いします。

## 1 月〜3 月 SAPUI5/OpenUI5 と AWARD 受賞

昨年は Backbone.js をずっとやっていたのですが、仕事の都合で[SAPUI5/OpenUI5](https://sap.github.io/openui5/)という SAP 社製の UI フレームワークを利用して Web アプリを作成していました。

[業務系アプリケーションに特化した SAP 社製「SAPUI5」を触ってみた](http://blog.mitsuruog.info/2014/02/sapsapui5.html)

少数精鋭のプロジェクトでアジャイルっぽい要素を組み合わせて短期間で仕上げた仕事でした。この時の功績で、**SAP AWARD OF EXCELLENCE 2014**を取得しています。  
(今年の秋には AngularJS をやっていて、正直一年でこんなにも使うフレームワークが変わるとは思いませんでしたね。)

また、[Developers Summit 2014：開発者のための IT カンファレンス](http://event.shoeisha.jp/devsumi/20140213/)の Yet Another Your Story (Enterprise TED 3)にて講演させていただきました。いまとなってはいい経験です。

[デブサミ 2014 で 35 歳からフロントエンジニアにキャリアチェンジして 35 歳定年説を覆した話をしてきた](http://blog.mitsuruog.info/2014/02/20143535.html)

この辺りは日々忙しくて夢中で駆け抜けた時期でした。今思うと、何も考えず夢中で走り続けられるって大事だなとおもいます。

## 4 月〜6 月 個から組織へ

この頃、次にやりたいことのスケールが自分を超えていると感じていたので、今まで学んだフロントエンドのスキルなどを組織で活かそうと模索していた時期でした。  
いままで個人の成長に重きを置いてきましたが、その視点が組織や仲間にまで広がったということは、個人的にはずいぶん成長したとおもいます。

5 月に HTML5fun 立ち上げイベントにて声をかけられて講演する機会をいただきました。その時に感じている自身のエンタープライズ HTML5 感について話させていただきました。

[HTML5fun で「エンタープライズでの HTML5」について最近思うことを話してきた](http://blog.mitsuruog.info/2014/05/html5funhtml5.html)

今思うと、フロントエンドエンジニアを目指してからずっと、「エンタープライズでフロントエンドエンジニアが増えますように」と言っている気がしますね w。まじ変な人です。  
たぶん、一緒に Web アプリケーションを作って苦楽を共にする仲間が欲しかったのだとおもいます。

この時は、組織として強化するべきフロントエンドの技術や開発手法など広く探っている時期でした。見つけたのが後で出てくるハイブリッド開発手法や AngularJS でした。

## 7 月〜9 月 ハイブリッド開発手法と AngularJS

この頃はハイブリッド開発手法(Cordova)と AngularJS を有用性を見極めるため、ひたすらサンプルのアプリや Web サービスのコードを書いて検証を重ねていました。
Cordova のフロント部分に AngularJS が利用できることが分かったので、エンタープライズにて AngularJS でどのように Web アプリケーションを構築すればいいかを念頭に検討を重ねていました。

9 月には[いまや最も優れた JavaScript フレームワーク「AngularJS リファレンス」出版記念会](http://html5experts.jp/albatrosary/10855/)にて、AngularJS の取り組みについて話させていただきました。

[なぜ AngularJS を薦めるのか ー 個人的な思い](http://blog.mitsuruog.info/2014/11/angularjs.html)

## 10 月〜12 月 AngularJS をより深く

この頃は AngularJS の MEAN スタックを使ってもっと複雑な Web アプリケーションを作成していました。(とは言ってもあくまで β 版サービスレベルです。)

[MEAN(MongoDB, Express, AngularJS, Node.js)スタックが優れている理由 - Mozilla Open Web Day in Tokyo を終えて - albatrosary's blog](http://albatrosary.hateblo.jp/entry/2014/10/06/073638)

AngularJS 関連で、他の SIer にて講演させていただいたり、ハンズオンのチューターとして参加させていただきました。  
自身の持つ AngularJS、Cordova、Nodejs のスキルを駆使して多くのデモアプリやサービスを作成していました。この過程で AWS などのクラウドサービスを利用することが日常的となり、併せて弱点だったインフラのトレーニングを積むことができました。

## 来年の活動

といった感じで、個人としては成長できた一年でした。来年は、今年できなかった組織やチーム、仲間と共に自身も成長していきたいとおもいます。

特に今年の後半は徐々にアウトプットが少なくなったようで、勢いがなかったような気がします。これは、今年やりたかった「今まで学んだフロントエンドのスキルなどを組織で活かす」という部分がうまく機能しなかったため、自身の中にいろいろ迷いが生じていたためだと思います。  
これは使い慣れたガラケーが手放せない人に、最新式のスマートフォンを売っている、気持ちに通じるものがあります。

というわけで、来年はこういう無駄なところで悩まず、なるべく早い時期にまっすぐ走れる道を見つけたいとおもいます。
そして、チームや仲間と共にさらに成長していきたいです。

来年こそはもっと質の良いアウトプットしたいですね！！  
では、みなさん良いお年を。

### p.s.

35 歳からフロントエンドエンジニアを目指して走ってきたのですが、ここまでこれたのは妻の支えと娘の笑顔があったからです。本当に感謝したい。  
(と言える気持ちになったのが、今年一番の収穫なのかもしれない。)

2014年を振り返る

だいぶ前のことですが、9/22 に行われた[AngularJS リファレンス」出版記念会](http://html5experts.jp/albatrosary/10855/)にて SIer での AngularJS の取り組みについて話させていただきました。

先日、その資料を見て興味を持ってくれた他の SIer にて AngularJS について講演させていただく機会をいただいたこともあり、なぜ AngularJS をいいと感じているのかや、AngularJS に期待することなど、個人的な思いを書いてみたいと思います。(あくまで SIer 目線です。)



詳細は資料を参照してくださいね。

こちらが 9/22 の AngularJS リファレンス出版記念会の資料です。

[今後の Web 開発の未来を考えて angularJS にしました](https://www.slideshare.net/mitsuruogawa33/webangularjs)

他社にて 講演したときの資料です。

[今後の Web 開発の未来を考えて angular js にしました(拡大版)](https:////www.slideshare.net/mitsuruogawa33/webangular-js)

## マルチプラットフォームとしての HTML5

まず、AngularJS を選定する際に外せないのが、「HTML5」の存在です。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/why_angular1.png)

ブラウザだけではなくモバイルアプリなど利用範囲が広いため、今後の Web アプリケーションのマルチプラットフォーム実行環境としては主役だなと思います。

## AngularJS の注目ポイント

AngularJS で注目しているポイントとしては次のような部分です。

1.  各モジュールのちょうど良いサイズ感
2.  生産性(4.の要件の範囲内であれば...)
3.  スキルチェンジ(JSP から AngularJS)
4.  Web 開発要件にマッチ

いくつか JS フレームワークを触っていきた経験的に、AngularJS の各モジュール分割(controller や filter など)の考え方は割と Better かなと思います。強いて言えば、規模が大きくなってくると細かな Service がたくさんできて DI が多くなるのが辛いといったとこでしょうか。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/why_angular2.png)

スキルチェンジに関しては、JSP と AngularJS はテンプレート部分にロジックを記述していくため、Javascript で全てテンプレートを生成するものより、理解しやすいと思います。また DI の概念や、各モジュールについての役割についても Java での Web 開発を例に説明できると思います。

## 開発支援ツールとしての Yeoman

私が Yeoman の存在を知ったのは 2013 年の 10 月くらいだったかと思います。

従来の Java での Web 開発と比較して、Yeoman が提供する Grunt タスク(特にフロント側リソースの本番ビルド)はかなりオーバースペックに見えたこともあり、ここ 1 年、少し慎重に評価していました。

AngularJS 開発にあたって Yeoman が必須な訳ではありませんので、Yeoman を使わずに自分の組織にあった Grunt タスクを 0 から作成して利用してもいいと思います。
(Yeoman は必須ではなくても、Grunt タスクは AngularJS 開発では必要だと思います。)

私の場合、当初は Yeoman を利用しない方向で考えていましたが、AngularJS を開発するにあたりいろいろとタスクを追加した結果、Yeoman でのタスクの劣化版を作っていることに気づきました。  
いまでは既存の Yeoman ジェネレーターを自組織に合うようにカスタムして利用しています。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/why_angular3.png)

> 本来は、なぜフロント開発がこんなにも複雑になってしまったのかを嘆くべきなのでしょうが。。。

## まとめ

個人的な AngularJS についての思いを書いてみました。  
SIer の中にいると、最近の Web 開発手法の進化と現場での意識のギャップに戸惑うことが非常に多いです。

AngularJS もそろそろ実用レベルのものに達してきたと思いますので、このあたりで少し実戦で使っておかないと、10 年後には Web 開発がまともにできないような組織になるのではと危惧しています。

SIer じゃなければ React.js か vue.js を使いたいです w

なぜAngularJSを薦めるのか ー 個人的な思い

昨年より IT 系のハンズオンをそれなりの回数行ってきて、良かったものから失敗まで様々経験した中で、ノウハウがたまってきましたので、気をつけるべきポイントを 6 つまとめてみたいと思います。

過去のハンズオンで記事にしているものは次の通りです。

- [Web Components ハンズオンをやってみた](/2014/09/web-components)
- [SIer で Node.js 初心者を集めてハンズオンをやってみたという夢のある話](/2013/12/siernodejs)



![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/handson1.png)

## 目次`

## 1. ハンズオンとは

> 体験学習を意味する教育用語。ー(中略)ー 本で学ぶだけでなく実際に行った方が学習効果が上がるという考えに基づく。
> [ハンズオン - Wikipedia](http://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%B3%E3%82%BA%E3%82%AA%E3%83%B3)
> 座学だけではなく、実際に手も動かしましょうという育成方法で、実際に手が動かないといけないエンジニアにとっては最適な育成方法だと思います。

座学では習得に時間が掛かるのですが、経験者の指導の元、集団学習の相乗効果もあり、質の良いハンズオンは短時間で効率的なスキルの習得ができると思います。

## 2. ハンズオンの心得

ハンズオンで最も悩ましいことは、ハンズオンが体験をベースにしているため**「当日にならないと分からないことが多い」**ということです。

ハンズオンは生ものです。参加者も初心者から上級者まで混ざって同じハンズオンを行うことになります。発表形式の勉強会・セミナーや、長時間作業するハッカソンのようなイベントとは全く別次元の難しさがあると思った方がいいでしょう。

さらに主催側での現場判断が非常に多いのがハンズオンの特徴です。そのため、成功させるためには用意周到な準備が必要です。

## 3. 成功させるための 6 つのポイント

では、本題。私が考えるハンズオンを成功させるための 6 つのポイントです。

### ポイント 1. ゴールの設定

ゴールの設定で間違いやすいことは「技術の正確さを伝える」ことがゴールとなっているケースです。経験的に、ハンズオンは「今、覚える技術の価値」に重きを置いて、ハンズオンではその**価値を体験させて感じさせることをゴールにするべき**だと思います。
これはハンズオンを受けた参加者の満足度に最も関わってくるポイントだと思うのですが、後日、参加者が自主的に考えて不足分を学習するように仕向けられるのが理想です。その楽しみをハンズオンで奪ってはいけません。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/handson2.png)

つまり、**魚のつり方ではなく魚を釣ることの価値についてゴールを置くべきです**。

### ポイント 2. 自習型コンテンツ

コンテンツについては**「自習型」「拡張性」**の 2 点です。参加者には様々なレベルがいる事を想定します。特に注意することは**上級者を飽きさせないこと**。上級者が飽きてくると場が白けだします。上級者にはどんどん先に進んでもらって、自分のイマジネーションを膨らませてハンズオンの題材を拡張してもらえるようなコンテンツとなっていることが理想です。

自習型コンテンツはハンズオンに付いて来れなかった人が後日、復習できるためでもあります。また、ハンズオン参加者が後日講師になることも想定しています。

### ポイント 3. タイムキーパー

ハンズオンの章ごとに制限時間があると、**緊張感を保ったままテンポ良く進めることができます**。制限時間があることで、そこまでに内容を終わらせなければなりませんし、周りの状況と比べてることで参加者が自身のレベルを把握しやすくなります。

ただし経験上、講師とタイムキーパーを兼務することは非常に難しいです(中には出来る人がいるようです・・・)。誰か別の人にタイムキーパーを頼んだ方がいいでしょう。講師はタイムキーパーの報告と現場の状況を鑑みて、タイムマネージメントしていく必要があります。

こちらが Web Components ハンズオンを行った際のタイムテーブルです。当日はこれをベースにいろいろ時間のやりくりしてました。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/handson3.png)

### ポイント 4. チューター

制限時間に間に合わなかった場合や、講師が手が開かない場合に参加者のフォローを担当してもらいます。チューターがいる事で、安心して(いろいろ切り捨てて)計画された時間通りにハンズオンを進めてることができます。**ハンズオンが途中で時間切れになってしまうほど、後味が悪いものはありません**。講師はより多くの人をゴールまで導くよう努力しなければなりません。

### ポイント 5. 代替え開発(実行)環境

参加者によって PC や実行環境は異なります。PC 固有の事情で実行環境が動作しなかったり、開発が出来なかったりした場合、そのフォローでハンズオン全体の進行が遅れることさえあります。そのため、**万が一のため、クラウドやブラウザ上で動作するような代替え環境を準備しておく**といいでしょう。

フロントエンド開発のハンズオンでは「[Cloud9](https://c9.io/)」がおススメです。

### ポイント 6. 成果発表会

作ったものは何かしら発表する機会があった方がいいです。その方が参加者同士の刺激になります。講師側も見てて楽しいです。

##︎ 4. 課題

一番の課題は 0 からコンテンツを作る場合のコストです。

ハンズオンの内容にもよるのですが、必ずしもコンテンツを作る必要はなく、海外の Blog とかチュートリアルなどをコンテンツとして利用してみるのもいいと思います。

## 5. まとめ

ハンズオンを成功させるためのポイントについてまとまったものが無かったので、私が考えるハンズオンを成功させるためのポイントを 6 つまとめてみました。

1.  ゴールの設定
2.  自習型コンテンツ
3.  タイムキーパー
4.  チューター
5.  代替え環境
6.  成果発表会

成功のさせるには「ゴールの設定」が最も大事なのですが、現場をうまく回すためには「タイムキーパー」と「チューター」が地味に大事だと思います。

いかがでしたでしょうか。

## 番外

### a. 場を作る

ハンズオンの会場の制約などあって必ずしも出来る訳ではないのですが、「場」というものを常に意識して会場の設営などやってます。こちらのスライドに良くまとまっています。

[夏サミ B5「そろそろ社内研修を活かしませんか？」](https://www.slideshare.net/gaoryu/20130801-devsumi)

IT系ハンズオンを成功させるための6つのポイント

[デブサミ 2014](http://event.shoeisha.jp/devsumi/20140213/)のエンタープライス向けのショートセッションにて
10 分間という短い時間ですが、私の「Story」「Action!」についてお話させていただきました。

Yet Another Your Story (Enterprise TED 3)
[http://event.shoeisha.jp/devsumi/20140213/session/401/](http://event.shoeisha.jp/devsumi/20140213/session/401/)



![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/devsumi1.jpg)

講演前の TED メンバー。みんな緊張してます w。（撮影：荒井さん）  
（上段左から、高柳さん、中野さん、梅澤さん、川添さん）  
（下段左から、高野さん、わたし、平栗さん）

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/devsumi2.jpg)

講演前の準備風景（撮影：荒井さん）

資料は 5 分で読める内容ですので、悩める業務システムエンジニアの方は、読むと少しエネルギーをチャージできると思います。

内容は、35 歳からフロントエンジニアへキャリアチェンジした、私の小さなサクセスストーリーについてです w。
ちなみに読者の自発的な「Action!」を促す仕様であるため、自己啓発本のような即効性のあるものではありません。
でも、共感できる方には内側からじんわり効いてくる内容だと思います。

資料はこちらです。

[35 歳無名のシステムエンジニアが 1 年半でフロントエンジニアになるために行った 3 つの成長戦略](https://www.slideshare.net/mitsuruogawa33/35-31190170)

では、少し言いたかったこととか背景とか補足しますね。

## 伝えたかったのは「自分主体」への転換

伝えたかったことは「SI 最高！」ではありません w。
あまり資料の中では語られてないのですが、自分の中で 1 年半でもっとも変わった部分があるとすると「思考停止しなくなった、情報に流されなくなった」ところだと思います。

今でも「SI オワコン」と言われている世の中ですが、
それを聞いて「オワコン」と感じるかどうかは、自分受け取り方次第なのです。

資料中で成長戦略を見直すとか、現職に残って頑張るとか言ってますが、
大事なことはすべて自分で考えて決断することだと思います。

## 35 歳以上だからできること

今回は私と同年代をターゲットにしていますが、
それには私なりに SI 業界の悲しい現状を意識した明確な意図があります。

というのは最近、情シスや SI は役割を攻めに変えなければ！というような流れになってきて、号令をかけるだけの上の人たちはイケイケになっている訳ですが、
その一方で、現場では過去の負の遺産や無理難題を背負わされて身動きが取れない所も少なくはありません。
まさしく崖っぷちです。

こんな崖っぷちの状況をなんとかするためには、
業務システムの開発現場や動いているシステムの現状を知っていて、未来の話を考えられる前向きなエンジニアの力が必要なのではないでしょうか？

このような役割ができるのは、はっきり言って今の 35 歳以上の人たちだけです。

## SI だから出来る日本の未来の為に出来る事

ところで 20 年後、日本の未来は明るいのでしょうか？
うーん。

私には 3 歳になったばかりの娘がいるのですが、
娘が大きくなったときに日本がどうなっているのか心配でなりません。

良くも悪くも、今までの企業システムは SI が支えてきました。
そして、これからも SI は日本の企業システムを支えていくでしょう。
世界と戦う企業のために、武器となる IT サービスを SI が提供できなければ、やっぱり「オワコン」の SI はそこに頼っている企業共々終わってしまうと思います。
SI だけだといいのですが、企業まで共倒れさせてしまうのはいかがなものかと。。。

まじ SI 頑張れ。

## 最後に

とはいえ、SI を取り巻く状況は年々厳しくなってきたのも事実です。
いつぞやのガードナー予測にあった通り、今後いくつかの SI は姿を消すかもしれません。
そんな状況の中、保守的な SI 業界にいるとついつい弱気になってしまいがちですが、私が会社の同僚に口を酸っぱくして言っていることが 1 つあります。

> 「全体の 2 割を変える、2 割が変わると全体が変わる。」

> 「一度に全体を変るのは難しい。まず 2 割の有望な人を変えるように試みる。その 2 割の人を使って全体にアプローチしていこう。」

これは、会社の中だけではなく、SI 業界、元気を失った日本社会全体にも言える事なのかもしれません。そんな熱くて前向きなオッサン増えるといいですね。

まじオッサン頑張れ。

## 謝辞

川添さん、高柳さん、資料作成詰まった時、助けていただき本当にありがとうございました。
皆さんのサポートがなければ、この発表は世に出なかったと思います。

それから TED メンバーの皆さん、素晴らしい時間を共有できて本当に有り難かったです。
これからもそれぞれのフィールドでのご活躍お祈りしています。

###️ で、宣伝 w

そんな、悩める SI のシステムエンジニア皆様へ、私が所属する社外コミュニティ「html5j エンタープライズ部」にて HTML5 に関するカンファレンスを 2/28 に開催することにしました。

[「Enterprise×HTML5 Web Application Conference」](http://conference.html5biz.org/2014spring/)

無料です。ビールまで奢ります w。

ここでは、「HTML5 を使っていかに安全にアプリケーションを構築するか」に特化したベンダー系セッションと
「HTML5 を実際の企業システムで使う上でのノウハウ」が一杯詰まったオープン系セッションの 2 つを準備しています。

これからの SI を背負う熱意のあるエンジニアの皆さんの参加をお待ちしております。
（平日開催です。まじめな内容ですので、有給ではなく堂々と業務時間でお越しください。）

次はあなたの Action！

デブサミ2014で35歳からフロントエンジニアにキャリアチェンジして35歳定年説を覆した話をしてきた

今年も最後となりましたので、自分の 2013 年の活動について振り返ってみます。
ちなみに去年の最後は[enja-oss について](http://blog.mitsuruog.info/2012/12/enja-oss.html)書いてます。  
それから「来年こそはもっと質の良いアウトプットしたいと思います。」と締めくくってますね。果たして私は今年、何をやっていたのでしょうか。。。



![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/mitsuruog.png)

1.  1 月〜3 月 翻訳と Backbone.js の SPA チュートリアル作成
2.  4 月〜6 月 HTML5j エンタープライズ部（旧えんぷら部）に参加
3.  7 月〜9 月 JJUG とのコラボレーション
4.  10 月〜12 月 技術研究所へ配置換え
5.  来年の活動

## 1. 1 月〜3 月　翻訳と Backbone.js の SPA チュートリアル作成

この間は、enja-oss にてひたすら stylus 関連の翻訳してました。

- [https://github.com/enja-oss/stylus](https://github.com/enja-oss/stylus)
- [https://github.com/enja-oss/nib](https://github.com/enja-oss/nib)

Javascript の勉強がてら、Airbnb の Javascript スタイルガイドの翻訳を行いました。  
現在では 9 カ国語に翻訳されている、Airbnb のスタイルガイドですが、私の日本語版が最初ですね。  
当時、Javascript どう書けばいいのか迷っている時期でしたので、このスタイルガイドの翻訳は自分にとって非常に良い活動でした。

[https://github.com/mitsuruog/javacript-style-guide](https://github.com/mitsuruog/javacript-style-guide)

おそらく密かに今年のアウトプットとしては一番のヒットだったのが、Backbone.js で SinglePageApplication を作るためのチュートリアルです。
現在では、自分でカンニングするほど w、当時そんなスペックが自分にあったなんて・・・信じられない。

[https://github.com/mitsuruog/SPA-with-Backbone](https://github.com/mitsuruog/SPA-with-Backbone)

当時、Bootstrap2.3 でエンタープライズ向けの Web アプリを作ってました。  
Bootstrap は余白が多いので頻繁にカスタムする機会が多く面倒でしたので OSS にしました。3.0 対応は未定です。

[https://github.com/mitsuruog/bootstrap-narrow](https://github.com/mitsuruog/bootstrap-narrow)

## 2. 4 月〜6 月　 HTML5j エンタープライズ部（旧えんぷら部）に参加

この時期は、HTML5j エンタープライズ部の運営メンバーとして活動していました。  
今の自分があって、ここまで努力できるのもコミュニティメンバーのおかげです。本当に感謝しています。
あまり、後先考えずに参加したのですが、結果としてその判断は間違っていませんでした。

[http://www.html5biz.org/](http://www.html5biz.org/)

この時期は黙々とコードを書いては思索する毎日でした。  
中規模案件のフロントエンドを一切合切任される立場となり、はじめて、フロントエンドのエンジニアとして本格的に仕事をすることとなりました。
普段の鍛錬の結果が実務に本当に活かせるのか、自分との孤独な戦いの日々でした。

## 3. 7 月〜9 月　 JJUG とのコラボレーション

この時期は社内でもフロント関連技術習得を目的としたコミュニティを作っていて、7 月に社内で初めて HTML5 関連技術の勉強会を開催しました。
そのとき未来のフロントエンジニアに向けて作った資料です。

[これからフロントエンジニアを目指すあなたへ](https://www.slideshare.net/mitsuruogawa33/ss-24060048)

7 月には会社のビジネスパートナー向けのセミナーで講演してます。  
ちょうどこの当たりから社内で「HTML5」関連の講演とか頼まれるようになってきましたね。

ただ、この時期仕事の方がテラ忙しくて大変でした。  
140 画面くらいのリッチな社内システム作っていて、フロント側 1 人（私 w）に対してサーバ側 30 くらいの体制でやってて、しかもバックエンドの技術支援とか共通機能とか作ってたので、自分が遅れる（デグレードも w）と開発が全部止まるというような、とにかく辛い立場でさんざん鍛えられました。
そのとき感じたのが、エンタープライズ現場のフロント力の低さで、今の自分の活動ポリシーである「進化し続けるフロントエンド技術とシステム開発の現場をいかに融合させるか！ 」が生まれた時期でした。

忙しい傍ら、勉強がてら co-meeting の未読数を通知するだけの簡単な chrome の extentions を作りました。

[https://github.com/mitsuruog/co-meeting-notifier](https://github.com/mitsuruog/co-meeting-notifier)

9/9 にエンタープライズ部と JJUG と共催で「Java×Web」をテーマに 200 人規模の勉強会を企画して行いました。いままでエンタープライズ部の企画は部長の川田さんが取り仕切っていたのですが、私が手を上げて企画しました。

参加者層を読み違えたので、勉強会自体はちょっとアレでしたが・・・  
自分がエンタープライズ向けに伝えたかったメッセージはレポート記事などで伝わったと思います。レポート記事はこちらです。

[業務系システムは今すぐ脱 Struts を！」業務システムエンジニアのための HTML5 勉強会#04 活動報告](http://gihyo.jp/news/report/2013/09/1901)

## 4. 10 月〜12 月　技術研究所へ配置換え

10 月からは 1 年の期限付きで技術研究所へ配置換えしました。  
実は、ずっと本気で転職を考えているのですが、あえて現職で頑張る道を選ぶことにしました。
（このことについてはそのうち記事にしようかな。。。SI の退職エントリ多いし）

この時期から社内外問わず講演する機会が増えましたね。  
一番光栄に思ったことは 11/9 の JJUG CCC での講演機会に恵まれたことです。  
普段、Java をやっている身として JJUG CCC に出て話をするなんて、夢のような話でした。
そのとき発表した内容がこちらです。

[メンテナンス性の良い Web システムを構築するために Java とフロントエンドでやるべきこと](https://www.slideshare.net/mitsuruogawa33/webjava)

そうそう、11/9 の JJUG CCC の当日に Macbook Air が届きました。JJUG CCC も Mac で登壇しています。これまでずーと Windows＆lenovo でしたが、今ではすっかり Macbook Air の虜ですね。

仕事では、とあるベンダー製 HTML5 関連の UI フレームワークの国内初事例に挑みながら、フロントエンドのテスト自動化など、HTML5 時代の開発現場の負担やリスクをいかに軽減するか模索する毎日です。

12 月に社内で Node のハンズオンとかやりました。資料はこちらです。
来年も、社内でフロントエンドのキーテクノロジについてハンズオンしながら教えますので、今後もリソース増えそうです。

[https://github.com/mitsuruog/node_study](https://github.com/mitsuruog/node_study)

同僚が困ってたので、サクッと three.js のサンプルとか作りました。

[https://github.com/mitsuruog/richo-theta-with-threejs](https://github.com/mitsuruog/richo-theta-with-threejs)

ざっとこんな感じですね。  
うーん、去年の自分と比べると全くの別人なんですが、正直もっと頑張れたかなと。。。  
もっと頑張れ自分。

## ５. 来年の活動

来年は、今年（前 Windows マシンが壊れて）できなかった JavaEE とフロントエンドのチュートリアルを完成させたいですね。
とりあえず Backbone.js で作ってますが、他に有名どこのフレームワークでも作ってみてエンタープライズ目線で検証・評価したいと思います。

テスト自動化についても、何らかの結果を出したいです。
それからいくつかフロント技術に関する論文を書いて発表したいです。

それから、活動のフィールドを変えます。  
今年 1 年、エンタープライズ HTML5 の立場で活動してきましたが、フロントエンド技術のコアが Javascript と言うこともあり、ブラックボックス化が困難であり、企業としてマネタイズすることが難しいと感じています。  
近い未来では HTML5 特需、IE11 対応特需など見込まれますが、やっぱり一過性のものかなと思っています。

という訳で、表では今まで通りフロントエンジニアとして活動していきますが、裏では、本当にお金になる HTML5 とは？ということをキーワードで活動していたいと思います。

来年こそはもっと質の良いアウトプットしたいと思います。  
では、みなさん良いお年を。

2013年を振り返る

2013/11/09 に行われた[JJUG CCC 2013 Fall | 日本 Java ユーザーグループ](http://www.java-users.jp/?page_id=695)で話してきました。Java の講演者が多い中で HTML5 系の話ということなのか、立ち見が出るほどの大勢の方に聞いていただきました。本当にありがとうございました。  
講演の内容を少し補足しながら、ほかにも言いたいことがあったので書きたいと思います。



### このエントリでお伝えしたいこと。

1.  JJUG CCC 2013 Fall にて話してきました
2.  発表内容についてのちょっとした補足

早速ですが、発表資料はこちらです。

[メンテナンス性の良い Web システムを構築するために Java とフロントエンドでやるべきこと](https://www.slideshare.net/mitsuruogawa33/webjava)

発表内容については、Java の JSF か JAX-RS を使って開発を一通り経験した場合、普通の感覚のエンジニアであれば気づくようなポイントをフロントエンジニアの目線からまとめてガイドライン化したものです。  
これから JSF や JAX-RS を使ってみようと考えている方には、少しは有益な情報になったのではないかと思っています。

概要は以下の通りです。

- フロント側とサーバ側の役割分担を明確にすること。特に JSF は注意。
- JAX-RS
  - フロント側は JavascriptMV\*系フレームワークで構造化する前提で、REST で作る。
  - どれだけのフロントエンジニアの調達
  - 教育ができるかが成否を分ける。
- JSF
  - フロント側はほどんど何もしない。フロント側は JSF が提供する機能のみで作る。
  - フロントエンジニア不在でもある程度リッチな Web システムが構築可能だが、限界はある。

## その他言いたかったことをつらつら・・・

フロントエンジニアとしては、JSX−RS を使って行きたいのですが、Struts+JSP 主体の業務系エンジニアが、すぐフロントエンジニアにスキルチェンジできる訳ではないので、今後の業務系システムでは JSF が主に使われていくのかなと考えています。  
とはいえ、Struts ＋ JSP から JSF ストレートに移行できるというような単純なものではなく、JSF 独自のライフサイクルやお作法があるため、扱えるようになるための教育コストは掛かると思っておいた方がいいでしょう。

また、JSF でもっとリッチな UI を実現したい場合、Richfaces、Primefaces といった、サードパーティ製のライブラリという選択肢があります。ただし、JSF というブラックボックスの上にさらに大きなブラックボックスを抱えるようなイメージ構図になります。何かあったときに Javascript 側のデバックを行うのは相当な困難が伴うでしょう、ご利用は計画的にといったことでしょうか。

## 最後に

業務系システムにおいては今後 JSF が使われて行くだろうと先ほど言いましたが、本当はフロント側とサーバ側は JSON などのデータを挟んで粗結合に構築するべきだと思います。そのためこれからの Java の Web 開発の本命は JAX-RS だと思ってます。

今回の JJUG CCC での講演の件、貴重な体験をさせていただきました。JJUG スタッフの皆さん感謝しています。ありがとうございました。

JJUG CCC 2013 Fall で話してきた

今年も今日で最後となりましたが、このような素晴らしいコミュニティでの活動について書くことが出来、非常にうれしく思います。
少々勢い余って参加したのですが、参加してみると非常に収穫が多く、参加して本当に良かったと感じています。



### このエントリでお伝えしたいこと。

1.  enja-oss に参加しよう！
2.  OSS を支える人たちと精神に感謝！
3.  来年はもっと頑張る！

## enja-oss とは

[@cssradar](http://twitter.com/cssradar)氏が立ち上げた、OSS のドキュメントを日本語訳するコミュニティです。
Guthub で運営されており、2012/12/31 時点で 14 名が参加しています。
私は主に Backbone.js と Underscore.js の翻訳に携わっています。

[https://github.com/enja-oss](https://github.com/enja-oss)

こちらは先日社内で 3 分 LT をした際に、enja-oss での私の活動について紹介した資料です。
（内容薄いです・・・orz）

[Enja OSS やってます](https://www.slideshare.net/mitsuruogawa33/enja-oos-15742434)

## enja-oss の特徴

まず、enja-oss はギブ&テイクの精神で運営されているコミュニティです。翻訳に協力したい方であればどなたでも参加できます。

また、翻訳初心者向けに[@cssradar](http://twitter.com/cssradar)氏が監訳を行ってくれます。

技術文書という性質上、誤訳があってはならないというプレッシャーの中で、監訳を受けられるという事が、私にとっては積極的に翻訳にチャレンジしようというプラスに働いています。

（本当に[@cssradar](http://twitter.com/cssradar)氏には感謝です。）

## enja-oss での収穫

参加して 1 ヶ月程度ですが、本当にたくさんあるので頑張って 3 つに絞りました。

1.  翻訳した部分について深く知れる。
2.  Github のコミッタとしての経験。
3.  他社のフロントエンジニア（しかもトップエンジニア達）との交流。

（英語の読解力と読むスピードが格段に上がったのですが、ある意味当然なので除外します。）

### 1. 翻訳した部分について深く知れる。

皆さん機械翻訳しことがあるのでわかると思いますが、直訳しても何を言っているのか理解できないことが多々あります。そんなときはソースコードを読んだり、機能テストを行ったりして言わんとすることを確かめる必要があり、結果深く知ることが出来ました。

とは言っても、理解した内容を分かりやすい日本語に置き換える部分は、また別次元の難しさがあり、これは常に悩みます w。

### 2. Github のコミッタとしての経験。

個人で Github を利用していても、なかなか Pull&Request 処理することなんてありませんよね。

それに、OSS のコミッタってなんか響きがかっこいいです w。

（ただそれだけです・・・）

### 3. 他社のフロントエンジニア（しかもトップエンジニア達）との交流。

enja のメンバーを見るとすぐ分かるのですが、サイバーエージェントのトップエンジニアが多数参加しています。

私も一時期、このようなトップエンジニアと関わりたくて転職を考えていたのですが、思わぬところでコラボレーションできて非常に感激しています。他のメンバーについても魅力的な人が集まっているので、すべてにおいて貪欲に勉強させていただきます！

## 最後に

長々と書いてきましたが、実は OSS の文化や空気に直接触れられたのが一番の収穫でした。
何かやる際に、「公開して世の中の役に立つような事をしよう」という目標（意識転換？？）が出来たのが良かったです。

来年こそはもっと質の良いアウトプットしたいと思います。

では、みなさん良いお年を。

enja-ossに参加して思ったこと

[子育てエンジニアがお役立ち育児グッズをひたすら紹介する Advent Calendar 2012](http://www.adventar.org/calendars/45) の 22 日目のエントリです。ちょっとおもしろそうなので参加してみました。  
タイトルは少し釣りっぽいです。



### このエントリでお伝えしたいこと。

1.  お食事エプロンはポリエチレンとかシリコン製に限る！
2.  毎日の小さな努力を続けること。
3.  人生は長いので、とにかくあせらず頑張る。

このアドベントカレンダーの趣旨として、まず育児グッツを紹介することになっているので、我が家でおそらく一番活躍している育児グッツの「お食事エプロンを」紹介します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2012/OGYU.jpg)

「OGYU」というメーカー（ブランド？）のお食事エプロンです。ポリエチレン製で食器感覚で洗えます。これは「PLATINUMBABY」とのコラボ品なので現在は購入することはできませんが、類似品は[Amazon](https://www.amazon.co.jp/dp/B001QOAS2Y/ref=as_li_qf_sp_asin_til?tag=mitsuruog-22&camp=243&creative=1615&linkCode=as1&creativeASIN=B001QOAS2Y&adid=00QK31KGT3T3CED7A7W9&)などで購入可能です。

購入から約 1 年間毎日使っていますが、本当に丈夫で、嫌なにおいが一切しません。  
もう一度生まれ変わって子育てしても購入したいほどです。本当にオススメです。

で、ここからが本題です。

## 子育てエンジニアが感じる焦り

まず、「子育てエンジニア」と言っても私が専業主夫として育てている訳ではありません。  
妻と共働きですので、あくまで家事と育児の分担はフェアで行きたいというのが、私のポリシーです。

ただ、独身の自由な頃と比べると、自分の時間というものは確実に減っています。
という訳で、やりたいことのタスクが消化できず、塩漬け状態のものが溜まってくると、少し焦りや苛立ちを感じることも少なくありません。

このような感覚は、子供を持つエンジニアが 1 度は持つ感覚だと思います。

## 今年 1 年どれくらい時間を使えたのか？

とは言っても、時間がまったくないわけではありません。
少しずつであっても毎日努力しているはずです。  
せっかく、この（アドカレ）機会を得ましたので、毎日の努力時間を明確にして、客観的に判断することにしました。

私の場合、一日の自由時間は PM22:00 ～の 2 時間です。
休日も家事をほとんど受け持つので、週を通して変化は無い前提で計算しました。
また、年間通してほぼ休まずできたので年間で計算した場合、次の通りでした。

自由時間（時間単位）

- 2（h/日）
- 14（h/週）
- 60（h/月）
- 730（h/年）

少し分かりやすくするため、日単位にします。

自由時間（日単位）

- 0.08（日/日）
- 0.58（日/週）
- 2.50（日/月）
- 30.42（日/年）

計算してみると（当たり前の事実なのですが・・・）私が感じている感覚よりも遥かに大きい値が出て驚きました。

この時間に対する考え方は個人差があると思いますが、私は今年 1 年間のアウトプットを考えたとき、時間に対して少ないなと感じました。（だって、年間で 1 ヶ月もあったのですから。）

と言うわけで、結論としては

- 時間は充分あった。
- 時間に対してのアウトプットの量が少なかった
- 焦っていたのは時間ではなく、アウトプットの量。

という訳で、目線がミクロになってしまって焦ってしまったようです。
（それにまだまだ、スキルが足りてませんね・・・）
とは言っても、改めて計算してみると、毎日の少しずつの努力の積み重ねが大事だと言うことが、本当に痛いほど分かりました。

## まとめ

1.  人生で焦った時ほどマクロな目線を意識すること。
2.  1 日少しの努力を続けること。（1 日 2 時間で年間 30 日！！）

来年もこのペースを維持しながら、さらにレベルアップして行きたいと思います。  
それから、来年はもう少しアウトプットの量を増やしていきます。

Tag: その他