フロントエンドの勉強としてGitHub PagesでダメWebサイトを公開してみました

はじめに

記念すべき最初の「実装してみた」記事です。
GitHub & フロントエンド初心者がこんなもの↓を作りました、という話です。

• こまど GitHub Pages

目次

はじめての「実装してみた」

技術の勉強が捗らない！

技術ブログのつもりで始めたこのブログですが、これまでの投稿で何一つとして実装していないことに気づきました。仕事でプログラムを書くのは好きなのですが、どうもプライベートの技術の勉強は捗らないんですよね。勉強に時間を割くことは吝かではなく、書籍やネットの記事などを見て勉強することも少なくないのですが、

• 内容がエモい話に偏ってしまう（仕事術とか組織論とか開発手法とか）
• Hello World的なものや単一の機能の写経までで途絶してしまう

というのが自分の傾向としてあるな、と感じています。課題解決の手段としてエモい話が有効である場合も多く、自社の状況からするとこちらの方にまず手が着けやすそうだったので、その方面に力が入るのはある程度は意図的ではあります。

ただ一方で、技術で解決されるべき問題をエモい話で解決しようとしてしまったり、業務で与えられた技術的課題を自分の技術力の不足によって解決できなかったりするという怖れがある以上、技術の勉強をすることは不可欠だなと考えています。

「おそらく自分のやりたいことがマネジメント方面にあるのだろうな」、「新卒でエンジニアになったからといっても技術にこだわる必要はないんじゃないか？」などと思うこともあり、考えをまとめておきたいと思っているのですが、「いいから実装しろ」という天のお告げが聴こえたので、とにかく何か実装してみることにしました。

フロントエンドの勉強をしよう

さて、学ばねば、と思っている技術はいくらだってあるわけですが、今回JavaScriptを勉強したいなと思いました。JavaScriptは、

• 業務で使うことがある
• Webとかbot作成とかいろんな場面で使える
• AngularとかReactとかNodeとか聴こえてくる

といった理由で、学ぶ必要性は感じています。ただ、JavaScriptをそれ自体として学ぶのはイメージが湧かず、またWebサイト制作でもすれば、JSは当然学ぶことになるのでしょうが、新人研修でWeb技術を少しだけ学んだときに興味が持てず、業務でもビジネスロジック側を触ることがほとんどになったので、これまで放置してきました。

Web系に転職したり、フリーランスになったりする予定も今のところないし、趣味で何かサイトで公開したいという気持ちもないし、Webサイト作ってもなぁ、というのが正直なところです。しかし、 「いいから実装しろ」 という天のお告げが再び聴こえたので、Webサイトを制作してみることにしました。

はじめてのGitHub Pages

「GitHub Pagesがあるじゃん」と思った

さて、Webサイトを作るなら、どのように作っていくのがよいのでしょうか。やはり、公開した方がいいだろうな、と思ったとき、「GitHub Pages で公開すればいいのでは？？」 と思いつきました。ちょうど先日、『わかばちゃんと学ぶGit使い方入門』を読みまして、

GitHubには【GitHub Pages】という静的Webサイトの無料ホスティングサービスがある

ということを知識として得ていました（手元に今ないのですが、確かこの本で知ったはず）。

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

【2018.05.07追記】 やはりわかばちゃん本でした。Section 29です。

ゆくゆくはDB接続をするようなアプリケーションを作れればと思っていますが、さしあたりのWebサイト制作という目的にはGitHub Pagesで足りると考えました。また、GitHub Pagesを使用することには、

• Git, GitHubを使う練習になる
• 勉強・試行錯誤の過程が残る
• フィードバックをもらいやすい

などのメリットもあると感じ、よし、GitHub Pagesでやってみよう！ と決めました。

GitHub Pagesに公開してみた

GitHub Pagesでのページ公開の方法は下記のサイトを参照しました。

• GitHub Pages を使った静的サイトの公開方法が、とても簡単になっていた ｜ Tips Note by TAM

大昔、中学生のとき色々と苦しみながらホームページを公開していた記憶があるのですが、簡単なもんですね。 手順は、

1. GitHubにレポジトリ作って、
2. ローカルにクローンして、
3. ローカルで編集して、
4. コミットして、
5. プッシュして、
6. Settingsから公開

これで公開は完了です。

はじめてじゃないJavaScriptとHTML & CSS

JavaScriptを書いてみた

さて、いよいよ中身です。とはいえ、<h1>タグとかは流石にわかる一方で、実践的に「こういうサイトが作りたい」というものがあるわけでもなかったので、書籍のサンプルコードのなかでJavaScriptを使っている風のところを選んで実装してみることにしました。今回は、こちらの書籍に載っているストップウォッチにしました。

これからWebをはじめる人のHTML&CSS、JavaScriptのきほんのきほん

下に今回書いた（写経した）コードの一部を示しています。秒を60で割って分にして、それを更に60で割って時間に……、という流れ、懐かしいですね。

// タイマーの処理
var goTimer = function(){
    var now = new Date();
    var milli = now.getTime() - start.getTime();
    var seconds = Math.floor(milli / 1000);
    var minutes = Math.floor(seconds / 60);
    var hours = Math.floor(minutes / 60);

    seconds = seconds - minutes * 60; 
    minutes = minutes - hours * 60;
    // 0補完
    hours = addZero(hours);
    minutes = addZero(minutes);
    seconds = addZero(seconds);
    document.getElementById('timer').innerHTML = hours + ':' + minutes + ':' + seconds;
}

function(){...}というのがJSだなぁという印象です。もっとも、ES2015からはアロー関数で書けるようになっていて、僕の思うJavaScript像は既に時代送れになりつつあるようですし、僕が知っているJavaが7以前でラムダ式がなかったりするので、Java像もJavaScript像も同程度に歪んだものであることを痛感しました。モダンな書き方ができるようにならないといけませんね。

HTML & CSSも（久しぶりに）書いてみた

見た目にはあまり興味がなく、目的としてもJavaScriptを学ぶことが第一だったので、CSSは特にこだわる必要を感じていませんでした。しかし、友人に「Bootstrapは見た目的に欲しいよね」と言われ、敢えて使わないというようなこだわりもないので導入することにしました。下記のサイトを参考にしました。

• Download · Bootstrap
• Bootstrap3日本語リファレンス
  CDNで提供されているので、上2つのうちの前者のサイトから、【BootstrapCDN】という項目に記載されている下記のコードをコピーして貼り付けます。

<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.1.1/css/bootstrap.min.css" integrity="sha384-WskhaSGFgHYWDcbwN70/dfYBj47jz9qbsMId/iRN3ewGhXQFZCSftd1LZCfmhktB" crossorigin="anonymous">
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.1.1/js/bootstrap.min.js" integrity="sha384-smHYKdLADwkXOn1EmN1qk/HfnUcbVRZyYmZ4qpPea6sjB/pTJ0euyQp0Mk8ck+5T" crossorigin="anonymous"></script>

これでボタンやテーブルに対して簡単にスタイルを適用できるようになりました。めでたしめでたし。サンプルコードの写経だけではあんまりですから、下記の2つを参考にして実装することで、申し訳程度の「オリジナル感」を出しておきました。

• Twitterのタイムラインを貼る（お決まり）
  Twitterタイムラインの埋め込みとデザインカスタマイズの方法 | 創kenブログ
• flexboxで2カラムレイアウトにしてみる
  floatより辛くない「flexbox」でざっくりレイアウト - Qiita

はじめてのJSフレームワーク

Vue.jsをやってみることにした

せっかくなので、JSついでにVue.jsも試してみました。

他のJSフレームワークも考えたのですが、しがないラジオでの言及や友人の話から、Reactなどに比べてとっつきやすいらしいという印象を持っていたためVue.jsに。JSの勉強が進んだらNode.jsでサーバーサイドも書いてみたいと思っています。

Vue.jsを使ってみるのに、何かサンプルを探していたところ、下記のページが見つかったので、こちらのタスク管理アプリを実装することにしました。 また、日本語版の公式ガイドも参照しています。

• Vue.js入門その３〜簡単にTODOアプリを作ってみたよ〜 – RE:ENGINES

jp.vuejs.org

Vue.jsを使ってみた

当初は、「JSフレームワークって大変なのでは？」と思っていたのですが、Vue.jsの導入は簡単でした。Bootstrapと同じくCDNで提供されているので、下記のコードを公式からコピーして貼り付ければ使えるようになります。今回は開発バージョンの方にしました。

<!-- 開発バージョン、便利なコンソールの警告が含まれています -->
<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

こちらを貼り付けたあとは、HTMLに{{ }}で囲まれた「プレースホルダー」を記述し、js側からそれを指定してデータを入れてやればVue.jsのHello Worldは完了です（？）。今回は触りの部分だけで、Vue.jsの何が優れているのか等を理解できるところまではやっていないので、公式ガイドを読みながら勉強してみようと思います。

はじめてのGitHub Issue

写経したはずなのにバグが出た

「さーて、写経して動くようになったっぽいしGitHubにプッシュだー」と公開し、満足した気分でポチポチしていると「ん？」と気づくことがありました。最初から存在しているタスクは正常に【Done!】で削除できるのに、画面から新しく追加したタスクは削除されるタイミングがおかしいではありませんか。 これバグじゃん。

Issueを書いてみた

写経元のサイトから見られるサンプルは正常に動いていましたので、自分のコードに問題がありそうです。しかし、コードを見直してみても、原因がパッと見ではわかりません。そこで、Issueを書いてみることにしました。GitHubの練習です。そこで上げた記念すべき第1号のIssueがこちら。

• 画面から追加したタスクに対するDoneボタンの挙動がおかしい · Issue #1 · ky-yk-d/github-pages-practice · GitHub

Issueのコメントを書くにあたっては、ネット上の情報を参考に書いてみました。書いてみて感じたのは、他の人に伝わりやすいIssueを書くためには、形式・内容の両面の洗練が必要ということです。バグの報告は業務でもする機会があったのですが、口頭で、かつ画面を一緒に見ながら報告することが多かったので、言語でわかりやすく書くのは難しいなーと思いました。

ちなみに、こちらのバグ、JSの中にタイプミスがあった（1箇所だけ isDeleted じゃなくて idDeleted になっていた）というオチでした。自分で修正してクローズ。次はどなたかにissue上げてもらったりプルリク出してもらったりできると、GitHubらしくなってきますね。

おわりに

「フロントエンド技術を勉強するぞ！うぉー！」と走り始め、雑ではありますがWebサイトらしきものを公開するところまでやってみました。思ったことをまとめておきます。

• ネットの情報だけでも色々作れることが実感できた
• 勉強する足がかりを作ることができた
• やっぱりデザイン大事なのである程度気を使うべきだと思った
• 「こういうページが作ろう」というゴールを設定すべきだと思った

最後のものが重要ですね。今回の目的は、とにかく実装してみることだったので、仕方がないのですが、やはり「こういうものを作ろう」というゴールは持たなければならないなと実感しました。言語やツールが手段でしかない以上、目的がなければそれらの勉強が捗るはずがありません。

「プログラミングは嫌いじゃないけど作りたいものがないから勉強できない」という、エンジニアの一部の層には確実に存在しているであろう悩みを僕も持っていますし、一朝一夕で「こんなものが作りたい！！」となることは多分ないと思います。

しかし、今回何もないまま実装してみて目的設定の重要性を痛感しましたので、目的設定に労力を割くのも勉強の一環だと思って、一度ちゃんと考えてみようと思います。一方で、設定できないことを勉強しないことの言い訳にしては元も子もないので、これから週に1回は何かしら実装して記事を書いていきます！ 頑張ります。頑張ります。

最後にお願いをいくつか。

• オススメの書籍や記事、勉強方法などあれば教えてください！
• サイトにツッコミどころがあったらGitHubでIssue or プルリクお願いします！

わかばちゃんと学ぶ Webサイト制作の基本

改訂新版JavaScript本格入門 ~モダンスタイルによる基礎から現場での応用まで

ノンデザイナーズ・デザインブック [第4版]

Tech系ポッドキャストについて(2)：しがないラジオについて

イベントレポートが間に入ったので、前回更新から少し空いてしまいました。ポッドキャストについての記事の続きです。

（前回の記事）

ky-yk-d.hatenablog.com

しがないラジオとの出会い

Tech系ポッドキャストの存在を昨年末に認知したものの、それから特に聴くようになったわけではなかった僕ですが、この4月に「しがないラジオ」に出会ってから、音楽を聴くことが減ってポッドキャストを聴くようになっています。

shiganai.org

正式名称（？）は「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」。パーソナリティはzuckey（@zuckey_17）さんとgami（@jumpei_ikegami）さんのお二人。もともと富士通の新卒入社の同期で、現在はそれぞれ転職をして別々の会社で働かれているということです。

聴くようになった経緯は、たまたまTwitterのTLに流れてきたツイートを見て、「面白そうだし聴いてみるかー」という程度のノリで聴いてみた、というものです。聴き始めてみると、これがなかなか面白く、過去回に遡って消化をしはじめてしまいました。

僕にとって「しがないラジオを聴くこと」の何が良かったのか

Tech系ポッドキャストを聴くのが初めてだった訳ではないにも関わらず、何故僕はしがないラジオに（それこそブログを書くほどの）エンゲージメントを持ったのでしょうか。思いつく理由を書いてみようと思います。

パーソナリティのお二人への親近感

パーソナリティのお二人と僕との間には色々と共通点があり、話を聴いていて親近感を覚えています。

まず、年齢が近い。年齢は僕がたぶん1~2個下ということになると思うのですが、ほぼ同じ世代で、社会人になったのもお二人が2年早いだけなので、お話を聴いていて共感できることが多くあります。

また、文化的にも近しさを感じます。gamiさんとは大学が同じで、在学期間も被っていることもあってか、語り口に馴染みがあるというか、同じものを見てきたな感があります。zuckeyさんは別の大学ですが、僕にもアニオタ声オタ声優ラジオリスナーの時期があったので、非常に親近感を持っています。ヨルナイト×ヨルナイトいいっすよね。  

話のとっつきやすさ

話がとっつきやすいので、気軽に聴くことができています。

一応、Web系の技術の話が割合としては多いと感じていますが、特定の技術について語り続けているという印象はなく、様々な話題を取り上げています。そして、ゲスト回ではWeb系以外の業界の方々を招き、それぞれの分野のお話を上手く聴き出していますので、興味のある回をピックアップして聴いているだけでも面白いです。

また、たびたび登場するReact.jsやVue.jsの話も、聴いていてしんどいということにはなりません。僕はJSを業務で使うことがあまりなく、そのあたりの知識は乏しいので、滔々とこの分野の話をされると退屈に感じてしまうと思うのですが、なんででしょうか、不思議と聴いていて辛くないんですよね。説明の仕方がいいんですかね？とにかく聴いていて辛くないです（もっと分かるようになると楽しいのでしょうが）。

他のポッドキャストなどの情報源を知るきっかけになった

お二人がRebuild.fmに憧れてポッドキャストを始めたという経緯もあり、他のポッドキャストへの言及が度々あります。情報収集源・エンタメとしてのポッドキャストの面白さを知るきっかけを担っているのではないかと思います。

ゲスト回の多さもしがないラジオの特徴だと思います。上でも触れましたが、様々なバックグラウンドからゲストを招いているので、その人のTwitterをフォローするなどを通じて新たな分野の情報源を獲得する入り口としての効果がありました。

勝手に選ぶ「しがないラジオ十選」

過去回全部聴いた訳ではないのですが、印象に残っている回を挙げてみようと思います。

①ep.1 楽しいラジオ

初回ですね。初回の高揚感、Web系に転職して楽しくて仕方がない感じがキラキラと出ています。 

②ep.6 楽しいエンジニアの哲学

gamiさんが哲学の話をし続ける回です。学生時代、曲がりなりにも哲学に近い分野にいた人間ですので、楽しく聴きました（東浩紀は真面目に読んだことがないのですが）。個人的には、下記の部分がツボでした。

「永井均はすごい低レイヤなC言語とかアセンブラを書いている人、東浩紀はどっちかっていうともっとフロントエンドな感じ」www #しがないラジオ ep.6

— 駒戸（こまど） (@ky_yk_d) 2018年4月24日

③ep.7 楽しい雑談

あまり聴かれていない回として言及されていた記憶がありますが、コミュニケーションについて悩んでいるzuckeyさんが本を読んで得た知見をgamiさんが日頃から実践していたというスリリングな（？）回です。

④sp.7a 楽しい！スキルの組み合わせで仕事を作る話

『わかばちゃん』シリーズの作者・湊川あい（@llminatoll）さんのゲスト回です。前向きさというか、直向きさというか、なんというか勇気をもらえる回です。後編の「学習コストを下げる話」も面白い。

⑤sp.8a 楽しくない7次受けSIer

てぃーびー（@tbpgr）さんゲスト回。ひどいブラック企業でも向上心を忘れず、自分のできる範囲で業務改善に取り組み続けたてぃーびーさんのお話は、駆け出しの社会人としてとても勉強になるお話でした。

⑥sp.11b 楽しいドイツでの研究生活

石丸翔也（@shoya140）さんゲスト回。ドイツと日本の労働の文化の違いについては色々なところで言及されていると思いますが、改めて考えさせられた回でした。

⑦sp.13a 楽しいエンジニアが職種を超えて業務が効率化された話

ぷぽ（@pupupopo88）さんゲスト回。人にものを教えるということについては、僕も学生時代から色々と考えてきました。それについてはどこかで記事にします。たぶん。

⑧sp.14a 楽しい積ん読カンバン術

るっか（@lucca0show）さんゲスト回。この回を聴いてTrelloを使い始めました。Trello積ん読カンバン、やばいです。見たくないものを見えるようにしてしまった。頑張ります。

⑨sp.19a 楽しい！？PL／Iでレガシー銀行システム開発

はっせー（@Dear_you_cry）さんゲスト回。聴き始めて最初の方に聴き、衝撃を受けた記憶があります。レガシー技術の話は必聴です。自分の会社のレガシーさは生温いな、と思えるほどです。

⑩sp.22b 楽しい超スクラムと驚異の1 Hour Sprint

きょん（@kyon_mm）さんゲスト回。アジャイル、スクラムの実践について非常に刺激的なお話をされています。スクラム関係者のなかにはスクラムの形式を重んじる人もいますが、自分なりに消化し、より良い実践方法を探ろうとされています。

今後の展開？

これだけのゲストを呼びながら、また一回一回も1時間を超えているにも拘らず、高い更新頻度を維持しているというのもしがないラジオのすごいところだと思います。僕がいうのも変ですが、若いお二人が配信されているポッドキャストということで若い世代のエンジニアにとっては貴重なのではないでしょうか。下記のようなイベントも開かれるということですので、今後の展開にも期待したいですね。 

shiganai.connpass.com

（↓ポッドキャストの中で言及されていた書籍）

動物化するポストモダン オタクから見た日本社会 (講談社現代新書)

ザ・コーチ

ファシリテーション入門 (日経文庫)

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

4/26「エンジニアリング組織論への招待 ☓ カイゼン・ジャーニー」 に参加しました

概要

イベントに参加してきました。内容はこの2月に相次いで出版された2冊の書籍、

• 『エンジニアリング組織論への招待』
• 『カイゼン・ジャーニー』

のコラボ企画です。著者の方々は以下の三名です。

• 広木大地（@hiroki_daichi）さん
• 市谷聡啓（@papanda）さん
• 新井剛（@araratakeshi）さん

会場はajitofmでおなじみのVOYAGE GROUPさん。

「エンジニアリング組織論への招待 ☓ カイゼン・ジャーニー」 devlove.doorkeeper.jp

書籍について

開催が発表された時点で既に両方の書籍も読んでいました。順番としては、『エンジニアリング組織論への招待』の方が先で、 発売日前に手に入れていました。原理っぽい話が好きで、うっかり文系大学院まで行ってしまった人間には非常に好印象でした。

大型書店にいったら22日発売の『エンジニアリング組織論への招待』が既にあったので買ってしまった

— 駒戸（こまど） (@ky_yk_d) 2018年2月18日

『カイゼン・ジャーニー』については、ずいぶん遅れまして、読み始めたのは3月末でした。物語仕立てだと思って、買うまでもないと最初は思っていたんですね。すみません。本日の広木さんのお話にもあったように、物語仕立てであることには意義があるのだと、読んでからは思いました。

カイゼン・ジャーニー読み始めた。第1部の江島の人物紹介が他人事に思えない。 #kaizenj

— 駒戸（こまど） (@ky_yk_d) 2018年3月27日

どちらの書籍も非常に楽しく読み、比べて読みたい、もっと知りたいと思っていた本だったので、このイベントが発表されたときは久しぶりに、

ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

となりました。

イベントの中身

本来はきちんとまとめて、内容を消化して公開すべきものと思いますが、鮮度が命、ということでメモ書きをそのまま公開させていただきます。後日、自分なりに消化して別途投稿するかも・・・？

前説

出席者の集まりが悪く、少し開始が遅れたので、広木さんが前でお話をされました。

エゴサーチして「エンジニアリング組織論よかった、カイゼンジャーニーよりいい」と言っている人がいて、問題と思った。自身もカイゼンジャーニーを読んでいて、同じテーマを違う形で扱っているだけの、いい本だと思っていたので、Twitterにその旨を書いたところ、同じくエゴサーチをしている新井さんに発見された（笑）一度会ってみて（主にアルコールが）盛り上がったので、今回こういうイベントをする運びとなった。

1．それぞれの書籍について語る（LT）

こちらについては、実際は、池田さん→原田さん→西村さん→小賀さん、の順番だったと思います。doorkeeperに書かれていた順番で下書きを用意していたので、そのままになっています。
また、開始の遅れによって40分取っていた時間が20分しか取れなくなったため、当初10分間だったと思しき持ち時間は5分に短縮され、みなさま苦労していらっしゃいました。

『エンジニアリング組織論への招待』①：池田秀行さん

発表タイトル：「（未定）」

何を話そうか迷ってタイトルを出していなかったら「未定」となっていた。不確実性の話をしている本なのでこのままでいいや、となった。

技術者と経営者の両方を経験されてきた立場からのお話でした。

• 不確実性の扱いについて一貫した書籍
  • 思考方法
  • メンタリング
  • チーム運営
  • 組織運営
• 感じたこと
  • 自分自身は不確実なことに対する耐性は強い（なんとかなるだろ、感）
  • その分、他人やチームの不確実性というものに、これまではキチンと向き合えていなかった
• 自らを振り返るには最良の本
• 組織リファクタリングのその先にあるもの
  • 技術・ビジネスモデルがコモディティになると組織力が武器になる
  • 組織もシステムもアーキテクチャが重要
  • 人には能力が眠っていて誰にでも創造性を発揮できるポテンシャルがある

「招待」②：小賀昌法(@makoga)さん

発表タイトル：「経営者が読みたくなる『エンジニアリング組織論への招待』の薦め方」

経営者と技術責任者の対話のベースとなる本。経営者に読んでほしい。

想定パターン

①本を薦める
②読む
③第1章で挫折する

なぜなのか

• 目次を見てもテンションが上がらない
  「リファクタリング」とか、「メンタリング」とか・・・。経営者はプライドが高いので「メンタリング」などと言われても「できてるわ！」となってしまいがち。
• 序盤でエントロピーとか数式が出てくる。

対策：経営者が抱えていそうな課題からアプローチする

• 抽象的な指示でもうまくいく、のが経営者にとっても嬉しいはず！
  →デリゲーションポーカーを使おう！
• 「なんで最初は早かったのに後になると・・・？」
  →技術的負債の話。見えるようにしよう！
• アーキテクチャの複雑性と将来要件の不確実性
  →エンジニアが知っていて、経営者が知らないこともあれば、経営者が知っていて、エンジニアが知らないこともある。それを解決するには、一緒に読むしかない！

『カイゼン・ジャーニー』①：西村直人(@nawoto)さん

発表タイトル：「わいが西方でおま！」
遅れていらっしゃったので、原田さんに

チームに時間守れと言っているアジャイルコーチが時間通りに来ない

と皮肉られていました。 慌てていたのかLTもかなり苦しい形になってしまい、ご本人も下記のようにツイートされていました。

LTから出直しやで

— Nishimura Naoto (@nawoto) 2018年4月26日

「アジャイルチームを支える会」からきた。「元・流しのスクラムマスター」。

読書感想文

• 「なぜこれをやるのか」
  これからの人のための理由、順序、そうそうあるある物語、共感が軸
• ソフトウェアの難しさ
  広さ、難しさ、前提知識のアップデート、知識の再編集、オールインワンRailsみたいな感じ 昔あった話を、これからの人たちに向けて、今なりのやり方を整理する
• 巻き込み力
  これから求められるHR、人材スキル

巻き込みエピソード

（※用意されていたようですが、時間短縮のため略されました）

『カイゼン・ジャーニー』②：原田騎郎（@haradakiro）さん

発表タイトル：「カイゼン・ジャーニー」に何が書いていないのか

著者二人が下手くそで、しかし重要なことが書かれていない。

「助けて」

登場人物がみな、自分でなんとかしようとしすぎ。「マネージャー助けて」と言ってあげること。マネージャーからしてみれば、何をしているかよくわからないエンジニアには声をかけづらい。

「ゆっくり」

あのプロジェクトは急ぎすぎ。カイゼンをしていくには安定しておく必要がある。カイゼン・変化の間に、何スプリントか、何も起きない、ユーザーも平和な時期が必要。

「アジャイルコーチは？」

外からくる傭兵はあんなに優秀ではない。アジャイルコーチは来てからしばらくは観察しなければならない。コーチの役割は、チームが見逃していることを気づかせること。

「逸脱しよう」

市谷さんと最初に話した時は「越境」ではなく「逸脱」だった。今までの自分のやり方を少し外れてみる。そうするとどう変わるかわかる。境界もわかる。

2．著者陣による対談

テーマ0：お互いの本を紹介する

『エンジニアリング組織論への招待』について（新井さん）

• 多岐にわたる内容で、書くの大変だったんじゃないか。
• 幅の広さと深掘りを両立できているすごい本。
• 飲み会の時にかかった時間や章立てについて聞いた。
• 認知心理学については自分も興味を持っていたので、学び直すチャンスだと思った。
• 教科書のような感じ。

『カイゼン・ジャーニー』について（広木さん）

伝えたいことがあった時に、納得する回路は人によって違うから使い分ける。自分は原理でしっかり説明されているといいタイプ。今回は、共感を伴った伝え方をするために必要な、ナラティブ性を入れたいとは思ったが、無理だと思った。そうしたら、自分の本と同時期にそのアプローチで書かれた本が出て衝撃を受けた。因果だなと思っているので、一緒に読んでほしい本。

テーマ1：2つの本に共通することは何か。なぜ、共通部分が生まれたのか。

市谷さん

ある難しさに向き合っていくためにどうするか？どうにもならないんじゃないかと諦めてしまいがちな問題に直面することはよくある。それに対して、『招待』はその構造を明らかにすること、『カイゼン・ジャーニー』は動的なアプローチ。

広木さん

共通部分だと思っているのは、「問いを持ちなさい、その問いはあなた自身に向かっています」ということが再帰的に、常に書かれていること。フレームワークや考え方の断片は様々な媒体に書かれている知識。これらの本に書かれているのは知恵。「この状況どうしよう」を問いかけること。なぜその問いを持ち続けられるかというと、良くしたいから。良くしたいという気持ちは、周りに振り回されて失ってしまいがちだが、問いを持ち直すことが必要。それをくどくど言っている本が2冊同時に出てしまったのは大変なこと。大変なので、多くの人で分かち合うと良い。バイラル性を出していきたい。。巻き込んだ方が楽だし、問いを捨てずにいられる。単なるノウハウとしてではなく、輸入物、舶来品ではなくて、色々な人の営みを自分たちのものとして捉え直そうとしたのが2018年2月という時期だった。

テーマ2：それぞれの本で異なる考え方、表現は何か。

新井さん

『カイゼン・ジャーニー』は「物語、解説、物語、解説、、、」と進んでいく。個人からチーム、自社開発から受託開発、という展開。展開に合わせてプラクティスを紹介していく本になっている。『招待』は「Theory」であって、物語ではない。ページ数も多いので、深く解説ができている。『ジャーニー』の初稿にはダブルループ学習の話なども出ていたが、紙面の都合でカットしてしまった。『ジャーニー』を読んでよくわからなかったところを『招待』を読んでもらうといい。それと、キャラクターがいる。

広木さん

「いきなりエントロピーとか言っちゃう感じ」の理屈っぽさ。シンプルな理屈が説明されないでアジャイルやスクラム、マイクロサービスが唐突に出てきて、若い人が飛びついて失敗することをよく見る。ちゃんとベースとなる理屈から出発するものを書こうと思った。情報科学という分野、そもそも科学とは、というところを飛ばしがち。経験主義にせよ、仮説法にせよ、大学の情報系の教養ではやるが、実務に触れていないので重要性がわからずに過ぎてしまう。実務に触れてからだとわかる話、サイバネティクス、エントロピー、科学史が『招待』に書かれている。
『カイゼン・ジャーニー』も『エンジニアリング組織論への招待』も、「なぜ自分のところの事情がこんなに書かれているんだ！？」と言われるが、人類がずっとそうだったから。そういう部分に触れたいなら、『招待』。青春時代、大学時代の取り戻しができるかもしれない。

現場でそれぞれの本をどんな風に使っていけばいいか。著者が気をつけていることは？

市谷さん

「ぼっち」の人向けにこの本は書いた。「なんか変だな」「なんでこんなことしてるんだろ」と思っても、周りは全然感じていない、という境遇にある人に、ぼっちでも次の一歩を踏み出せると思ってほしい。原田さんが「助けて」という話をしていたが、「助けて」と言っても助けてもらえないことも多い。そのときに傍らに置いておいてほしい。

広木さん

何人かで読んで思ったことを言いあった方がいい。ちょっと気になる、ちょっとむかつく、ちょっと話が通じないかもしれないあいつと、これをきっかけに話をする、アルコールを飲む。色んなチームを見ていても、大人は嘘をつく。大したことのない諍いが大きなものになり、あとから理屈や正しさを持ち出される。問いを自分に向けること。ちょっとコミュニケーションをとる。ちゃんと話をしなければならないと気付きながらも、なんか嫌だなと思ってコミュニケーションを怠った結果に起きる問題。コンティンジェンシー理論に関して。お互いにどっちが先にするかというのを監視しているとだめ。それを突き崩す社会の仕組みを作らなければならない。「あいつと話したくないなー」と思い浮かべているあいつと話をしてみよう。ソーシャルメディアを作っていた経験からすると、最強のソーシャルメディアはアルコールだが、アルコールに匹敵するバイラル性、話したくなるようなものを作ったつもり。ビールがライバル。

新井さん

「ファイブフィンガー」などのプラクティスをやってみると、チームが変わっていくんじゃないか。そういう使い方をしてもいいと思う。

お互いに聞いて見たいこと。

Q. 新井さん

表紙の色や英語タイトルの決め方？

A. 広木さん

かっこよさめの本のタイトルをつけたかった。アルファベットの英単語二つ（『Joy, Inc』とか）をつけようと思ったが、技術評論社が「そういうのは違う」という雰囲気があった。洋物に見えては、という感じだったので、わもので、「招待」とついている本があったのでつけた。装丁を考えているときに、デザイナーから現在の英題が出されていたのでいいなと思ってつけた。色については、『ティール組織』が日本で出る前だったが、原書で流行りそうな雰囲気を見ていたので、近いもので少し差別化した。

Q. 広木さん

モデルと思しき人から何か言われたか。

A1. 市谷さん

直接言われなくても、肖像権とか色々あることがわかった。今日の司会の方もモデル。ギルドワークスの同僚だが、こだわりが強い。細かいすぎて色んな人が逃げていく。そんな人。

（司会の方「最初は本名で登場していたんですが今は違います」）

A2. 新井さん

僕も出ています。最初の方に出てくる。

Q. 広木さん

見る人が見れば実際の出来事そのままじゃんという人がいるのでは？

A. 市谷さん＆新井さん

実体験に基づいている確かに出している。1章の終わりの、勉強会をやった後に声をかけてくれた人がいた、というのはそう。

会場からの質問

Q

技術的負債の返却は、ビジネスインパクトに中々跳ね返ってこず、経営層やステークホルダーの協力を継続的に得ることが難しいと感じています。特に長期プロジェクトで中々成果が出ないような状況を乗り越えるコツやエピソードがあれば聞きたいです

A1. 広木さん

自社サービスをやっている組織がどうするかというのが『招待』で、最初は受託なのが『ジャーニー』。自分たちでビジネスをやるとなると、技術力・エンジニアリングリソースという最も調達が難しくなっているリソース、ボトルネックになるリソースの効率化に投資できない会社が生きていけるはずがない。そういったことをきちんと伝えれば、経営層にも伝わるはず。伝え方が悪いのではないか？お互いの認識をすり合わせようと思って、コミュニケーション取ろうとおもって、経営層やステークホルダーにもアプローチするべき。「いつもなんか文句を言っているやつ」と思われたらだめ。あと、「作り直し幻想（作り直せば負債がなくなるという幻想）」は危険。

A2. 市谷さん

「できなくなることがこれだけあります」ということをちゃんとコミュニケートする。エンジニアが逃げてしまう、一緒に働いていた仲間が居なくなってしまうということを目の当たりにすれば、やばいことはわかるはず。

Q

『エンジニアリング組織論への招待』への質問です。 「不確実性に向き合う」というテーマに少しでも関連する理論やプラクティスが全部ブッ込まれてるように感じるほどの情報量だと感じました。これらは広木さん自身、全部実際に実践してきた経験を通して書かれたのでしょうか。どの辺りが理論で、どの辺りが実践なのかに興味ありました。

A. 広木さん

全部やったことのあること。実践したことのないものは理論として書いていない。理屈が切断されているよりは、実践が飛んでしまう方がマシだと思ってこうなった。

Q

経営者へ本を薦めるお話がありましたが、マネジメントされている側の立場として、同僚やマネージャーなどに広げていく方法など何かありませんか？？

A1. 新井さん

勝手にぼんぼんアップする。「実は読んでいるんですよ」という人は出てくる。想いは伝わる人には伝わる。レスがなくても続ける。あと、問題駆動。その人、そのチームが抱えている問題に 関係する形で伝えよう。

A2. 広木さん

とりあえず買っておいておく。UX的な話にはなるが、自分で見つけておもしろいと思うと勧めたくなるが、色んな人に勧められると斜に構える人が出てくる。「自分で見つけた」と、斜に構えるタイプの人に感じさせることは重要なのではないか。「社内Slackでシェアする限りでは写真を貼ってもオッケー！！」ユニコーン企業数社で全社チャンネル（#general）に＠channel で投稿されている。ユニコーンになりたければ投稿しよう！

最後に一言

新井さん

「夜中のラブレター」。ちょっとテンションが上がって考えたこと、妄想をやってみる。甚大な損失を負うことはたぶんない。やってみると自分ごとになってきて楽しい。そんなジャーニーを。

広木さん

セルフマネジメントができることを示すために45キロやせ、禁煙もした。この本を読めばできる！

市谷さん

誰かと一緒に仕事をする、何かを作るのは難しい。協働作業はなかなかうまくいかない。なんとかしていくやり方を広めていくことを読者と一緒にやっていきたい。全部は同意できなくても、少しでもやってみよう。

3．懇談会

「じゃんけんぽん（本）」という書籍のプレゼント企画がありました。広木さんは「デリゲーション・ポーカー」を付けて贈呈という大盤振る舞いでした。僕はゲットできませんでした（が、サインは広木さん新井さんからいただけました！）。

その後の立食形式の懇談会では、広木さんが独演会をしていました。その内容も非常に面白かったのですが、メモをとるという感じではなかったので、印象に残ったお話だけ。

広木さんが懇親会でされていた、「先読みできない要求のストリームに、最小の労力で対応するための用意をするのがアーキテクチャ。そのストリームをフーリエ変換してレイヤで切る発想が、ガートナーのSoE/SoRなどの話にもなる。」というお話も印象的でした。 #eotkaizenj

— 駒戸（こまど） (@ky_yk_d) 2018年4月26日

電車の都合で市谷さんが早く帰られるタイミングで、みなさんで写真撮影。最後は、広木さんの号令で一本締めとなりました。懇談会の時間がたっぷりあったので、著者のみなさんや他の方々とお話できたのはとてもよかったと思います。

おわりに

素晴らしいイベントだったと思います。著者のお三方、LT登壇者の方々、スタッフのみなさま、本当にありがとうございました。新井さんが最後に仰っていましたが、これから日本のソフトウェア業界がもっと楽しく、よいところになるといいですね。

※書籍の読書体験と今回のイベント体験の両方を元に考えた記事を別途書くかもしれません。乞うご期待。。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

SCRUM BOOT CAMP THE BOOK

アジャイルサムライ−達人開発者への道−

Tech系ポッドキャストについて(1)：t_wadaさんとajitofm

初回に予告していたポッドキャストの話を書こうと思います。

ポッドキャストとの関係

昔からiPodユーザーで、ポッドキャストという媒体の存在は知っていましたが、学生時代まではニュースや外国語学習の番組を聴いてはやめ、聴いてはやめの繰り返しでした（飽きっぽい）。学生時代は主たる関心が研究の方にあり、ニュースも語学番組も直接研究に活かせるものではなかった（語学は読解が研究のためには圧倒的に重要でした）ですし、常にガラガラの電車で移動し、書籍を主な情報源とする暇人学生にとってはポッドキャストという媒体はあまり重要ではなかったのです。

就職し、通勤電車で満足に本を広げられない時間ができてからも、しばらくは音楽を聴いて過ごしていました。エンジニアとしての情報収集という点においても、技術書をパラパラと読んでみる程度で、勉強会に行ったり、Twitterで業界の人をフォローしたりといったことはしていませんでした。

t_wadaさんとの出会い

2017年9月くらいから、情報収集をしようと思い立ってTwitterを再開し、またconnpassに登録して勉強会に参加するようになりました。そして、2017年12月5日に開催された下記勉強会での、和田卓人（@t_wada）さんのお話の際に、Tech系ポッドキャストという存在を初めて認識しました。 

connpass.com

確か、この講演のなかで、「ajitofmというポッドキャストに出演して、テスト駆動開発について話した」、というようなことを聴いたのだったと思います。自宅PCのポッドキャストのデータの日付が、12月6日になっていますので、翌日すぐに聴いたんですね。ミーハーですね（笑）それがこちら。 

ajito.fm勉強会の際の和田さんのお話がとても面白く、またテスト駆動開発というものが自社における極めてアクチュアルな問題に関わるものであったことで、しばらく和田さんの書かれた記事や講演資料を読み漁っていました（笑）そのなかで、ajitofmの和田さんゲスト回（6: Worth is Betterを含めて）を聴いたわけです。思えば、この時にTDDを通じて初めてXP、アジャイルというものに接したのではないかと思います。そう考えると、僕にとっては大きな転機だったかもしれません。

ajitofmと、しがないラジオ以前 

閑話休題。このとき、ajitofmについては、和田さんゲスト回以外もいくつか聴きましたが、自分にはわからない技術の話が多く、生活に密着したものにはなりませんでした。ただ、今もフォローはしていて、2018年3月に『エンジニアリング組織論への招待』の著者：広木大地（@hiroki_daichi）さんがゲスト出演された回は拝聴しました。 

ajito.fm

こうして、2017年12月にTech系のポッドキャストというものの存在を認識したわけですが、それからしばらくはまた音楽を聴く日々に戻りました。ポッドキャストが生活に溶け込みはじめたのは、つい先日、しがないラジオに出会ってからです。まだ、聴き始めてから3週間程度しか経っていませんので、すっかり定着したとは言えないのですが、確かなマイブームになっていますので、この気分の盛り上がりを記事にしておきたいと思います。

あんまり一回に長く書くと、すぐにネタがなくなりそうなので、続きは次回。。

テスト駆動開発

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

ブログを始めます。目標：週1更新

著者は何者なのか

こまどです。漢字表記は駒戸ということにしています。もともと下の名前に関わるあだ名だったのですが、性別を偽る（男です）つもりもないので、上の名前という設定にしました。

都内のソフトウェアハウスでSEとして働いています。 未経験で業界に入り、この4月で2年目に突入しました。主な業務はプログラム書いたり、テストしたり、ですね。この辺については今後書くことになると思います。

学生時代は人文系の分野にいまして、うっかり修士課程まで出ました。研究内容については、今のところ書くつもりはあまりありませんが、ノスタルジックな人間なので、大学時代の話はちょくちょく出すとは思います（笑）

このブログに何を書くのか

これが決まっていたら、もっとブログを書くのは早かったと思います。。

このブログは何のためにあるのか

第一には、長い文章を書く訓練をするためです。
学生時代から文章を書くのが苦手で（なぜ大学院にまで進んでしまったのか？）、慣れのためにも、長い文章を書く機会を作ろうと思い、何度もブログを始めては挫折し、始めては挫折し、を繰り返しました。

文章というと、Twitterは、学生時代から愛してやまないツールで、短文投稿は苦痛もないし、それなりに整ったものを書けているんじゃないかと思っているのですが、長い文章になると一気に苦痛で、取り留めもなくなってしまいます。

長い文章を書く機会は、研究者を志す身でなくなった現在ではほとんどありませんので、かつてほど深刻な問題ではなくなっているというのは確かです。しかし、長い文章を書けないという現象が思考の方の散漫さに因っている、あるいはそれらが相互に関連しているという気もしないではありません。

第二には、自分の勉強を促進するためです。
これはよく言われることだと思いますが、アウトプットの場を設けることは、勉強の質を上げると思います。

このブログでは読書からのインプットを、アウトプットすることが多くなると思っています（あ、これは「このブログに何を書くのか」になりますね）。主に、技術書やビジネス関係の書籍になると思います。

読書は、自分にとって重要なインプット源です。高校までは本を読む方の人間ではなかったのですが、大学で見栄を張って本を買い漁り、何かに追われるようにしてそれなりに読書をするようになりました。お陰で、今でも本を読むのは基本的には苦行ですが、本を読むというのは自分にとって自然な行為になっています。

僕が本を読む目的は、娯楽というよりは勉強です。しかし、勉強のために読んでいるにもかかわらず、ざっと読んですぐに内容を忘れてしまったり、書籍の世界のなかだけで読んでしまって現実をその目で見てみるということをしなかったりと、勿体無い読み方をしていると常々思っていました。

そういうわけで、このブログで読んだ本の内容を紹介したり、それを元に考えたことを書いたりすることで、よりよくインプットを消化できるようになれたらいいなと思っています。

今後の更新について

更新頻度：1週間に1回の更新を維持する
上にも書いていますが、自分にとって文章を書くのは重い課題です。何度となくブログ執筆には挫折してきました。今回も、挫折するのではないかという恐怖心が大いにあります。

しかし、いやむしろだからこそ、週に1回という更新頻度目標を設けて、ブログを書くことにします。苦手だとわかっていることこそ、習慣にしてしまう必要があります。好きなことは勝手にやるからです。

意気込み
ブログ開設のきっかけは、最近聴き始めた複数のTech系ポッドキャストです（こちらについては多分近日中に記事にします）。そして、その一つにゲストで出演されていたカカカカックさんの下記スライドが最後に背中を一押ししてくれました。

speakerdeck.com

このスライドには唸らされる箇所が多かったのですが、特に「うっ」となったのはこれです。

エンジニアリングをしていれば毎日がネタの宝庫なはず
ネタが本当にないのであれば、その仕事は楽しいと言えるの？

この煽りにYesと返せなければならない、仕事にネタがなくても、プライベートの勉強にはネタがたくさんあると言えなければならないと思いました。それなりに楽しく勉強している気分ではいたのですが、自信を持って楽しんでいることを表現できたらいいなと思っています。

予防線（頻度を守るために）
最後に。繰り返しにはなりますが、僕は文章を書くのが得意ではありません。ですから、短い記事や、練られていない記事をたくさん書くことになると思います。でもそれで最初はいいと自分にも他人にも言い訳をさせてください。更新頻度だけは守りますから……

というわけで、今後の更新に乞うご期待。。