Slide 1
Slide 1 text
ここはウォーターフォール市、アジャイル町 第一章
業務改善の問題地図２丁目 読書会
無力感
2020/12/26
インフラ勉強会
amarelo（アマレロ）
Slide 2
Slide 2 text
自己紹介
コーヒー焙煎人兼エンジニア amarelo（アマレロ）
twitter：@amarelo_n24
※アマレロ：ポルトガル語で「黄色」
特技：コーヒー豆焙煎
資格：AWS認定クラウドプラクティショナー
ソリューションアーキテクトアソシエイト
Microsoft Azure Fundamentals（AZ-900）
好きなコーヒー：ブラジル ブルボンアマレロ
好きなお菓子 ：ブルボンのお菓子全般
アルフォート、ブランチュール、シルベーヌ、チョコリエール、ルマンド・・・
Slide 3
Slide 3 text
主な登壇履歴
インフラ勉強会（2019年8回、2020年1回）
・インフラエンジニアのためのコーヒー入門（2019/1/31）
・沼への誘いLT大会：アルフォートのすすめ
・技術書同人誌との出会い・執筆LT（2020/3）
など
外部勉強会（2019年7回、2020年2回）
・ #ssmjp：ITエンジニアへのコーヒーのすすめ（2019/10）
令和になってようやくSSD換装をした話（2020/12/18）
・エンジニアの登壇を応援する会：鈍行列車の旅をやってみた話
・ラクス：はじめてのトラックボール（2020/10）
など
Slide 4
Slide 4 text
書籍紹介
ここはウォーターフォール市、アジャイル町
ストーリーで学ぶアジャイルな組織のつくり方
著者：沢渡あまねさん、新井剛さん
出版社：翔泳社
URL：
https://www.shoeisha.co.jp/book/detail/97847981
65387
Slide 5
Slide 5 text
書籍紹介
業務改善の問題地図
~「で、どこから変える?」~進まない、続かない、
だれトク改善ごっこ
著者：沢渡あまねさん、元山文菜さん
出版社：技術評論社
URL：https://gihyo.jp/book/2020/978-4-297-
11639-2
Slide 6
Slide 6 text
今回の読書会の目的
「無力感」は、ここは「ウォーターフォール市、アジャイル町」第一章
と業務改善の問題地図２丁目共通のテーマです。
両書籍を合わせた読書会で、「無力感」の原因や立ち向かい方について
考察したいと思います。
Slide 7
Slide 7 text
アジェンダ
１．ここアジャ第一章のストーリー要約
２．ハマナ・プレシジョンの無力感の原因は何か？
（１）認証基盤運用チームの４つの問題
（２）業務改善の問題地図２丁目を元に考察
（３）無力感の深掘り
３．無力感に立ち向かうためには？
（１）アジャイルになる
（２）改善の風土をつくる
４．まとめ
Slide 8
Slide 8 text
１．ここアジャ第一章 ストーリー要約
Slide 9
Slide 9 text
登場人物（第一章に登場する人物のみ）
◆ハマナ・プレシジョン株式会社 認証基盤運用チーム
相良 真希乃（３３歳）：主人公 チームリーダー
森岡 俊平 （２７歳）：５年目の技術系社員
原野谷 渉 （４１歳）：カジマ・システムサービス インフラエンジニア
笠井 美香 （３２歳）：ハドソル（※）ヘルプデスクリーダー
※ハマナ・アドバンスト・ソリューションズ
◆アジャイル勉強会
中須賀 葵 （？？歳）：北欧雑貨通信販売企業に所属するスクラムマスター
Slide 10
Slide 10 text
認証基盤運用チームの現状
認証基盤チームはインシデント、クレームだらけ。
真希乃はチームの現状を知ることにしたが…
何かいい方法は無いものか…
美香：電話対応に追われる。
諦めの態度。
渉：イライラ
俊平：受身意識
Slide 11
Slide 11 text
アジャイル勉強会への参加
「アジャイル勉強会～セイチョウする組織をつくる～」にて
中須賀 葵のプレゼンを聞き、アジャイルに興味を持った。
プレゼン終了後、真希乃は声をかけようと一歩踏み出す決心をした！
過去に流した涙を、
未来の笑顔に
変えたいんだ！！
Slide 12
Slide 12 text
２．ハマナ・プレシジョンの無力感の原因は？
Slide 13
Slide 13 text
（１）認証基盤運用チームの４つの問題
Slide 14
Slide 14 text
（１）認証基盤運用チームの４つの問題
①開発メンバーと顧客だけで要件や仕様が決まる。
②ユーザテスト工程で運用上の問題が次々に発覚。
③「運用でカバー」で取り合ってもらえない。
④運用やヘルプデスクの声が届かない。
Slide 15
Slide 15 text
①開発メンバーと顧客だけで要件や仕様が決まる。
ハマナ・プレシジョンでは、ウォーターフォール型にてシステム
開発、運用のやり方が決まっていくため、前工程での決定事項を
後工程で変えづらい。しかし、開発メンバーとハマナ・プレシジョ
ン業務部門の間で要件定義と仕様が決められてしまう。
◆さらなる問題点
・システム利用者や運用の観点が抜けていること。
Slide 16
Slide 16 text
②ユーザテスト工程で運用上の問題が次々に発覚。
運用観点を考慮しないシステムのため、運用上の問題が次々に
発覚する。
◆さらなる問題点
・運用メンバーやヘルプデスクが文句を言っても
時すでに遅し…取り合ってもらえずに工程が
進んでいく…
Slide 17
Slide 17 text
③「運用でカバー」で取り合ってもらえない。
運用でカバーしきれない不具合や、ユーザからのクレームが多い要
望については、システムを改修して対応する。
◆さらなる問題点
・開発チームでの変更内容が運用チームに共有されない。
⇒変更点が運用チームに共有されないため、ユーザー
から指摘されて初めて問題に気づく。
・過去に運用チームが問題視してフィードバックした
ことが反映されていない（私見）。
Slide 18
Slide 18 text
④運用やヘルプデスクの声が届かない。
届ける機会もない。届けても聞く耳持たないような気もする。
◆さらなる問題点
・新たなインシデントやクレームを増やす原因に。
・チーム内外ともに、情報共有をしなくなる。
⇒インシデント状況が共有されず「気づきベース」の
偶発的かつ属人的対応になる。
Slide 19
Slide 19 text
（２）業務改善の問題地図２丁目を元に考察
Slide 20
Slide 20 text
現場が改善提案しない９つのポイント
①怖くて言えない
②空気を読んで言えない
③テーマがない
④言語化できない
⑤気づかない／気づけない
⑥無力感
⑦トクしない
⑧サポートしてくれない
⑨愛着がない
Slide 21
Slide 21 text
ハマナ・プレシジョンに該当するものは？
①怖くて言えない
②空気を読んで言えない
③テーマがない
④言語化できない
⑤気づかない／気づけない
⑥無力感
⑦トクしない
⑧サポートしてくれない
⑨愛着がない
Slide 22
Slide 22 text
④言語化できない
問題や課題を言葉にできない。みんなモヤモヤと心に不満を抱えている
だけで、それが組織内で問題点・課題として顕在化しない。
・俊平は問題だと思っていても、何とかしたいと思っていない。
・渉はいつもイライラしている原因は、生煮え状態のリリース。
その状態でリリースしてくる担当者に文句の一つも言っていない。
※言っているけど変わらないから諦めたのか・・・
・美香はユーザの声をプロパ社員に上げてきたが、何一つ変わら
ないため、言語化するのを諦めている（言語化しない）。
Slide 23
Slide 23 text
⑤気づけない
前任者に気遣って気づかないフリをしているのも含む。
ハマナ・プレシジョンのメンバーは、
言語化できていない ⇒ 問題だと気づいていない
もしくは
言語化しない ⇒ 問題だと気づいているフリをしている
Slide 24
Slide 24 text
⑦トクしない
改善提案しても、評価されない。
改善して仕事を効率化しても、残業代が減るだけ。
あるいは、その分面倒な仕事が新たに降ってくる。
ハマナ・プレシジョンの場合は、改善提案しても評価されない。
それ以前の問題で、改善提案しても誰も聞いてくれない。
※美香が過去に行ってきたことから明白。
Slide 25
Slide 25 text
⑨愛着がない
そもそも、組織に愛着がない。
よって、わざわざ意見する義理もない。
※個人的には根本的に一番マズいレベルだと思う。
ハマナ・プレシジョンの場合、このレベルまで行っているのでは？
・俊平の受け身な態度、美香の諦めの態度、渉のイライラから、
組織や自分が関わっているシステムへの愛情が薄れている、
もしくは無いと思われる。
Slide 26
Slide 26 text
⑥無力感
今回のキーワード。
もっとも闇深い背景。なぜ、社員が改善提案しないか？
現場が本音を言わないか？些細なヒヤリハットすら報告しないのか？
無力感しかないため
・頭ごなしに否定される
・実行された試しがない
・報告書を作成する作業や説明するのが面倒
Slide 27
Slide 27 text
「無力感」は、⑦⑧⑨も包含している。
解決しないと組織そのものの求心力、
働く人たちのエンゲージメントに影響する。
Slide 28
Slide 28 text
意見や提案が行われないのは・・・
「この組織を信頼していない」
社員のメッセージの可能性大！
Slide 29
Slide 29 text
（３）無力感の深掘り
Slide 30
Slide 30 text
そもそもなぜ無力感に苛まれるのか？
①奇特な勇者のボランティア活動
②改善能力不在
③改善が上手くいったためしがない
④改善の進捗共有や情報共有がされていない
Slide 31
Slide 31 text
①奇特な勇者のボランティア活動
組織の問題・課題を指摘し、改善を提案する人は奇特な勇者！
無力感が支配している職場では、待てど暮らせど現れない。
奇特な勇者が現れ改善提案しても、あからさまに否定される…
こうして次の勇者が生まれない組織風土が出来上がる。
Slide 32
Slide 32 text
②改善能力不在
問題や課題が分かっていても改善する能力がない。
目先の仕事に追われるばかりで、改善を考えることや
そのスキルの育成をしてこなかった。
最初、ハマナ・プレシジョンのメンバー（真希乃も含む）
は改善する方法も能力もなかった、分からなかった。
それが無力感につながっていると思われる。
Slide 33
Slide 33 text
③改善が上手くいったためしがない
改善能力が無いと改善体験そのものが生まれず、改善の
成功体験も生まれない。ますます無力感を高める。
改善しようとしても、
・中間管理職ブロック ※
・抵抗勢力の邪魔
で長続きせず自然消滅に…
※（私見）ハマナ・プレシジョンの場合、課長の掛塚がブロックしてたのでは？？
Slide 34
Slide 34 text
④改善の進捗共有や情報共有がされていない
改善活動を始めても、その進捗や情報が共有されない。
現場に不信感を募らせる原因になる。それを解消させない
（情報共有しない）と、無力感へとつながる。
ハマナの場合、認証基盤システムの追加リリースをしてい
る（一応改善活動はしている）。しかし、そのリリース情
報を正しく共有しないため、美香たちヘルプデスクの不信
感を募らせ、渉の不信感（イライラ）を募らせている。
Slide 35
Slide 35 text
無力感が支配する組織風土を放置すると…
業務を俯瞰して改善
できる人材が育たない
エンゲージメント低下 コンプライアンスを
脅かすリスクに
Slide 36
Slide 36 text
無力感が支配する組織風土を放置すると…
ハマナ・プレシジョンの場合…
・俊平のような「意思なんてない」人間を増やす。
・インシデントが常態化する（当たり前になる）。
・ヘルプデスクメンバーがオペレーションミス起こす。
または、ヒヤリ・ハットを抱え込むようになる。
・多忙な状況を放置して、メンバーのメンタル不全に。
等のようなことが考えられる。
Slide 37
Slide 37 text
３．無力感に立ち向かうためには？
Slide 38
Slide 38 text
（１）アジャイルになる
Slide 39
Slide 39 text
ウォーターフォールとアジャイル
ウォーターフォールとアジャイルは共存可能
Web業界などの開発方法論ではない！
ゼロイチの二項対立でもない！
アジャイルは「ありかた」
Slide 40
Slide 40 text
Web業界などの開発方法論だけではない
アジャイルは、
「個人と対話」をし「動くソフトウェア」を基準にし、
「顧客と協調」し「変化に対応」することに価値を置く。
開発現場以外にも適用できる。また、すべてを完璧にする
必要はなく、一部を取り入れるだけでもよい！
Slide 41
Slide 41 text
アジャイルの原則
アジャイルには12個の原則がある。これらの言葉が価値基準や判断
基準になる。
※４つの視点で整理する。
視点 内容
チーム 日々一緒に働く／意欲に満ちた人々で構成／信頼する／フェイストゥフェイスで話
す／自己組織化されたチーム
プロセス 早く継続的に提供／定期的なふりかえり／やり方を調整する／できるだけ短い時
間・感覚でリリース／持続可能な開発を促進／一定のペースを維持
プロダクト 価値あるソフトウェア／技術的卓越性と優れた設計／無駄なくつくれる量を最大限
にする／動くソフトウェアが進捗の尺度
顧客 顧客満足を最優先／要求変更を後期でも歓迎／お客様の競争力を引き上げる
Slide 42
Slide 42 text
ゼロイチの二項対立ではない
■ウォーターフォールのメリット
要件変更、メンバー変更がほぼなく複雑性が低い環境
ならば、計画を作り予定通り作ることが可能。
■アジャイルのメリット
世の中の状況や要件が頻繁に変わり、複雑性が高い環境。
プロセスを繰り返しながら徐々に成果を積み上げ、
早く失敗し学びに変えることができる！
いいとこ取り、目標に合わせて強弱を変えても良い。
最短でビジネスゴールを目指すために共存を！
Slide 43
Slide 43 text
アジャイルとは「ありかた」
アジャイルに正解はない。
チームとしてセイチョウし、顧客価値を最大にしていくためには、
たゆまぬカイゼンを続けることが重要。
そのために、実践と学びのループを回す仕組みを作ること！
Be Agile!!
Slide 44
Slide 44 text
まずは定期的なふりかえりから
「どうせやっているミーディング」を問題提起、改善提案、改善の実行とふり
かえりの場にする。
例：KPT（ケプト）
K：Keep（よかったこと、今後も続けたいこと）
P：Proglem（問題点、今後は止めること）
T：Try（試してみたいこと）
用意するもの：ホワイトボード、付箋、ペン
やること：自分の意見を付箋に書き出してホワイトボードに貼る。
他人の意見を見ることで新たな気づきや言語化のヒントに！
見える化、言える化のサイクルを促進。
Slide 45
Slide 45 text
（２）改善の風土をつくる
Slide 46
Slide 46 text
（２）改善の風土をつくる
①改善を「仕事」に
②改善した先の「世界」を明確に
③本気を行動で示す
④「成果」より「変化」を
Slide 47
Slide 47 text
①改善を「仕事」に
改善を「仕事」として認める。
足りないリソース（ヒト、モノ、カネ）を調達する。
現場に権限を与える。
そんな時間がない現場の場合は、
「その予算や時間を確保すること」をテーマにしてみる。
組織力強化、人材育成、マネジメント能力強化に！
Slide 48
Slide 48 text
②改善した先の「世界」を明確に
何のための改善か？
改善した人にその後何を期待するか？
改善した後、組織として何に注力したいか？
改善を目的にしないためにも、
改善後のビジョンを考え、
改善の大切さを自分の言葉で
発信して理解してもらう。
Slide 49
Slide 49 text
③本気を行動で示す
トップは改善活動を現場任せにしない。
・改善した人や組織を評価する。
・改善した人や組織が得する仕組みを雰囲気をつくる。
・社内の育成や環境整備に投資する。
・自発的な改善を活動を邪魔しないよう、無駄な慣習や
事務作業を減らす。
Slide 50
Slide 50 text
④「成果」より「変化」を
成果は、数値化によって評価を
変化は、言語化によって評価を
組織風土はすぐには変わらない。
改善成果はすぐには現れない。
しかし、変化は小さくても目に見えて
現れる。その「変化」を言語化して、
「改善は楽しい！」ことの共感を生もう！
Slide 51
Slide 51 text
４．まとめ
Slide 52
Slide 52 text
まとめ
メンバーが意見を言わないのは、組織を信用していない可能性大！
無力感が支配する組織は、メンバーのエンゲージメントを下げ、
コンプライアンスのリスクを高める。
ウォーターフォール、アジャイルはゼロイチではない。
うまく共存させて、たゆまぬ改善とセイチョウを。
改善することが楽しいを思え、改善している人が得をする風土と
仕組みをつくり、共感者を増やしていこう。
Slide 53
Slide 53 text
ご清聴ありがとうございました！