2022-01-11

教育目的プロダクトのプロダクトオーナーの仕事

アジャイル＆スクラム

岡島です。こんにちは。

私はFDP（Future Design Project）のプロダクトオーナーをやってます。FDPは、社員の技術獲得を目的とした教育プロジェクトで、プロダクト作りを通じて、機械学習の実践的なスキルを獲得することがゴールです。

このブログでは、私がFDPで開発されるプロダクトのプロダクトオーナーとして、具体的にどんなことを考え、どんなことをしているのか、なるべくわかりやすく説明していくつもりです。

これまで開発してきたプロダクト

FDPは今年で二年目を迎えるのですが、これまでに、次のようなプロダクトを開発してきました。

機械学習とARによる帽子着せ替えカメラアプリ
機械学習で脇温度を推定する非接触型体温計（育てるAI検温）

f:id:HappymanOkajima:20220111002112p:plain — 育てるAI検温

いずれのプロダクトも教育目的であり、「プロダクトが売れそうか」ではなく、「メンバーが何を学べるのか」を重視して、コンセプトや利用技術を選んでいます。

また、いずれのプロダクトもScrumを採用しており、今後開発するプロダクトもその予定です。

教育目的プロダクトならではの難しさ

実際にプロダクトオーナーを一年間やってきて感じたことは、教育目的のプロダクトは、バックログアイテムとその優先度や、プロダクトビジョン、プロダクトゴールの設定が意外に難しいということです。

フィーチャーとしての新規性や製品の完成度（品質）よりも、経験・獲得できる技術の内容を優先する必要がありますが、あまりにありきたりなスペックだと、メンバーのモチベーションも上がらず、結果的に教育効果を下げてしまうことになりかねません。

また、あまりに野心的な目標設定をしたり、メンバーにとって関心や面白みを感じられないテーマでもうまくありません。

プロダクトのビジョンやゴールに関しては、やはり「そもそも、私たちは、なぜこのような活動をしているのか？」という根源的な意義に立ち返って考えていく必要があります（※ 具体的な内容については、次回以降の記事で詳しく説明していく予定です）。

組織に知識を蓄積していくために

ちなみに、FDPは毎年メンバーが全員入れ替わるため、組織的に知識を蓄積していくような仕掛けが必要です。そこで私は、野中郁次郎先生らのSECIモデルを参考に、意識的に暗黙知と形式知が相互変換され、スパイラルに、より質の高い知識が広まっていくような取り組みを模索しています。

詳しくは、2022年1月5日~7日に開催された、Regional Scrum Gathering Tokyo 2022 にて発表させていただいた資料をご覧ください。

ではまた！

2022-01-05

朝会のファシリテータ当番を通知する Slack Bot を作ってみた

技術

こんにちは。永和システムマネジメント FDPメンバの坂部です。

Bolt と Heroku でさっと作りました。

最初は Express.js を使っていましたが、Slack Bot 用フレームワークの Bolt が案外使いやすそうだったので、移行しました。

きっかけ

今まで、手作業で miro のふせんを貼り替えて、朝会のファシリテータを管理していました。

f:id:sakabehiroki:20220105124535p:plain

ただ、この方法だとふせんの移動を忘れることがありました。

そこで、Slack Bot で自動化することにしました。

作ったもの

毎朝、ファシリテータ当番にメッセージを送信します。

f:id:sakabehiroki:20220105124616p:plain

また、Slack のコマンドで /members と入力すると、登録されているメンバ一覧を確認できます。

f:id:sakabehiroki:20220105125350p:plain

他にも、下記のコマンドに対応しています。

コマンド	内容
/add	自身をメンバに追加
/delete	自身をメンバから削除
/add <任意のユーザ名>	指定した ID のユーザをメンバに追加
/delete	指定した ID のユーザをメンバから削除
/skip	"次のファシリテータ"を更新
/notify	ファシリテータ通知を手動で発火
/members	登録メンバ一覧と次のファシリテータを表示

こんな感じで書いていきます

毎朝の通知は、Heroku Scheduler でスクリプトを起動して、Slack Bot の Incoming Webhook に投げることで、実行しています。

import { fetchAndUpdateFacilitator } from "...";
import got from "got";
import * as holiday_jp from "@holiday-jp/holiday_jp";

async function main() {
  const today = new Date();
  // Sunday or Saturday or Holiday
  if (today.getDay() == 0 || today.getDay() == 6 || holiday_jp.isHoliday(today)) {
    return;
  }

  // From DB
  const slackMemberId = await fetchAndUpdateFacilitator();

  // SLACK_WEBHOOK_PATH は事前に Slack アプリの画面でぽちぽちして生成されるやつ
  const url = `https://hooks.slack.com${process.env.SLACK_WEBHOOK_PATH}`;

  // Incoming Webhook にリクエストを投げる
  try {
    await got.post(url, {
      json: { text: `<@${slackMemberId}> 今日のファシリテーターです` },
    });
  } catch (error) {
    console.error(error);
  }
}

main();

Slack のコマンドを受け付ける Bolt アプリはこんな感じです。

import { App } from "@slack/bolt";
import { fetchUserList } from "...";

// Bolt のアプリを作成
const app = new App({
  // SLACK_BOT_TOKEN と SLACK_SIGNING_SECRET は Slack アプリ作ったときに生成されるやつ
  token: process.env.SLACK_BOT_TOKEN,
  signingSecret: process.env.SLACK_SIGNING_SECRET,
});

// membersコマンドを受け付ける
app.command("/members", async ({ ack, respond }) => {
  // コマンドのリクエストを承認
  await ack();

  // From DB
  const userList = await fetchUserList();

  const usersText = userList
    .map((user) => (user.isFacilitator ? `${user.userName} <== 次のファシリテータ` : `${user.userName}`))
    .join("\n");

  await respond({
    // Slackで "ユーザの一覧です…" と応答する
    text: `ユーザの一覧です\n\n${usersText}`,
    // 応答をチャンネルに投稿して、コマンド送信者以外にも見えるようにする
    response_type: "in_channel",
  });
});

// アプリを起動
(async () => {
  await app.start(parseInt(process.env.PORT || "3000", 10));

  console.log("⚡️ Bolt app is running!");
})();

所感

Slack Bot（に限らず Bot 全般）を初めて作ったのですが、シンプルな機能なら案外簡単に作れるんだなーとわかりました。

これからも、ちょっと Bot ほしいなと感じたら作っていこうと思います。

2021-12-28

早くも今年をふりかえる

雑記

はじめに

岡本です。
ブログが始まってまだ5日目ですが早くもふりかえりですw

実はFDPの活動は10月からスタートしていて、ここに載せるのが追い付いていないのですが、仕事納めに年末らしいエントリが欲しくなったので概要だけ書いてみます。

それぞれについては後で詳細なエントリが出てくるかもしれません（メンバの皆さんに期待！）

これまでのあらすじ

10月

キックオフ

f:id:Okamoto-Takuya:20211224162305p:plain — チームの船出（ちなみにチーム名はBoatです）

fdp-blog.hatenablog.com

読書

メンバが全員揃って『機械学習って何？』というレベル0からのスタートなので、とりあえず本を買って読んでみます。
そもそもどんな本を読んだらいいかも分からないので、全員でググってそれらしい本を2冊読んでみました。

f:id:Okamoto-Takuya:20211228213037p:image:w250

f:id:Okamoto-Takuya:20211228213101p:image:w250

とてもラッキーなことに『勉強のためなら金に糸目は付けない（意訳）』という会社の方針を頂き、その後も月に数冊のペースでメンバが好きな本を買って読んでいます。

動画

同時にAIの基礎について評判の良い動画があると聞いたので、これも全員で視聴しました。

www.coursera.org

これは分かりやすくて良かったです。

ワーク#0（タイタニック）

機械学習のHello World的な、Kaggleのタイタニック問題をやってみました。

www.kaggle.com

データ取得
モデル構築
学習
予測
評価

といった機械学習の基本のキがなんとなくイメージできるようになりました。
さすがハローワールドです。

fdp-blog.hatenablog.com

11月

環境構築

タイタニックは初心者らしくGoogle Colaboratory を使いましたが、ソフト開発屋らしくコード管理したい！ということで、docker container + VS Code + Git/Github を使った開発環境を作ってみました。

機械学習とソフト開発の文化の違いみたいなものも見えてきて、なかなか興味深い学びがありました。

colab.research.google.com

fdp-blog.hatenablog.com

ワーク#1（クラスタリング）

そろそろ何か実践として手を動かしたいということでPOがお題を持ってきてくれました。

弊社のAgile Studioではリモート見学会というのを随時開催しているのですが、参加者から頂いた評価アンケートのデータが膨大でとても手作業で分析できないという事で、これを機械学習を使って改善できないか？という物です。

スプレッドシートに書かれた日本語のコメントを扱うので自然言語処理にも少し触れることが出来ました。

f:id:Okamoto-Takuya:20211228215828p:plain — クラスタリング結果

fdp-blog.hatenablog.com

ワーク#2（分類）

今度は同じお題を分類という手法を使って分析してみます。

『分類とクラスタリングって何が違うの？』がようやく理解できるようになりました。

f:id:Okamoto-Takuya:20211228220104p:plain — 分類の答え合わせ

fdp-blog.hatenablog.com

ワーク#3（回帰）

クラスタリング、分類と来たので今度は回帰をやってみようかということで、再びKaggleから適当なお題を選んでトライしてみます。

100,000 UK Used Car Data setwww.kaggle.com

これまではネットにあるサンプルコードや、やってみました系の情報をほぼ写経に近い形で参考にしていたのですが、ここでは少し自分たちで考えて、色々な回帰のアルゴリズム比較に挑戦してみました。

f:id:Okamoto-Takuya:20211228222035p:plain — アルゴリズムによる予測精度の比較

公開スクラム

私たちのチームでやっている日々のスクラムを公開してみました。

朝会とふりかえりとモブプログラミングの様子を生中継しながら実施、緊張しました～

www.agile-studio.jp

12月

オンボーディング

ここで新しく三田村さんがジョインしたので再スタートの意味も込めてオンボーディングをやってみました。（キックオフ参照）

f:id:Okamoto-Takuya:20211228205135p:plain — オンボーディングの様子

f:id:Okamoto-Takuya:20211228205200p:plain — オンボーディングの様子

ワーク#4（画像分類 with ニューラルネット）

3か月目に入りまた新しい領域に手を出してみたい！ということで、今度はニューラルネットに挑戦してみます。

これまたKaggleから適当なお題を選んでトライです。

Fruit and Vegetable Image Recognitionwww.kaggle.com

ここで初めての挫折！！
ここまでは比較的順調に進んでいた（やってみたら一発でそれらしい結果が出た）のですが、ここにきて壁に突き当たります。

学習しても予測精度が2%台とかでサッパリ結果が出なくなってしまいました。

色々と調べた結果、最終的には学習回数やパラメータ調整によって結果が大きく変動することがわかりホッと安心しました（いい成績が出た訳ではない）が、何となく雰囲気でやっていてもダメなことを痛感し身が引き締まる思いでした。

f:id:Okamoto-Takuya:20211228223852p:plain — フルーツと野菜の写真を判別する

f:id:Okamoto-Takuya:20211228223829p:plain — フルーツと野菜の写真を判別する

おわりに

改めてふりかえってみるとたった3か月ですが色々やってきたなあ、という気持ちになります。

今年いっぱいで大枠としての学習期間は終了し、来年の1月からはFDPとして本格的なプロダクト開発をスタートします。

また新しいネタが沢山出てくると思いますので、チームの成長と共にここに記録していこうと思います。（メンバの皆さんに期待！2回目）

今年一年、ありがとうございました！
来年もよろしくお願いします！！

2021-12-28

チームビルドをやってみた

アジャイル＆スクラム

はじめに

岡本です。

10月からFDPの活動を始める時にまず最初にやったチームビルドについて紹介してみます。

登場人物

チームメンバの4人はほぼ初対面でした。
（金融事業メンバのお二人だけはお互いに知っている）
　

f:id:Okamoto-Takuya:20211228180024p:plain:w200:left 坂部（DEV）
ITサービス事業部
社会人としてのソフトエンジニア歴は1年未満
今年の新卒入社
Agileネイティブ世代
チームで一番沢山＆カッコいいコードを書きます
　

岡本（SM兼DEV）
ITサービス事業部
ソフトエンジニア歴25年くらい
Agile/Scrum歴は10年くらい？
　
　
　

見澤（DEV）
金融システム事業部
ソフトエンジニア歴15年くらい
Agileエンジニアにリスキル中
ScrumもPythonもGitもVSCodeもこの10月から触り始めました
　
　

三田村（DEV）
金融システム事業部
銀行勘定系システム一筋35年
生粋のコボラー＆ウォーターフォーラーから
Agileエンジニアにリスキル中
この12月から新しくジョインしました
　
　

やったこと

偏愛マップ

「自分について」何でもいいのでひたすら書き出し、それをお互いに説明し合います。
今回はマインドマップの形で書き出してみました。

普通の自己紹介ではなかなか出てこないようなDeepな情報とか、それに対するツッコミが生まれてなかなか楽しいです。
口頭だと流れてしまうこともマップとして視覚化されていると強く意識に残るのと、終わった後に何回でも見直せるのが良いですね。
あと内容だけでなく、マップの書きっぷりにもそれぞれの個性が表れるなって思いました。

6人（チームの4人とPOの岡島さん、社長の平鍋さんも）でやって2時間近く盛り上がりました。
ちなみに6人中3人がギタリストだったことが判明しました。

せっかくなので全員の画像を貼ってみます。
雰囲気だけでも察してもらえると。

坂部さん

岡本

見澤さん

三田村さん

ドラッガー風エクササイズ

次の質問に対する回答を自分で作成して、それをお互いに紹介し合います。

自分は何が得意なのか？
どういう風に仕事するか？
自分が大切に思う価値は何か？
自分にとっての地雷は何か？
チームメンバーは自分にどんな成果を期待していると思うか？
他のチームメンバーに期待することは何か？

こちらも結局2時間くらいチームでワイワイと盛り上がりました。

なかなかにタフな質問で改めて聞かれるとすぐに答えが出てこないのですが、答えにくいなりに悩む過程とかそこから出てきた言葉にその人の個性が出てくるような気がします。

あとは短い付き合いながらも既に出来かけていたチームメンバへの印象というか先入観が結構あてにならず、「この人ってこんなこと考えていたんだ～」という発見がいくつもあってビックリしました。

f:id:Okamoto-Takuya:20211228190031p:plain

やってみて

どちらも目新しいものではなく、岡本も前から知ってはいたのですが、ちゃんとした形でチームビルドとしてやってみたのは初めての経験でした。

正直に言うと、この手のエクササイズは苦手で、何かウサンクサイというか芝居がかった会話をする気恥ずかしさもあって（セミナーとかでよくやらされますよね）避けていたのですが、やってみると面白かった＆得るものが多くて、やって良かったと思います。
メンバのみなさんも「やって良かった」「楽しかった」と言ってくれてるのでホッとしています。（社交辞令でないことを祈る）

多分ですが、偏愛マップとかドラッガー風エクササイズとかの個々の成果物というよりは、それを書き出したり説明しあう場に生まれる「会話」に本当の価値があるような気がします。
なので後から成果物だけを共有してもあまり意味はなくて、一緒に集まって会話することが大事なんだろうな、って思いました。

オンボーディング（12月に追加実施）

メンバ紹介の所にも書きましたが、金融システム事業部の三田村さんだけは業務都合によりこの12月から後追いでジョインする形になっています。

そこで改めてチームの足並みを揃える意味でオンボーディング（新規メンバの受け入れ）をやりました。

内容は基本的に10月にやったのと同じように

FDP活動のゴール共有
チームの現状説明　to 三田村さん
ドラッガー風エクササイズ（第2回）
12月からのチーム運営ルールを全員で考える

みたなことをやりました。

オンボーディングではあるのですが、先行しているチームに新しくメンバが追加されるのではなく、4人で新しいチームを立ち上げるような意識で臨みました。

もちろん完全にフラットな状態に戻っての再スタートではありませんが、「先行＆後発メンバ間の境界をなくしたい」という意図がチーム内で共有できたのは大きな成果かな、と思います。

チームビルドの大切さ

「プロジェクトの成否（の大部分）はチームで決まる」って思っているので、10月から新チームを立ち上げると決まってからは、「最初のチームビルドに全力投球する」と決めて自分なりにいろいろ考えたり準備を進めてきました。

まずは最初のスタートがなんとか形になったので、良かったな～と胸を撫でおろしている所です。

この後もメンバのみなさんと力を合わせて、来年の42期FDP終了時には、「これで解散するのが惜しい！」と思えるようなチームにしていきたいと思います。

よろしくお願いします！

2021-12-28

VS Code Remote Containerで、自分用の拡張機能をインストールしたい

技術

こんにちは。永和システムマネジメント FDPメンバの坂部です。

WSL2 + Docker + VS Code Remote Developmentでdotfilesの設定が反映されない〜と唸っていたところ、それとは無関係ですが、便利な設定を見つけました。既に知っている人も多いと思いますが、わたしはつい先ほど知りました…

わたしたちのチームは、VS Code Remote Developmentを介して、ローカルコンテナ上で開発しています。もちろん、Dockerfileやdevcontainer.jsonもチームで共有しています。コンテナ内で使うVS Code拡張機能についてもdevcontainer.jsonで管理して、共有しているのですが、それ以外の拡張機能を使いたくなるときってありますよね？

.devcontainer/devcontainer.json

{
   ...,
  "extensions": [
    "esbenp.prettier-vscode",
    "ms-python.python",
    "ms-toolsai.jupyter",
    "bungcip.better-toml"
  ]
}

わたしは、GitLens、Git Graph、GitHub Pull Requests and Issues、Code Spell Checker あたりを愛用しているのですが、今までこれらはコンテナビルド後に手動でインストールしていました。

これって実はVS Codeの設定で指定できるようです。今まで知りませんでした…

Userのsettings.json

{
  ...,
  "remote.containers.defaultExtensions": [
    "github.vscode-pull-request-github",
    "eamodio.gitlens",
    "mhutchie.git-graph",
    "streetsidesoftware.code-spell-checker"
  ]
}