スクラム開発はKI活動とほとんど同じ

# はじめに
スクラム開発はとても有名だと思うんですが、
おそらくKI活動、というものはあまり知られていないんじゃないでしょうか

ただ、実はこのKI活動、30年ほど前からある活動（開発の進め方）なのですが、
非常にスクラム開発に類似した点があります

私は現在AIエンジニアなのでスクラム開発を取り入れようとしているんですが、
まあ例によってなかなかうまくいかないものです

ですが、前職（メカエンジニア）で使っていたKI活動と類似している点が多いので、
そのノウハウをスクラム開発にうまく活用できないかなと色々トライしているところです

今回は、KI活動の紹介と、スクラム開発との類似点について紹介していきます
スクラム活動に行き詰っているときに何かの参考になれば幸いです


# KI活動（Knowledge Intensive Staff Innovation Plan）とは
## 基本コンセプト
KI活動については、あまり情報が多くないのですが、こちらのPDFで紹介されています
https://www.jmac.co.jp/data/pdf/rd4-01_details.pdf

> KIとは
> ・「ナレッジワーカー」の日常業務を「チームワーク」を活かした「オープンマインド」で
> ・「互いの仕事の中身や思考が見える」仕事のスタイルに変えることにより
> ・「生産性向上」と「組織風土の活性化」を実現するプログラムです

と紹介されています
ナレッジワーカーと書かれていますが、
主に製品の開発・設計を担うエンジニア部門の生産性向上を目的としています

また、XTECHでも取り上げられていますね
https://xtech.nikkei.com/it/article/Keyword/20071010/284077/

## KI活動の４つの手法
上で紹介している、XTECHの記事から抜粋します
> （1）週1回2時間以上の頻度で開催する上下関係を越えて本音で話す場「ワイガヤミーティング」
（2）模造紙と粘着メモ紙を使って作る「見える計画」
（3）個々の役割を明確化して上司が合意するプロセス「合意納得＆契約マネジメントスタイル」
（4）業務の振り返りプロセス「YWT（やったこと・分かったこと・次にやること）」

この時点で、なんとなくスクラム開発に似ているなと思いませんか？

## 実際に前職でやっていたこと
KI活動は手法の普及から30年近く経ち、
各社それぞれで異なった進化を遂げていると思います
実際に、私が前職で「KI活動」として行っていた内容を紹介します

MTGとしては、以下の３つを行っていました

- 朝会：基本的に毎日行う
- 段取り：週に１回
- はきだし：半期に一回、または必要になったとき

### 朝会
朝会は、以下の内容を共有する場になります

- 全体連絡：全員の共有事項を主に上司が話す（例：明日避難訓練があります、など）
- 各個人の業務内容と進捗報告（大体1分/人目安）
- 明日以降の予定の共有（例：明日休み、外出など）


この朝会は、スクラムでいう「デイリースクラム」ですね

ただし一般的なデイリースクラムと異なるのは、
プロジェクトのメンバーだけではなく、所属部門に所属するメンバー全員で行います（～10数名）

メカエンジニアにしても、AIエンジニアにしても、未知の問題にぶち当たるときが多々あるんですが、
問題解決への糸口は意外なところから出てくることも多いです
プロジェクト外のメンバーのノウハウや知識、人脈などが役に立つことが結構あるんですよね
そのためには、普段からざっくりとでもお互いに何をやっているか知っておくことはとても大事だと思います

また、各人の業務報告では、

- 昨日やったこと（成果があればそれも一言で報告　※成果は「良くなかったこと」も含む）
- 今日やること（月曜などは今週やる事）
- 予定に対する進捗（うまくいっているか、遅れているか）
- 困っていること

についてを報告します
ここで重要なのは、短い時間でも各個人が必ず話す時間を作ることです

スクラムでの失敗談でよく「デイリースクラムが機能していない」話を聞きますが、
これらの事項を意識してかつ短時間で話すべきかなと思います

リーダー：「問題ありますか？」⇒　メンバー全員：「ありません」
のパターンだと、実際ほとんどの問題は埋もれてしまいます

各個人が話すようにすると、本人が気づいていない問題も見えることがあります
その辺にほかのメンバーが気づいたら声出ししてあげるのも大事ですね

また、各メンバーの相談事や質問などで長くなりそうな場合は、
朝会後に別途時間を設けて必要なメンバーだけで話すようにしていました
全部話しているとどうしても長くなってしまいますからね…


### 段取り
段取り（と、前職では呼んでいました）では、以下を行っていました

- 開発プロジェクトの日程確認
- 完了タスクの内容報告
- タスクの洗い出しと優先順位付け
- タスクの各メンバーへの割り振り

この段取りが、上で紹介した「KI活動の４つの手法」における(1)～(3)の手法を含んでいます

また、スクラムに当てはめると以下の内容を含んでいます

- プロダクト・バックログの整理
- スプリント・バックログの設定
- タスクボードのメンテナンス

使っていたのはExcelのガントチャートです（メカ屋はITには疎かったので…）
一時期Redmineを使おうっていう話もあったんですが

この段取りでは明確に「スプリント」という期間は設けません
１～２週間を目安として、洗い出したタスクにおいて作業時間を見積もり、
優先順位をつけて各メンバーに割り振っていきます

というのも、メカエンジニアの仕事（というより新製品開発の仕事）においては、
基本的にこれまでやったことないことに新しくチャレンジしていくので
「想定通りに仕事が進む」なんてことは滅多にないんですよね…
（大体は『下町ロケット』のような「なぜうまくいかない！」状態に陥ります）

ただし、重要なマイルストーンが近い場合においては、
2～3か月先までスケジュールを引くこともあります
短期的な日程ばかり見すぎると、中長期的な進捗が分からなくなりこともありますからね

さて、段取りはスクラムにおける「振り返りミーティング（レトロスペクティブ）」に一見見えますが、
実際段取りの中ではほとんどKPTのような振り返りは行っていませんでした

前職におけるこの方式が長い期間をかけて最適化されたこともあって、
「業務の進め方としての振り返り」を毎週やってもほとんど何も出ないんですよね
（これはスクラムでも同じだと思います）

とはいえ、定期的にやり方を見直す必要があります
それが、次に紹介する「はきだし」になります

### はきだし
「はきだし」では、KIの４つの手法のうち
（4）業務の振り返りプロセス「YWT（やったこと・分かったこと・次にやること）」
の役割を主に担います

また、スクラムでいうと「振り返りミーティング」における「KPT」に似ています

先にも述べましたが、業務プロセスの最適化が進んでくると、
振り返りを毎週やってもほとんど改善点なども出なくなります
そのため、この「はきだし」は半期に１回くらいのペースでやっていました

ここでは、

- 今のチームにおける問題点を洗い出す
- 問題を分析し、次にやる事を決める
- 良かったこと（前回から変化したこと）も洗い出す

実際の進め方としては、
1. メンバー全員を集め、時間を取って問題点（良かった点も）をポストイットに書き出す
　 ※とにかくたくさん出すことを意識することが大事
2. 一人ずつ順番に、ポストイットを模造紙に貼っていく（口頭で説明しながら）
　 ※ここで、似た内容のものがあれば、それに賛同する形で隣にポストイットを貼っていく
3. 他の人の意見を見て、思いつくところがあればその場で新しくポストイットを作ってもOK
4. ポストイットが出尽くしたら、グルーピングを行う（KJ法）
のような形で進めていました

次にやる事は、何も自分たちだけでやる事に限りません
場合によっては他部門などへの働きかけが必要になるものもあり、
そういった「次にやる事（T）」は上司などを通じて他部門へ要望を出すこともあります

また、前回の「はきだし」を振り返り、
良くなったこと、変わらないところを洗い出すことも重要です

# さいごに
スクラムの元になったのは、"The New New Product Development Game"という論文ですが、
読んでみると、日本の製造業における新製品開発プロセスが元になっていることが分かります

そう考えると、新製品開発におけるKI活動（というより、開発活動そのもの）が、
非常にスクラムに似通っているのも、当然と言えば当然の話なのかもしれませんね

※"The New New Product Development Game"については、こちらでわかりやすく要約されています
https://blogs.itmedia.co.jp/hiranabe/2012/06/origin-of-scrum-reopened-1.html