「匠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"(会話のためのモデル)

問題と解とモデル

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

感想

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

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

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

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

開発現場を漸進的に改善する〜匠の冬祭り2018 in 関西 その2

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

it-takumi.connpass.com

第ニ部は、三菱電機の細谷さん、権藤さんの「開発現場を漸進的に改善する」がテーマでした。 （その1はこちら）

以下はまとめです。

改善活動の悩み

• 現場が協力してくれない、メンバー乗り気ではない、否定的。
• 活動が定着しない、元のやり方にすぐに戻る
• やめることができずに仕方なくやっている

など

チェンジマネジメント

そんなときは、チェンジマネジメントを学ぶ

tatsu-zine.com

変化への恐れ

変化に恐れを抱くのはなぜか？

変化はバランスを崩す要因となり得る→バランスが崩れるのが怖くなる

変化の恐れをコントロールする

• 変化への恐れに着目しコントロールすることが重要
• Fearless Change：アイデアを広める方法をパタン・ランゲージとしてまとめた書籍

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

改善活動の形態

• チームの一員：自分の作業を改善、自分の所属するチームを改善（ボトムアップ)
• リーダー・マネージャー：自分の組織を改善するトップダウン
• 組織外の支援者：他の組織の改善を支援するトップダウン（不安定）

チームの一員としての改善

試行錯誤の回転を早く、最初から大きく実施しない。うまくいってる感を出す

進め方

※()内の番号:Fearless Changeのパターン番号

• 1.やってみる(17)
• 2.ステップバイステップ(3)
• 3.小さな成功(2)
• 4.振返りの時間(5)

仲間を巻き込む

• 雑談等の会話で反応を見る
• 興味を持ったらデモしてみせる
• 反応があったら一緒にやってみる

進め方

• 1.エバンジェリスト(1)
• 2.イノベータ(16)
• 3.個人的接触(20)
• 4.やってみる(17)

2,3人を巻き込めたらチームに広げるチャンス

変化への恐れへの壁

• 変化の恐れを克服するには、効果を出すだけでは充分ではない

効果を出すだけではなく取り組みについて組織でアピールする

• チーム内外に対して効果を様々な機会でアピールする
• 定例会のような場で取り組みを何度も報告
• チーム外の報告会で発表する

アピールの進め方その1

• 1.勉強会(25)
• 2.体験談の共有(32)
• 3.種を撒く(22)
• 4.達人のレビュー

アピールの進め方その2

• 1.身近な支援者(35)
• 2.定期的な連絡(24)
• 3.便乗(21)
• 4.成功の匂い(40)

アピールの進め方その3

• 1.著名人を招く(27)
• 2.外部のお墨付き（12)
• 3.正式な推進担当者(29)
• 4.感謝を伝える(18)

リーダー・マネージャ：組織を改善する（トップダウン）

基本的な考え方は、チームの一員としての実施と同じ

• 0.予備調査
• 1.やってみる(17)、ステップバイステップ(3)、小さな成功(2)、イノベータ(16)
• 2.振返りの時間(5)
• 3.アーリーアダプター(11)

組織の壁にぶつかる

そんなやり方は認められない→(ここを超えるのが最も難しい)→実績が出ているので良い方法だけど導入は難しい→段階的に導入

組織の壁を超えるのに大事なこと

• 取り組みのアピール
• 信頼貯金
• 相手が信頼している人からのポジティブな評価

組織の壁を超える進め方その1

• 1.個人的な接触(20)
• 2.恐れは無用(46)
• 3.懐疑派代表(44)

組織の壁を超える進め方その2

• 1.便乗(21)
• 2.外部のお墨付き(12)
• 3.達人を味方に(14)

組織外の支援者

支援先が抱える問題や原因を共有しないまま新しい方法を導入してもうまくいかないことが多い

• 目的を共有するために、匠Methodを使っている
• 目的を共有したら手段を提案していく

※使うパターンは、リーダー・マネージャと同じ

事例1:テストプロセスの導入

見通しの良いテストの段階的詳細化の手法

テストプロセス手法構築時

• 大学との共同研究として実施

  • 著名人を招く(27)：
  • イノベータ(16)

  • 現場の第一線のメンバーが検討メンバーとして参画

    • 正式な推進担当者(29)

手法適用初期段階

• テストスキルが高くモチベーションが高いメンバーを支援して適用開始

• アーリーアダプタ(11)

• 成果を社内で定期的に開催される発表会で発表

  • 便乗(21)

• 社外発表(JsSST)

  • 外部のお墨付き(12)

手法適用拡大段階

• 段階的な適用を支援

  • ステップバイステップ(3)

• エントリ層の適用支援

  • 小さな成功(2)

• 組織の従来からある改善活動目標への取込

  • 便乗(21)

事例2:スクラムによる業務改善

施策開始の前段階

• 作業の見える化をテーマ
• 物理的なカンバンを使用
• 三菱社内のカンバンは、教育が行き届いていて、マネージャーが一番上、年次ごとに上からメンバーが順に並ぶ

# パターン

• ステップバイステップ(3)
• 小さな成功(2)
• 便乗(21)
• ふりかえりの時間(5)

施策開始時

• スクラムの研修：社外講師招聘
• スクラムマスタ任命
• 小集団活動のテーマとして継続実施

# パターン

• 著名人を招く(27)
• 正式な推進担当者(29)
• 便乗(21)
• グループのアイデンティティ(13)

施策実施時（当初)

• 小さな成功(2)
• 場所重要(36)
• 空間を演出する

施策実施時（停滞期)

• 身近な支援者(35)
• 正式な推進担当者(29)

施策実施時（停滞期からの脱出)

• 身近な支援者(35)
• 正式な推進担当者(29)
• 協力を求める(6)

• 外部のお墨付き(12)

  • やってみる(17)

• 施策実施時（定着へ)

  • やってみる(17)
  • ステップバイステップ(3)
  • 小さな成功(2)
  • アーリーアダプタ(11)
  • 感情を伝える(18)
  • 個人的な接触(20)

事例

問題点

組織の支援活動で、原因を共有しないまま、新しい方法を導入しようとして、うまくいかないことが多く発生していた

課題

• 匠Methodによって、支援活動の目的を共有する
• 目的を共有した上で活動内容を具体化・実施→Win-Winの関係を築く

取り組み

ステークホルダー、価値分析モデルを関係者で、それ以外のモデル(価値デザインモデル、要求分析ツリー)は自部門のみで実施（全てをやるのは時間がかかる)

• 関係者全員で支援活動に対する要求の合意ができて、手戻りを削減できた

• 依頼元の要求の全体像が明確になり、新たな支援活動につなげることができた

• 課題

  • 自部門でモデル作成→依頼元レビュー→修正　に時間がかかった

それぞれがもっている技術領域が異なる

• グループとして期待されていることを、何をするべきかを合意する
• モチベーション向上

感想

なにか新しいものを組織に導入するときには、３つの障害があります。

それは「選べない」「使いこなせない」「維持できない」の３つです。これらの障害があるために、人はその場にとどまり続け、少し変わったとしても元に戻ってしまいます。

今回の発表では、Fearless Change のパターンをもとに、改善活動をどのように組織に導入し、維持していくかという話でした。

話の中でも、組織の従来からある活動に便乗したり、外部のお墨付きを得たり、著名人を招いたりして「出来ている感」を徐々に社内外にアピールし、使いこなせている感を出し、モチベーションを上げ、浸透させ維持していくところが特に参考になりました。

その3へ

匠Methodの書籍はこちら

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

匠Methodによるデジタルトランスフォーメーション〜匠の冬祭り2018 in 関西 その1

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

it-takumi.connpass.com

第一部は、匠Business Placeの田中豊久さんの「匠Methodによるデジタルトランスフォーメーション」がテーマでした。

以下はまとめです。

時代の流れ

• 1960年代：メインフレーム
• 1980年台：パーソナルコンピュータ
• 1990年台：インターネット
• 2000年代：ソーシャル
• 2010年代：BigData,IoT、AI時代

デジタルトランスフォーメーション

「ITの浸透が、人々の生活をあらゆる面でより良い方向に変化させる」(WikiPadiaより)

デジタルに頼るだけで良いのか？

• 「人間」が問われる時代

• 匠Methodとは

  • 自分を見定めるメソッド
  • ビジネスでの合意形成
  • 新たな価値観の注入
  • みんなの「うれしい」を創造する
  • 技・人・心

技

• 知識体系

  • 価値→未来（価値検証）
  • 要求→未来（要求実現）

  • 価値から考える

    →プロジェクトの早い段階で不要なものを取り除くことができる

• その未来の価値は？未来から価値を考える

• 要求の価値は？要求から価値を考える
• その施策はなんのため？行動→要求→価値とトレースして考える

何のためにモデリングをするのか？

• 見える化の3つの価値

  • 発見
  • 合意形成
  • 継続的活用

• 作ったモデルはどのように活用されるか？

  • チームの合意形成
  • 自分たちは何のために集まっているのか？腹落ちするゴールをつくる

モデルの種類

価値モデル

心を刺激するモデル

• 価値デザインモデル

  • 強みをデザインする
  • 自分たちは本当は何をしたいのか
  • 中長期的に考える

• 価値分析モデル

  • ステークホルダー、嬉しいこと、目的
  • 嬉しいことをデザインする
  • 目的は価値を提供できるか

要求モデル

安定のモデル(納得感)

• 要求分析ツリー

  • ロジックツリー、抜け漏れの発見
  • ビジョンから業務までの構造化
  • アイデアの粒度の整理
  • 優先度付けの根拠

活動モデル

• ゴール記述モデル

  • 要求分析ツリーからの具体化
  • プロジェクトプラニング
  • 評価設定

人

• 匠Methodを使うことによって思考が変わる

  • 常に価値を問うようになる

    • 仕事で外すことが少なくなる
    • モチベーションが高くなる

• 心が強くなる

  • 自分を大事にしながら、社会のために頑張ろうという気持ち→心が強くなる
  • 未来を実現したいというモチベーションにつながる

デジタル時代と匠Methodの関係

• 人は死ぬが、機械は死なない
• 機械は知識の継承が簡単

• 機械は人を超えていく

  • 機械は生きない
  • 自分は何がしたいか？を問うことが大事

  • デジタル時代には価値を瞬時に捉えられる人が強い

    • 実現への道はAIが考えるかもしれない

  • 誰かを喜ばせたいというのは人間の根源的な欲求→これからの時代も大事なこととして残る

匠Methodで何が出来るか？(事例)

• 匠Method+介護=M3ケアポータル

• ArchBRANDING

  企業ブランディング、製品ブランディングを活動にまでつなげる

萩本順三さんによる補足

• オブジェクト指向、要求開発のモデリング：心を刺激するものが少ないと感じていた
• 心を刺激するモデルをつくると、モデルは絵に描いた餅ではなくなる。これが価値：楽しい（ハラハラ・ドキドキ)
• ハラハラ・ドキドキ(デザイン思考)と納得(システム思考)の間を行き来してモデルを洗練させる

感想

デジタルトランスフォーメーションにより、さまざまなものがデジタル化し、人々の生活が年々変化してきています。

そして、スマホの普及、IoT、アクセス解析データなどのビッグデータをプログラムが分析することにより「正しい答え」を導き出される流れはこれからも加速していくでしょう。

プログラムが答えを出してくれるようになる中で「有限かつ貴重な時間の中で、自分たちは何に取り組むべきなのか」を考えることが重要になっていきます。

人の時間よりもお金が重要だった時代、つまり「お金＞人の時間」の時代から「人の時間＞お金」の時代にますますシフトしていくからです。

この仕事の根源を考えることは、人の役割であり、データで導き出すものではありません。

自分たちが取り組むべきものを見つけることができる、それが匠Methodの重要な価値のひとつではないでしょうか。

その2へ

匠Methodの書籍はこちら

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