2019年1月2月の振り返り

月次報告みたいな何か。

何をやったか

  • 転職活動を行い2社から内定を得た
  • エリック・エヴァンスのドメイン駆動設計を読み、セミナーに参加した
  • How Google Worksの英語版を購入し、読み進めている
  • TOEIC受験を申し込んだ
  • スタディサプリEnglishによる英語の学習を継続した
  • Python3でWebスクレイピングの練習を行った

量的には以下のグラフの通りとなる。 

f:id:ShandyGaffLover:20190306180636j:plain

2019年1月2月の学習時間

 

1か月の合計学習時間は1月が38時間11分、2月が46時間6分だった。すごいね。

 

成長ポイント

  • 転職活動における連日の面接を通じて、2社から内定を得ることができた。基本給が少しだけ上がった。
  •  英語のドキュメントを読む上での精神的な抵抗が下がった。

    Automate the Boring Stuff with Python を参照しながらBeautifulSoupで簡単なWebスクレイピングを行うくらいには。

 

課題

  • ドメイン駆動設計については今の時点で何らかのアウトプットが欲しい
  •  英語のドキュメントを読む速度が圧倒的に足りない

 来月について

 

 

 

【書評】アジャイルサムライ――達人開発者への道

よく耳にするアジャイルな開発とは何か、というのを理解したかったので、アジャイルサムライを読んだ。

shop.ohmsha.co.jp

どんな本か

アジャイルな(agile)開発とは、直訳すると「敏捷な」「すばしっこい」「活発な」開発であり、特にソフトウェア開発の文脈では迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。

いくつかのよく知られた実践方法が人口に膾炙しがちだが、その本質は以下のアジャイルマニフェストにある。
アジャイルソフトウェア開発宣言
アジャイル宣言の背後にある原則

本書は、上記アジャイルマニフェストに則ったアジャイルな開発がどういう問題意識のもとに生じたのかや、アジャイルな開発の全体像及びプラクティスについて、ざっくり語ったものである。文体が非常にフランクでとっつきやすく、アジャイルな開発の入門書として読みやすい。

学んだこと

  • アジャイルな開発では動くソフトウェアこそが進捗の最も重要な尺度である、と考える。
  • 開発はイテレーティブに進む。各イテレーションで分析、設計、実装、テストが密に連携する。
  • アジャイルな開発には「顧客」が存在し、あらゆる要求の真実の源、優先順位づけ、何を作らないかを決める存在となる。そして顧客を直に巻き込めば巻き込むほど、プロダクトは良くなっていく。
  • チームで成果責任を果たす。役割分担をきっちり区別しない。
  • QCDを固定し、スコープを変動させる。プロジェクトの進捗に合わせ何を作らないかを決めていく必要がある。
  • 決して簡単ではない。万人がこのような働き方を好むわけではない。

感想

アジャイルな開発を実践するにあたって近年ではDon't "Do" Agile. Be Agile.というフレーズがよく聞かれる。

www.slideshare.net

アジャイルな」という言葉の広まりとともに、エクストリームプログラミングの手法も周知されていった。しかし重要なのは背景となる原理原則あるいは思いである。結局のところプロジェクトは常に生ものであり、ひとつとして同じプロジェクトがない以上、自分で考える必要があるだろう。もちろん、知識として数ある手法を覚えておくことは必要だ。

以下、完全に余談だが、この本の最初のページには以下のようなことが書かれている。

君がこの本を手に取ったことに祝福を。おめでとう。というのも、君にはすごく大事な2つのことが備わってるってことだからだ。

  1. 君は学ぶことが心から好きだ。
  2. 君はソフトウェアのことを大切に思っている。

このどちちらもが大切なんだ。君が学びたいという気持ちを抱かなければ、私との旅がこうして幕を開けようとすることもなかった。君がソフトウェアのことなんて気にしない人物だったら、私たちの世界は今よりも暮らしづらいものになっていただろう。

この本を購入した当時の自分は孤独だったが、この言葉には勇気をもらうことができてよかったと思う。

【書評】テスト駆動開発

よく耳にするTDD:テスト駆動開発とは何か、というのを理解したかったので、テスト駆動開発を読んだ。

www.ohmsha.co.jp

どんな本か

その名の通り、テスト駆動開発の実践の様子をコードと文章で説明したもの。
テスト駆動開発とは「動作するきれいなコード」をゴールとし、その過程で生じる開発者の不安を解消するための開発手法である。具体的には以下の3つを繰り返す。

  1. 失敗するテストコードを書く
  2. プロダクトコードを書き、テストを成功させる
  3. 設計判断を行う*1

学んだこと

つまるところ、よりよいコードと設計を生み出すための試行錯誤のプラクティスである。

感想

ポイントは2つあると思っていて、1つはプロダクトコードよりも先にテストコードを書くこと。これから作ろうとしているプロダクトコードがすでにあるという気持ちでテストコードを書くということ。

もうひとつは設計判断より先にテストコードを書くこと。139ページの言葉を借りると、

テストとコードの間の重複除去が、設計を駆動する

となる。

すなわち、テスト駆動開発設計ありきではないのだ。したがって古典的なウォーターフォール開発のように、詳細設計書ありきでコードを書く開発現場では適用できないのは残念であった(仕事で生かせないため)。

そもそもテスト駆動開発においては、ウォーターフォールにおける詳細設計と製造を分割しない。それらはテストコードによって駆動され、互いにフィードバックをかけながら洗練されていくものである。

そしてその哲学は非常に納得感がある。

*1:本文中では「リファクタリング」と呼ばれている。しかしメソッドの外部構造も変更しうるので、リファクタリングってあまり適切な呼び方ではないと思っている

2018年12月の振り返り

月次報告みたいな何か。

何をやったか

  • スタディプラスで学習記録をつけ始めた
  • 技術書を2冊読んだ
  • アルゴリズムパズルの解答を継続した
  • CodilityのLessonsの解答を行った
  • スタディサプリEnglishによる英語の学習を継続した
  • はてなブログとQiitaのアカウントを新設した
  • Herokuに自作アプリを上げた

 

量的には以下のグラフの通りとなる。 

f:id:ShandyGaffLover:20190104144218p:plain

2018年12月の学習記録

 

1か月の合計学習時間は65時間35分だった。すごいね。

 

成長ポイント

アルゴリズムの教養がない自分の弱みを認識し、具体的に対策案を講じ実践したこと。

このあたりは確かに課題発見・解決力が強い...。

 

shandygafflover.hatenablog.com

 

一番継続しやすそうな本で21時間18分学習した。その結果

  • 最低限知っておくべきアルゴリズムの知識がついた
  • 問題を何度も解くことで実践的な分析ができるようになった
  • CodilityのRespectableの難易度の問題を自力で2問解けた

特に3つ目は大きい。

 

上記が一番のメインなのだけど、ほかにも

  • 単純に勉強量が増加した
  • 週15時間のペースをつかんだ
  • 英語の勉強を週2時間継続している

とか。

 

課題

読んだ技術書に対し「何を学んだか」のアウトプットが弱いと思う。

アクセス解析を見る限り、特に誰が読んでいるというわけでもないブログなので、今後は「他人が読んで理解できるか」よりも「自分が何を学んだか」がわかるように書くようにしよう。

 

 来月について

  • 週2時間の英語の学習を継続しよう
  • アルゴリズムの学習を継続しよう
  • (ペースをつかんだので)スタディプラスのTwitter連携を停止する
  • 読んだ技術書に対し「何を学んだか」がわかるような書評を書こう

 

あとはこれを12か月続けてみよう。

 

 

 

【書評】Head Firstネットワーク――頭とからだで覚えるネットワークの基本

私事で恐縮なのだが、このたび情報処理技術者試験の高度区分であるネットワークスペシャリスト試験に合格した。

 

というわけで、自分がネットワークの勉強をしたときに読んだ本を紹介する*1

www.oreilly.co.jp

 

<どんな本か>

数あるO'ReillyのHead Firstシリーズのひとつである。同シリーズはいずれも独特で特徴的な記法により読者の学習を促進する試みがなされており、ビジュアル重視で、文体はくだけており、考えを深めながら学べるようになっている。したがって何かを「学ぶ」人には格好の教材だ(本稿の趣旨とは若干ずれるが、なかでも私は O'Reilly Japan - Head Firstオブジェクト指向分析設計が好きだ)。

 

本書のテーマは「ネットワーク」である。ネットワークとひとことで言っても、物理層からアプリケーション層まで扱う範囲は極めて広大だ。本書では例えば以下のような基本事項の理解に主眼を置いている。

 

 随所に簡単なエクササイズもあるので、理解を深めながら読み進めることができる。まさに学習教材としてはうってつけであろう。ただし、既にネットワークに関する知識の深い人が読んでも得るもの少ないと思われる。あくまでもネットワークに関する基礎知識を楽しく学習できるものだ。そういう意味でネットワークの学習の初めの一歩としては大変おすすめできる

 

<感想>

自分のバックグラウンドはアプリ開発メインなので、これまでネットワークについてはかなり朧気な理解のまま業務を行っていた。しかしこの本を読んでネットワークについて一定の理解を得ることができたので良かったと思う。ただ正直なことを言うと、前半の物理層の話はあんまり興味を持てなかった。

 

ネットワークに関する技術は現代のインターネットにおいて重要で不可欠なものとなっているし、ネットワークを利用しない場面はほとんどない。しかしその仕組みをきちんと理解する難易度はとても高い(そもそも範囲が広大すぎるし、ひとつひとつも結構難しい)。また日頃の業務においてpingコマンドを利用したりはするけれど、背後の原理やメカニズムについて理解はあやふやなままだったりもした。そんな中本書でネットワークの学習の敷居が下がったのはうれしかった。

 

<こんな人におすすめ!>

  • ネットワークを「なんとなく」理解した状態で仕事をしているエンジニア
  • 過去にネットワークを勉強しようとしたけど難しすぎて挫折した人
  • まだ技術にそこまで精通していない社内SEやインフラ担当者 

 

<逆にこんな人にはおすすめできない>

  • ネットワークの特定の領域に関する深い知識を求めている専門家

  • リファレンスを探しているプロフェッショナル

 

*1:ちなみにもしネットワークスペシャリスト試験の合格を目指す場合は、過去問を3年分3周解答することをおすすめする。ここで紹介する本はあくまでもネットワークに関する「理解」を促すものであり、情報処理技術者試験のような「過去問からの流用が多い問題」の攻略はまた別に必要だ。

【書評】アルゴリズムパズル ――プログラマのための数学パズル入門

アルゴリズムについて勉強する必要が私情により出てきたので、以下の本を買って取り組んでみた。

www.oreilly.co.jp

<どんな本か>

アルゴリズム的なパズルを集めた本。アルゴリズム的なパズルとは、問題を解くためのはっきり定義した手順を扱うパズルのこと。例えば エイト・クイーンハノイの塔狼とヤギとキャベツなどだ。

 

またこの本は副題にもあるように、プログラマ向けである。その理由は、コーディングにおいて適切なアルゴリズムを選択し実装することが、ロジックの簡潔さやパフォーマンスに影響するためである。

 

具体的な例を知りたい方はCodilityのLessonsなどがわかりやすいだろう。

app.codility.com

 

実際、IT企業の採用試験として問われることも多いようだ。

www.iandprogram.net

 

書籍の最初にはチュートリアルとして知っておくべきアルゴリズムの解説がある。バックトラックや縮小統治法、分割統治法、動的計画法といった基本的なアルゴリズムを学ぶことが可能だ。

 

本編のパズルは合計150問収録されている。難易度は初級、中級、上級の3段階。いずれも歯応えがある。 

 

<感想>

ひとつひとつのパズルに歯ごたえがあり、とても勉強に...というか頭の体操になった。普段アルゴリズムを意識してコーディングする機会が全くないため、チュートリアルで紹介されるアルゴリズムも勉強になった。

 

ただ解説は良くも悪くも必要最小限にとどまっている印象が強かった。ものによっては「え、ほんとにそれで証明できるの?」というポイントもあった(例えば52. 三角形の数え上げ)。

 

<こんな人におすすめ!>

・パズルが好きな人

アルゴリズムを楽しく学びたい人

・日常的にコーディングを行う人

 

<逆にこんな人にはおすすめできない> 

・パズルがニガテな人や、休みの日にわざわざ頭を使うことに疲労を感じる人

・生活の中でコンピュータに触れる機会がない人

・より本格的な数学書アルゴリズムの厳密な証明を求めている人 

 

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

Twitterで話題になっていた「エンジニアリング組織論への招待」を読んだ。

gihyo.jp

 

<どんな本か>

プロジェクトの炎上やアジャイルの失敗、経営者とエンジニアの認識の食い違いなど、エンジニアリングを取り巻く環境には日々様々な問題が生じている。本書はそれらの問題が「わからないこと」すなわち「不確実性」に対する不安を根源とするものであると考え、未来と他人に対する不確実性とどのように向き合うのかを突き詰めていくものである。

 

不確実性との向き合い方を突き詰めていく上で、本書では2つのキーワードが頻繁に登場する。それが「情報の非対称性」と「限定合理性」の2つだ。

「情報の非対称性」とは、同じ目的を持った集団で、何かの情報を片方の人が知っていて、もう片方の人が知らないという状態である。例えば上司が把握している情報を部下は知らない状態や、現場が把握している情報を経営陣は把握していない状態などである。

また「限定合理性」は、ある人にとっての個人的に最適な戦略が、全体にとって最適であるとは限らないことである。例えば受託開発において、品質と見積もりを検収する能力がないが納期に厳しい発注者と、稼働時間に応じて料金が決定される受注者を考える。このとき受注者側には、品質を犠牲にしてでも納期を守るインセンティブや、見積もり期間を長く伝えるインセンティブがはたらく。結果として高い料金と長い時間、品質の低いソフトウェアを発注者は受け取ることになる。

本書では、これら2つのキーワード「情報の非対称性」と「限定合理性」を切り口として、円滑なコミュニケーションを促し、冒頭で上げたような問題と向き合うためにはどうしたらよいかを模索する。第2章ではメンタリングの技術の紹介を通じて1:1の人間関係のあり方について、また第3章、第4章ではアジャイルなチームの原理や不確実性マネジメントの紹介を通じて、チームやプロダクトの単位で不確実性を減少させるためにはどうしたらよいかを考えている。

 

本書を最も本書たらしめる点は、不確実性との向き合い方を突き詰めていく上で、組織の構造を適切にデザインする必要を説いている点であろう。

第5章では「ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というトム・デマルコの言葉を引用しつつ、組織設計とソフトウェアのアーキテクチャが本質的に似ていることを指摘する。これは、より良いアーキテクチャで品質の高いコードを書くには、権限移譲が適切になされたより良い組織設計が必要となることを示唆している。したがって積極的な組織設計やコミュニケーション設計を行うことで、アーキテクチャをより良いものに変えていく「逆コンウェイ作戦」が成立するのだという。

 

<感想>

エンジニアを取り巻く環境で生じる様々な問題は、ともすれば「コミュニケーションの問題」と単純化され終わりにされてしまいがちである。それをもっと深堀し、情報の非対称性と限定合理性、それらを引き起こす組織構造のデザインにスポットを当てているのは面白いし、非常に納得感があった。

多重請負構造の中で働く一エンジニアとしては、情報の非対称性と限定合理性に関する指摘はまさにその通りといった感じで、現実の職場で発生する事象をよく説明してくれる。

エンジニアはもちろん、社内でITを担う部署を持つ企業に勤める人(特に権限が強い人)にはぜひ読んでほしい書籍。