「Pythonプロフェッショナルプログラミング 第3版」は、10年の取り組みの集大成

2018年6月12日にビープラウドのメンバーで執筆した「Pythonプロフェッショナルプログラミング 第3版」が出版されます。

Pythonプロフェッショナルプログラミング第3版

第1版が2012年3月26日、第2版が2015年2月27日、第3版が2018年6月12日の発売で、約3年おきに版を重ねてきました。

最新技術に合わせてバージョンアップ

IT技術は日々バージョンアップされ、数年もすれば技術の構成やベストプラクティスも変わってきます。

技術の進歩に合わせて、書籍も第3版としてバージョンアップしました。

主な改訂内容は以下のとおりです。

• Python2.7.6→Python3.6.4
• Ubuntu14.04 LTS→Ubuntu16.04 LTS
• Webアプリケーション(2章) サンプルアプリケーションを「乗りログ」という新たなアプリケーションに変更
• ソースコード管理(6章) Mercurial→Git/GitHub
• Pythonパッケージの利用と開発への適用(9章)：manylinux, Dockerの活用
• 継続的インテグレーション(10章)：Jenkins→Circle CI
• テスト(13章) ：テストの見積もりについて説明追加
• 開発環境のセットアップ(Appendix)：Vagrant、ネットワーク設定、ファイル同期、環境のバックアップなどの説明を追加
• プログラマーのための機械学習(15章) を新たに追加

上記以外にも全面的に内容を見直し、細かい修正を加えています。

機械学習の章を新たに追加

ビープラウドでは、2017年から機械学習・データ分析系のシステムも受託開発しています（2017〜2018年の実績は6案件（2018年6月時点））。

機械学習のプロジェクトというと、データサイエンティストやドメインエキスパートといった役割が浮かびますが、ビープラウドではWeb開発を担当していたプログラマーも、機械学習のプロジェクトに携わっています*1。

機械学習の実プロジェクトから得たノウハウ、主にプロジェクトの進め方や考え方を「プログラマーのための機械学習」の章として追加したのも第3版の大きな特徴のひとつです。

「プロフェッショナル」というタイトルの意味

プログラマーになるためには、まずプログラミングの文法から学び始めます。

しかし仕事として実際のプロジェクトにプログラマーとして参加するには、プログラミングの文法を学んだだけでは良い仕事はできません。

なぜならプロジェクトにはQCD(Quality:品質、Cost:費用、Delivery:納期）の制約があるからです。

実プロジェクトにおいてQCDの制約の中で、職業としてのプログラマー（以下、プロフェッショナル・プログラマー）としての役割を果たすには、プログラミング以外にも、開発環境、エディターの使い方、ソースコード管理、ドキュメント、テスト、デバッグ、設計、サーバーインフラ、パフォーマンス、ライブラリ、ミドルウェア、継続的インテグレーション、課題管理、レビュー、チームでの仕事の進め方などさまざまな知識を持ち、活用する必要があります。

プロフェッショナル・プログラマーは、プログラミングだけではなく周辺技術を活用できてはじめてプロジェクトのQCDを守れるという、ある意味厳しい環境で仕事をしているといえるでしょう(だからこそナレッジワーカーとしてのプログラマーの仕事の価値があります)。

プログラミング言語Pythonに特化し、プロフェッショナル・プログラマーにとって実プロジェクトで必要な知識・スキルのベストプラクティスをまとめたのが「Pythonプロフェッショナルプログラミング」です。

さまざまな技術についてまとめていますので、書籍は488ページ(全15章+Appendix)にも及んでいます。

また会社のサイトトップには以下のように会社のミッションが書かれています。

株式会社ビープラウドはソフトウェア開発のプロフェッショナルチームです。 日々研鑽した知識・技術・創造力とチーム力で、アイデアをカタチにし、価値を創り出します。

ここでの「プロフェッショナル」は、職業という意味だけではなく、以下のような意味も込められています*2。

• 専門家のこと。ある分野について、専門的知識・技術を有しているひと
• そのことに対して厳しい姿勢で臨み、かつ、第三者がそれを認める行為を実行している人

この「プロフェッショナル」への思いが、書籍のタイトルにも込められていることも加えておきます。

本書の土台になっているもの

ビープラウドでは、2008年4月にPythonを開発のメイン言語に定めました。

それ以来10年間にわたり、90以上のプロジェクトでPythonを採用し、開発実績を積み、技術やノウハウを洗練してきました。

ビープラウドの技術者たちの会話を聞いていると、さまざまな技術の比較やよしあし、技術動向、技術の経緯など「よく知っているなぁ」と感心することが多々あります。

これらの知識は「より良い仕事をしたい」「自分のスキルをアップしたい」「技術が好き」という意志がベースにあり、多くの時間を使って追求した結果です。

技術者のすべての行動には理由が必要です。

「なぜその技術を使うのか？」「なぜそのように技術を使うのか」

理由を突き詰め、積み上げた先にあるのが価値を創り出す安定したシステムです。

日々多くの時間を使い追求した技術を土台に「なぜその技術を使うのか？」「なぜそのように技術を使うのか」が随所に説明されている点も本書の見どころのひとつです。

PyQとのコラボレーション

ビープラウドで運営しているオンラインPython学習プラットフォームのPyQで、書籍とのコラボ問題を用意しました（コラボ問題は無料です。クレジットカードの登録が必要で、書籍内にキャンペーンコードが記載されていますので画面で入力してください）。

第2章で新たに用意したサンプルWebアプリケーションの「乗りログ」を開発する問題です。

「乗りログ」を作ろう

書籍で読んだことを、PyQで実際に手を動かしプログラミングし動かすことで、理解を深めることができます。

ご自分で環境を用意するよりも早くアプリケーションを試すことができますので、是非トライしてみてください。

pyq.jp

最後に

Pythonを採用して丸10年という節目に、ビープラウドのノウハウ・知識を書籍としてまとめてくれた会社メンバー(11名)、書籍をレビューしてくれた社内メンバー(16名)、そして社外から唯一レビューに参加してくれた @aodag に感謝します。

そして本書の出版に尽力してくださった秀和システムの平野孝幸さんに感謝します。

「Pythonプロフェッショナルプログラミング 第3版」は「Pythonによる開発のイマを知るのに最適である」と自信をもっておすすめできる書籍に仕上がりました。是非お手にとってお読みください。

Pythonプロフェッショナルプログラミング第3版

*1:機械学習の顧問としてサイボウズ・ラボの西尾泰和さんに2017年から参画していただき、機械学習を勉強したエンジニアが西尾さんにアドバイスを受けながら手を動かすというカタチでプロジェクトを進めている。勉強と実践のギャップを埋める効果を狙った取り組み（参考URL）

*2: Wikipediaより

決断力を磨くために私が日々考えていること〜羽生善治氏講演「決断力を磨く」に参加しました

2018年4月25日に静岡県の沼津市で開催された、羽生善治さんの講演に参加しました。

講演のテーマは「決断力を磨く」です。

羽生さんの話は18時40分頃から始まり、約1時間20分でした。

講演内容は、報知新聞のサイトでまとめられています*1。

www.hochi.co.jp

羽生善治さんについて

羽生善治さんは昨年竜王に返り咲き、永世７冠となりました。

2018年3月には順位戦A級を勝ち抜き、現在は佐藤天彦名人との名人戦に挑戦中です（2018年5月8日現在1勝1敗)。

棋士はどのように手を決断しているか

羽生さんの話で印象に残ったのは、棋士がどのように指す手を決断するときに、直観で２、３手を選ぶ→ロジック（手を読む）→大局観で選択するという思考の過程を経ているという話です。

1.直観で２，３手を選ぶ

まずは、今までの集大成をもとに、直観で１秒にも満たない時間で２，３手を選ぶ

2.選んだ２、３手の先を読む

選んだのは2、3手でも手の組み合わせは掛け算なのですぐに読むべき手のパターンが爆発する（10手先は3の10乗で6万弱のケース）

3.大局観で手を選択する

大局的な視点で戦略的、抽象的に手を選択する

仕事に必要な決断力

経営の仕事に限らず、日々の仕事では正解が存在することはほとんどありません。

そのため、自分が「正解である」という手を決断する必要があります。

この決断が速ければ仕事は速く進行し、選択した手が正解であれば望ましい結果がもたらされます。

指してみて結果が現れないと正解かどうかがわからないのは、将棋も仕事も一緒です。

私は経営者として日頃から決断の機会も頻繁に訪れます。

私が心がけているのは、なるべく即決することです。

なぜなら私がすぐに判断すれば周りの人がすぐに動き出すことができ、会社やプロジェクトのスピードに直結するからです。

このエントリーでは羽生さんに触発され、決断力を磨くために私が日々心がけていることをまとめます。

仕事のドメインについて勉強・研究し続ける

羽生さんは「まず、直観で２，３手を選ぶ」とおっしゃいましたが、その元になるのは「今までの集大成」です。

集大成とは、棋士で言えば定石や手筋の研究、対戦の経験などです。

一般的な仕事でいえば対象ドメインの勉強や実践経験といえるでしょう。

これらが直観のインプット（材料）になります。

この材料が不足していると、誤った手を選択してしまうことも多くなり、思考も迷宮入りします。

決断力を磨くためには仕事のドメインについて常に学び続け、判断材料を仕入れ洗練させる必要があります。

価値観を育てる

決断するには判断基準が必要です。

判断基準がないと、毎回１から考えなくてはなりません。

判断基準の元となる自分なりの価値観を育て、自分の中で運用されていれば決断は速くなります。

開発者としての価値観を育てたい場合は、まずアジャイル開発の考え方を学ぶと良いでしょう。

最近では開発者に限らず、アジャイル開発の考え方で行動する組織として「アジャイルエンタープライズ（アジャイル企業）」という考え方もあります。

アジャイルエンタープライズ (Object Oriented SELECTION)

さまざまな人の考えを知る

人の考え方や、仕事の理論、仕事の方法は無数にあります。

それらは時代とともに変わっていくもので、数は無限に増えていきます。

自分の価値観とは違うことを言う人に対して「なぜそのようなことを言うのか」が分からないという場面は多々あります。

しかし読書などで自分とは違う価値観や考え方、理論も知っておくと理解できたりします。

そのように材料を増やしておくことで、一緒に仕事をする人の背景や考え方も踏まえると新しい手が見えてくることがあります。

直観で行動した結果を判断ロジックにフィードバックする

自分の直観が正しかったかどうか結果をもとに振り返り、判断ロジックを再構築することも必要です。

振り返りにより、どのようなときに自分は選択を間違えるのか、即決を一旦止めたほうが良いのか、直観が当たるのかが分かるようになってきます。

私は仕事以外の場面でも、日頃から直感を磨くようにしています。

shacho.beproud.jp

立ち止まる習慣をつける

勉強をし、自分なりの判断基準を持ち、経験が豊富になってくると、素早く判断できるようになります。

しかし同じ思考回路を繰り返していると、いつしか時代や周りの環境が変わったときも同じ思考回路で判断してしまいます。

同じ思考回路（プログラム）で、同じ出力（判断）を繰り返す状況となり、いつしか時代の変化についていけず偏屈な老害になりかねません。

決断するべき課題が現れたら、一旦判断を保留し、自分と違う視座（他人の視座）で考えてみたりすることによって新しい思考を得ることが出来ます。U理論でいうと以下の図になります。

これを日々習慣づけると、思考回路を日々再プログラミングしてアップデートし続けることができ、思慮深い人になれるのではないでしょうか。

大局観で選択する

大局観とはなんでしょうか。WikiPediaには以下のように書かれています。

ボードゲームに置いて、部分的なせめぎ合いにとらわれずに、全体の形の良し悪しを見極め、自分が今どの程度有利不利にあるのか、堅く安全策をとるか、勝負に出るかなどの判断を行う能力のこと。 大局観に優れると、駒がぶつかっていない場所から意表を突く攻めを行うなど、長期的かつ全体的な視野のもと手を進めることが可能となる。

大局観で判断するのと対象的なのは「ベタ読み」で判断することです。

ベタ読みとは目の前の駒の状況を元にひとつひとつ読んでいくことです。これを全てに適用していたら時間はいくらあっても足りません。

匠Methodの要求分析ツリーでいうと、ビジョンや目的レベルに照らし合わせて判断するのが「大局観で判断する」、IT要求、活動レベルだけを見て判断するのが「ベタ読みで判断する」に該当するのではないでしょうか。

物事を判断する時に「ビジョンに合っているか」「そもそもどのような価値があるのか」という大局的、抽象的、戦略的視点で常に考えることで取捨選択が速くなります。ビジョンから外れていたり、価値が生まれないアイデアはすぐに捨てることができるからです。

このような思考をメタ認知というそうです（弊社メンバーに教えてもらいました）。

メタ思考トレーニング (PHPビジネス新書)

まとめ

羽生善治さんの「決断力を磨く」というテーマの講演をもとに、自分が経営者として決断するために日々考えていることをまとめてみました。

羽生さんのように長い間活躍できるように、経営者として名人クラスに決断力を磨き上げていきたいと思います。

*1:記事がいつまで残っているかはわかりません

「匠Method活用法」を読んで、製品、会社、個人に必要なブランディングアプローチを学ぼう

匠Methodの書籍の第２弾となるビジネス価値を創出する「匠Method」活用法が2018年4月20日に発売されました。

ビジネス価値を創出する「匠Method」活用法

本書の構成

本書は以下の構成です。

• 1章：匠Methodを生み出す過程

  匠Methodの開発者である萩本順三さんが匠Methodにたどり着くまでにどのように過程を歩んできたのかが語られている

• 2〜4章：匠Methodの基本的説明

  モデルのサンプルを用いながら匠Methodの基本について説明

• 5〜8章：匠Methodを拡張したArchBRANDINGというブランディングアプローチの説明

2016年12月に出版された匠Method: 〜新たな価値観でプロジェクトをデザインするために〜との主な構成の違いは、匠Methodに至るまでの過程と、ブランディングについて重点的に説明されていることです。

2〜4章で匠Methodの基本モデルについて分かりやすく説明されていますが、匠Methodについてさらに知りたい人は、前著の匠Method: 〜新たな価値観でプロジェクトをデザインするために〜を読まれることをおすすめします。

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠Methodに至るまでの道

萩本さんは27歳でソフトウェアエンジニアのキャリアをスタートし「複雑多様化した社会やビジネスをまとめてより良い方向へ導くための手法をつくるべきである」という使命を持ち、そのための方法論（メソッド）をつくりあげてきました。

萩本さんはソフトウェア工学を学ぶ中でオブジェクト指向に出会いました。そしてオブジェクト指向をベースに人の認知・心、戦略、価値を見える化しカタチにする方向へと方法論（メソッド）を発展させていきます。その取り組みは20年以上の実践や研究の歳月を経て進化し、匠Methodとして実を結んでいます。

このような匠Methodの成り立ちや背景を知ることで、匠Methodを構成する要素を表面的ではなく立体的に理解し、活用できるようになるでしょう。

ArchBRANDINGというブランディング手法

本書の特徴の２つ目は匠Methodを拡張したArchBRANDINGというブランディング・アプローチの説明に重点が置かれている点です。

ブランドを高めるメリット

製品や会社、そして個人にもブランドがあったほうが何かとメリットがあることはぼんやりと分かっていることでしょう。ブランドを高めるメリットは何でしょうか。

まず、ブランド力がない場合が以下の図です。

ブランドがないので、外向きに力を使い働きかける必要があり、活動に必要な、人、モノ、カネ、情報を得るためにお金をかけたり、時間を使わざるを得ない状況です。また価格も下げざるを得ないかもしれません。

この状態で活動を続けていくと、いつかは力尽きてしまうかもしれません。

一方、以下の図はブランド力が高い場合です。

活動に必要な、人、モノ、カネ、情報が自然と集まってくる状態です。自然に集まってくるので内部にお金や時間を使うことができます。

このような状態で、お金やリソースをかけて外にアプローチしていくと相乗効果でブランドが広がっていくことでしょう。

ブランドをつくるには

上記のような状態が組織や製品・サービス、そして個人にとって理想的ですが、どのようにしてブランドをつくりあげればよいのでしょうか。

まずはホームページやランディングページをつくったり、ブランドのロゴをつくるかもしれません。

また、日々の開発やマーケティング、カスタマーサポートなどの活動はブランド力を高めることに直結しているでしょうか。

このようにブランドをつくるといっても、なかなか方法が思い浮かびません。

匠Methodを拡張したArchBRANDINGは、ブランディングのためのプロセスを提示しています。

ArchBRANDINGでは、ブランディングに必要な要素として、以下の３つを上げています。

• Concept(意志)：脳

  企業や組織の関係者で共有化されて、文章や体系として「見える化」されている考え

• Design(表現)：顔

  ブランドの価値を示す言葉や形状、表出された具体的な考え

• Action(活動)：手足

  ブランド戦略や企業戦略を「見える化」していく具体的な活動

そしてこれらをつなぐのが、ArchBRANDING：神経・血管です。

本書では、１つの人格をもったヒトのように一貫したブランディング戦略を進めるための考え方とプロセスを説明しています。

意志のあるブランドの威力

本書では「プロダクトのブランディングサイクル」として、以下の３つをあげています。

• 宣言型ブランディング（自分たちの意志をブランディング：企画・開発期）
• ユーザー体験型ブランディング（ユーザー体験をストーリーとしてブランディング：発展期）
• 活動蓄積型ブランディング（自分たちの強みとする活動をブランディング：成熟期）

書籍「リーンブランディング」の著者は、多くの優れたスタートアップがブランディングできずに世の中に知られず廃れていったのと同時に「単純なMVP（実用最小限の製品）しかなくても深い意味の込められたブランド」をもったスタートアップが注目を集め、事業を軌道に乗せて成功した事例を数多く見たといいます。

「単純なMVP（実用最小限の製品）しかなくても深い意味の込められたブランド」をもったスタートアップとは、ここでいう「宣言型ブランディング」をしたスタートアップであるといえるでしょう*1。

本書では、自動車業界のコンセプトカーの事例をもとに「宣言型ブランディング」の重要性について説明しています。

「匠Method活用法」とあわせて読みたい

リーンブランディング ―リーンスタートアップによるブランド構築 (THE LEAN SERIES)

私の匠Method活用について

私はconnpassやPyQなどの製品開発や、受託開発の企画フェーズ、そして自身のキャリアデザインに匠Methodを活用しています。

匠Methodを学び始めたきっかけは、2012年4月27日のBPStudy#57で著者の萩本順三さんにお話いただいたとき*2に、匠Methodを知ったことです。

いままで製品企画についてさまざまな手法を調べましたが、匠Methodはアイデアをカタチにするという点で唯一無二の手法であると確信しています。

場合に応じて他の手法*3も使いますがそれは部分的な使い方であり、プロジェクトのアーキテクチャー、羅針盤として機能しているのは匠Methodで作成したモデルです。

匠Methodを学ぶ場である匠道場*4には、2013年1月から毎月参加し、継続して匠Methodを学んでいます。

私は匠道場が2018年4月までに64回されたうち、63回参加しています*5。

この参加率の高さから、私の匠Methodへの確信は伝わると思います。

また、カタチにするという点での手法の確かさは、オブジェクト指向をベースにシステム開発から発展してきた匠Methodの起源に由来するものだと思います。

まとめ

よい製品やサービスをつくっただけでは世の中に広まりません。それは会社などの組織や人においても同様です。

良いものをつくった人、そしてチームにはその価値を世の中に広く伝え、その価値で良い方向に世界を変えていく使命があります。

そのときに核となるのがブランディングです。

匠Methodでは「内の価値と外の価値の両立が重要」という考え方があります。

よいものをつくった段階は「内の価値」ができた段階です。

匠Method(ArchBRANDING)によって「外の価値=見せる価値」を見える化し、活動までつなげていくことで「価値を世の中に広め、良い方向に世界を変えていく」使命を果たせるようになるのではないでしょうか。

そのようなブランディングをしたいチーム、組織、個人に本書をおすすめします。

ビジネス価値を創出する「匠Method」活用法

あわせて読みたい

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

*1:「宣言」するタイミングですが、MVP（実用最小限の製品）が出来たくらいのタイミングが良いでしょう。それより早いとまだ方向性も定まっていないことも多いからです。

*2:直接の知り合いではありませんでしたが、浅見智晴さんにご紹介いただき、お話いただきました。依頼させていただいたのは、Publickeyに掲載された記事「Top DevOps / アジャイル開発 特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐」を読んだのがきっかけです。

*3:ビジネスモデルキャンバス、バリュープロポジションデザイン、カスタマージャーニー、UXブループリントなど

*4:匠道場とは、匠Methodのライセンスを購入している企業の社員が参加できる匠Methodを学ぶ場。2013年1月から毎月1回開催されている

*5:不参加は2013年3月の第3回開催のみ

「カイゼン・ジャーニー」はアジャイル開発への誘いの書

界隈で話題の「カイゼン・ジャーニー」を読みました。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

書籍の概要（ストーリー）

「カイゼン・ジャーニー」の主人公は、江島という20代の若手エンジニア。

忙しく混乱した日々の仕事を懸命にこなす毎日。

そんな開発現場や会社の体制に不満を抱えてはいるものの、状況を変える何かを自分でできているわけではない。

そのような日常から話（ジャーニー：比較的長めの旅行）はスタートします。

社外勉強会での出会いをきっかけに、主人公が行動を起こしていくストーリーです。

おすすめしたい人

• 仕事で成長したいエンジニア
• いまどきのアジャイル開発を学びたい人
• アジャイル開発導入を検討している／取り組んでいる開発プロジェクトのリーダー
• エンジニアの気持ちを知りたい人
• 自社の勉強会を開催している人／開催を検討している人

本書の特徴

「カイゼン・ジャーニー」を読んで感じた特徴を紹介します。

現場あるあるが面白い

プロダクトの開発や受託開発に限らず、システム開発の現場では日々さまざまな問題や事件が起こります。

そのような現場で良く起こることを、飲み会のネタで話したりします。

本書ではそのような既視感のある場面が次々と登場し「あー、あるある」と思いながら読み進めました。

そのような開発現場で発生する問題を主人公の江島がどのように解決していくのか。

それが本書の見どころの一つです。

こういう人いるいるが面白い

本書はストーリー仕立てなので、さまざまな登場人物が登場します。

開発現場にもさまざまな職種な人がいますし、人のタイプや特徴もさまざまです。

本書では「あー、こういう人いるいる」と思えるような人たちが登場します。

自分だったらこのような人たちとどのようにコミュニケーションするだろうとイメージしながら読みました。

アジャイル開発、チーム開発のさまざまなプラクティスを学べる

本書ではアジャイル開発、チーム開発、リーダーシップに必要な手法や考え方がストーリーの中に散りばめられています。

タスクボード、朝会、KPT、事実・意見・対策、重要と緊急のマトリックス、WIP制限（緊急割り込みレーン）、素朴理論と建設的相互作用、学習する組織（氷山モデル）、スクラム、スプリントプランニング、スプリントボード、インセプションデッキ、ゴールデンサークル、組織の成功循環モデル、Working Agreement、ドラッカー風エクササイズ、ファイブフィンガー、スプリントレビュー、クネビンフレームワーク、リファインメント、狩野モデル、むきなおり、星取表（スキルマップ）、モブプログラミング、モブワーク、バリューストリームマッピング、ECRS、カンバン、ポストモーテム、タイムラインふりかえり、感謝のアクティビティ、タックマンモデル、リーダーズインテグレーション、モダンアジャイル、アジャイルな見積もりと計画づくり、プランニングポーカー、リリースプランニング、パーキンソンの法則、CCPM(Critical Chain Project Management)、YWT、スクラム・オブ・スクラム、アーキテクチャーと組織構造（コンウェイの法則）、デイリーカクテルパーティー、ユーザーストーリー、ギャレットの５段階、仮説キャンバス、ユーザーストーリーマッピング、MVP(Minimum Viable Product)、ユーザーインタビュー、SL理論、ハンガーフライト

いまどきのアジャイル開発の考え方、手法、そして現場で役立つ理論が並んでいて、眺めるだけでもワクワクするようなキーワードが並んでいます。

自分の状況と照らしあわせて使えそうな手法や理論をさらに深掘りして調べてみると、いま自分が抱えている問題を解決する糸口になるかもしれません。

上記のプラクティスをストーリーの中で学べるので、活用場面のイメージがつきやすいのも本書の特徴です。

貫かれている価値観：越境

仕事の目的は価値を実現することです。

アジャイル開発もユーザー価値の実現が目的です。

しかしユーザー価値を実現するためにプロジェクトやをスタートしても、目の前の仕事に取り組んでいくと仕事を遂行することに必死になり、視野が狭くなります。

視野が狭くなると、仕事自体が目的化します。

プログラマーでいうと目の前のプログラミングタスクを完遂していれば、自分の仕事はこなしているというように考えることです。

プログラマーの仕事はプログラミングすることではなく、ユーザー価値を実現することです。

価値を実現しないプログラムをいくらつくっても、その仕事には意味がありません。

人の性質として、自分の安全な領域「コンフォートゾーン」をつくり留まろうとします。

コンフォートゾーンの周りには「境界」がうまれます。

この境界内に留まると視野が狭くなり、ユーザー価値を実現する行動から遠のいていきます。

本書のストーリーでは、この「境界」を「越境」するという考え方が貫かれています。

越境するには勇気が必要です。

越境すると一時的な混乱が生まれ、失敗のリスクも高まります。

仕事では一度境界を越境しても、また新たな境界が生まれその境界をまた越境するということの繰り返しです。

主人公の江島が「越境」を繰り返し成長していく姿を、ハラハラしながら読みました。

最後に

3月で仕事が山積みです（今も）。

しかし本書を読み始めるとすぐに次が読みたくなり、一気に読み終わりました。

本書はシステム開発の現場の情景がリアルに描かれていて、かつ最新のアジャイル開発のプラクティスが学べます。

カイゼン・ジャーニーは、エンジニアに限らず、IT、システム開発に関わる人すべてにおすすめの書籍です。

レビュー文化の会社で、楽に生きられる思考法

「コードを憎んで人を憎まず」

コードレビュー時のレビュアー（レビューする側）の考え方（レビュー時に人格攻撃にならない、感じられないように気をつけるなど）として、良く使われる言葉です。

一方で、レビュイー（レビューを受ける側）はどのように考えればよいでしょうか。

マシンやプログラムからエラーメッセージが出ることを「怒られる」と言ったりします。

実際には、マシンやプログラムはエラーを伝えているだけで「怒っている」わけではありません。

しかし、マシンが出すエラーメッセージは無機質なので怒られているように感じることから「怒られた」と言うようになったのでしょう。

このように同じエラーメッセージでも、人の捉え方によって（エラーを）親切に伝えてくれているのか、怒っているのかが変わってきます。

怒られてる・責められてると感じた場合の人の反応

Slackやチケットなど文字のコミュニケーションも無機質になりがちなので、自分の仕事や成果物について指摘を受けると怒られている・責められていると感じてしまうことがあります。

周りの人はチームとしての仕事の質をより良くしようとして、誤りや改善点、より良いと思う案などを伝えます。

しかし、それを怒られている・責められてると感じてしまうと、人は以下のような反応をします。

• つらそうになる（表情に出る）
• へこむ（未熟な自分を責める）
• ムッとして反論する（防御反応として）

このような反応があると、周りの人たちは以下のように変わっていきます。

• 傷つけたり、へこませたくないから指摘しなくなる
• ムッとされるのを怖がって指摘しなくなる

周りから自分の仕事について何もいわれなくなると、人は成長をするチャンスを失います。

自分の仕事の誤りや改善すべき点は自分からは見えにくいので、自らを改善し成長へとつなげることが難しいからです。

指摘を遠慮するコミュニケーションが蔓延すると、仕事の質が上がらず成果が出ないチームが出来上がります。

責められている・怒られていると捉えないための対策

周りの人からの指摘を責められている・怒られていると捉えずに、素直に受け止め活用できるようになるにはどのように考えたらよいでしょうか。

仕事と自分を切り離す

仕事の目的は価値を創り出すことです。

そのために、仕事や成果物に対してお互いにコメントしたりして、協力して質を高めていきます。

しかし、周りの人からの指摘を責められている・怒られていると捉えてしまう人は下図の青い点線内のように仕事と自分を結びつけてしまいます。

このような人は自分の仕事について指摘をされると、自分の人格や人間性について指摘されているように感じてしまいます。

指摘は仕事に対してのもので、自分自身に対するものではないと切り離して考えると自分も周りも気持ちが楽になるでしょう。

冷静かつ客観的に指摘を取捨選択する

自分の仕事の改善点を複数人に指摘されると「フルボッコにあった」という人がいます。

責められている、怒られているを通り越して殴られていると感じています。

殴られたように感じた指摘を素直に受け取れる人はいないでしょう。

しかし本当に成長できる人は、周りの人から指摘された中で、適切なことは取り入れる、適切ではないものは捨てるということができる人です。

そのためにも、冷静に指摘の内容を把握し、客観的に取捨選択できる力が必要です。

※仕事を始めたばかりの人や経験の浅い人は何が適切か判断できないことが多いので、混乱しないためにも複数人でコメントや指摘をするのではなく一人のメンターをアサインするのが良いでしょう。

完璧な人はいないと割り切る

学生時代にテストで良い成績を取っていた人も、仕事では一人で完璧な成果を出し続けることは難しいです。

仕事では人ひとりではカバーしきれない幅広いジャンルの多種多様な知識、観点、スキル、経験が求められるからです。

一人では満点にならなくても、チームで満点に近づけていくのが仕事です。

チームで仕事の質を上げるからといって、自分の仕事の質をあげるための努力を惜しんでは本末転倒ですが、完璧な人はいないと自分に対して割り切ると気持ちが楽になるでしょう。

コメント・指摘する側の考え方

私は仕事において指摘する側にも、指摘される側にもなりますが、コメントや指摘をする側の考え方も簡単に書いてみます。

人と仕事を切り離す

冒頭のレビュアーの心得（コードを憎んで人を憎まず）のとおり、人と仕事の成果は切り離して考える必要があります。

人と仕事を一緒に考えると、仕事がうまくいかない時ほど「あの人はXXでだめだ」となりがちで、お互いに良い関係の構築が難しくなります。

「人は人」「仕事は仕事」と分けて考えることで、価値の実現に集中して協力する前向きなコミュニケーションができるようになります。

「人を見るな、仕事を見ろ（人の顔色ばかりみるな、仕事に意識を向けろ）」とどなたかが言っているのを聞いたこともあります*1。

自分と人、仕事と人を切り離すという考え方は、アドラー心理学の「課題の分離」に近い考え方かもしれません。

嫌われる勇気―――自己啓発の源流「アドラー」の教え

人は変えられないと割り切る

人が思い通りに動かず、その人の行動を変えようとすると「なんでお前はXXなんだ。XXするべきだ」などといいたくなります。

これは人格を責めてしまっています。

しかし、人は人格や人間性を指摘されると頭に来て反撃します。

また自分を変えてこようとする人には本能的に守りに入るので、守りと攻撃という戦いが始まってしまいます。

このようなときは、イソップ寓話の北風と太陽の話を思い出すと良いでしょう。

人を変えようとするのは「北風」、価値の実現に向けて自分ができることに集中するのが「太陽」です。

人を変えようとして、変わらないとイライラしてしまいます。

根気はいりますが、人を「変える」のではなく「変わる」のを待つ*2と、気持ちも楽になるでしょう。

過去は変えられないと割り切る

チームの誰かが大きなミス（ひどい品質のプログラムなどをつくったなど）をしてしまったとします。

嘆いても責めても、過去は変わりません。

そのようなときは「（ミスをした）過去は変えられない」と考え、未来をより良くしていくことに集中します。

そうすれば、現在への嘆いている状況から、未来に目が向きます。

そして未来に結果が出れば、過去のミスもプラスに捉えられるようになるかもしれません。

まとめ：仕事と人を切り離すメリット

レビューなどの場面で仕事と人を切り離して、仕事の目的（=価値の実現）に集中することで、以下のようなメリットを得られます。

• チームの仕事の質が高まり、価値の実現に近づく

  率直に誤りや改善点を話し合うことで、仕事の質を高めることができる。結果、価値の実現に近づく 　

• お互いに成長できる

  周りの人からの誤りや改善点の指摘を受け入れて、自分を改善することで成長することができる。

• メンタルが楽になる

  自分が責められている、怒られているという思い込みから解放されることで、仕事でへこむことが少なくなる。

同じ言葉でも、人の捉え方によってプラスにもなるしマイナスになります。

人のことを悪く捉えたり、被害者意識をもつと、コミュニケーションに悪影響を与えます。

仕事の目的（=価値の実現)をおさえて、その実現に集中したほうがシンプルに仕事に取り組めて成果も出やすくなるでしょう。

*1:たしかDeNAの南場さんだったと思いますが、Google検索ではみつかりませんでした

*2:スクールウォーズの名言でも「相手を信じ、待ち、許してやること」という名言があります

「独学プログラマー」は、職業プログラマーへの道標

ビープラウドの 清水川貴之( @shimizukawa )さんが監訳、清水川貴之さんと新木雅也さんが翻訳した「独学プログラマー」を読みました。

独学プログラマー Python言語の基本から仕事のやり方まで

書籍の概要

著者のコーリー・アルソフは、大学卒業後(大学では政治学を専攻)、独学でプログラミングを学び始めました。1年の独学後、eBayでソフトウェアエンジニアとして働き始め、そのあともシリコンバレーのスタートアップでプログラマーとして働いています(2017年時点で28歳。インタビュー: "独学プログラマー" コーリー・アルソフ 【PyCharm Blog 翻訳】より )。

「独学プログラマー」は、仕事でプログラマーになったり、独学でプログラミングを学ぼうとする同じ立場の人たちに向けて書かれた書籍です。

仕事で通じるプログラマーになるために、必要な技術的知識(プログラミング、Python、オブジェクト指向プログラミング、アルゴリズム、ツールなど)、プログラミングの心構え、プログラミングを学ぶための情報源、仕事の選び方、面接の受け方などが自分の経験をもとに書かれています。

おすすめしたい人

以下のような方々におすすめします。

• 仕事でプログラミングをできるようになりたいひと
• プログラマーとして仕事を始めたばかりで、さらにスキルを高めたい人
• プログラミングの概念、用語などを復習し、理解を深めたい人
• プログラミングを教える立場の人
• プログラミングの課題がほしいひと

本書の特徴

私が本書を読み進めていく中で感じた特徴をいくつかあげてみます。

説明が簡潔で、プログラミングへの理解を深めやすい

本書を読んでいて一貫して感じたのは説明がわかりやすいということです。

本書では、説明に新しい概念や用語が登場した時には、以下のように書かれています。

XXX(概念・用語。太字で記載)とは〜(説明)です。

そして、概念・用語の説明は章末に用語集にまとめられています(用語集のメリットについては後述)。

たとえば「関数」は以下のように書かれています。

この章では関数について学びます。関数とは、入力値を受け取り、命令を実行し、出力値を返すまでの複合文のことです。

概念や用語の初出は太字で記載されていて、重要なことだと見た目ですぐにわかります。

「簡潔でわかりやすい説明＋章末の用語集」という構成で、初学者も読んでいて迷子にならず理解できるようになっています*1。

用語集で概念を繰り返し復習し知識を定着できる

プログラミングを学ぶ時に、概念や用語などの理解は重要です。

プログラミングでは、それらの概念や用語を活用しながらコーディングしていくからです。

プログラミングを学び始めたばかりでは、プログラミングの概念に対する理解が定着せずに「あれ？これはなんだっけな」と、立ち止まることもしばしばです。

また、基本概念の理解が曖昧なままにプログラミングに取り組み、プログラムが動いたとします。

しかし、なぜ動いているのかを理解していない状態では、プログラミングへの理解が浅かったり、学習の進みが遅くなってしまいます。

本書の用語集を繰り返し確認することで、プログラミングの基本概念に対する理解を深め、知識を定着させることができるでしょう。

文法を学んだ後のステップアップにちょうど良い課題が用意されている

プログラミングの概念や文法を学び、プログラムの実行方法を覚えたあとは、実際に何かをつくってみるのがスキルアップの近道です。

しかし、いきなりライブラリやツールやプロダクトをつくるのもハードルが高いですし、何をつくって良いのかわからないこともあるでしょう。

本書では、以下のようにプログラミング課題を用意しています。

各章末：「チャレンジ」

章内で学んだことを少し発展させたプログラミング課題。学んだ文法で他のことを実行してみる

各Part末：「知識をひとつにまとめる」

Part内の各章で学んだ内容を、組み合わせて実践的なプログラムをつくる

用意されている課題は以下のとおりです。

• Part1：ハングマン

  • 目的：学んだ文法を組み合わせアプリケーションをつくる
  • 内容：ループ、文字列マッチ、リスト、関数などを使い、文字列を予想するゲームをつくる

• Part2：戦争（War)というカードゲーム

  • 目的：オブジェクト指向プログラミングの概念を体感する
  • 内容：Card、Deck、Player、Gameというクラスをつくり、相互に呼び出し合う

• Part3：Googleニュースをスクレイピング

  • 目的：プログラミングの強力さ、便利さを体感する
  • 内容：スクレイピングでWebの情報（Googleニュース）を自動で収集する

本書に用意されている課題は、シンプルでありながら楽しい内容で、かつプログラミングの強力さや便利さを体感できる内容です。

従って、プログラミングの概念や文法を学んだあとの次のステップには、取り組みやすく、かつ実践的な課題ではないでしょうか。

興味のある方は取り組んでみてください。

プログラマーとしての心構えや考え方を学ぶことで職業意識が高まり、仕事の質があがる

プログラマーとして良い仕事をし続けるには、プログラミングスキルや知識だけでは足りません。

少しでも良い仕事をしよう、スキルを高めようという向上心や自分の仕事への誇りが、日々の仕事の質を上げてくれます。

本書では各章のはじめに、プログラマーやプログラミングに関する名言が書かれています。たとえば、以下のようなものです。

• 口ではなんとでも言える。コードを見せなさい。--- Linus Torvalds(リーナス・トーバルズ)
• 神話と伝説の魔法は我々の時代に現実のものとなる。呪文を正しくキーボードに入力すれば、ディスプレイに命が宿り、これまでに見たことがないものが示されるのだ ---Frederick Brooks(フレデリック・ブルックス）

これらの名言を自分の仕事や経験と照らし合わせることで、プログラマーとしての職業意識が高まり、仕事に対する誇りが生まれることでしょう。

仕事としてのプログラミングを強く意識した本書ならではの内容といえるでしょう。

また、23章のプログラミングのベストプラクティスに書かれている以下のような考え方も身につけていくと、プログラマーとしての仕事の質を高めることにつながるでしょう。

• コードを書くのは最終手段
• DRY
• 直交性
• どのデータも1か所で定義しよう
• 1つの関数には1つのことだけをさせよう
• 時間がかかりすぎるなら、たぶん何か間違えている
• 最初に良い方法で実装しよう
• 慣例に従おう
• 強力なIDEを使おう
• ロギング
• テスト
• コードレビュー
• セキュリティ

独学でプログラミングを学ぶために

プログラミングを身につけたい人にとって「プログラミングスキルをどのように学べばよいか？」「どのように仕事で通じるプログラミングができるようになるのか？」ということは大きな課題です。

本書の上記のような特徴により、これらの課題をクリアするための、プログラミングの学び方を本書は示しているといえるでしょう。

また、日本語版の独自コンテンツとして「継続して学ぶために」という補章で、基本知識やノウハウを学んだ上で、さらに独学するために役に立つ読みものや、Q&Aサイト、コミュニティ、学習サイトが紹介されています。

厳選された内容になっているので、プログラミングスキルを高めたい人は参照するとよいでしょう。

PyQとのコラボ

オンラインPython学習プラットフォームPyQに「独学プログラマー」とのコラボコンテンツを用意しています。

書籍内にコラボコンテンツのキャンペーンコードが記載されているので、登録してチャレンジしてみてください(3日間無料です。クレジットカードの登録が必要です)。

PyQ内の独学プラグラマーコラボコンテンツは、監訳者の清水川さん作成です*2。

最後に

現代は何かの仕事をするのに、さまざまな知識、技術が必要です。

それらの全てを人に教わることはほぼ不可能です。

したがって、プログラミングにかぎらず、知識や技術を独学で身につけていくことが求められます。

そして、独学するための書籍や情報は、インターネットや書籍を始めとしてここ数年で増えてきました(全ては無料ではありません)。

したがって、知識や技術が独学で身につくかどうかは、その人が本気でやるかやらないかにかかっているのではないでしょうか。

独学でプログラミングを身につけ、職業としてプログラマーになった経験をもとに書かれた本書は、知識や技術を独学で学ぶという視点で読んでみても新たな発見があることでしょう。

また最初に書きましたが、本書は説明が簡潔でとても読みやすく且つわかりやすいことが特徴です。

著者がそのように心がけたことももちろんあるでしょうが、監訳者、翻訳者、そしてレビューに関わった方々の力も大きいのではないでしょうか。

「独学プログラマー」は、仕事でプログラミングができるようになりたいという人への道標となるおすすめの１冊です。

*1:説明は簡潔でわかりやすいのですが、説明が足りない、もう少し理解に説明が必要と感じた箇所については、書籍内でも提示されている他のサイトや、他の文書などを参照したほうがよいでしょう

*2:※いちばんやさしいPythonの教本が、表紙のそでにキャンペーンコードが書かれていて見つけやすかったのに対し、独学プログラマーのキャンペーンコードはPyQとコラボコンテンツと関連する章内に書かれています。是非とも書籍を購入して探してみてください（ヒント：アルゴリズム）。

アジャイル時代のモデリング〜匠の冬祭り2018 in 関西 その3

2018年2月2日(金) に開催された「匠の冬祭り2018 in 関西」に東京からサテライト枠で参加しました。

• （その1）
• （その2）

it-takumi.connpass.com

第三部は、平鍋健児さんの「アジャイル時代のモデリング」がテーマでした。

以下はまとめです。

平鍋さんがアジャイルに向かった経緯

「仕様書通りにつくりました、検収してください」はつまらないので、アジャイルの方に向かった

デジタルビジネスとアジャイル開発

ミッション・リスク分割型ビジネスとウォーターフォール型開発（従来型）

• 市場→(市場分析)→ビジネス→(発注)→IT
• ビジネスとITで綱引きになる

ミッション・リスク共有型ビジネスとアジャイル型開発

• 顧客開発と製品開発
• ニーズとシーズ、どっちが先か
• スタートアップ（新事業）→シーズとニーズの中間を成長させる
• リーンスタートアップ

アジャイルは３周目

• (1)エンジニアがいかに良い仕事をするか
• (2)少人数で製品をつくりだす（リーンスタートアップ）

• (3)先進的大企業が、社内スタートアップを立ち上げる

  • アジャイルを大企業に（スケールアップ）は失敗する。予算と承認の壁

GEのデジタル化

• データを使って資産の生産性を上げる
• 重要スキル：サイエンス、セキュリティ
• 重要課題：スキルのある人を集めて難題を解かせる
• GE Growth Value(成長) → GE Belief(信念)
• コーディングは全てのイノベーションの素：読み書きそろばんと同じ

開発の型による違い

• ウォーターフォール型開発

  • 壮大な伝言ゲーム

• アジャイル型開発

  • 組織横断で、アントレプレナーシップを持っている人たちを参画させる

    • 企画、品質、開発、UX、Analyticsなどを招き入れる。コタツモデル

  • 今までのアジャイル型開発は開発にフォーカスが当たっていた

ここからの資料は以下。

Modeling in the Agile Age - JP from Kenji Hiranabe

ITのモデリング

• 成果物：コードしか残っていない
• INPUT(User Requirements)→活動→OUTPUT(WORKING Software)

• "While code is the truth,is is not the whole truth." by Grady Booch

• BDUF(Big Design Upfront)

• NDUF(No Design Upfront) ：一貫性がない、拡張性に悩まされる
• "Let's keep the modeling baby but throw out the bureaucracy bathwater."（大事なものまで流してしまうな。いらないものは流してしまえ）

なぜモデルを使うのか？

人間はイメージの方が概要をうまく掴むことができる

KEEPするもの

• Architecture
• Domain Model
• Key Use Cases

これらが無いと、コミュニケーションの時間を無駄にしてしまう

Temps

• Casual Modeling

• Class, Sequence Diagrams

• UMLに写真を入れる。味気ないから

• Key Usecases

  • ユーザーから見たシステムの代表的なつかいかた
  • 誰がユーザーで何が嬉しいのか

チームが大きくなった時（Scaling)

• 小さなものをやっつけてからチームを分割する
• 人づてで知識を伝える

• チームに新しく人が入ってきたら、モデルを使ってウォークスルーで伝達する。

  • 紙で渡した時点で、2〜3割の情報になる
  • "Model to have a conversation"(会話のためのモデル)

問題と解とモデル

• 簡単な問題は、モデルをつくらなくても問題→解に進めることができる
• 複雑な問題は、問題→分析モデル→設計モデル→解へと進む

感想

アジャイルソフトウェア開発宣言には、ソフトウェア開発の価値として「包括的なドキュメントよりも動くソフトウェアを」と書かれています。

この文を拡大解釈し、ソースコードこそ最高のドキュメントという考えのもと、ドキュメントや図（モデル）を軽視する人が時々見かけられます。

しかし、ソースコードから全てを読み解き、システムの全体像を捉えるのは時間がかかりすぎてしまいます。

平鍋さんの発表では、モデルの良さ、ソースコードの良さを活かしながら、人が最大に価値を創り出せる新しいアジャイル開発のかたちを感じさせてくれました。