『アジャイルサムライ』はアジャイルの第1歩

書評

『アジャイルサムライ』を読了したのでレビューを書きます。

入門書としての3つの特色

アジャイルサムライは特に入門書と知っていて読んだわけではないのですが、アジャイル関連の入門書籍としてぴったりな理由が3つあります。

  • 過不足ない分量
  • カジュアルな語り口
    • 「マスター・センセイと熱心な弟子」という謎のコーナーがある
  • たくさんのわかりやすい図

ちなみに私が一番好きなのは荒ぶる四天王*1の図です。

毎週価値を届けよ

海外の書籍にありがちなのは、同じ主張を何度も繰り返すということです。『アジャイルサムライ』も例に漏れず、あることの重要性を繰り返しています。

それは、見出しに挙げたとおり、「毎週お客さんに価値を届けること」です。

実際、やろうとしたら大変

上記「毎週お客さんに価値を届ける」にはいくつか必要なことがありますが、特に私の印象に残ったのは、「成果責任を果たす」ことです。具体的には以下のことをやる必要があると述べられています。

  • 君は、仕事の質に責任を持たなきゃならない。
  • 君は、スケジュールを守らなきゃならない。
  • 君は、お客さんの期待をマネジメントしなきゃならない。
  • 君は、身銭を切るかのような覚悟でお客さんの資金を扱わなきゃならない。

文章にすると当たり前なような気がしますが、実際やろうとすると結構な覚悟が要りそうな印象があります。

『カイゼン・ジャーニー』を読んだときも思ったのですが、読み物としては楽しくても、実際にやろうとなるとめちゃくちゃ大変だ……という感想を持ちました。

疑問……お客さんはだれ？

本書は非常に読みやすいですが、わからなかったところもあります。

例えば、本書では、建設会社で使うシステムの例が多く使われていました。この場合は、誰がお客さんかわかりやすいと思います。

一方、パッケージ製品など、お客さんがたくさんいる場合、本書でいう開発に参加する「お客さん」は誰なのか、ちょっとよくわかりませんでした。おそらく、それを売っていくであろう事業部なのだろうなとは思いましたが。

アプリケーション開発への参加を促すべき「お客さん」が誰かは、もう少し掘り下げられていても良かったなと思いました。*2

まとめ

現在私はアプリケーションの開発に従事していますが、その進め方を客観的に見つめ直す上で、本書は非常に役立ちました。

2011年に日本語訳の初版が発売されましたが、あまり古さを感じませんでした。

プロジェクトにより状況は様々でしょうが、どんな人でも面白く読めると思います。

最後に目次を挙げて終わりとします。

目次

※目次は以下のサイトを参照しました。

『アジャイルサムライ』の書影と主な目次が出てこないから自分で貼るよ - 角谷HTML化計画(2011-07-02)

*1:時間、予算、品質、スコープ

*2:プロジェクトにおいてお客さんが誰かというのはプロジェクト参加者が認識を揃えるべき重要事項です。

JavaScriptのthisでハマった。

JavaScript

JavaScriptのthisよくわからんわという内容です。

問題概要・解決策

以下のようなdataを持つVueファイルを作成したとします。

data(){
    return{
        // 適当な要素
        hogeArray: [1, 2, 3],
        fuga: 1,
    }
}

以下のようなmethodは、意図通りに動作しません。TypeError: Cannot read property 'fuga' of undefined というエラーが出ると思います。

piyo() {
    let filteredArray = this.hogeArray.filter(function (value) {
        // 1だけをfilterする。→ここでエラー
        return value === this.fuga;
    });
    this.hogeArray = filteredArray;
}

正しくは、以下のように書く必要があります。

piyo() {
    const fugaValue =this.fuga;

    let filteredArray = this.hogeArray.filter(function (value) {
        // 1だけをfilterする。
        return value === fugaValue;
    });
    this.hogeArray = filteredArray;
}

thisは難しいということを初めて知った瞬間であります。 定義をちゃんと読んでみたいと思います。

thisの定義とは

いくつか参考文献を挙げます。

場所 thisの参照先
トップレベル（関数の外） グローバルオブジェクト
関数 グローバルオブジェクト（Strictモードではundefined）
call／applyメソッド 引数で指定されたオブジェクト
イベントリスナー イベントの発生元
コンストラクター 生成したインスタンス
メソッド 呼び出し元のオブジェクト（＝レシーバーオブジェクト）

Qiitaの記事が私にとっては一番わかりやすいです。

エラーとなったものは、関数パターンで、thisはグローバルオブジェクトを指していると思います。 正常なものは、thisは呼び出し元のVueオブジェクトを指していると思います。ふと冷静になるとなんでthisでいい感じに各プロパティが指せるんだという感想になりますが、ちょっと今回はおいておきます。

今回は解決方法が楽だったので助かりました。

追記

ドンピシャな記事を教えていただきました。

tadaken3.hatenablog.jp

読了『ライフ・シフト』

書評

各所で話題になっていたので読みました。

大事そうだなと思ったところをまとめます。

人生100年時代になる

表紙にあるように、人間の平均寿命は伸び続けているので、1991年生まれの私は100年いきてもおかしくないという状況にあります。

その場合、65歳でリタイアしようとすると、所得の何パーセントを貯蓄に回さなければいけないかという問題がありますが、かなり現実離れした値になってしまいます。*1

じゃあどうすんねんという話ですが、基本的には労働期間を伸ばすことになります。しかし、ひたすら働き続けると、自分の知識が古くなっていくので所得は下がっていく。それを避けるために、自己投資（リ・クリエーション）が大事だと述べられています。

感想ですが、所得が下がっていくかどうかはどのような仕事をしているかによる気がします。大事なのは、スキル向上にもならず、あまり価値のない経験しか積めていけないような仕事に就き続けないよう気を付けることだと思います。

無形資産の定義

現金や住宅などの有形資産との対比で、作中では無形資産が定義されています、以下の3つに分類されています。

  • 生産性資産
    • 仕事で成功し、所得を増やすのに役立つもの
    • スキルや知識など
  • 活力資産
    • 肉体的・精神的な健康と幸福
    • 健康・友人関係・パートナーや家族との関係など
  • 変身資産
    • 人生で大きな変化を遂げるために必要な資産
    • 自分について知っていること、多様性に富んだ人的ネットワークなど

作中では、これら無形資産についての話が多いです。

新しい人的ネットワークがキャリアを変える

人生を変えると言い換えてもいいかもしれません。

以下の一節は、僕に刺さりました。

しかも、意外なことに、人々は新しい職に関する情報を親しい友だちから聞くことはあまりない。そのような有益な情報は、たいてい友人の友人など、それほど緊密な関係にない知人から寄せられる。

まず、そういうチャンスがそれほど親しくない人からやってくるという心構えを持てました。さらに、チャンスがよく知らない人からやってくるとすると、それを受けるか否かを考えるのはかなり重い判断になります。なので、それを受ける以前から、どのような職だったらチャレンジしたいかという市場調査・自己分析が必要だと思います。

とはいえ未来は大変

作中を通しての雰囲気は、「100年人生を悲観する必要はないけどそこそこ頑張んないと大変だよ」という感じです。例えば、お金を稼ぐためにハードワークする時期が必要とも言っていますし、自分がどのような人間であるか、どうありたいかというアイデンティティにも向き合う必要があるとも言っています。

とりわけ、私にとっては後者が難題です。私自身アイデンティティ形成が容易な「3ステージ人生*2」を送ると信じて疑わなかったのですが、ここ5年程度でそれが難しいと分かって以降も再適合できてないような感覚があります。

おまけ

作中では何度か、「年に1回の2週間～5週間の休暇だけでは活力資産が損なわれてしまうよ」という記述がありましたが、私は会社員になってから2週間以上の休みはとったことないな……となりました。

*1:ちゃんと計算していませんが、10％や20％では済まない。実家暮らしだとギリギリ可能

*2:大学を出て、会社員として40年ほどを過ごし、引退して余生を過ごすモデル

『DNSをはじめよう』を読んで初めてDNSが分かった

書評

『DNSをはじめよう』は、技術書典４で発売された同人誌です。

booth.pm

DNSを構成するもの

「DNSってあれでしょ、IPとアドレスを変換するやつ」という状態だった私でしたが、DNSサーバが何で構成されているかを学ぶことができました。

ちなみに変換するのはIPとドメインです。

DNSサーバの全体像は以下のようになります。

  • DNSサーバ
    • フルリゾルバ
    • ネームサーバ
      • ゾーン①、②、……
        • リソースレコード①、②、……
          • Aレコード
          • NSレコード
          • MXレコード
          • TXT(SPF)レコード
          • SOAレコード
          • CNAMEレコード
          • などなど……

この全体像は私の作成ですが、書中でも順を追って説明しているので構造を理解しやすかったです。

実際の作業における補足

実際の作業ではほぼ詰まることはありませんでしたが*1、書中の手順と実際の手順に差異がありましたので共有したいと思います。

whois情報代行がデフォルトでついている

書中では、ドメイン作成時にwhois情報代行をつけるよう注意されていますが、実際にドメインを作ってみると向こうで自動で設定してくれるようでした。

f:id:alek3:20190104223235p:plain

Amazon Linuxではjwhoisがインストールできない

今回はEC2インスタンスを作ってそこでdigやwhoisコマンドを試しました。これらのコマンドを実行するためにはパッケージのインストールが必要です。しかし、jwhoisをインストールしようとしたところ、以下のエラーが発生しました。

$ sudo yum install -y jwhois
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
No package jwhois available.

結局、 sudo yum install -y whois でwhoisコマンドを使えるようになりました。

Amazon LinuxはRHELで、書中ではCentOS前提なので、使えるパッケージに差があるんでしょうかね？

所感

書中ではお名前ドットコムでドメインを買ったり、AWSでアカウントを作成することを要求されます。

実はこの本は二周読みました。一周目は読んだだけ、二周目はアカウントを作ったり、手を動かしたりしました。

正直一周目ではいまいち頭に入ってきませんでしたが、二周目で実際に手を動かしてみると*2しっかりと理解することができました。

また、案外時間もかかりません。作業も含めて10時間弱で終わったと思います。

まとまった時間を使ってササっと終わらせるのがよいと思います。

*1:さらっと流していますが結構ありがたい。手順は詳細に書かれています。

*2:ノートに内容をまとめることを含む

2018年の失敗

今年も一年無事に過ごすことができましたが、たくさん失敗もしました。振り返ってみたいと思います。

髪を抜く癖が再発し、前髪が短いままになる

今年の秋ごろ、悩んでいるときや、ストレスがかかっているときに、前髪をクルクルしてしまう癖が再発しました。

その結果、前髪が不自然に短くなってしまいました。

最近は落ち着いたと思っていたのですが、今日髪を切りに行ったところ、美容師さんに「前髪伸びてないね～やばいんじゃない？」と言われてしまいました。

今後は、前髪を大事にしたいと思います。

Folioに100万円入金して、20万円以上損失を出す

ネット投資信託サービスFolioは去年の11月頃に始めました。当初は10万円ほど買っていたのですが、徐々に増やし、今年の1月に一気に50万円増やしました。

今年の1月は、そう日経が24000円くらいだったころです。

あとはお分かりの通りです。

どのへんで損切りすべきか、だれか教えてください。

Pythonを勉強しようとしてコミュニティに参加するも、フェードアウトする

私はもともとJavaを書いているのですが、もう一つ言語を身に着けよう！と思ってPythonを始めました。

手始めに、オンライン学習サービスのPyQをはじめました。

また、以下のコミュニティにも参加しました。

  • Python入門者の集い
  • Pythonもくもく自習室（rettypy）

さらに、SDVXという音ゲーでちょっと役立つツールを作成しました。

github.com

とはいえ、ここから仕事に使えるレベル*1となるとかなりのジャンプアップが必要だなと感じました。

そこからあまり進歩せずに今に至っています。

反省としては、目標を決めてそこまでがんばろうという気持ちが足りなかったなということですね。

まあ趣味レベルには身に付いたといえなくもないので、失敗ではないかも。

読書ペースが遅く、積読がたまる

現在Trelloを使って、技術書の進捗状況を管理しています。そのリストは公開しています。*2

trello.com

積読とここ半年の読書量を比較すると、今のすべての積読を消化するのに1年くらいかかってしまう計算になります。

さすがにもう少しペースを上げたいと思います。

具体的には、通勤時のスキマ時間とか、寝る前の数十分とかを確保したい。

同時に、取捨選択も大事だなと思います。月2冊のハイペースで進めていっても24冊ですからね。

  • 仕事で使える技術書
  • 仕事で使えるビジネス書（マネジメントとか）
  • 趣味

をバランスよく組みたいと思います。

今週の記事がしょぼい

しょうがない。来週から頑張ろう！

*1:もしくは自作サービスとしてリリースできるレベル

*2:そのうち非公開にするかも

読了『エンジニアリング組織論への招待』

書評

読了したのでレビューです。面白かったです。

現在のプロジェクトと自分の立ち位置

とあるプロダクトを開発、成長させるプロジェクトに1年以上携わっています。ゼロからプロダクトを立ち上げるところから参画していて、最近は「リーダー的」に立ち振る舞うようマネージャーから求められています。

責任ってなんだ

一メンバーから「リーダー的」な役割になると責任が増大するような気がします。しかし、私は、この責任というものがどういう義務を負った状態なのか、長らく分かっていませんでした。

本書239ページにその答えが記載されています。

権限を委譲された側は、その権限に見合う会社のリソースを取り扱うことができ、その権限に見合う自由度を手にすることができます。一方で、権限にはそれに対応する責任が伴います。これを「説明責任」といいます。

説明責任とは、与えられた権限に対して、何を行い、どのような結果をもたらしたのかという説明を、権限を付与した人に報告する責務のことです。

なるほど。マネージャーからしたら、確かに説明はしてほしいですね。

なぜ開発が失速するか

本書では、プロダクトの開発スピードが、だんだんと遅くなっているという悩みが251ページから解説されています。スピード低下の理由は、システムが複雑になるから、機能を追加するために、既存の設計を変更する必要があるから、といったものでした。

これはまさに私がいまプロジェクトで経験しているものと同じで、初期のころに比べると多くの機能が追加されるとともに、設計が大きく変わっています。そして、開発スピードは当初に比べると今は遅くなっています。

所感ですが、機能追加よりも、機能を変えずに設計を変えていくほうが難しいような気がしています。

技術的負債の位置づけ

「技術的負債」というワードは、意外と説明するのが難しいですが、「見える・見えない」、「プラスの価値・マイナスの価値」を軸に、新機能、バグ、アーキテクチャ、と比較することで理解しやすくなります。*1

こういうのを図示されると、もやもやと考えていたことがクリアになりますね。

コミュニケーション

順番は前後しますが、第2章はメンタリングの話です。メンタリングはコミュニケーションを通じて行うため、コミュニケーションのやり方についての記述が多いです。

コミュニケーションをやっぱりサボっちゃいかんな、と反省しました。

また、以下のような感想を持ちました。

読んでいるとメンタリングは相手にがっつり向き合わないとできないように感じますが、私は第1章・第2章を読み終えた際、なんとなくメンタリングを受けたような気持ちになりました。

まとめ

対象読者が明記されていないのですが、私は以下だろうと思いました。

  • ITエンジニアで、特に自社サービスの開発に携わっている人
  • チームで業務に取り組んでいる人
  • もうちょっとうまいこと仕事が回らんかな～ともやもやしている人

読んでみると、そういったもやもやがはっきりとした問題になるかもしれません。問題が分かれば、あとは解決していくだけです*2。

参考

togetter.com

*1:ツイートの「エン組」はエゴサ避けです。

*2:まあそれも結構大変なんですが……

JJUG CCC 2018 Fall #jjug_ccc 参加しました

Java イベント

JJUG CCC という、半年に一度あるJavaのカンファレンスに行ってきました。

www.java-users.jp

参加したセッションについて軽くまとめて行きたいと思います。

セッション一覧や、一部のスライドはこちらにまとまっていると思います。

d.hatena.ne.jp

Pivotal認定講師によるSpring Framework 5.1ハンズオン！

上記のセッション一覧にこのセッションが入ってなかったのでスライド等をあげておきます。

www.slideshare.net

qiita.com

Springはなんとなく使っているけど、1からアプリケーションを構築しようとすると難しいなという課題感がありました。

そんな中、ハンズオンセミナーがありましたので参加することにしました。

実際参加してみると、おいおいこれを無料で受けちゃっていいのかよ……。という充実した内容でした。

Springのベーシックなアプリケーションを構築する上で、一つの正解を教えていただいたなと思います。

まだ全部完走していませんが、基本的なBeanやConfigurationの設定から始まり、Spring DataやSpring Securityを触れるということで、最初に抑えるべきポイントはすべて押さえられていると思います。

おそらく、通常有料で開催している講座のダイジェスト版みたいなもので、時間内（105分）に終わらせるのは難しいから後でやっておいてねとも言われました。

一方で、失敗したところが2つありました。一つは、ハンズオンの事前準備をしてこなかったところ。公式ホームページのセッション詳細には書いてなかったのでスルーしていましたが、講師のTwitterなどでは事前告知があったようです。

もうひとつは、インターネットに全然つながらなかったところ。事前準備を完了するにはインターネット環境が必要なのですが、接続が多かったのか、全くインターネットに繋がりませんでした。これはどのあたりに原因があったのかイチ参加者には分かりかねますが、改善してほしいというのが正直な感想です。

俺が好きなのはJavaだけどJavaじゃない 〜虎の穴でのJava活用について〜

オタクならみんな知っているとらのあなのランチセッションです。

お昼ごはんもついていました。ごちそうさまです！

f:id:alek3:20181216135113j:plain
お昼ごはん

内容はリニューアルしたECサイトについての話でしたが、そこまでマニアックではありませんでした。Javaでシステムを組むとしたら非常にベーシックな作りになっていると思います。

ここ最近の宣伝の勢いがすごいので勢いのある会社なんだなと思いました。

今こそStream API入門

Java Champion 桜庭さんの講演です。めちゃくちゃわかりやすい。すごいわこの方。

自分がStreamを書くようになった一番の要因は、「同僚が書いていて、君も書きなよと言われたから」なんですけどね。

まず内部イテレータと外部イテレータの違いもよく分かってなかったので、そこらへんの理論強化につながったのが良かったです。

flatMapは全然使ってないなと思っていましたが、二次元の配列をなめすときとかに使うよと言われて、今までは使えそうなケースに当たらなかっただけなんだなと思いました。

Streamが使えない場合*1ってどんなのがあるんだろうというのがよく分かってなかったのですが、例えばindexに対して、index+1や+2を使わないといけないときだそうです。なるほどそりゃそうだ。

IDEの力を借りればいい感じに短く書いてくれるとのことでしたが、実際そうで、今回扱ってなかったメソッド参照まで使って書いてくれます。

秒間 200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術

以前、とあるアドテクの会社にお話を聞きに行った時に、「パフォーマンスチューニングの経験ってあります？」「いや、あんまり……」となって微妙な空気になった経験があるので、実際のところどうしているのか気になって聞きに来ました。

全く畑違いの分野なので細かいところはよくわかりませんでしたが、計測して一番時間食っているところを潰していくようです。

けどその計測する環境を整えるのは割と大変なような気がするんですが……。

まとめ

去年も参加したのですが、そのときに比べてついていける（知っていることが多少ある）セッションが多くて成長を感じました。

*1:すなわち通常のfor文とか拡張for文とかを使う