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

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

アジャイル時代のモデリング〜匠の冬祭り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回開催されている

デザイン思考とシステム思考の融合、匠Methodの成り立ち〜匠道場に参加(2018.1)〜その1

2018年1月25日(木)に匠道場*1に参加してきました。

今回は、師範の萩本順三さんが、第1部ではデザイン思考とシステム思考の融合、匠Methodの成り立ち、第2部は、価値起点思考を二元論で説明するというテーマでお話されました。

f:id:haru860:20180128214216p:plain

第1部は、デザイン思考とシステム思考の融合と、匠Methodの成り立ちがテーマでした。

デザイン思考とシステム思考の融合

デザイン思考とシステム思考

  • デザイン思考:直感的、感性的な発想を重視する思考法

    • ここでの「デザイン思考」はデザインのプロセスのことではない。
    • (参考)WikiPediaの定義: デザイン思考(でざいんしこう、英: Design thinking)とは、デザイナーがデザインを行う過程で用いる特有の認知的活動を指す言葉である
  • システム思考:論理的な構造を重視する思考法

意志・表現、活動

  • デザイン思考=表現(右脳的なもの)
  • システム思考=活動(活動に行き着くまでの論理展開:左脳的なもの)
  • 表現と活動を行き来し、洗練させる

描く力と作る力の両立(匠Think)

  • 片方が得意な人は片方が苦手なことが多い
  • 両方を活かしながら、思考していくことが重要
個人的メモ

(個人的な問い)両方ができると、何がよいのか?

(個人的な回答)

以下の2つの思考を行き来することで思考が洗練される。

  • (感性→ロジック)直感で考えてロジックで証明する→パナソニック創業者の松下幸之助氏の考え方(直感で考え、ロジックでサポートする。そして決断する)
  • (ロジック→感性)ロジックで考えたことを実現したとして、人として嬉しいのか?自分たちが取り組むべきことなのか?情熱を持って取り組み続けることができるのか?を思考することができる
  • 感性を活かすことでチームや自分の個性を活かした思考が生まれてくる(感性は人ごとに異なるので)→自然に差別化される(ロジックだけで考えるとどうしても他の人や競合と似てきてしまう)
  • 感性だけだと実現性に乏しくなる。アイデアは良くても説得力がないので、最後の最後(稟議など)で人を動かしにくい(最初は「いいね」と言ってくれる)

匠Methodの成り立ちと誕生〜オブジェクト指向から匠Methodへ

27歳でIT業界へ

  • 27歳でIT業界に入った
  • スティーブ・ジョブズが開発したNEXTSTEPを購入。その考え方に影響を受けた(最先端のオブジェクト指向)
  • 素人の視点があったからこそ、ソフトウェア工学に疑問を持てた

    • オブジェクト指向を客観的に見ることができた、本当に役に立つのか

自分の考え方を手法としてカタチにしたい

目指していたこと
  • 複雑なものをシンプルな構造で説明する。それこそがソフトウェアエンジニアの仕事の本質である

    • 複雑性をシンプルで共通的な本質として解明することができる
    • 究極の本質を見抜く
  • 人の新たな思考法を生み出す

オブジェクト指向の探求

  • モノに指令を出す(Smalltalk)
  • 構造主義

    • 認知の世界
    • 言葉(シニフィアン:記号表現、言葉、音声) - 概念(シニフェ:記号内容、概念、イメージ)

      • 言葉が概念を指している
      • 言葉は同じだが、概念が関係者間でずれている場合がある
      • 概念は言葉で構成されている。分解していくと認知がずれていくことが分かる
      • 概念を言葉で分解していくことで詳細化、具体化に役立つ
  • ものごとを徹底的に探求したい→最初の頃は、目の前の仕事に必要のない余計なことまで考える、全体を理解しないと納得しない、できない社員だった

  • 要求や価値は曖昧である。それをカタチにできると思った

常に考えていたこと

  • 曖昧性を排除すること

    • 言葉の指す概念を明確にすること。曖昧性をなくして皆で同じものを見る
  • 本質面での抽象理解を促進すること

    • 本質的な言葉を共有し詳細を排除する。ヒトは本質さえ理解すれば、詳細を知らなくても強い結束力を持てる
    • オブジェクト指向設計は納得理解できた。オブジェクト指向分析は怪しいと思った
    • ソフトウェア開発は見えないものだらけ(恐怖感だらけ)

      具体化、詳細化、構造化が見える化ではなく、抽象化・本質を捉えることが見える化である

  • 人の心を工学として取り扱う

    • 海外から入ってきたオブジェクト指向方法論は、構造化手法の焼き直しだと感じた
    • 自分で方法論をつくろうとした→オブジェクト指向方法論Drop→苦しんだ(5年後にやっとかたちになった)
    • システム思考に限界を感じた

      • 論理的に書けば書くほど使えないものになる→論理的美の虚像
      • プロフェッショナルの仕事で使えるものをつくりたかった
      • 感性的な発想を組み込んだ。人が感じるものや感じたことをカタチにする
  • 正しい勘違いは大切にする

    • 守破離の守を終えた後、自分のレベルではできないことを「できる」と思う勘違い
    • 「できる」と正々堂々という→自分を伸ばすことにつながる
    • やらないとチャンスはない→やれば経験値があがる

豆蔵設立、要求開発の方法論へ

豆蔵でビジネス戦略の見える化に取り組んだ

  • 仮説的な戦略からIT手段へと考える→論理的美の虚像の排除につながる

    • 2000年代前半当時のモデリングの流行は、動的モデル、静的モデルを分類することだった(モデリングの対象は全て手段)
    • 要求開発では、以下のビューで表現した

      • ビジネス戦略
      • 業務プロセス
      • サービス(ビジネス/システム ユースケース)
      • 情報(データ)
    • 手段が広がらないようにアプローチした

一定の効果があったが、以下のような問題点があった。

  • 戦略が絵に描いた餅になる(戦略の効果を考えていないため)
  • 戦略とは何かを考えた。

    • Howの勝ち組がWhatになっているだけ
    • 戦略を疑わないといけない
    • 「戦略と実現の線上にしか価値は存在しない」(匠Think)
個人的メモ
  • Howの勝ち組がWhatになる流れ

    • どこかの企業で成功した事例が、戦略のベストプラクティスとして研究される
    • 他の企業で、価値を考えずに戦略のベストプラクティスを真似する
    • 価値や目指す方向(ビジョン)を考えずに導入したり、自分たちの文化に合わないことをしているので、価値を生み出せず失敗する

特許庁プロジェクト

  • 総務省の技術顧問、内閣官房のGPMO補佐官時代→ Publickeyの記事
  • 日本の大規模システムの実態を見ることになった
  • 日本のユーザー企業はIT活用ができないと感じた
  • 業務設計、フローチャートの大量生産

    • 役人はプロジェクトだと思っていない。無責任に言い放つ
  • ユーザーの要求を待ち続けるIT業界(SIer)の業務慣習

  • 手法から作ることは文化

    • 文化を形成したい→匠Method
  • 守りのスキルばかり蓄積され、日々の仕事に忙殺される

匠Methodの誕生

価値をデザインし、価値記述の要素から戦略を創り出す

  • 価値-戦略-手段(手段にはお宝が埋まっている)
  • 価値への着目

    • 戦略を定義する前に、価値をデザインすることから始めた
    • 価値を書くことは手段の証明になる
    • 価値を演出する、デザインする
    • 価値を描いたあとに考えた戦略は、絵に描いた餅が少なくなる(価値で検証された戦略)
    • 価値とは何かを考え、匠Methodの新たなモデルとして採用した
  • 一人の脳から出てくる感性を信じ続ける

  • 世の中の考え方を学び、咀嚼する
  • → 自分なりの考え方を組み合わせて生み出す
  • 感性は持って生まれたセンスではなく訓練で磨けるもの

    心が震える経験を積む→感性を磨いていく

感想

オブジェクト指向設計から始まり、要求開発、そして価値や人の感性までつながった匠Methodは萩本さんの20年以上の探求から生まれています。

20年以上の思索のなかで少しずつ組み立てられ、深められてきた思考を、匠Methodを通じてシンプルに使えることはとても価値があることではないでしょうか。

第2部は価値起点思考を二元論で説明する です。

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

2018年

2017年のテーマは、昨年2月のブログに書いたとおり「攻め」でした。

shacho.beproud.jp

2017年のテーマを「攻め」にした理由は、2016年に「守り」に入った反省からです。守りに入った自分は*1、経営で過去と同じ失敗を繰り返し、脆くも崩れていきました。

f:id:haru860:20180102091551j:plain

「攻め」には、自分の意識改革が必要でした。

その意識改革とは「過去」についていっさい考えないことです。

過去を思い出すときは「あのときはこうしておけば良かった」という後悔の念であったり、「あの行動は良かった」などと余韻に浸っている時間が大半です。

「振り返り」といえば聞こえは良いですが、後悔の念や余韻に浸ることは、過去に縛られることであり、未来のためにほとんど役立ちません。

過去のことを考えなくなった分、現在や未来のことを考える時間が増えました。それにより「やるべきことは未来をつくることだけだ」というシンプルな気持ちがうまれ、自分の行動・判断のスピードにつながりました。

見習うべき「攻め」の姿勢として、将棋の羽生善治永世七冠を思い出します。

羽生善治さんは公式戦やタイトル戦の重要な場面で、あえて今まで指したことのない冒険的な手を指すそうです。

そのようにリスクをとる理由は、手堅い手を指した目先の勝利よりも、新しい手を指すことによる経験の獲得と進歩、そして将棋の進歩のためです*2

「リスクなくして成長なし」

自分と会社の進歩、そして世の中の進歩のために、今年も攻めていきたいとおもいます。

*1:「守る」と「守りに入る」は大きく違います。

*2:すべての手が冒険的ではなく、手堅く指す場面も多いとはNHKの番組でおっしゃってました。

2017年登壇・発表まとめ

2017年は、社外*1で13回お話しする機会がありました。

特に夏の1か月は、すべて異なるテーマで5回の登壇機会がありましたが、無事乗り切ることができました。

発表の機会をつかって自分のノウハウや知見をスライドでまとめておくと、自分の振り返りや知識の共有などに使えて有用です。

以下にスライドとブログをまとめておきます。

Baseball Play Study 2017 冬 野球振返りスペシャル(BPStudy#124):2017/12/19(火)

匠塾大LT忘年会:2017/12/11(月)

ブログ

shacho.beproud.jp

MOONGIFTオフ会#1:2017/11/21(火)

ブログ

shacho.beproud.jp

BPLL#14:2017/10/31(火)

BPStudy#120:2017/8/31(木)

ブログ

shacho.beproud.jp

DDD Alliance:2017/8/30(水)

ブログ

shacho.beproud.jp

流山高校講義:2017/8/25(金)

ブログ

shacho.beproud.jp

みんなのPython勉強会#27

ブログ

shacho.beproud.jp

Developers Summit 2017 Summer:2017/7/28(金)

ブログ

shacho.beproud.jp

匠道場 6月開催 Q&A:2017/6/22(木)

shacho.beproud.jp

要求開発アライアンス5月定例会 パネル:2017/5/30(火)

redajp.connpass.com 匠の要求開発里帰り 討論会「価値主導によるビジネス最前線で活用するメソッドや開発手法の効果と進化の方向性」にパネラーとして登壇

BPStudy#116 :2017/4/24(月)

Baseball Play Study 2017春(BPStudy#115) :2017/3/28(水)

某大手SIer 社内勉強会 :2017/3/7(火)

Developers Summit 2017 :2017/2/16(木)

ブログ

shacho.beproud.jp

匠女子会 :2017/2/8(水)

Community Manager Summit 2017 :2017/1/23(月)

ブログ

shacho.beproud.jp

*1:社内向け勉強会やイベントを除いている。BPStudy,BPLLは社外の方が参加するので、社外に含めている