ビープラウド社長のブログ

株式会社ビープラウドの社長が、日々の思いなどを綴っていきます。

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

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

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

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

書籍の概要(ストーリー)

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

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

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

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

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

おすすめしたい人

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

本書の特徴

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

現場あるあるが面白い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最後に

3月で仕事が山積みです(今も)。

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

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

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

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

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

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

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

f:id:haru860:20180318130248p:plain

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

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

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

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

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

f:id:haru860:20180318145745j:plain

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

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

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

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

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

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

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

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

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

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

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

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

仕事と自分を切り離す

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

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

f:id:haru860:20180318135733p:plain

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

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

f:id:haru860:20180318130639p:plain

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

f:id:haru860:20180318130736p:plain

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

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

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

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

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

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

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

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

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

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

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

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

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

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

人と仕事を切り離す

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

f:id:haru860:20180318130910p:plain

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

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

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

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

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

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

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

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

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

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

  • お互いに成長できる

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

  • メンタルが楽になる

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

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

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

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

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

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

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

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

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

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

  • 作者: コーリー・アルソフ,清水川貴之監訳,清水川貴之,新木雅也
  • 出版社/メーカー: 日経BP社
  • 発売日: 2018/02/24
  • メディア: 単行本
  • この商品を含むブログを見る

書籍の概要

著者のコーリー・アルソフは、大学卒業後(大学では政治学を専攻)、独学でプログラミングを学び始めました。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冊です。

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

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

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

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

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

it-takumi.connpass.com

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

f:id:haru860:20160710192748j:plain

以下はまとめです。

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

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

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

ミッション・リスク分割型ビジネスとウォーターフォール型開発(従来型)
  • 市場→(市場分析)→ビジネス→(発注)→IT
  • ビジネスとITで綱引きになる
ミッション・リスク共有型ビジネスとアジャイル型開発
  • 顧客開発と製品開発
  • ニーズとシーズ、どっちが先か
  • スタートアップ(新事業)→シーズとニーズの中間を成長させる
  • リーンスタートアップ

アジャイルは3周目

  • (1)エンジニアがいかに良い仕事をするか
  • (2)少人数で製品をつくりだす(リーンスタートアップ)
  • (3)先進的大企業が、社内スタートアップを立ち上げる

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

GEのデジタル化

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

開発の型による違い

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

    • 壮大な伝言ゲーム
  • アジャイル型開発

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

      • 企画、品質、開発、UX、Analyticsなどを招き入れる。コタツモデル
    • 今までのアジャイル型開発は開発にフォーカスが当たっていた

f:id:haru860:20180216005727p:plain

ここからの資料は以下。

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

問題と解とモデル

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

f:id:haru860:20180216010651p:plain

感想

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

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

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

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

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

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

it-takumi.connpass.com

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

f:id:haru860:20180216001343j:plain

以下はまとめです。

改善活動の悩み

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

など

チェンジマネジメント

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

tatsu-zine.com

変化への恐れ

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

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

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

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

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

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

  • 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/01/30
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (16件) を見る

改善活動の形態

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

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

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

進め方

※()内の番号: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の関係を築く

取り組み

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

  • 関係者全員で支援活動に対する要求の合意ができて、手戻りを削減できた
  • 依頼元の要求の全体像が明確になり、新たな支援活動につなげることができた

  • 課題

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

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

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

感想

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

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

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

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

その3へ

匠Methodの書籍はこちら

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

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

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

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

it-takumi.connpass.com

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

f:id:haru860:20180215233318j:plain

以下はまとめです。

時代の流れ

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

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

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

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

  • 「人間」が問われる時代
  • 匠Methodとは

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

  • 知識体系

    • 価値→未来(価値検証)
    • 要求→未来(要求実現)
    • 価値から考える

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

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

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

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

  • 見える化の3つの価値

    • 発見
    • 合意形成
    • 継続的活用
  • 作ったモデルはどのように活用されるか?

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

モデルの種類

価値モデル

心を刺激するモデル

  • 価値デザインモデル

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

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

安定のモデル(納得感)

  • 要求分析ツリー

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

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

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

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

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

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

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

  • 人は死ぬが、機械は死なない
  • 機械は知識の継承が簡単
  • 機械は人を超えていく

    • 機械は生きない
    • 自分は何がしたいか?を問うことが大事
    • デジタル時代には価値を瞬時に捉えられる人が強い

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

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

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

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

萩本順三さんによる補足

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

感想

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

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

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

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

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

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

その2へ

匠Methodの書籍はこちら

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

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

価値起点思考を二元論で説明する〜匠道場に参加(2018.1)〜その2

匠道場*1の第ニ部は「二元論」で匠Methodを説明するというテーマでした。

第一部はこちらです。

萩本順三さんの資料は以下です。

二元論

世界や事物の根本的な原理を背反する2つの概念で説明する。

1. 表現(Design)-活動(Action)

暗黙知

  • 意志

    当事者たちの想い、自信と誇り、語りの力、生きがい・やりがい・社会的責任

形式知

人の考えはカタチにしなければ伝わらない。

  • 表現

    (匠Method:ステークホルダ、価値デザイン、価値分析):デザイン思考

  • 活動

    (匠Method:要求分析ツリー、ビジネスコンテキストフロー、ゴール記述モデル):システム思考

参考情報

表現/活動のデザインの説明は、BizZineの連載「意志をブランドにして伝えるArchBRANDING」の第二回『「企業意志」を起点に魅力的なブランドを作る「ArchBRANDING」』のP3に説明がある(翔泳社IDの登録必要あり)。

個人的メモ
  • プロジェクトが目指す方向について、ビジョンをつくる「ビジョン構築力」がこれからの時代は求められる。なぜなら、AIやデータを使って何をしたら1から10、1から100にすることは効率的にできるかもしれない。しかし自分たちの感性を活かしながら何を目指していくかを考えたり、0から1を生み出すのはAIの仕事ではなく、人の主な仕事になるからである。(キャッチコピーをつくるのはAI化されるかもしれない:電通のAIコピーライター「AICO」、その実力はいかに?:1度に2万案のクリエイティブを作成。キャッチコピー案をAIがつくり、ABテストが自動で実施されキャッチコピーが決定される。)

    • プロジェクトの関係者間の認知はずれていることがしばしばある。言葉やモデルで認知を明示することにより、認知のずれを防ぎ、最短距離で目指す方向に向かうことができる。これは仕事の効率化をはかろうとするなかで最も重要なことである。(第1部の「構造主義」)を参照のこと)
    • 参考:ビジョンの考え方:良いビジョンとは
  • 情報が溢れるなかで、自分たちの活動のコアを把握し、短時間(20秒など)で説明できるスキルが求められる

2. ニーズ思考-シーズ思考

  • ニーズ思考

    • 何を必要とされているか
  • シーズ思考

    • 自ら突き上げる価値観
  • ニーズだけ捉えても、何も生み出せない(アンケート結果をもとに活動を決めるなど)

  • 要求分析ツリーでニーズとシーズを結合させる。結合させないとバランスが崩れる
個人的メモ
  • なぜ自分たちがその仕事に取り組む必要があるのか?が問われる時代(シーズ思考)
  • 「シーズからニーズを描く」

3. 価値ストーリー-プロジェクト目的

価値をデザインする(価値ストーリー:価値記述)→ブランディング

↓(価値を目的につなげる)

↑(目的の価値を検証する)

プロジェクト目的(下心)をデザインする

ニーズとプロジェクト目的(潜在的シーズ)のマッチング(ニーズとシーズの最初のマッチング)

個人的メモ
  • 要求分析ツリーで、価値デザインモデルのシーズと、プロジェクト目的(潜在的シーズ)をマッチさせる。目的を潜在的シーズと考えておくと、マッチさせるときのコンフリクトが少なくて済む
  • 価値分析モデルで目的を抽出/設定するのはファシリテーターのスキルが求められる場面なので、目的を潜在的シーズと捉えると考えやすい。

4. 現在価値-未来価値

  • 現在価値

    • いま現場で問題・課題となっていることを達成しようという認識
  • 未来の価値

    • 中長期的に獲得すべき価値を目指す意識
個人的メモ
  • 「育てながら勝つ」思考

5. 現意識と新意識

  • 未来は2つの観点で思考する
  • 現意識

    • 現在の延長で考えた未来価値
  • 新意識

    • 新たにビジネスを変える・変わることを前提で考えた未来価値
  • どのような比率でどのタイミングで新意識を入れ込むか

    2〜3割がた新意識を入れる

  • 未来を考える時に、現意識になっていないかを問う

個人的メモ
  • 「新意識」はシフトする思考が必要
  • シフトするには、リニア思考、線形バイアス(現状のまま、未来も進むであろうと予想する人の特性)を排除し、[ブレークした姿をイメージする]

6.7.8 戦略(What)-実現(How)

  • 戦略と実現をセットで考えることを基本とする。実現を戦略から切り離して放置しない
  • 「戦略と実現の線上にしか価値は存在しない」(匠Think)
  • WhatとHow:すべてをWhatとHowで説明する(シンプルに考えるため)

    • シンプルにするため、Why,Whoは意図的に入れていない
  • How指向

    • 戦略指向:Howの手探り
    • How指向:Howからの突き上げ(イノベーション)
    • Howのチューニング:業務レベル、ITレベルでHowを試行錯誤する→価値を生み出す
    • 手段は貴重。人は手段からスタートしている。それが本質→ Howへのこだわり(エンジニア思考)
個人的メモ
  • 最上位のWhat(ビジョン)の中にWhyの要素は包含される
  • Whoはステークホルダーモデル、Whom(誰にどのような価値)は価値分析モデル
  • エンジニアはHowの専門家。価値を実現するHowを常にウォッチし、活用するスキルを身につけることで価値創造につなげるのがエンジニアの役割

9. 外の価値-内なる活動

Drop
  • 外:コンポーネント活用の視点(使う人)
  • 内:コンポーネント提供の視点(作る人)

二元論の考え方はオブジェクト指向方法論Dropから始まった。

# (1)ビジネスの視点で開発プロダクトの作業を叩き洗練可
  • 外の価値:ビジネス価値・戦略、オペレーション
  • 内なる活動:IT要求、開発

    • 要求開発四象限
    • 企業デザイン(NDS:要求開発宣言ArchBrandingにもつながっている)
    • 外に宣言する→行動のプレッシャーになる→早く実現する
# (2)見える技から身についている技を叩き洗練化する
  • 外の価値:見せる技→内なる活動:身についている技

    • 実装に困っている→ずっとやっている
    • 最初に本を書いた時に感じたこと→印象が悪かった→優秀だと思われた(見せかけの印象)
  • 見せる技とはなにか?

    • すこしだけToBe寄りの見せる技(今できていないことも含めて書く)
    • 身についた技を捨てる(洗練化)
    • 内(具体的な技)は流れが変化が速い。外(見せる技)は、流れがゆっくりしている
    • ゆっくりな流れのなかで洗練していく(一流に向けて変えていく)
    • 自分をブランディングする
# (3)その手段のどんな価値が誰に必要とされているものなのか?
  • 外の価値:価値
  • 内なる活動:要求、実現
個人的メモ
  • 活動は、人に届いてはじめて価値になる。

    • 情報過多の時代にはシンプルな外の価値を明示し、拡げていくマーケティング力は必須である
  • 外の価値は、継続的な内なる活動から溢れ出るものによって形成する

10. ミクロ(自分)-マクロ(社会)

  • 「ミクロ・マクロ同一活用の原則」:匠Methodのフィロソフィー
  • ミクロもマクロも匠Methodの知識体系のもとに、同じ方法で思考することができる
  • プロジェクトデザイン(マクロ)→プロダクトデザイン(ミクロ)
  • 葛飾北斎:円だけでフラクタルに絵を描く→世界の本質を表現

    • ミクロ、マクロの原則も同じ
  • オブジェクト指向のMVCモデルを知った時は本物と感じた(大きいものも小さいものも同じ方法で考えることができる)

  • キャリアは社会視点をもってデザインするべき

    • 志を高めることにより、自分をレベルアップする
    • 社会に自分をつなげることによって、自分が引き上がる
    • 自分をブランド化する
    • 社会視点でビジョンを描く
    • 自分、組織、顧客、社会を串刺しにする視点
  • 自分と社会を行ったり来たりする

  • AIがつくりあげた社会で良いのか
  • 社会を考える時に、自分が問われる
  • 相反するものをつなげて、バランスを取る
個人的メモ

参加者からの質問

価値を描いた時に、優先すべきもの、やるべきものがぶつかることがあると思う。そこはどのように考えたら良いか

萩本さんの回答

  • ファシリテーターの力が問われる

    • その場の合意感、納得感を以下につくりだすか
    • コタツモデル(ビジネスオーナー、現場担当者、システム開発の立場がお互いに膝を突き合わせて話し合う)がそのためにある

私なりの回答

コタツモデル、その場の合意感、納得感に加えて、以下のように考える。

ステップ1. ステークホルダーへの共感(ステークホルダーの痛み、ステークホルダーの嬉しいこと)をイメージ・把握する
ステップ2. 三方良し、四方良し、五方良しの施策を考える
ステップ3. 各施策の連携で、全体として価値のバランスを取る(全体最適)
ステップ4. 『制御可能で制御価値のあるものから手を付ける』(匠Think)
  • 7つの習慣の関心の輪、影響の輪で考える

    • 自分たちが影響を及ぼせて価値を最も生み出せるものから進めていく
    • 影響の輪を徐々に拡げていく

f:id:haru860:20180128183029p:plain

  • 戦略思考で考える

    • 全てを一度に実現するのではなく、順番に実現していく
    • 例:利益アップを最終的に実現したい場合に、コスト削減をまず実現し、次に売上をアップするというように進める(コスト削減→売上げアップの順が正しいということではない。これは会社の特性による)

    • コスト削減と売上げアップの両方を同時に狙う「全てが重要」という思考は戦略ではない

f:id:haru860:20180128184029p:plain

全体の感想

書籍のビジョナリー・カンパニーで「ORの抑圧をはねのけ、ANDの才能を活かす」という挿話がある。

「一流の知性と言えるかどうかは、二つの相反する考え方を同時に受け入れながら、それぞれの機能を発揮させる能力があるかどうかで判断される」とし、ビジョナリー・カンパニーは、このANDの才能を持っている企業であると述べられている。

上記のように、匠Methodは、二つの相反する考え方を成り立たせる仕組みが組み込まれているので、匠Methodで思考すれば自然にANDの才能を発揮できるようになるでしょう。

f:id:haru860:20180129073618j:plain

匠Methodについて書かれた書籍はこちら

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

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

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