「読書」カテゴリーアーカイブ

リモートワークについて考える 『強いチームはオフィスを捨てる』


リモートワークを導入することについて、 リモートワークを実現している 37シグナルズ の CEO Json(ジェイソン) Fried(フリード)David(デイヴィッド Heinemeier(ハイネマイヤー) Hansson(ハンソン) の書いた『強いチームはオフィスを捨てる』を読んで考えてみた。

続きを読む リモートワークについて考える 『強いチームはオフィスを捨てる』


この一冊で「読む力」と「書く力」が面白いほど身につく!


この一冊で「読む力」と「書く力」が面白いほど身につく! (青春出版社)』を読みました。

読む力書く力に分けて合計120を超えるテクニックが紹介されています。 情報整理、速読・多読、ビジネス、企画書、メールと分野が多岐にわたるのですが、 その中でも 今の私に使えそうだと思ったテクニックを3つ紹介します。

資料として使いやすいノートは「1枚目」が違う

106ページに記載されているこの方法、とてもいいと思います。 ノートの最初の3ページほどを、目次として整えていきます。 さらに記号も使って見やすくわかりやすくします。

過去、アイディアをノートに書き溜めるということをやっていたのですが、どこになにを書いたかわからなくなって、使えるノートになりませんでした。 もしあのとき 最初の数ページで目次を作っていたら、 もっと有意義なノートになっていたと思います。

私が使っている B5 ノートは 35行60ページ あるので、 平均で 1ページにつき2行で目次に書き足すなら 最初の2ページを使えば済みます。

107、108、120、121ページのテクニック と合わせて使えば、 考える力も さらに伸びそうです。

好感度の高いメールは「締めのひと言」が違う

タイトルから考えて 「書き手の人間性」が垣間見えるような一文を追伸としていれる というのが、 筆者が最も言いたかったことだと思うのですが、 私が注目したポイントはそこではありません。

ビジネスメールでは、 わかりやすく的確な文章を書くことが求められます。 文章のわかりやすさは、 自分で自分の作った文章を読んで感覚的に推敲・改善していくものですが、 この本にはその基準となる文字数が記載されていました。

50文字を超える文は要チェックです。 改善の余地があります。

新聞でも、 要点は50文字以内でまとめられているそうです。

手帳に書くとモチベーションが上がる「10年計画表」

今後10年のプランを手帳に書くというテクニックです。 私は手帳を使わないので、ノートあるいはパソコンやスマートフォンの背景に応用します。

過去に、 企業研修等で 今後の人生プラン・キャリアプランを考えることがありました。 でも、 考えたのはそのときだけで、 しばらく見てもいませんでした。

でも 今後のプランは きっと役に立つと思います。 だから見えるところに 10年プランを置いておこうと思いました。 自分のゴールが念頭にあったほうが、 濃い時間が過ごせるに決まっています。


DIxAOP の Java Framework, Spring


Spring3 入門 (技術評論社)
Spring3入門 を Amazonで買う

DIxAOP ってなんだ? と思っていたら、 ある人が紹介してくれました。 DIxAOPについてはわかりやすく書かれているそうです。 パラパラっと見てみましたが、 EAADDD などのアーキテクチャを一通り知っている人が書いた本に見えます。 今回は第1章をじっくり読んでみました。 Spring フレームワーク の前書きみたいな内容で、 Spring を使ったことのない私にはちょうどいいです。

Spring の特徴

Spring の特徴として 際立っているのが DIxAOP だ。 第1章では紹介程度になっているのだが DIxAOP なくして Spring は成り立たないといっても過言ではなさそうだ。

Spring の DIxAOP 設計 は Webアプリケーション が抱える 3つの問題点 を解決する。 以下、簡単にまとめた。

オブジェクトのライフサイクルの問題
オブジェクトの生存期間をコントロールする作りこみが困難
部品化の問題
部品化をするためには実装非依存にする必要があるが、それなりにコストがかかる。 (注: 単にインターフェースを使えばいいという問題ではない。)
技術隠蔽や不適切な技術隠蔽
高レベルの技術を初級レベルの開発者に利用させて不具合を引き起こしてしまったり、不適切な技術隠蔽をしてその技術の利用が困難になってしまったりすることが開発現場でよく起こる。

Spring では、 上2つの問題を DIコンテナ が、 最後の問題を AOP が解決する。

Webフレームワーク というと Rails や FuelPHP, CakePHP などがあり、 「(アクティブレコードパターンの) 簡単にデータベースが使えるもの」という印象を受けてしまいがちですが、 Spring3 入門 では アーキテクチャ の考え方からしっかりと書かれていて EAAに見られるパターンの説明も(第1章では)随所で行われています。 第1章では特にレイヤの分離の説明が重点的に行われています(フレームワークを使う人には是非ともわかるようになっていてほしい内容です!)。 コードの例もあり、全体的にしっかりした印象を受けます。

以下、第1章の中で私が(個人的に)重要だと思った内容を簡単に書き留めました。

アプリケーションアーキテクチャ

プログラムを作る際には 最低でも 2つの方面からの要件・目標がある。

  • ユーザの要件: ユースケースなどで表される機能要求やレスポンスタイムなどの非機能要求
  • 開発者・運用者の目標: 開発期間の厳守、変更・機能追加のしやすさ、テストのやりやすさ

この本では 2つ目の 開発者・運用者の目標 からアーキテクチャの重要性が説かれている。

アーキテクチャに求められるもの

  • 開発効率
    • 意図を把握しやすく、理解しやすい構造
    • テストが容易に行える構造
  • 柔軟性
    • 変更しやすく、機能追加しやすい構造
    • 将来の環境の変動に耐えられる頑健な構造

ティアとレイヤ

Web アプリケーション の アーキテクチャ は ティア と レイヤ に分かれている。 ティア は 物理層 を表し、 レイヤ は 論理層 を表す。

ティア

クライアント層、中間層、 EIS(Enterprise Information System)層 の 3つに分かれるのが基本となっている。

各ティアの例
クライアント層 パソコン、スマートフォン
中間層 アプリケーションサーバ
EIS層 DB、レガシシステム

レイヤ

EAA の冒頭あたりにある分類と同じ分け方でレイヤが書かれている(プレゼンテーション層、ビジネスロジック層、データアクセス層 の3層)。 (もちろん異なる分け方もある。) 互いに隣接するレイヤ間では一方向のアクセスのみ許す。

トランザクション処理がどのレイヤに属するのかは迷うところだが、本書ではプレゼンテーション層とビジネスロジック層の境界と説明されている。

Spring3 入門 (技術評論社)
Spring3入門 を Amazonで買う

テスト駆動開発の基本とメリット


Test-Driven Development By Example (Kent Beck)
Kent Beck の Test-Driven Development By Example を Amazon で買う

同僚の勧めで Test-Driven Development By Example を読むことにしました。 書いたのはあの Kent Beck です。 日本語のものもあるのですが、そちらは絶版になっているので買うなら中古です。

この本では具体例が示されていて、どのようにテストができていき どのようにコードができていくのかがよくわかります。 まだ最初のほうしか読んでいませんが、他人(Kent Beck)のテストの書き方がわかるので、自分のやり方を見直すよい機会になります。

Test Driven の基本

Preface のところに Test Driven の基本ルールが書いてあります。

  • 自動テストに失敗するまで新しいコードを書かない。
  • 重複は排除する。

テストで失敗するまでコードを書いてはいけません。 これに関連して よくはまる落とし穴に、「テストコードのテストコードを書く必要はないのか」というのがあります。 これについて 同僚は次のような説明をしてくれました。

自動テストがないときはどうやってテストしていましたか? (PHPの場合) var_dump などでテストをしていたと思います。 テストコードのテストコードというのは、 その var_dump と 目視 のテストを書くってことと同じことなんですよ。 テストコードそのものの正しさは開発者が担保するようにして進めるんです。

わかったようなわからないような説明かもしれませんが、要するにそんなこと言っていたらきりがないからテストコードは開発者のチェックとコードの間に入れる保険なんだと思います。 またテストコードのバグについてはじゃんじゃん直していいそうです。

そして Kent Beck はコードの書き方について重要な方針を書いています。

自分の書いたコードのテストは自分で書こう

これ重要ですね。 この本をバイブルってことにしておけば、自分で書いたコードのテストは自分で書いてくれって言えますからね。 Red / Green / Refactor の順でやろうと思ったら自分で書くしかないんですけどね。

テスト駆動・自動テストのメリット

開発現場では往々にして「自動テストなんてやって意味あるのか」「時間がかかるだけじゃないのか」という議論が勃発します。 地位の高い人がそういうことを言い出すとどうしようもなくなったりします。 モチベーションにも繋がるところなので 自動テストのメリットを再確認しましょう。 本書では social implications として4つのことが書かれているのですが、それを仕事上のメリットとして書くと次のようになります。

汚いコードの密度が減り、品質保証は受け身の仕事じゃなくて能動的な仕事になる。
自分でコードを書くことが品質保証に繋がるので、問い合わせを受けてから手を動かすようなものではなくなります。
ドッキリするようなコードに遭遇することが減り、マネージャの見積もり精度が上がる。
開発者のみならずマネージャにとっても嬉しいことが起こります。
技術的な会話の議題が明確になり、同僚との協力作業の効率が高まる。
開発者の能力にもよると思いますが、書籍上ではそういうことが書かれています。
汚いコードの密度が減り、新機能の追加されたリリース可能なコードが毎日増えて顧客との関係が向上する。
毎日というのは言い過ぎかもしれませんが、バグを見落とすことが少なくなるので新規機能の追加に集中できるようになります。

特に2番目は重要ポイントですね、 テストドリブンとは関係なさそうな人にもメリットがもたらされるので。 どれも理想論に見えますが、テストドリブンの目指すところは上記のメリットです。

この本を読んで今以上にテストドリブンに力を入れていこうと思いました。 中にはテストを書かない人もいるのですが、具体的な進め方も書いてある本なので 他人への説明も楽にできると思っています。

Test-Driven Development By Example (Kent Beck)
Kent Beck の Test-Driven Development By Example を Amazon で買う