事故は現場で起きているんだ

システムエンジニアの奮闘記

TeamGeekを読んだので殴り書き

今回読んだ本は、「TeamGeek」。
Googleのエンジニア2人が自分たちの経験に基づいて書き出した本で、エンジニアリングチームで成功するための心構えを語ってくれる。

ちなみに、本を読んで殴り書きする理由は、

  • 自分に足りないことを補充する
  • 忙しい生活の中で、忘れないようにメモしとく
  • 何日後、何ヶ月後、何年後にもメモを見て思い出す

ためであるので、今後も本を読んだあとの殴り書きは続くよー

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

前置き

まず、この本のミッションステートメントと構成(=目次)を確認しよう。

一番最初に印象に残ったのは、この本の「ミッションステートメント」。我々のプロジェクトにもこのようなミッションステートメントを設定・公言すべきだろうなー

ミッションステートメント

本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。

目次

6章と2つの付録で構成されていて、各章はまたいくつかの節で構成されている。ここでは、6章のタイトルのみ列挙する。

  • 1章 天才プログラマの神話
  • 2章 素晴らしいチーム文化を作る
  • 3章 船にはキャプテンが必要
  • 4章 有害な人に対処する
  • 5章 組織的操作の技法
  • 6章 ユーザーも人間

中身

じゃ、実際に本を読んで心に残ったことまたは残したいことを忘れないうちに！

1章 天才プログラマの神話

エンジニアリングチームで成功するには、自分が「謙虚・尊敬・信頼」の原則に基づいて行動できているかを認識しなければいけない。

リーナスの本当の功績は、そういつ人たち(=数百人もの頭のいい人たち)をリードしてうまく調整したことだ。Linuxは協働作業の輝かしい成果である。

人間は本能でリーダーやロールモデルを設定し、崇拝し、模倣しようとする。

いつも1人でやっていると、失敗のリスクが高くなる。そして、成長の可能性が低くなる。
そもそも、どうやって正しい方向に進んでいるとわかるのだろうか？

検証を重視した「早い段階で、高速に、何度も失敗せよ」の精神を忘れないようにしよう。

最高のチームはスーパースターをうまく活用している。全体は部分の総和よりも大きい。

ビジョンを共有しよう。仕事を分担しよう。他人から学ぼう。そして、素晴らしいチームを作るんだ。

人間関係は確実にプロジェクトよりも長続きするものである。

自分をよく見せようとするよりも、「集団」のエゴを考えてみてはどうだろうか。

建設的な批判をする人は、心から他人を思いやり、成果を改善してほしいと願っている。

相手に対する疑問ではなく、自分の疑問として謙虚に聞くのである。相手が間違っているのではなく、自分が理解できないだけであることを強調する。

学習をやめると退屈になる。知らないうちに時代遅れになってしまう。

影響を受けやすくなれば、それだけ影響を与えやすくなる。弱いところを見せれば、それだけ強い人だと思われる。

三本柱(HRT)

謙虚(Humility)

世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。

尊敬(Respect)

一緒に働く人のことを心から重いやろう。相手を1里の人間として扱い、その能力や功績を高く評価しよう。

信頼(Trust)

自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。

あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。

2章 素晴らしいチーム文化を作る

チームの文化とは、エンジニアリングチームが共有する経験・価値・目標のことである。

プロセスそのものよりも、衝突を解消するプロセスを持っていること、それを守っていることが重要だ。

コミュニケーションの原則は、同期コミュニケーション（ミーティングなど）の人数を減らし、非同期コミュニケーション（メールなど）の人数を増やすことである。

エンジニアリングチームのミッションステートメントであれば、チームの方向性を定義して、プロダクトのスコープを制限するだけでいい。ミッションステートメントを書くには時間や手間がかかるが、やること／やらないことを明確にしておけば、年単位で仕事の節約になる可能性もある。

意思決定者がいない限り、部屋に5人以上いたら決まるものも決まらない。

3章 船にはキャプテンが必要

伝統的なマネージャーはどうやって仕事を完了させるかを考える。リーダーは何ができるかを考える…（どうやって仕事を完了させるかはチームに考えてもらう）。

Googleのマネージャーという言葉には「部下がいる」以上の意味はない。

チームの幸せと生産性を高めることがマネジメントの仕事の指標になる。

必要以上にマイクロマネジメントをしたり、パフォーマンスの低い人を無視したり、自分の言いなりになる人を採用したりする。すぐに治療しなければ、チーム全体を殺してしまう。

管理したくなる衝動を抑えるんだ。

君よりも頭がよくて、代わりになるような人を採用したほうがいい。

ソフトウェア開発において人間を扱う部分がいちばん難しい。そのなかでも最も難しいのは、期待に応えない人をどうするかという部分である。

パフォーマンスの低い人に直接働きかけることで、必要かつ重要な変化の触媒となるのである。

友人関係とチームをリードすることを混同してはいけない。

人は自分が扱われるように行動する。

チームのマイクロマネジメントをしなくなれば、前線で働く人たちのほうがリーダーよりも仕事に詳しくなる。つまり、リーダーの仕事はチームの合意形成や方向性の決定を支援することであり、目標の達成方法はプロダクトを作る人が決定すべきことだ。

エンジニアからの質問を歓迎しよう。君の意思決定や意見に対して質問してきたら、その人は君のことをもっとよく理解しようと思っているのである。質問を歓迎すれば、優れたリーダーになるための建設的な意見が手に入る。

チームとして何を達成したいかを考えよう。フィードバックと批判をオープンに受け止めよう。

失敗したときに謝罪できるリーダーは尊敬される。

エンジニアであれば、懐疑的や批判的な感度を高めていると思うが、チームをリードするときには、そのことがマイナスになる。

エンジニアが相談を持ちかけるのは、君に問題解決をしてほしいからではない。彼が問題解決するのを手伝ってほしいからだ。

リーダーはチームに貢献することが嬉しい（貢献することが可能である）ことをチームに理解してもらおう。

多くの場合、適切な答えを知るよりも、適切な人を知るほうが価値がある。

不可能な目標を達成しようとすると、失敗する可能性が高くなる。だけど、簡単にできそうなことをするよりも、できそうもないことに挑戦して失敗するほうが道が開けるはずだ。

自力で学ばせようとするのは難しいが、それはリーダーの大切な役目でもある。

フィードバックや批判を伝えるときは、メッセージが正しく伝わっているかどうかが重要だ。

（優秀なリーダーたちは、）チームメンバーの幸せを調べて、やるべきことを理解しているかを確認し、その仕事に満足できるようにしていた。

委譲せよ。ただし手は汚せ。

優秀なリーダーは、取り返しがつくかどうかの判断に優れている。

リーダーとしての仕事は、どのエンジニアが何を必要としているかを把握して、それを与えることだ。

仕事の目的が見つかれば、モチベーションと生産性が驚異的に向上する。

4章 有害な人に対処する

ネガティブな振る舞いを拒否するような文化を作るほうが健全だ。排除するのはあくまでも振る舞いであり、特定の個人ではない。

好ましくない振る舞いをする人は、それが悪いことだと気づいていない。あるいは、そもそも気にしていない。無知や無関心は悪意よりもタチが悪い。るまりは、HRTが欠けているのである。

誰が正しいか間違っているかではなく、結論にたどり着くかどうかが重要だ。

有害な振る舞いを排除すれば、頭がいい（けど人付き合いの苦手な）人は生産性の高いメンバーになる。

感情が高まってしまうと、相手にする価値のない人に一生懸命返事を書いて、何時間や何日間も時間をムダにしてしまう。

言葉にトゲがあったり無礼な感じだったりしても、まずは指摘された点を好意的に解釈する。

短期的なメリットのために文化を妥協する必要はない。

5章 組織的操作の技法

先を見越した行動や責任を自ら求める振る舞いによって、マネージャーの作業を軽減することができるし、今のレベル以上の仕事が可能なことも提示できる。また、コンフォートゾーンを抜け出して、新しいことに挑戦したいという気持ちも表わせる。

自分が期待することを他人に伝えること。

組織を動かして、自分の仕事に利用できる仕組みを見つけよう。自分が居心地のいい場所を作り出すのである。

勝てる見込みのある重要な争いを選択しよう。勝てない争いで資本を使い果たしても意味がない。ストレスになるし、これといった理由もなくキャリアに制限がかかってしまう。

君のやっていることだけでなく、君が「うまく」やっていることを上司やチームの外部にいる人たちに知らせる必要がある。

攻撃的な仕事は、ユーザーに見えるものである。

防御的な仕事は、プロダクトを長期的に健全にするためのものである。

ぼぐたちは、技術的負債がどれだけあっても、防御的な仕事に時間や労力の1/3～1/2をかけないといるルールを作っている。それ以上は政治的自殺行為につながるからだ。

選択肢を知れば人間は自由になれる。

6章 ユーザーも人間

ユーザーに集中すれば、他のことはすべてついてくる。

はじめて使うユーザーのことを考えてみよう。

プロダクトは最初の体験が超重要なのだ！

成功しているソフトウェアというのは、問題を限定してそれをうまく解決したものだ。

優れた設計は簡単なものを簡単に、難しいものをできるだけ簡単にする。

ユーザーには常に敬意を払おう。

信頼は最も大切なリソースだ。

Treasure DataのData Connector for MySQLを利用する際の注意事項

Treasure Data Data Connector

今やってるシステム開発作業で、MySQLのデータを「主データ」としてTreasure Data(以下、TD)へアップロードする必要があったので、TDが提供するData Connector for MySQL(以下、Data Connector)を試してみたことのメモ書き。 ちなみに、該当機能のマニュアルは下記リンクを参照。

docs.treasuredata.com

背景

システムで利用する「主データ」のアップロードフローで、TDのDATA Connectorを使ってMySQLからTDへダイレクト登録ができるようにする。 ちなみに、システムで利用する「主データ」は約30個ある。

アップロードフロー

  1. Data Connectorの利用に必要なConfigファイル作成(xxx_seed.yml)
  2. TDコマンド(td connector:guess)を使って、Configファイル(xxx_seed.yml)からアップロード用ファイル作成(xxx_load.yml)
  3. TDコマンド(td connector:issue)を使って、アップロード用ファイル(xxx_load.yml)に基づいて、MySQLからTDへダイレクトでデータアップロード

Configファイルのサンプル(初期バージョン)

in:
  type: mysql
  host: ホスト情報
  port: ポート番号(3306)
  user: ユーザID
  password: パスワード
  database: mysql側のDB名
  query: "SELECT id
       , title
       , category
       , target_date
  FROM DB名.テーブル名
 WHERE target_date = '2016-11-04'
;
"
out:
  mode: append

問題点発見！

データ処理対象日である「target_date」は、TDのテーブルでは下記形式で保存される必要がある。

YYYY-mm-dd (例：2016-11-03)

しかし、DATA Connectorを利用すると、下記のように登録されてしまう。

YYYY-mm-dd HH:MM:SS[.fraction] (例：2016-11-03 00:00:00.000)

原因

結論から言うと、DATA Connectorの仕様だった。
※DATA Connectorは裏側ではembulkを使っている。

github.com

上記リンクページを「timestamp_format」で調べてみると、

  • MySQLのテーブル.カラムのデータ型：date/time/datetime
  • TDのテーブル.カラムのデータ型：string

の場合、データ型がtimestamp_formatとして適用される仕様らしい。

解決策

同じリンクページに書いてあるように、Configファイルへ「column_options」項目を追加してあげればOK。

  column_options:
    target_date: {type: string, timestamp_format: "%Y-%m-%d", timezone: "+0900"}

Configファイルのサンプル(解決バージョン)

in:
  type: mysql
  host: ホスト情報
  port: ポート番号(3306)
  user: ユーザID
  password: パスワード
  database: mysql側のDB名
  query: "SELECT id
       , title
       , category
       , target_date
  FROM DB名.テーブル名
 WHERE target_date = '2016-11-04'
;
"
  column_options:
    target_date: {type: string, timestamp_format: "%Y-%m-%d", timezone: "+0900"} # timezoneでは日本時間を指定
    open_date: {type: string, timestamp_format: "%Y-%m-%d", timezone: "+0900"}  # ←この行の説明は下にあるよー
out:
  mode: append

ちなみに、Configファイルは、アップロードするテーブルの数と同じ数が必要。つまり、今回だと約30個のConfigファイルが必要。

従って、Configファイルのテンプレートファイルを用意して、各テーブルごとに適切なConfigファイルを自動的に作ってくれるロジックを作成した。

ちょっと待って、その場合、「column_options」はどうする？テーブルによっては、「target_date」だけではなく、「open_date」や「close_date」等、日付形カラムが複数あったり異なったりの場合があるよねー。それをテーブルごとに変数化してロジックに渡す？？

あんまり望ましくないやり方だな…

それで試してみたのが上記サンプルコードのように、「column_options」への項目追加。 つまり、該当テーブルでは使ってないけど、他のテーブルで使ってるカラムもテンプレートファイルにまとめて書いて置けば、各テーブルで該当するカラムだけをいい感じなデータ型に変更してくれるし、エラーにもならない！
※サンプルコードの場合だと、「target_date」カラムが「YYYY-mm-dd」のデータ型に変わる。

これで問題解決！

以上、TDのDATA Connectorを利用する際の注意事項ー

より良いコードを書く、リーダブルコード

最近やってるプロジェクトではPythonを使っている。
そのプロジェクトがWEB系ではないので、自作でフレームワークを作成し、そのフレームワークをチームメンバーで利用することにした。
フレームワーク作成時に悩んだのが大きく2つあった。

  • クラスの構造
  • 名前(クラス、メソッド、変数…)

「名前なんかなんでもいいじゃ！」と思うかも知らないけど、チームで開発するには結構大事なんだ、その名前が…
それに、参考にしたのが「リーダブルコード」

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

この本が教えてくれる考え方を章ごとに整理。 ※リストになっている箇所は「鍵となる考え」、リストになっていない箇所はそれ以外で良いと思ったこと、気付いたことである。

リーダブルコード

1章 理解しやすいコード

  • コードは理解しやすくなければいけない。
  • コードは他の人が最短時間で理解できるように書かなければいけない。

2章 名前に情報を読め込む

  • 名前に情報を詰め込む。

いい名前というのは、変数の目的や値を表すものだ。
識別子のスコープが大きければ、名前に十分な情報を詰め込んで明確にする必要がある。
プロジェクトで一貫性を持たせることが大切だ。

3章 誤解されない名前

  • 名前が「他の意味と間違えられることはないだろうか？」と何度も自問自答する。

最善の名前とは、誤解されない名前である。

4章 美しさ

  • 一貫性のあるスタイルは「正しい」スタイルよりも大切だ。

読み手が慣れているパターンと一貫性のあるレイアウトで使う。
似ているコードは似ているように見せる。
関連するコードをまとめてブロックにする。

5章 コメントすべきことを知る

  • コメントの目的は、書き手の意図を読み手に知らせることである。
  • コードからすぐにわかることをコメントに書かない。

読み手の立場になって考える。
質問されそうなことを想像する。

コメントを書く3つの簡単な手順

  1. 頭のなかにあるコメントをとにかく書き出す。
  2. コメントを読んで（どちらかと言えば）改善が必要なものを見つける。
  3. 改善する。

6章 コメントは正確で簡潔に

  • コメントは領域に対する情報の比率が高くなければならない。

7章 制御フローを読みやすくする

  • 条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く。
  • 行数を短くするよりも、他の人が理解するのにかかる時間を短くする。
  • 変更するときにはコードを新鮮な目で見る。一歩下がって全体を見る。

条件は否定形よりも肯定形を使う。
単純な条件を先に書く。
関心を引く条件や目立つ条件を先に書く。

8章 巨大な式を分割する

  • 巨大な式は飲み込みやすい大きさに分割する。

9章 変数と読みやすさ

  • 変数のことが見えるコード行数をできるだけ減らす。
  • 変数を操作する場所が増えると、現在値の判断が難しくなる。

タスクはできるだけ早く完了するほうがいい。

10章 無関係の下位問題を抽出する

関数というのは、小さくて独立したものになっていれば、機能追加・読みやすさの向上・エッジケースの処理などが楽にできる。

11章 一度に1つのことを

  • コードは1つずつタスクを行うようにしなければいけない。

タスクを分割すると、コードのことを考えやすくなる。

12章 コードに思いを込める

おばあちゃんがわかるように説明できなければ、本当に理解したとは言えない。
--- アルバート・アインシュタイン

問題や設計をうまく言葉で説明できないのであれば、何かを見落としているか、詳細が明確になっていないということだ。

13章 短いコードを書く

  • 最も読みやすいコードは、何も書かれていないコードだ。

たまには標準ライブラリのすべての関数・モジュール・型の名前を15分かけて読んでみよう。
ライブラリを全部覚えろと言ってるわけじゃない。どんなことができそうか感じ取るだけでいい。
不必要な機能をプロダクトから削除する。過剰な機能は持たせない。
最も簡単に問題を解決できるような要求を考える。
定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく。

14章 テストと読みやすさ

  • 他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。
  • コードを完全にテストする最も簡単な入力値の組み合わせを選択しなければいけない。
  • テストには最もキレイで単純な値を選ぶ。

一般的な設計原則として、「大切ではない詳細はユーザから隠し、大切な詳細は目立つようにする」べきだ。
テストの本質というのは、「こういう状況と入力から、こういう振る舞いと出力を期待する」のレベルまで要約できる。

おわりに

本は15章まであるが、15章はおまけであるため、実際に読んだ方がいいと思う。
いろいろ「考えさせる」本なので、結構なところで役に立つ。
ま、自分にネーミングセンスが欲しいというところには変わりがないけどな。。。
また頑張ろうぜ！！

カオスマップ。そして、アドテク用語

他部署との打ち合わせや雑談でときどき出てくるアドテク関連用語が気になって、アドテク関連本とウェブページを見てたけど、まだまだ用語は紛らわしい…
そのうえ、アドテク関連プレイヤーを役割別に1つのマップに載せた「カオスマップ」！！！ これは、本当のカオスじゃ！！！
あれもこれも忘れがちなので、とりあえず書いておく。

アドテクの基礎知識

カオスマップや関連用語を扱う前に、アドテクの基礎を整理していこう。

アドテクとは？

アドテクノロジーの略称。
アド(広告)のテクノロジー(技術)、その中でもインターネット広告の配信や流通のための技術を指す。

アドテクの三本柱

  • 広告主(Marketer) : 広告を依頼する方
  • 媒体社(Publishers) : 広告を掲載する方
  • 消費者(Consumer) : ウェブユーザー

広告配信のプロセス

  • クリエイティブ(広告)入稿
  • 配信設定(予約)
  • 広告配信
  • レポーティング

カオスマップ

アドテクが登場してからそれほど長くない歴史の中、関連技術は日々進化している。
また、それぞれの技術を持ったプレイヤーがアドテクの戦場に参戦し続けている。
各プレイヤーが「我々が標準だ！」と叫んでるので、(アドテクの)世の中は混乱に陥っているのだ。
その混乱(?)を1つのマップに表したのが、下のカオスマップである。

www.slideshare.net
Hiroshi Kondoさん、画像をリンクさせていただきました。問題になりそうでしたら、ご連絡くださいませ。

出典：Jp chaosmap 2014-2015

カオスマップのカテゴリ

カオスマップのカテゴリ解説とサービス・企業一覧（リンク付き）｜デジタルマーケティングラボ

今回読んだ本の1つである「アドテクノロジーの教科書」の著者、広瀬信輔さんが運営するDMLサイト。
ここに全部書き写すことも考えてみたけど、もっと優れたサイトがあるので、そのリンクだけを張る。
ただし、単行本とKindle版で内容が異なるのか、もしくは、単行本の初版第1刷と第3刷(←これが読んだ本)で内容が異なるのか、今回検索したら出てきたGoogle Booksには、164Pのプレビューでカオスマップのカテゴリ解説がChapter05の01としてあるのに、単行本ではそもそもChapter05の01が「市場規模」になっている…

DSP、SSP、DMP

アドテクにはいろんなプレイヤーが登場しているが、その中でも重要な役割を担っているDSPとSSP、そして、最近(?)話題になっているDMPについての概要説明。

DSP

Demand Site Platform。
インプレッションごとに買付判断を行い、
広告主にとって意味のあるインプレッションのみをバイイングする広告主利益に特化したプラットフォーム。

SSP

Supply Side Platform。
媒体社の広告収益を最大化させるためのプラットフォーム。
1インプレッションごとに、複数のアドネットワーク、DSPから入札される広告の中から最も収益性が高いものを予測し、配信する。
媒体社にとって増え続けるレムナントを自動的に、そして、より高く販売することが大きな課題となっており、そのニーズを満たすのがSSP。

DMP

Data Management Platform。 顧客のデータ資産を活用し、収益化に結び付けるためのプラットフォーム。
自社で蓄積しているユーザデータの管理・集約に加えて、第三者のデータサプライヤーが提供するユーザデータを広告配信などに利用可能。

(これも重要)オーディエンスデータ

Audience Data。
Webサイトの訪問回数やユーザーIDを保存しておく仕組みであるCookie(クッキー) のデータを元に、購入履歴や属性データ、位置情報などを組み合わせ、個人そのものは特定しないが、広告メッセージを受け取る”人”を想定するデータ。
広告を配信するターゲットを精度高くセグメントし、CPCやCTRを良くするために活用される。

広告主と媒体社のニーズ

最後に、広告主と媒体社の(たぶん、今後もずっと続くと考えられる)ニーズについて。

広告主のニーズ

効果の良い広告枠や、ブランド認知に適した広告枠に対して競合他社よりも優先的に買付を行いたいというニーズが生まれてくる。

媒体社のニーズ

メディアのコンテンツ価格やブランド価格を毀損しない広告主、自社メディアのユーザにとって有益な製品をより優先的に配信したいというニーズが生まれる。

関連用語

広告のターゲティングや効果測定等でよく出てくる用語をまとめてみる。

  • CPA : Cost Per Acquisition。広告単価の指標で、顧客獲得（acquisition）一人あたりの支払額。または、何らかの成果（action）一件あたりの支払額。
  • CPC : Cost Per Click。ネット広告の掲載料金の単位の一つで、クリック1回あたりの料金。
  • CPV : Cost Per View。動画広告視聴1回あたりのコスト。
  • CPCV : Cost Per Completed View。動画広告を完全視聴１回あたりにかかるコスト。
  • CPM : Cost Per Mille。1,000回インプレッションあたりの広告コスト。Milleはラテン語で1,000を意味する「mille」からきている。
  • CTR : Click Through Ratio。クリックスルー率。インターネット広告の効果を計る指標の一つ。広告がクリックされた回数を、広告が表示された回数で割ったもの。
  • ROI : Return On Investment。利益ベースの投資対効果。
    ROI＝{(売上-売上原価)-投資コスト}÷投資コスト✕100
  • ROAS : Return On Advertising Spend。広告費用の回収率。
    ROAS＝広告経由の売上÷広告費×100
  • RTB : Real-Time Bidding。1インプレッションに対してリアルタイムで入札を行う仕組み。0.1秒間で処理される。
  • FloorCPM : (CPMはCost Per Mille。)最低落札金額。この金額を下回った入札金額の広告はSSPのオークションに参加できない。

エンジニア、ブログを書く

自己紹介

東京に住んでいるシステムエンジニア。
現職に就いたのが1年前ぐらいで、前職でもシステムエンジニアをやっていた。
前職の場合、システム業務の9割以上が.NetとSQL Serverであったので、
オープンソース系が9割以上である現職で毎日奮闘中。
といっても、今のメイン作業はデータの集計。

ブログ？何で書くの？

率直に言うと、前職ではそれほど優れたエンジニアがいなかったので(自分が優れたエンジニアだと言ってるわけではない。まだまだ足りない人間なんだ。まだまだ。)、あんまり勉強熱心ではなかった。 (← 分かる。これ、言い訳。)
1年前、今の職に転職してから、開発部の、特に若いエンジニア達の頑張る姿を見て、すごく反省中。
このままでいいのか？と考えると、ダメに決まってるし、人生つまらなくなるし…
だけど、数年間知らないうちに身に付いてしまった怠け癖を直せるのか？と悩んでるときに、1つの本と出合えた。

アジャイルサムライ

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

職場の仲間からお勧めされて、読んでみた。読んで、良かった。
今までの自分のエンジニアとしての自覚がものすごく甘かったこと、 人間としても未熟な者であることをこの本が気付かせてくれた。

それで、これからまた頑張ろう！！勉強しよう！！と思った。
そのやり方の1つとして、ブログを書くことにした。

なぜ？

現場で日々に悩んでたことの解決策やアプローチの整理で、少しずつ成長したいから。
人は、話すことで、書くことで、その場で、その時点で考えたことを本物の自分のことにすることができると信じてるから。

これから何を書く？

現場ではほぼ毎日と言ってもいいほど、いろんなことが発生するんだ。
その中でのノウハウや印象に残ったこと等を書くつもりである。
エンジニアとして、諦めず、毎日頑張っていこう！！

あきらめたらそこで試合終了ですよ (Feat.安西先生)