$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

教師や学校の特徴を理解して一緒に対応する - 「学校と一緒に安心して子どもを育てる本」を読んだ

子供がそろそろ3年生になるが、今のうちに教師とどう対応するか、いじめが起きたらどうするかなどを知っておけるといいなと思い、「学校と一緒に安心して子どもを育てる本」を読んだ。

この本では教師というのはどういう人でどう対応すると協力してくれやすいか、小学生のそれぞれの学年別にどういう特徴があるか、悪口・いじめ・学級崩壊などのトラブルにどう対処するかなどについて教えてくれる。教師や学校観点から考えて、親がどう対応するべきかを説明してくれるのが非常に良かった。

たとえば印象に残ったのはこの辺り。

  • 個人面談で具体性もなく特に問題ありませんと言われたときは、例えば、「どういうところですか?」「休み時間はどの子と遊んでいますか?」と聞くといい。その時に一緒にいるメンバーと遊びを答えられたら、よく見ているということがわかる。
  • 先生への言葉遣いの変更
    1. 責める言い方 → 相談に変える。×「どうして〜してくれないんですか」(攻撃、非難されている感じを与える)○「どうしたらいいでしょうか」(要望、相談の形に)
    2. 断定・対立っぽい言い方 → 状況共有にする。×「子どもが先生のことを嫌だと言っています」(話し合いの余地がない)○「子どもがどうも学校が楽しくないみたいで……」(話し合いのきっかけが生まれる)
    3. 指示で押す → 困りごととして提示する。×「〜くんと席を離してください」(先生に考える余地を与えていない)○「〜くんといると、トラブルが多くなるようなのですが……」(先生に考えてもらえる)
    4. ジャッジする → 話し合いの入口を作る。×「先生の今回の対応の仕方、おかしいと思います」(断定的で、話が進まない)○「先生の今回の対応について、お話しさせていただきたいのですが」(言うべきことは言うための伏線となる)
    5. 単発のお礼 → いつも感を出す。×「この間は、ありがとうございます」(絶対NGではないのですが、もうひと工夫)○「この間も、ありがとうございます」(いつもありがたいということが伝わる)
  • 暴力を受けているなど、絶対に止めてほしいものがあった場合は、学校へ要求を持っていく。その場合一発で、管理職(校長・教頭)を交えて話をつけるべき。
  • 学期崩壊が起きたとき、先生を変えては逆効果。学級崩壊が起きたとき、その年に立て直すことはなかなか難しい。また、交代するとして優秀な人は担任を持たないで自由しているわけではないので、交代するメンバーもいない
    • どんなレベルの先生も、年度のスタートから一緒に子どもと過ごすと、何人かの子どもと心が通っている。その絆も立ち切ってしまうと、不安な気持ちの子どもたちをたくさん作り出す

学校と一緒に対応しようとした時、実際に対応してくれるのは先生であり、確かにその人たちの特性を知った上で相談するのが大事だなと気づかされた。小学生の親におすすめの本でした。

読書ノート

- 教師は挫折した経験が少ない。だから根本的に強くはない 20
    - 一つ間違うととても傲慢になりやすい
    - 若い先生は真面目でやる気がある人が多い
    - やさしくて善良で真面目な人は、子供の問題行動に対応する能力は低い
- 教師の特徴と対応 24
- ルールは子供と一緒に作る。自分が決めたという自覚を作る。表にして見えるところに貼る 33
- 子どもの6年間の成長段階別ガイド 34
    - 2年生はひみつやないしょを持ちたくなる
    - 漢字のできない生徒のほとんどが小3から。複雑な漢字が増える 51
        - 教科書の本文が急に読みにくくなる。3年生で音読に引っかかるようになったら注意。
        - 様々な学習のレベルが一気に上がると考えるといい。
    - 小3で悪口を注意するには、悪口そのものの否定ではなく、まず言っていることをよく聞いてから、言いたいことの思いをわかってあげる 54
    - 小4は学ぶ仕事も上手になるので、子どものことがわからなくなってくる時期で、親も不安になる時期である 57
- 音読は文章の意味をつかみやすくする最適なもの。算数の文章題がわかりにくいときは、子どもに問題の文章を音読させるといい。 62
- 連絡帳の冒頭にお礼を入れてから、要望を書くといいです。例えば、「いつもお世話になっています。この前の○○の時はお世話になりました」など。 100
- 例えば、暴力を受けているなど、絶対に止めてほしいものがあった場合は、学校へ要求を持っていく。その場合一発で、管理職を交えて話をつけるべき。 100
- 先生の悪口を子どもと一緒になって言わないように。我が子がいじめの加担者になりかねない。 114, 186
- 信じてもらいたいと先生に言いに行くときは、絶対に信じさせるための事実を持っていく 120
    - しかし、事実をつかむのは保護者にとって難しい。せめて親だけでも自分の子供を信じる。
- 個人面談で具体性もなく特に問題ありませんと言われたときは、例えば、「どういうところですか?」「休み時間はどの子と遊んでいますか?」と聞くといい。その時に一緒にいるメンバーと遊びを答えられたら、よく見ているということがわかる。 123
- 先生への言葉遣いの変更 129
    1. 責める言い方 → 相談に変える。×「どうして〜してくれないんですか」(攻撃、非難されている感じを与えます)○「どうしたらいいでしょうか」(要望、相談の形にすると うまくいきます)
    2. 断定・対立っぽい言い方 → 状況共有にする。×「子どもが先生のことを嫌だと言っています」(話し合いの余地がありません)○「子どもがどうも学校が楽しくないみたいで……」(話し合いのきっかけが生まれます)
    3. 指示で押す → 困りごととして提示する。×「〜くんと席を離してください」(先生に考える余地を与えていません)○「〜くんといると、トラブルが多くなるようなのですが……」(先生に考えてもらえます)
    4. ジャッジする → 話し合いの入口を作る。×「先生の今回の対応の仕方、おかしいと思います」(断定的で、話が進みません)○「先生の今回の対応について、お話しさせていただきたいのですが」(言うべきことは言うための伏線となります)
    5. 単発のお礼 → いつも感を出す。×「この間は、ありがとうございます」(絶対NGではないのですが、もうひと工夫!)○「この間も、ありがとうございます」(いつもありがたいということが伝わります)
- いじわるをされた、いじめられたと言ったら、一回大声でやめてっていいなさいと教える。そしてそれができたかどうかを必ず聞く。それでもうまくいかないなら保護者の出番でいじめを芽の内に摘んでしまう 141
    - 嫌ないじめの話を深刻に話し合うだけでなく、明るく楽しいことも大切。例えば、おいしいものを食べに連れて行くなど
    - 子どもがいじめについて語り出したならそのまま信じる。そのつらさを「その程度のことで」なんて軽々しく扱わない。あなたにも何か原因があるんじゃないの?なんて言ってはならない。
    - 中途半端な強さをいじめに求めると逆にやられてしまうし、できなかった時の自己否定につながる。
    - 子どもの許可なく学校に相談に行かない。子どものプライドを潰すと、子どもは追い詰められる。先に子どもを説得して了承をとる。
- 学期崩壊が起きたとき、先生を変えては逆効果。学級崩壊が起きたとき、その年に立て直すことはなかなか難しい。また、交代するとして優秀な人は担任を持たないで自由しているわけではないので、交代するメンバーもいない 150
    - どんなレベルの先生も、年度のスタートから一緒に子どもと過ごすと、何人かの子どもと心が通っている。その絆も立ち切ってしまうと、不安な気持ちの子どもたちをたくさん作り出す
    - 「学校崩壊をあなたが頑張って止めさせなさい」というのは厳禁。できない。大人の教師が必死になっても食い止めることができないので 153
- 叱る時は全力で。小言ばかりの親は、鬱陶しいだけ。叱るときは自分主語で。 160
- 学習は、なぜその学習をしなければならないのかということを納得させていくことが大事。これを内容関与的動機付けという 178
- 喧嘩をして相手に怪我をさせてしまったとき、絶対にお互い様ということは言わない 188

#RSGT2026 に参加し、いろんな人から刺激をもらってきた

ブログを書くまでがカンファレンスということで、RSGT2026に参加しました記事です。

今回参加したのは、「開発フロー改善がうまくいって知見も溜まったし、どこかで発表したいな」と思った時にたまたまRSGT2026のプロポーザル応募をしているのを見て、勢いでプロポーザル応募したのがきっかけ。結果的にプロポーザルも通り、初参加 & QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化するという発表をしてきた。

初参加で、しかもこれまでスクラムやアジャイル系のイベントにはほぼ参加したことがなかったため、ほとんど知り合いがいないという状況だった。けれど今回の機会で色んな人と廊下や懇親会で話せて、興味深い議論をしたり知り合いを増やせたりしたなと思う。

セッションもレベルが高いものばかりで、特に以下の2つのセッションが参考になった。両方とも深い知見であると同時に、会社でまず一歩目を踏み出せそうな内容だった。

このような貴重な機会を作ってもらい、スタッフの皆さんありがとうございました。また来年も発表のネタを作って登壇できたらなと思います。

スピーカーディナー

知り合い全然いない!という状況でオロオロしていた。そんな中Bayashiさんが「ブログ見てます」と話しかけてくれて、さらには二次会にも連れていってもらえたのがとてもありがたかったです。

スポンサートークで市谷さんを初めて見て驚いた。昔「正しいものを正しくつくる」という本に感銘を受けていたので、参考になりましたと挨拶に行きたかったが、機会を作ることができず。また別の機会があれば話しかけにいきたい。

その場ではセッションなどには中々出にくいスタートアップ大変話が聞けて良かった。みんな大変なんだな〜と思いつつ、自分も大変な中頑張っていきたい。

An introduction to Beyond Budgeting – Business agility in practice

脱予算経営の話。僕自身は脱予算経営のことを全く知らなかったので勉強になった。このフレームワークを全部適用するのは難しすぎるんじゃない?と思いつつ、いくつかの考え方は使えそうだなと思った。

  • 予算はないが何に使ったかは透明になっている
    • 気づき: 透明性が異常な支出を抑えるという考え方が面白い
  • 誰かが違反するのは絶対起こる。連帯責任にはしない、その人に対して厳しい対応をする。
    • 気づき: これはルールを作る話にも似てる。失敗したからすぐに標準化したルールを作るとどんどん締め付けが強まる

懇親会で脱予算経営の話がいくつか出たが、全てをやろうとするのは逆に難易度を上げてるだけでは?という意見も出てきて面白かった。いくつかの会社では、予算の透明化&申請自体はノールックで承認ということをやっている会社があったのも興味深い。

「予算は最初に貰う的に妥当性をある程度判断するものである」と自分の中で固定観念があることに気づけた。

「アウトプット脳からユーザー価値脳へ」がそんなに簡単にできたら苦労しない

speakerdeck.com

アウトプット脳になりやすい職能をユーザー価値脳へ意識変革するのは難しいため、アウトプット脳のチームとユーザー価値脳のチームに橋をかけようという話が良い。以下三つを行うことで橋をかけられる。

    1. 実験の設計
    2. 安全な小さな実験から価値検証を始める
    1. 会話の設計
    2. 話す順番から会話をデザインする
    1. KPIの設計
    2. 評価指標から「仮説の集合」への再定義

発表中や発表の後にも質問させてもらったが、一気にやるのが難しかったら(1)からやれば良いとしつつ、(3)ができないと説明が難しくて辛くなるという話を聞いて、めっちゃ納得してしまった。

「私の要求最優先!あなた後回し」そんな対立を超えてビジネス、開発、顧客が本当に欲しかったものを全両立するプロダクト組織の作り方

speakerdeck.com

トレードオフを詳しく理解して、その理解を通して解決方法のパターンを知れる発表だった。発表中だけでは理解し切ることが難しく、次の日の朝に発表資料をもう一度読んで頭の中を整理していた。

「本当は〜したいが、仕方なく〜している」と思う時はあったが、その時にトレードオフ構造を図にして解決方法を探るという手法を使えてなかったなと気づいた。システム思考も関係しそうだし、もっと深く勉強して問題解決のアイテムとして身につけておきたいなと思った。

Day2でmoriyuyaさんに「トレードオフについて話しかけにいってもいいですか?」とXでメンションしたところ、快くOKしてもらい話すことができた。なんとコーチーズクリニックの場所に連れていってもらい、その場で1時間ほどノートに状況を書いてもらいながら会社の状況の整理をしてもらえた。とても頭が整理されたし、その時に得たものを一つずつでも実施していきたい。ありがとうございます🙏

自己管理型チームの一員となるためのセルフマネジメント:モチベーション編

speakerdeck.com

行動を阻害するフリクションの種類とそれぞれの対応方法についての説明が、僕の中では一番参考になった。以下のように言葉にすることで、ざっくりとした認識をカテゴライズして次に進むときの指針にできそうだった。

  • 物理的フリクション
    • 作業のステップ数が多いなど物理的な手間
  • 認知的フリクション
    • 頻繁な通知により断続的に集中が途切れるなど認知的負荷
  • 心理的フリクション
    • 不安感や抵抗感により動けない状況

また発表の進め方として、モチベーションの源泉や身の回りのフリクションについて、それぞれ2分ずつ周りの人と話すという時間があったのは良い。発表を聞くだけだと自分の経験と紐づけることができず結果的に内容を落とし込めないことが多い。しかしこの時間があったことで一種の「経験」となり、その後の発表の内容を落とし込めるようになった。

ABC理論の話に繋がるのも面白い。最初ABC理論と聞いたとき、「聞いたことない理論だな?」と思ったが、よく聞くと昔自分の勉強した認知行動療法の話だと気づいた。認知行動療法、自分の感情を理解するのにすごく良いよね。

ちなみに僕は自分の気持ちが落ち込んだ時は「ファイブコラム」という手法を使っている。これは出来事に対して以下の順で言語化することで、自分の解釈のバイアスの矯正も行う手法。「それ以外の可能性のある考え方」を考えることで、自分のバイアスを見つけられるのが良い。

  • 気分が落ち込んだ出来事
  • その時に起こった感情と強さ
  • その時心を占めた考え
  • それ以外の可能性のある考え方
  • 感情の変化と強さ

QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する

speakerdeck.com

自分の発表。#RSGT2026 で「QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する」という発表をしましたの記事に伝えたいことは書いたので、興味がある人がいたら見てもらえれば。

AI時代のアジャイルチームを目指して - "スクラム"というコンフォートゾーンからの脱却-

speakerdeck.com

AI時代だからこそ、チームで扱う変数を増やし、組織とチームの境目を積極的に溶かすという部分が良い。自分が無意識に定数にしてしまっているところを意識しないとなと思った。

懇親会でおよべさんに「モブプログラミングをしている時にAIからの返答待ちの時間は何をしてるんですか?」と聞いたところ

  • 「プログラミング」をしているわけではなくて、「仕事」を一緒にしている
  • 普段はAIの返答待ちの間に、別の仕事=Slackへの返信だったりその他だったりをしているわけで、そこも含めてモブでやる
  • そうすることで、仕事全体を学ぶという学習効果も生まれるよね

と話していた。こちらも自分の中で「モブプログラミングはプログラミングを一緒にする」という固定観念を持っていたんだなと意識できて良かった。

AI駆動開発の時代〜小さなチームで世界を変えよう〜

発表を見ていての一番の感想は「AI時代に改めてエンジニアリングを楽しんでいるんだなあ」ということ。僕は楽しんでいるクリエイターが好きなので、そういう意味で良い発表だった。

AI時代だからこそビジネス方面にもどんどん出ていくチャンスだなと思うので、逃げずにやっていきたい。

最後に

今回の4日間で非常に刺激をもらえた。ここで得たものを現実を見据えながら一歩ずつ実践していきたい。

#RSGT2026 で「QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する」という発表をしました

RSGT2026に参加して発表してきました。スクラム系のイベント初参加・初発表・かなり大きなホールでの発表ということで緊張した〜。

発表資料はこちら。QAフローの最適化とタイトルに入っていますが、QAチームの立場からというより、開発チームのソフトウェアエンジニアの立場から開発フローを改善していく話です。

speakerdeck.com

資料を作っていて、「うーん自分は結局この発表で何が伝えたいんだろう?」と迷っていたのですが、作っていく中で言語化できたように思います。それは今回のフロー変更がうまくいったのは2つの成功要因があり、さらにこの成功要因はQAだけでなく開発フロー改善全体に言えることだなということです。

簡単にこの部分で話したことを要約するとこんな感じ。

  • QAフローや開発フローの改善をするとき、最初からフロー設計をするのではなく、必ず事業やサービス理解から始める方が良い
    • よくある罠として、QAでどんな障害・バグも防ぎたいとなり、どんどんQAコストが膨らみ、その結果開発〜リリースまでのリードタイムが伸び、アジリティの高い開発が徐々に失われてしまう
    • そうならないように、「何は絶対に守りたいか」を先に明確にする。絶対に守りたいことを言語化すれば、障害などの問題が起きても、今後QAで継続的に確認すべきかを考慮できる
    • 絶対に守りたいことは、事業やサービスのコア価値にあり、それはサービス紹介資料・営業資料・PMの頭の中などに存在する。先にその内容を理解すれば、満たしたい品質水準を達成しながらコスパの良いQAを設計できる
  • 開発フローの改善を設計する前に、必ず開発フローの中で変更しやすい・変更しにくい部分の理解から始める方が良い
    • よくある罠として、開発フローで大きな課題を感じ、理想のフローの設計を始めてしまう
    • しかし事業の特性などで開発フローには制約がある。さらにこれまでの歴史的経緯などの理由で開発フローには慣性が生じている。そのため変更しにくい部分を無理に変更しようとしても反発が起きる
    • 反発が起きると変更自体は良い方向に向かうはずなのに、「全ての変更が失敗であった」となってしまい、何も変えられずに終わってしまうケースが多い
    • そのため、先に変更しやすい・変更しにくい部分を理解しておき、その情報を改善設計に組み込むことで、スムーズに変更を進められる

このような発表をしたので、もし興味が湧いたらぜひ資料も見てもらえればなと思います!

発表概要

QAフローが大変で開発したもののリリースに時間がかかってしまうという悩みはありませんか?

クラスター株式会社では障害を最小に抑えるため厚いQAフローを運用していました。このフローによってサービスの可用性品質は非常に高い一方で、開発を終えたものをリリースするまで最低でも12日かかるという課題がありました。

ソフトウェアエンジニアの立場からこの課題を解決するため、障害数をコントロールした上でリリースまでの期間を最短化する方法を模索・提案し、改善を進めました。具体的に次のことを一つずつ進めました。

  • 事業の特性を理解して達成したい品質基準を決める
  • 開発フローの制約条件を理解する
  • 達成したい品質条件や制約条件を満たすように、QAフローおよびその周辺の開発フローを再検討する
  • QAメンバーと一緒に、QAのregressionテストのテストケースや、テストすべき内容を決め直す
  • 決定した理想系に向けて移行計画を作る
  • 3ヶ月かけて、理想系まで移行する

改善の結果、以前は開発終了からリリースまで12日必要だったものが、今は最短で6日ほどでリリースできるようになりました。さらに新しいフローになった後も顕著な障害増加はなく、可用性品質をコントロールできている状況を作り出せました。

本セッションでは、私がQAフローの運用の最適化を行なった具体的な経験を紹介し、QAフローを最適化する時、もしくはQAフローを新しく始めたい時に何が大切かをお伝えします。