【書評】自走プログラマー ～Pythonの先輩が教えるプロジェクト開発のベストプラクティス120
「地図」 を持っている「自走プログラマー」になろう
本書は、システム開発を行う上で迷子にならないように、１人で進むことができる「地図」を自分で作れるように、設計から、実装、テストまで様々な状況の具体的な失敗例とベストプラクティスを教えてくれます。
タイトルに「Python」とありますが、Pythonを書いた経験が無くても、プログラミングの経験が少しでもあれば大体は理解できる内容になっています。(※ただし、Pythonのライブラリやフレームワークの話は少し分かりにくい部分はあります)
前書きに、
本書は、「プログラミング入門者が中級者にランクアップ」するのに必要な知識をお伝えする本です。
とあるように、基本的に、プログラミング初心者でも分かるように分かりやすく書かれており、一つ一つの作業の意味やメリットデメリットを理解することの大切さを認識することができます。
また、中級者にとっては、当たり前と感じる部分もあるかもしれませんが、要件定義やシステム設計部分はなかなか経験できない部分なので、新しい知識を得られるかもしれません。
本書のターゲット
本書の構成
第1章 コード実装
1.1 関数設計
1.2 クラス設計
1.3 モジュール設計
1.4 ユニットテスト
1.5 実装の進め方
1.6 レビュー
第2章 モデル設計
2.1 データ設計
2.2 テーブル設計
2.3 Djang ORM との付き合い方
第3章 エラー設計
3.1 エラーハンドリング
3.2 ロギング
3.3 トラブルシューティング・デバッグ
第4章 システム設計
4.1 プロジェクト構成
4.2 サーバー構成
4.3 プロセス設計
4.4 ライブラリ
4.5 リソース設計
4.6 ネットワーク
第5章 やることの明確化
5.1 要件定義
5.2 画面モックアップ
プログラミング初心者は自分の実装を説明できない
本書に書かれている、プロジェクト開発の失敗例は「とりあえず動けばOK！」と考えて、目の前の問題を解決するのに精一杯なプログラミング初心者が陥ってしまう、具体的な失敗例が書いてあります。そのようなプログラミング初心者は、設計の理由や、自分が書いたソースコードを言葉で説明することができません。
プログラミング中級者になるためには、自分のした設計や実装に対して、それを選択した理由やメリットデメリット、また、採用しなかった方法までしっかり理解して説明できる必要があります。
プログラミング初心者にとって、本書は、さまざまな場面のベストプラクティスを学べると共に、プログラミング中級者になるためには、常に様々なことを考えないといけないことを学べると思います。
私自身の学び
私自身としては、1章~3章はベストプラクティスを理解しており、すでに自分で考えながら進められていると感じました。
4章、5章に関しては、まだできていない部分があり、今後の仕事に役立てることができそうです。特に学んだことを以下に書いておきます。
4.4 ライブラリ
OSSなどのライブラリを選定する時に何を基準に採用する必要があるかを学べました。私自身、要件を満たしており、ある程度有名なものであれば、あまり考えずに採用してしまっていました。
5.1 要件定義
すぐに使う技術や細かい仕様に注目せずに、まずは作りたい価値を考える必要があることを学べました。まだしっかりと要件定義を経験したことは無いが、今後、個人開発など、機会があれば役立つと思います。
5.2 画面モックアップ
単純に経験がないので、新しい学びを得ることができました。特に、無駄に複雑なシステムや実装にならない様に、モックアップから実装までをイメージする必要があるということは今後意識しようと思います。
最後に
システム開発でぶつかる壁に対するベストプラクティスは、プログラミング初心者~中級者にとっては、まさに「地図」と呼べるものになるでしょう。
ベストプラクティスを知ってる上で、さらに、プロジェクトの状況や世の中の流れまでをしっかりと考慮に入れて、その都度、ベストな選択ができれば「自走プログラマー」と呼べるはずです。
自走プログラマーになるには、努力と時間が必要ですが、常にいろいろ考えながら行動すれば必ずなれると思うので、私自身、何事も最後まで考えることを忘れないようにしようと思いました。また、本書を若手育成の指針にしていこうと思います。
【書評】ゼロから学べる！ ファシリテーション超技術
良いファシリテーターになるための第一歩に
ファシリは最強のビジネススキル
私はITエンジニアとして仕事をしているのですが、毎日のようにチームで問題解決方法を話し合う会議や、新しいアイデアを考える会議があります。私自身リーダーという立場ではないものの、自主的にファシリテーターを何度も行いました。
その中で学んだのは、ほとんどの会議は、「ファシリテーター次第で上手くいくかが決まる」ということです。
本書は、ファシリテーションの基本的な技術や心構えが書いており、良いファシリテーターになるための最初の一歩としては最適な本だと思います。
本書のターゲット
- 会議が時間内に終わらなかったり結論が出ずに悩んだことがある人
- プロジェクトリーダー初心者
- 将来リーダーになりたい人
- 問題解決を通してよりよい仕事をしたい若手
本書の構成
第1章 会議にはファシリテーターが不可欠
第3章 ファシリテーターが知っておくべき議論の進め方と問題解決のステップ
第4章 会議中にメンバーの意見を引き出すためには
第5章 メンバーの意見を引き出しさらに整理する
第6章 合意形成の仕方
第7章 会議中の雰囲気づくりとファシリテーターの心構え
第8章 オンライン会議でのファシリテーション術
良い会議とは
まずは良い会議の定義を知ることが第一歩です。本書には以下のように定義しています。
- 時間厳守
- 決まる・まとまる(アウトプットの質)
- 参加者の納得度が高い
この中で特に重要なのは「参加者の納得度」です。
多数決や、ファシリテーターの独断による決定では納得度の低いメンバーが出てきてしまい、今後のモチベーションを下げてしまいます。
必ずしも正解の結論を出せばよいのではなく、全員の意見をしっかりと聞いたうえで、納得できる結論を出すことが重要です。
ファシリテーターに求められること
本書は、ファシリテーターに求められることとして、以下の3つを定義しています。
- 会議をデザイン(設計)できるか
- 会議をリードできるか
- "場づくり"をできるか
意外なことに、ファシリテーターは、上手な話術や強いリーダーシップよりも、事前の準備や雰囲気づくりが重要なんです。
特に、テーマについてのアジェンダ(会議の進行表)を作ることが重要な役割になります。どのような順番で、どのように議論して、どうすれば参加者全員が納得できるかを事前に設計することが、会議の成否が決まってきます。
「いい問い」を用意して意見を引き出す
会議中に「意見が出ない」ことはよくあります。
その原因の一つとして、「問い」が良くないことが挙げられます。
本書では「いい問い」の条件として以下を上げています。
- みんなが付箋を3枚以上さらさら書けるかどうか
- 問いの中に問いが含まれない
- 分かりやすく、かつ、シンプルに
ここで学んだことは、「問い」の抽象度のコントロールです。
例えば、「会議で困っていることを教えてください」は抽象度が高く、「経営会議の進行部分で課題と思っていることを教えてください」は抽象度が低い問いです。
どちらが「いい問い」ということではなく、「どちらの方が、よりテーマに合った意見を拾えるか」を考えて、問いの設計をする必要があります。
最後に
本書にも書いてある通り、ファシリテーションは「実践」あるのみです。多少失敗してもいいのでどんどん挑戦していこうと思います。
そのうえで、本書の基本的なファシリテーションの技術を頭に入れておくと、どこが上手くいって、どこが上手くいかなかったのかを理解することができるので、次の実践に生きていくと思います。
また、本書には、コロナ禍で増えたオンライン会議のファシリテーション術についても書いてあります。まずはファシリテーションの基礎ができていることが前提ですが、参考になりました。
【書評】エンジニアのための図解思考 再入門講座 情報の“本質"を理解するための実践テクニック
図解思考とは?
エンジニアとして仕事をしていると、以下のような能力が重要になってきます。
- 原因分析能力
- 問題解決能力
- 新しいアイデアを考える能力
- プレゼンなどのために、資料を作成する能力
さらに、状況が複雑化しており、これらはネットで調べただけでは答えにたどり着けない場合が多いです。そのような時に、現在の状況、ドキュメント、会話、思考などの、さまざまな情報を「図」や「表」で表し、思考の手助けをする。これを図解思考と呼ぶようです。
本書のターゲット
- エンジニアとして働く、若手から中堅
- 原因分析や問題解決能力が苦手な人
- プレゼン資料を作っても、なかなかうまく相手に伝わらない人
本書の構成
第1章 図解はなぜ必要か？
第2章 図解力を伸ばすコツ
第3章 「ラベル」で問題を一気に単純化する
第4章 「表」があなたの思考地図になる
第5章 「仮説思考」で発想を引き出す
第6章 プロセスに関する共通認識を作る
第7章 現実世界のユーザーの心理状態をイメージする
第8章 ロジックの型を知っておこう
第9章 情報の「粒度」を意識せよ
第10章 論理思考の根っこは「0次情報」
第11章 脳内イメージ操作能力を鍛えよう
第12章 1日3分、見出しをつけて要約を！
第13章 わかりにくい文章はとりあえず「分ける」
第14章 問題の解決策をゼロから考える
第15章 モチベーションを上げるヒント
全体像を把握するために図解が必要
原因分析や問題解決の場面で、すぐに答えを求めてしまい、ネットの情報をそのまま実行してみて失敗してしまうという経験はあるでしょうか？たまにはそれで解決することもあると思いますが、それでは問題の本質が理解できないままで、今後の応用が効かないという問題が出てきてしまいます。
まずは、全体像を図解してみる。そのうえで自分の現在地と次に進むべき道を明確にする。そうすれば、現在分かっていることと分からないこと、次に調査することが整理されて、状況を正確に理解でき、問題解決までの道のりが明確になります。
うまく図解するための「3行ラベリングワーク」
図解ができないという場合の大半の原因は「読解力不足」です。
図解をするためには、インプットした様々な情報を「理解」、「補正」、そして「表現」する必要があるのですが、読解力が無く、最初の「理解」ができていないため、図解が上手くできない人が多いようです。
その読解力を鍛えるのが「3行ラベリングワーク」です。
- 3行程度の箇条書を見つける。
- その箇条書の1つ1つに、「ラベル」をつける。
「ラベル」というのは、「見出し」のことです。
箇条書きの各文章に「ラベル」を付けるためには、文章を正しく読み取り理解し、一言で表す必要があるため、読解力と語彙力アップの練習になります。
構想力のあるエンジニアになるために
「構想力のあるエンジニア」とは本書では、以下のように表しています。
目的を達成するためのシステムの構想を立てて、それを必要なパーツのレベルまでブレークダウンして設計図を書ける人
世の中には「特定の問題を解くときにだけ使える統合パッケージ」が多数存在します。しかしこれにだけ頼っていると自分自身の力で、様々な状況に対応できるような問題解決能力が身に付きません。自分なりの「仮説と検証」を繰り返し、その中で本質を理解することで「構想力のあるエンジニア」に近づいていきます。
終わりに
普段から、自分が理解する時や、人に説明するときに「図」や「表」などを使うことを意識していましたが、それの大切さを改めて認識し、新たに情報を図解する手法とノウハウを知ることができました。
また、図解する以前に読解力が足りない部分があったことに気づかされたので、3行ラベリングワークを続けてみようと思います。
【書評】カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
初めに
ITエンジニアに読んでほしい！技術書・ビジネス書 大賞2019
の技術書部門10に選ばれた本書に興味をもったきっかけは、評判が良いからというのはもちろんですが、「カイゼン・ジャーニー」というタイトルでした。私自身、今の現場に漠然とした不安を持っており、自分がもっと成長できる環境が別にあるのではないのかという思いと、今の現場や働き方を改善することで、さらに成長できる環境にできるのではないかという思いで葛藤していました。そこで、まずは自分の今の環境を「カイゼン」するにはどんなことをすればよいのかを考えるヒントになるのではないかと思い、本書を手に取りました。
本書のターゲット
本書のターゲットは、ソフトウェア開発の現場を経験したことのある若手から中堅、またリーダー経験のある人です。さらには現在の現場でのプロジェクトが炎上していたり、今の環境がこれ以上成長できる環境ではないと感じている人にはとても刺さる内容だと思います。
本書の構成
ソフトウェア開発の現場を経験したことがある人であれば、共感できるストーリーを中心に書かれており、主人公である江島の、苦悩や努力、さまざまな経験を追体験できるような内容になっています。その中で、チームの状況に合ったアジャイル開発のプラクティスの解説があり、「カイゼン」のヒントがちりばめられています。
第1部 一人から始める
第2部 チームで強くなる
第3部 みんなを巻き込む
本書で紹介されるプラクティス
本書では、アジャイルやチームビルディングのプラクティスがたくさん紹介されています。ただし、そのプラクティス自体の詳細な説明が書いてあるというよりは、さまざまな状況に合わせて、実施する意味や効果が分かるように書いてあります。
このようなプラクティスは、確実に成功するような「正解」は存在しません。プロジェクトの状況や、メンバーの能力や性格まで、1つとして同じ状況の現場は存在しないので、プラクティスの目的をしっかり理解しながら、状況に合わせて臨機応変にやり方は変化させていく必要あるためです。
本書は、共感しやすいストーリーによって、プロジェクトの状況を読者が理解したうえで、今の登場人物の状況に合ったプラクティスの目的とやり方を紹介しているので、そのプラクティスが、どんな時に、どんな効果があるものなのかが理解しやすくなっています。
その結果、現実の自分の状況に合わせてプラクティスを実施するための考え方が身につくと思います。
【越境】
本書のサブタイトルにもある「越境」は大切なキーワードだと思います。
だれでも自分の想像外の場所に足を踏み入れることは勇気が必要です。新しい分野の勉強をしたり、さらには、なにかしら新しい趣味を始めることですら、なかなか行動に移すことが難しいです。
大事なのは、「なぜ越境するのか？」を常にしっかりと考え、目的を持って、自分の想像を「越境」してみる。そして周りの人を巻き込んでさらに「越境」する。そのサイクルを繰り返していくと、仲間と、一人ではできないような大きなカイゼンを実現できるでしょう。これが「カイゼン・ジャーニー」です。
タイミングが「遅すぎる」ということはないです。「気づいて動く時が、その人にとっての最速」です。
これからの行動
まずは、1人で「越境」してみます。
現状を整理して見える化してみる。次に、外部の勉強会やTwitterなどを使って、社外の人と交流してみて、いろいろ新しい考えや価値観に触れてみる。そのうえで、しっかりと目的を持ち、本書で紹介されたプラクティスを使って「越境」してみる。
そして、
「あなたは何をしている人なんですか？」
「あなたの目指す先はどこですか？」
という問いに、自信をもって答えられるようになる。
ワクワクしてきました！
終わりに
本書は、私にとって、アジャイル開発の技術書という面と、今後のエンジニアとしての人生の「改善の旅」の第一歩を踏み出すための自己啓発と、2つの面を持つ大切な本になりました。
読んだだけでなく、実践しないと意味はないので、今後私がどんな【越境】を実践したかは別途発信していけたらと思います。
社会人6年目まで全く勉強しなかった意識低いアラサーエンジニアが、業務外での勉強が習慣化するまでの3ステップ
始めに
新卒から社会人6年目まで全く勉強をせずに、なんとなく仕事をこなしているだけだった私が、業務外での勉強が習慣化するまでの行動と意識の変化を書いてみようと思います。
私と同じように、何となく仕事はこなせてはいるけど、「本当にこのままで良いのか？」という焦りを感じているような、若手から中堅の方に少しでもヒントになれば幸いです。
※私は、まだ勉強が習慣化したという段階なだけで、それによって何かを成し遂げた訳ではありません。ただ、私のように、勉強を習慣化することができなくて悩んでいる人が多いと思ったので、本記事を書きました。
私の情報
- 大学では特に勉強はせずに、バイトとフットサル漬けの日々。
- 2013年に、SES企業に新卒として入社。
- 入社6年目まで、とりあえず仕事をこなして、給料をもらうだけの日々。
- 入社8年目現在、勉強が習慣化され、仕事の成果が格段に上がり、同期をごぼう抜きして昇格する。
最近の業務外での勉強
2019年
2020年7月現在
- GCP Professional Cloud Architect 認定資格 取得
- ブログ開始 24記事作成
- ビジネス・IT・技術系の本の読書33冊
ステップ1
思い込みを無くす
・このまま何となく仕事を続けて食っていければいいや
⇒終身雇用じゃないので、成果出さないと切られるよ。
エンジニアは、勉強しないとやりたい仕事ができないよ。
・勉強する時間がない
⇒とりあえず、30分なら時間作れるよね？
・勉強したいけど、何を勉強すればいいか分からない
⇒ただの言い訳。まずは、何を勉強すればいいかを勉強しよう。
目標を明確にする
・まずは、必ず達成できる小さな目標をたてる
⇒本を1冊読む。勉強系のYoutubeを1本見る。など。
・成果が分かりやすい資格取得を大きな目標にする
⇒しっかり勉強すれば取得できるし、自信になる。会社での評価にもつながる。
・目標は定期的に見直して、必ず達成できるように調整する
⇒もし勉強を一か月さぼってしまっても、目標達成期日を1か月伸ばせばよい。
ステップ2
最初はとりあえずインプット
とりあえず本を読んでみましょう。軽く読めるビジネス書がおすすめ。
そうすることで、小さな目標の達成を積み上げることができ、自然と「もっと学びたい」という気持ちが湧いてきます。
勉強してることを周りにアピールする
モチベーションを維持するために、周りの人に勉強していることをアピールしましょう。ほとんどの人は褒めてくれると思います。嫌味を言うような人とは関わらない方が吉。
やる気が出ないときは無理にやらない
最初のうちは、やる気が出ないときは無理に勉強しなくてもよいです。疲れてしまって結局挫折してしまいます。気楽にやりましょう。
ステップ3
アウトプットを意識する
インプットに慣れてきたら、方法はなんでもよいので、インプットした内容をアウトプットする意識を持ちましょう。それだけで記憶に定着しやすくなりますし、業務で実践することで、結果的に大きな成果が出るようになります。
- メモする
- 実践する
- ブログを書く
- 勉強会を開催する
自分を成長させてくれるメンターを見つける
次にどのような勉強をすればよいか迷ったときや、勉強の目標を決める時に、効果的なアドバイスをくれる人を見つけましょう。道に迷ったときや、モチベーションが下がったときに助けを求められる人がいるのは心強いです。
朝活する
私の経験上、一番効率的に勉強できる時間帯は、妻が寝ていて、ゲーム配信がやっていない「朝」です。
Twitterを活用する
Twitterで、同じ勉強をしている人や資格を持っている人から情報収集しましょう。また、モチベーションが高い人と交流してみて、刺激を受けましょう。
終わりに
ここまで来ると、勉強が習慣化されて、逆に、勉強しないと気持ち悪くなってくると思います。
ネットに書いてあるような一般的な方法でなく、試行錯誤して見つけた、私自身に合った方法なので、この記事を一つの参考にして自分自身の方法を見つけることが大切だと思います。
ここまでいろいろ書きましたが、勉強を続けていくうえで一番大切なのは、「十分な睡眠」なので、無理せず自分のペースで勉強しましょう。
BigQuery がテーブルレベルのアクセス制御に対応されたので試してみる[ベータ版]
始めに
BigQuery がテーブルレベルのアクセス制御に対応されたようです。
2020年7月5日現在、まだベータ版ですが、一般提供されたら、業務で使いそうなので、今のうちに試してみました。
アップデートの概要
新しくBigQueryのテーブルレベルで権限を制御できるようになります。(BigQueryテーブルACL)
これにより、データセットに権限が無い場合でも、特定のテーブルまたはビューにクエリを実行することができるので、必要最小限の権限を付与する原則をさらに徹底できます。
想定されるユースケース
- 社外の関係者などに、1つのテーブルだけ共有する
- テーブルへの読み取り専用権限を承認ビューを使わずにできる
テーブルACLを使ってみる
- BigQueryのUIでテーブルを選択し、「テーブルを共有」ボタンを押す
- メンバーを追加して、BigQueryデータ閲覧者を付与してみる
まとめ
基本はデータセットごとに権限制御することは変わりないですが、これまでは、ある1つテーブルを別のチームに共有したい場合は、別のデータセットに承認ビューという形で提供していました。ただ、それだとやりたいことに対して、少し煩雑だと感じていました。テーブルACLを使うと簡単に実現できるので、正式にリリースされたら使う場面は増えていきそうです。
【書評】宇宙兄弟 今いる仲間でうまくいく チームの話
同じチームは世の中に1つも存在しない
あなたのチームは今、うまくいっていますか？
チームには、成熟したベテランもいれば、経験の浅い若手もいると思います。また、性格もバラバラで、さらには、メンバーの増減によってチームの状況は度々変化していると思います。それらすべての状況に当てはまるような、理想のチームを作る「成功のルール」は存在しません。
本書は、そのことを前提に、マンガ「宇宙兄弟」の個性的なキャラクターと印象的なシーンを具体例に出しながら、今のメンバーとチームの現状を整理し、「今いるメンバー」で、「自分たちだけの」理想のチーム作りのヒントを得られることができます。
私自身も、今のチームのメンバーでもっと成果を上げたいと思っており、その中で自分の強みを生かしたリーダー像を模索している時期だったので、とても参考になりました。
本書の目次
第1章 チームの成長を阻害する思い込みのワナ
第2章 チームの成長を促す4つのリーダーのスタイル
第3章 チームの成長法則「チームメイキング編」
第4章 チームの成長法則「チームビルディング編」
第5章 「しない」をすれば、あなたもチームもうまくいく!
4つのリーダースタイルとは
本書では、リーダーのスタイルを大きく4つに分けています。
ファシリテーター型 (支援と促進が得意)
マエストロ型 (職人肌で成果を出すのが得意)
ティーチャー型 (教えて諭すのが得意)
コンサルタント型 (専門的な知識で牽引するのが得意)
それぞれのタイプで「強み」と「苦手なこと」が存在し、チームの状況によって役割や出番が変わってきます。
本書には、自分がどのリーダーのスタイルなのかを知るためのチェックシートが付いています。ちなみに私は、ファシリテーター型とマエストロ型で多くチェックが付きました。私自身、メンバーを「引っ張る」よりも、「押す」ことでチームを前進させるタイプだと思うので、しっくりくる結果でした。
「チームの発達段階」とは
「自分たちのチームは今、どんな状態なのだろう？」という視点を持つために、アメリカの社会学者、ブルース・W・タックマンが提唱した「タックマンモデル」をベースにしたフレームワークを「チームの発達段階」と呼びます。
第1ステージ 【形成期】フォーミング
第2ステージ 【試行錯誤期】ストーミング
第3ステージ 【規範期】ノーミング
第4ステージ 【達成期】トランスフォーミング
まず、今のチームが「チームの発達段階」だと、どのステージなのかをメンバーで考えて、現状を理解することが、理想のチームを 作るための第1歩です。
本書はさらに、「チームの発達段階」の各ステージで、前述した4種類のリーダーが、それぞれどのような意識をもってリーダーシップを発揮すれば良いのかを教えてくれます。
終わりに
今いるメンバーで理想のチームを目指すために、自分らしく、自分なりのやり方で、楽しみながら、いろいろなことに試行錯誤しながらチャレンジしていきたいと思える本です。
チームの成長に悩んでいる人は、とりあえず、自分たちのチームが「チームの発達段階」のどのステージにいるかを、メンバー全員で話してみるとよいでしょう。
私自身も自分に合ったリーダー像を見つけることができたので、今のチームにしっかり向き合って、自分なりにいろいろチャレンジしてきたいと思います!
著者の長尾 彰さんの「宇宙兄弟」を題材にした著書である、『宇宙兄弟 「完璧なリーダー」は、もういらない。』と併せて読むと、自分なりのリーダー像と、チーム作りの方法が、具体的にイメージしやすくなのでおススメです。
