2日目も現地行ってきましたー。
A7）テスコンNOW
資料はこちら。PDF直リンク注意。
テスコン出たことないけど参加してみました！
テスコンの目的や形式などの説明ののち、実際に過去優勝や準優勝をされたチームの中から属性の違う3チームが語ってくれました。
- パナソニックITSさん
- キヤノンイメージングシステムズさん
- 考えるアシカさん
です。
みなさんテストの技術力向上などの目的で最初は参加されて、企業から出てらっしゃる2社のみなさんは毎年若手が参加する的な形で代々参加されているようでした。
テスコンに参加することで、個人としての学びやスキルアップがあるのはもちろん、とくにパナソニックITSさんやキヤノンイメージングシステムズさんでは社内でのテストエンジニア育成の仕組みの中にテスコンが取り込まれているようでした。このへんがコンスタントにテスコンで結果を出されている組織力に効いて来ている印象を受けました。
パナソニックITSさんはとくに「テスコンやテスト設計自体を楽しくやろうぜ！」感がとても出ていた点がすごいいいなーと思って見てました。またキヤノンイメージングシステムズさんは業務と比べてある程度制約が少なく、また時間をかけられる状況でテストの腕を磨くよい機会にされているようです。考えるアシカ（梁川）さんはテスコン優勝をきっかけに色々なチャンスにつながったそうで、そういった道が開ける感もまた魅力だなと聞いてました。
あとこれは個人的な感想ですが、今回のセッションって優勝経験者ズラリみたいな状態だったので、聞いていて正直「他の人はどうなんだろうか」という思いもあったんですよね。勝ったから、あるいは常勝軍団的な会社に居るから、という目線でのコメントでもあるよなぁと。 そんななか、最後の方に田辺さんがおっしゃっていた「結果にこだわりすぎる必要はない」「まず参加して、体験してみるべし」というのがセッション全体をグッとまた良くしてくれた感がありました。そうですよね、出ることに意義があるんですよね、と。たぶん参加してもほとんどの人は敗退して終わるわけなので、そこにも確かに得るものがある、という話があってよかった。
- テスコンの目的
- 教育機会の提供
- テストへの興味を高める
- 技術を競って高める
- 形式の説明
- バグ出しコンテストではない。設計成果物の良さを競う
- 審査基準の配点もあるよ
- それぞれ属性の違う方たちをパネリストとし、それぞれの話を聞いてみる場
- テーマ１ コンテスト参加のきっかけ
- パナソニックITS
- 神田さんはJaSSTでテスコンを知った。当時JaSSTの１セッションとしてテスコンが行われていたので
- 北海道のチームが面白いと思って、当時いた九州でチーム組んでとんこつラーメンでやってみた
- テスコンの参加者、他チームはよきライバルみたいな感じ
- その後、テスト全くやったことない人がチームに入ってくることがあって、教育することになった
- どうせ教えるならテスコンだ！と思い、また後輩たちが出るようになった
- 下口さんは2024年度、U30に参加
- 当初目的はスキルアップ
- 担当業務だといろいろな制約が多いが、テスコンであれば制約が比較的少なくやれるのが良い
- キャノンイメージングシステムズ
- 会社が新潟にあって新潟に関連するチーム名で出ている
- テスト設計の技術力向上の一貫で参加
- 自分たちの実力を試したい、と思って2016参加（榎本さん
- 毎回参加するたびに、キャノンイメージングシステムズさんがよい成果を出されている
- 考えるアシカ
- やながわさん、ソロで一般参加
- テスト対象が、これまで扱ったことのないものだったことが面白そうだと思い参加
- 自分の実力を確認したいと思っていたのと、転職直後で若干余裕があったことで自分を追い込むために参加
- 伊藤）ストイックや・・・
- テスコンの資料を見ていると学びがある
- 伊藤）わかるofわかる
- 自分もなにかしら一例を作れるといいなと思った
- ある年の審査員コメントで「内部構造が考慮できてない」とあったので、そういうものを自分で示したいと思った
- テーマ２ 取り組み、工夫点、成果
- パナソニックITSさん
- テスト活動の擬◯化、などテスト活動を楽しみたかった
- バグのモグラ化
- モグラを除いたら彼岸花を植えていくメタファ
- 伊藤）もうわけがわからないよ（褒め言葉
- 下口さんから
- コンセプトは引き続きテスト設計を楽しむこと
- 擬きつつき化
- 優勝したことでテスト技術者として自信になった
- 顧客からの称賛もあり関係性がさらによくなった
- キヤノンイメージングシステムズさん
- 榎本さん
- 当時テスト要求分析を進めていても発散して大変だった
- 一旦区切りをつけてテスト詳細設計に進んで、また要求分析に立ち戻って、と進めた
- 途中でコンセプトがブレることもあるので、そうならないように工夫した
- 若手が自由に取り組んでくれるように榎本さんがサポートしている
- 相談を受けたときに書籍を教えたりとか
- 前回参加メンバーをレビュワーとすることで、成果物の質も上がるしレビューする側のスキルも高まる
- 伊藤）めっちゃいいやん・・・
- 田辺さん
- 当時の自分は楽しむ、は抜けていたかも・・・とパナソニックITSさんの発表聞いて思った
- 基本に忠実、でいこうと思ってやってた
- テストベースに忠実に、と思って３色ボールペンで読み込みをしていた
- U-30のキヤノンイメージングシステムズさんの取り組みは他の手本になっている
- 考えるアシカさん
- テスト要求分析の工夫点
- RDRA
- システム要件定義のフレームワークなので、テスト要求分析に特化したものではない
- 各レイヤーをつなぐことで関係が明らかになり、ドメイン知識をもっていないSUTの理解に役立った
- 大規模なシステムのテストをする際、どこから手をつける？問題
- とかっかり難しいですよね
- RDRAを使うことでシステムを一貫して理解できる。この点有効だった
- AI活用
- LLMの活用
- 意地悪漢字、応用HAZOPガイドワードをLLMに与えて、多様なテスト要求を獲得することを目指した
- 内心、ChatGPTが流行ってきてたので「これは乗るしか無いやろ」と思った
- LLMは単純に言えば続く単語を高精度に予測するもの
- ソロ出場の欠点である、複数人でブレストができないことを補うことができた
- 最初はハルシネーションが大きすぎて「新人でもそんなことせんやろ」というリターンが多かったりもしたが、全く無駄だったわけでもない
- DiscordのQ&A
- テスコンは楽しそうだけど、自信ないなぁと思ってしまう。みなさんはどう乗り越えた？
- 下口さん
- 最初は苦労したが、皆と話せる機会が多く、実業務にフィードバックできることも多く、だから続けられたと思う
- 審査員から見て、テスコン長く続けてきて各チームの成果物こう良くなった、コミュニティ全体としてこうレベルアップしたみたいなポイントある？
- おーだんさん
- 仕様だけを見てテスト設計する、とかやりがちだが、優勝するような人たちはそこに閉じずにやってる
- 大きなものに対してどう全体的にテスト設計するか、といった視点
- 型が一定できてきた
- テスコンと実際の業務での成果物は一緒ですか？優勝チームの成果物を見るとすごい負荷が高そうで、実務では辛くね？
- 神田さん
- 実務とテスコンは完全に一緒ではない
- 実務はいろんな制約がある
- テスコンは自由なので楽しさはある
- が、やりすぎると終わらない
- 梁川さん
- テスコンていうとテストアーキテクチャみたいなキーワードが出てくる
- 既存システムをフルリプレースする仕事をやったとき、テストアーキテクチャの考え方はすごく良かった
- テーマ３ コンテストに出て変わったこと・効果
- パナソニックITSさん
- 神田さん
- 育成コンテンツとしてすごくいい
- 社内テスコンをやろうとしている。研修として。
- 下口さん
- お世話係になるが、楽しさを伝えられたらいい
- キヤノンイメージングシステムズさん
- 田辺さん
- 参加当時は初めてつかう技術ばかりで大変だったのを覚えている
- 反面、実際に使える場でもあるので、効果があった
- 自分が主体となってなにかをやりきる経験を積めるのはメリット
- 当時新人だったのでリーダー経験もなかったし
- 達成感や自信がつく
- 榎本さん
- 教育効果が高いと思っている
- 新人のころはテスト技法の研修をうけるが、使い所がわからないことがある。それがテスコンで経験できる。
- 業務ではスピードが求められ、テスト設計に十分な時間をかけられないこともある
- 他チームの成果物を見るだけでもいろいろな知見を得られる
- 生成AIを活用するなど、新しい技術が出てきたとしても、テスト設計の考え方が大きく変わることはないと思っている。なのでそうした普遍的な部分を学ぶのは価値がある。
- 考えるアシカさん
- 審査員から多角的なコメントがもらえて、自分の苦手を把握するきっかけになる
- 変化：キャリア形成
- テスコン優勝、をきっかけに名前をしってもらう
- ソフトウェア信頼性工学のカンファレンスで登壇するきっかけにもなった
- テスコンをトリガーにして活躍の場を広げる
- さいごに一言ずつ
- 神田さん
- 仲間が増えるよ
- 技術を高めあおう
- 下口さん
- テスト設計もりあげていきたい
- 榎本さん
- 社外からいろんなフィードバックをもらって、批判もあったが、それらも業務に役立ってる
- 田辺さん
- あまり結果にこだわらずに、まずは参加して体験してもらえたらいいと思う
- 参加せい！といった上司はねぎらってやってくれよな！
- 梁川さん
- さっき言い切っちゃった
- 社外でこういうつながりができたのは良かった
- 良い場なのでぜひ参加して
- テスコンの未来
- ソフトウェアテストってワクワクする技術なんだぜ！
- テストなんてつまらない、と思ってほしくない
- 大段さんの思うテスコンの未来
- AI駆動開発が進んでいく中でのスキル教育やキャリア形成への活用
- ソフトウェアテスト技術開発のチャレンジ・ノウハウ共有の促進
- テスト設計力＋AI駆動開発ツール活用力
- 競技としてテスト実行・テスト完了活動も含める
- おーだんさんが駆け抜けてフィニッシュ
A8）テストをどこまでやるの？価値とリスクから読み取りコンセンサスを得るための方法
前半の吉川さんパートを聞きました。
会場の後ろのほうで聞いていたのでスライド無し音声のみで、理解浅いところもあるかもしれません。
もともと「テストどこまでやるの？」という問いに対して、自分なりの答えがあまり出せておらず・・・ QA界隈のちょっと前の流行り言葉で言えば「チームで納得感を共有できたらOK」みたいな説明をしちゃってた気がします。
ただ吉川さん須原さんというガチ勢がどんなことを考えているのか知りたくて参加しました。
テストをしているとモヤモヤすることがありますよね？とい吉川さんの問いかけ。 かけたコストのぶんだけ効果が出ている？価値提供してる？といった問にズバッと答えるのは皆難しいですよねおそらく。
このモヤモヤは、テストがプロダクトの価値を直接上げる行為ではないからだ、と考えたそうです。
またQAはテストをすることやプログラム修正を行って他に影響が出ることの「リスク」の面に注目しがちですが、それらによって得られる価値も考える必要がある、ということで、労力・リスク・価値を考慮してテストを行う必要がある、という話でした。しかしこれらは単純比較ができないので、それぞれを価値、ここではお金に換算して比較をしよう、という発想。
リスクというとリスクベースドテストかな？と思いますし、信頼度成長曲線などとも似ている発想のように思われますが、それらとは違う考え方、ともおっしゃっていました。
スライド待って見返したい。
- みなさんテストやっててモヤモヤすること無いですか？
- コストかけるんだけど、そのぶんだけどんだけ効果があったの？をちゃんと示せてない
- 品質向上に貢献してるのはわかるけど、ほんとうにプロダクトの価値に貢献したの？
- テストやQAが価値提供を遅らせたりしていない？
- そもそもテストどこまでやれば
- なぜモヤモヤするのか
- テストはプロダクトの価値を上げる行為ではない、直接的には
- テストのアウトプットはプロダクトそのものではない
- 蛭田さん：QAは作家ではなく編集者みたいなものだ
- 間接的に関わっている存在
- なんのためにテストしているか、についていい定義がない
- ので定義づけしてみた
- 異論あると思うけど！
- 我々としては・・・
- テストとは、見えていないリスクを明らかにする行為
- リスクがなければテストしなくていい、ともとれそうだが、リスクがないなんてことはないのでは
- テストをどこまで、のふたつの意味
- 終了するかどうか
- リリースするかどうか
- あえて分けているのは、たとえば組み込みとかだと量産品に製品を書かなければならないが、書きながら最後のテストをしているといった事例が実際にあるから
- テストの労力と減らせるリスクを天秤にかけている？
- 価値を考えずに提言したことがあった、という失敗談
- QAとしても、リスクだけではなく価値も考えないといけない
- 修正やリリースの判断
- 労力
- リスク
- 価値
- しかし上記はものさしが違う
- 労力：時間
- リスク：影響度・発生度
- 価値：お金
- ものさしが違うので比較しにくい
- なんらかの形でお金に換算する
- リスクの構成要素
- 予測リスク
- 見えているリスク
- 対応したもの
- 除去したもの
- 許容したもの
- 未対応のもの
- 見えていないリスク
- 残留リスク
- ベイズ推定を使って欠陥数の割合を考えて、テストケース数から予測の総欠陥数を出した
- 信頼度成長曲線と何が違うの？
- 信頼度成長曲線はバグだけ
- こちらは価値が入っている
- 重大な欠陥があるとリスクが上がり、軽微なものが多いとリスクが下がるようになっている
- リスクベースドテストとは何が違うの
- リスクベースドテストはリスクをもとにテストの優先順を考えていて、こちらはROIを考えている
- リスクの計算に実績値を使っているので信頼性が高いはず
- 究極的には、予定していたテストを品質が良いので途中で打ち切る、ができたらいいと思っている
D9-1）チーム内連携強化のためのGQMフレームワークに基づいた不具合情報可視化の取り組み
不勉強なのでGQMフレームワークを知らず、不具合情報可視化というあたりが業務に役立ちそうだな～と思って参加しました。
ｷｬｰﾖｺﾋﾟｰｻｰﾝ・・・ってブログに書けよ！としらみ（@a_shirami）さんに言われたので書いときますね。
セッション内容に移りますと、横田さんが2024/2に入社されて1年くらいの間の取り組みのひとつとして、不具合情報を可視化してチーム内でコミュニケーションできるようにした、とのことでした。
不具合情報、というのはテスト実行時に登録した不具合チケットから得られる情報のことで、これまではチケットを個別に開かないと改修箇所や修正確認完了しているかどうかなどが確認できなかったそうです。 また、チケットを起票したひとと対応したひとしかその内容を把握しておらず、チームの他の方には充分共有されていないなど、このあたりに問題意識があったようです。
そこで、どのような不具合情報を収集すべきかを定め、それをチケットのテンプレに反映させ、皆に入力してもらって可視化できるようにした、というお話でした。
このときにGQMという目標達成度を測定するフレームワークを使った点が工夫ポイントだったようです。
お話伺う限り、QAとしてのとても真っ当な改善取り組みのような印象でした。なので2年後とか将来ここからどうなったのか、もまた聞いてみたいところです。とくに、たとえば不具合の質が変化したとか、数が減ったとか、そういう定量結果は知りたいですねー。
- ｷｬｰﾖｺﾋﾟｰｻｰﾝ
- しらみさんが隣でイキイキしている中セッションがスタート
- 自己紹介
- 横田さん、ZENKIGEN、QAエンジニア
- 2024/2に入社
- インプロセスQAの立ち位置
- 開発体制
- SaaS
- PdM/デザイナー/ソフトウェアエンジニア/QA（横田さん）
- QAゼミ一期生
- 採用DXサービスや目標設定支援ツールを提供している
- 発表概要
- 質問
- 不具合登録後、その情報活用できてますか？
- こんなふうに活用したい！等の想いはありますか？
- 今回は登録された不具合情報を分析・共有することでチームコミュニケーションを活性化する具体的な事例を紹介します
- 定義
- 不具合情報
- テスト時に登録を行った不具合チケットから得られる情報
- 概要
- 不具合情報可視化の取り組み
- コミュニケーション強化を目指した
- 有効性確認のためにアンケートを実施した
- 問題と背景
- 発生していた問題
- チームで不具合情報に基づくコミュニケーションができておらず共通の認識を持てていなかった
- 例
- 優先度が高い不具合は何
- 原因は何
- スケジュール内で完了できるの？
- 不具合情報は起票者と修正対応者のみ把握で、他のメンバーには十分共有されていなかった
- チケットのイメージ
- 手順が今の動作、期待値、そのほかコメント欄など
- 不具合チケットを開かないと改修箇所や修正確認完了が確認できない
- コメント欄に書かれちゃってるから
- 対応の流れ（スライドに図）
- １．テスト実施
- ２．不具合事象が出る
- ３．起票
- ４．一覧に格納
- ５．Devが確認と修正
- ６．修正内容がでる
- ７．チケットに書く
- ８．内容を起票者が確認
- 起票者と修正者以外も確認できるといい
- 問題点
- ①議論の目的が定まっておらず、不具合チケットから必要な情報が抽出できていない
- ②不具合情報に基づく進捗の共有や改善のアイデア出しができていない
- 課題と対策
- そもそもこれらの問題、なぜ起きてるの？
- ①のほう
- 収集すべき不具合指標が定まっていない
- 収集方法が定まっていない
- 不具合指標：不具合情報から傾向などを分析するために抽出するデータ項目
- ②のほう
- 不具合情報が可視化できていない
- 全体としてどうなのか
- コミュニケーションできない
- ①に対する課題
- チケットから収集すべき不具合指標を定義
- GQMフレームワークを活用し、不具合指標を体系的に定義
- 収集ルールを決める
- 手順書作成
- チケットテンプレ設定
- 指標に基づくデータを入力
- GQMご存知ですか？→少数が手を挙げた
- GQMとは
- 目標達成度を測定するフレームワーク
- Goal Question Metric
- 健康を維持するための生活を実践する、という例でGQMをみてみよう
- 伊藤）GQMいいな、QAチームのミッションに対するKPI設定時に使えそう
- ここから本題に戻る
- Goal：テスト実施内容に認識誤りが少ない状態であるか
- Question：修正対応せずにクローズしている不具合はあるか
- Metric：不具合総数の内クローズ不具合割合
- Metirc：クローズ不具合数の内対応しなかった（ページ変わった）
- 各種不具合指標に対して入力項目を作成した
- ダッシュボードを作成して不具合情報を可視化した
- デイリーミーティングで見て、リリースまでに直すべきチケットの数を把握し、リソースの調整判断がスムーズに
- ふりかえり会で見て、不具合の多かった機能を特定
- 対策の有効性確認
- 取り組みを実施したチームと未実施のチームにアンケートを取った
- 伊藤）アンケート以外に、実際に障害や不具合がどう変わったとか、リリースまでのスピードがどうなったとか、そのへんはどうなんだろう
A10）「真の学び」が未来を拓く～成長するエンジニアのマインドセット ～
招待講演は、成長するエンジニアのマインドセットのお話でした。若干好き嫌い分かれるかもしれないな～と思って聞いていましたが、自分は多くの点で納得が行くといいますか、そうだよね大事だよねと共感しながら聞いてました。
エンジニアを見ていると、輝き続ける人と残念な人がいるよね、という話からスタートしました。輝き続ける人はそのままの意味で、残念な人というのは能力ややる気があるのに成果に結びついていないもったいない人を指すそうです。じゃあその差はどこにあるのか。マインドセットだね！という話でした。
成長するエンジニアのマインドセットとして
- 心の声に耳を傾ける
- 実践こそすべて
- 師という存在
- 組織で卓越性を追求する
- 内なる成長を目指す
の5つを挙げて、それぞれについて詳しく見ていく、という流れでした。
自分が肝だと思ったのはとくに2番目の実践こそすべて、のところでした。情報・知識・学びそれぞれの意味の違いから、得た情報をもとに学ぶためには反復練習が不可欠であること、何度も実践をすることで「真の学び」が得られるということ。本読んで満足してちゃダメだよ、という話をされていました。これは確かにそうですね。
ただ自分のスタンスと違うなーと思ったのは、目の前の課題解決に役立つ情報を効果的に仕入れて実践する、というのは効率的に見える一方であまりおもしろくないなとも感じました。もしかしたら講演者の古畑さんの意図とは違うかもしれません、この受け止め方は。
自分としては、目の前の課題解決に役立つ情報はそれはそれでインプットするのですが、それだけではなくて普段から幅広くなんでもかんでもインプットをしておくことによって、いざ課題が出てきたときにあれもこれも色々試せる状態の中から「これ」というのを実践してみる、というのが良いのではないかなーと思うんですよね。課題に対して対応方法を都度学ぶ、というのは遅延評価学習法っぽい一方で、「じゃあどんなアプローチが有効そうか」というそもそも情報として仕入れる対象を思いつかないはずなんですよ。普段のインプットがないと。
みなさんJaSST22Tokyoの招待講演を思い出してほしいんですけど、
20220311 「世界に普及可能な日本発の高品質サイバー技術の生産手段の確立」 (登 大遊, IPA, 2022)
のP46にある
これ。このイメージの「学び」のほうがなんとなく私はしっくりくるんですよね。
再三になりますが、古畑さんはたぶんこういう「幅広くインプットする」ことを否定はしてなかったと思うので、受け取り方の問題な気はしてます。
【追記】 帰ってきて考えたら、そもそも古畑さんの発表自体、色々な分野の引用が含まれていたので幅広くインプットするのを否定しているわけはないですね。両立します。 【追記おわり】
基本この講演でおっしゃってたことは 全部正しい と思うので、自分ごとに落とし込んで行動変容するのを、聞いた人が各自頑張らんといかんよね～という感想です。自分も成長しよう。師を見つけよう。
- 今やっているのは、開発現場に実際入って技術支援
- いまどきの言い方で言うと伴走支援
- 釣り方を教えているのが仕事
- 今日のキーワードのひとつが問題解決
- 途中で会社生活の危機があり、そこから自分の意思で動くようになった
- これまでの講演から大事なポイントをまとめている
- 輝き続ける人と残念な人
- 輝き続ける人は、与えられた環境の中で徹底的に価値を見出していける人
- 残念な人は能力もやる気もあるのに何かが間違っているために結果がいまひとつになってしまう、もったいない人
- この差はなんだ？エンジニアのマインドセットの視点から
- エンジニアのマインドセットは成長の源泉
- 氷山モデルで下にあるのは、気構えや意識＝マインドセット
- ここに輝くのと残念になるのとの差がある
- 成長するエンジニアのマインドセットは、保有能力を向上させ、圧倒的な行動（結果）の差となって表れる
- 伝えたいこと
- 成長するエンジニアのマインドセット
- 心の声に耳を傾ける
- 実践こそすべて
- 師という存在
- 組織で卓越性を追求する
- 内なる成長を目指す
- 会社生活の危機
- 開発現場でうつ病で倒れて、4.5ヶ月自宅療養
- 当時、エンジニアとして研修所に出向になったが、これは一線から退くという意味だった
- 人生終わったと思った
- 極度の焦燥感
- 発病そしてどん底へ
- 過剰労働や上司との考え方相違で、不眠・同期・焦燥感
- 復帰後研修所への転籍を決めた
- しかし病状は良くならない、玄関出られない
- 日中も暗い、自殺願望
- 追い打ちとして他の病気も発症
- 研修所に大学同期が講師として来所
- 何をやってもうまくいかない、空回り
- これまでの人生何だったのか・・・・と思う
- 運良く現場復帰の奇跡
- 焦燥感からの開放
- ツルゲーネフの詩の引用をもらった
- なんとかしないと→まあいいか
- 自分の既成概念を取り払う
- 会社に長くいると考え方に染まって自分を見失う
- 会社でえらくなるのがいいこと？
- 自分何したかったんだっけ
- 会社人間としての自分の価値観を捨て去る
- そして症状が快方へ
- 自分はどうしたいのか、それはなぜか
- やったこと
- 内省
- 勉強
- このときデンソーに清水吉男さんがコンサルとして来てくれた
- そして実践し、結果につながる
- 2011年世界ソフトウェア品質会議でBest Paper賞
- 役に立たなかったことは、勉強だった
- 逆に役に立ったのは内省と実践→結果
- 全く役に立たないという意味ではない
- また運が良かったのは南山大学の青山先生のところで博士になった
- 逆境からの学び
- １．心の声に耳を傾ける
- ２．実践こそすべて
- ３．師という存在
- 心の声に耳を傾ける
- みなさん忙しいしなかなか毎日大変だと思う
- 自分の人生に背を向けない
- 徹底的に自分と向き合うのってなかなかできないですよね
- でも大事
- 今の自分から逃げないこと
- 目標と目的を言葉にする
- 目的とは何か？＝本当のゴール
- その目標はなんのために達成するのか
- 達成するとどんな影響力があるのか
- 何を成し遂げようとしているのか
- これらがはっきりわかった状態を「目的意識を持っている」という
- 目的意識があると何がいいのか
- 燃え尽きることがない。がんばれる。
- 目標達成型でなく目的達成型に
- 実践こそすべて
- 知識の体系的な反復が能力を向上させる
- 情報、知識、学び
- 情報：書籍や論文などに書いてあるもの
- 知識：情報を仕事や成果に結びつける能力
- 学び：情報を知識に転換するプロセス
- 学び＝情報獲得＋反復練習（実践）
- 学びには反復練習が不可欠
- 自分の外にある情報はそのまま実践されることはない
- 内側に取り込まれた情報だけが実践に結びつく
- 「師」という存在
- 生きる方向性を示し、心の手当をしてくれる
- 「師」のここでの定義
- 自分が心からこうなりたいと思える人
- 自分の専門分野で努力を重ね、成長し続ける人
- 他者（部下・弟子）の成長を本気で喜べる人
- 古畑さんの師のひとりはお父様の古畑友三さん：５ゲン主義の提唱者
- 「師」から学ぶ基本姿勢
- 是と非を見分け、非をひっくるめて受け入れたうえで長所を見ていくことが大切
- 組織で卓越性を発揮する
- 組織の目的と人の成長
- 組織とは社会的な道具（ドラッカー）
- 組織の目的には、人を成長させること、が含まれる
- 組織における人の成長は、知識の習得ではない
- 問題解決が人と組織を成長させる
- 現場が成長する仕組み
- トヨタ生産方式はカンバンを使った製造ラインの内容でも、単なるリーンの話でもない
- 自他の成長を促進する人材育成のシステムである
- 求められる人材
- 企業競争力に貢献できる人材、つまり現場の総智・総力による問題解決を達成できる人材
- 次世代を担う人材
- 真の問題を発見し、解決できる人材
- 組織の総知・総力を引き出せる人材
- 時代の変化に対応できる人材
- 競争力の向上には、卓越した技術・スキルが求められる卓越性の追求
- 開発現場の実際
- 対応すべき課題が山積み
- 課題に対して技術・リソースが不足している
- とにかく毎日できることに必死に取り組んでいる、刹那的達成感
- 学びの本質
- 技術者の学びとは
- 問題解決を通して自分の行動を変え、結果を変えるもの
- 卓越性の追求
- ひとができないことを、自分はいくつできるか
- 問題解決と技術習得
- 問題解決は職場での実践
- 技術習得は自分の時間での自己啓発
- ループを回せ
- 行動変容
- 学びは真似ることから始まる
- 自分より優れたものを徹底的に真似る＝「真に似せる」
- 真似るとは？
- Step1：すべて似せた状態をつくる
- これまでと違う考え方を受け入れる（いいとこ取りではない）
- これで気づくことがたくさんある
- 確証バイアスを捨てる
- Step2：行動でなく考え方を真似る
- どういう意図で、何の意義があってこうしたのか
- 自分自身で答えを発見する
- 社内の常識を疑い、社外の常識に従う
- ↑これを習慣化
- 自分自身で答えを発見する
- 行動して自分のものにする
- 社内の常識を疑い、社外の常識に従う
- 解決策、必ずある
- 社外発表をする意義
- 技術のベンチマーク
- 技術戦略の検討
- 技術動向の把握
- 自分自身を育てる
- 歴史に学ぶ
- 明治維新
- 一流の経営者に学ぶ
- 松下村塾が大事にしたもの
- 教育理念
- 学問とは「人としてどうあるべきか」を学ぶこと
- 成長する土壌を整え、学び続ける
- 松下村塾の教訓が３つあった
- 技術者の成長は（ページ間に合わず）
- まとめ
- 成長するエンジニアのマインドセット