こんにちは、アスクルの いのだい です。
アスクルでは社内のチャットツールとしてSlackを利用しており、分報チャンネルで日々思ったことをつぶやいています。2019年が終わり、自分がたくさん発言したことはなんだろう？？と思い、分報チャンネルの発言を集計してみることにしました。 Slack API が json 形式でレスポンスを返してくることを知っていたので、Python 3 で実装にチャレンジします。
続きを読むスクラム開発をボトムアップで始める (1) 〜 Impediment Listから始める 〜
自己紹介
はじめまして「むらたん」です。昨年9月にアスクルへ入社し、3PL事業であるOPA（Open Platform by ASKUL）を担当しています。事業についての詳細はこちらをご覧ください。
OPAはASKULやLOHACOと比べると歴の浅いサービスで、エンジニアチームはまだ立ち上げ段階ということもあることから、現在取り組んでいるチーム作りについて、何回かに分けて紹介したいと思います。
よくあるチーム作りと陥りがちな光景
チームの立ち上げ段階といえば、インセプションデッキを作ったり、ステークホルダーと共にチームビルディングに関するワークショップを小一時間やったりして、チームビルディングできた気になることがありますが、ほとんどの場合、それは幻想だと思っています。
チームの存在意義や目標の共有ができたとしても、チームメンバーの物事の捉え方や考え方、業務の進め方、保有スキルなど、メンバー同士で知らない事の方が多く、チーム活動を始めても機能せず、混乱状態に陥ります。
タックマンモデルと呼ばれるチームの成長段階を表したモデルでは、以下のように定義されています。
| フェーズ | 説明 |
|---|---|
| 形成期 (Forming) | チームが編成され、メンバー同士のこともよく分からないまま、チーム共通の目標を模索している時期 |
| 混乱期 (Storming) | チーム共通の目標や業務の進め方について、メンバー同士が衝突する時期 |
| 統一期 (Norming) | 混乱が収束し、チーム共通の目標や業務の進め方が定まる時期 |
| 機能期 (Performing) | メンバー同士が連動し、チームメンバー数以上の成果が出る時期 |
| 散会期 (Adjourning) | 何らかの理由でチームが解散する時期 |
ここでも混乱期が定義されていることから、チーム立ち上げ後に混乱状態となることは一般的だと言えます。しかし、メンバー同士で知らない事がある状態であれば、メンバー同士の衝突に加え、認識齟齬による計画とのズレや作業の手戻りが生じたりもするので、必要以上に混乱します。
その状態を脱するには、チームメンバー同士の透明性を確保する必要があります。
チームメンバー同士の透明性を確保する
アジャイル開発でおなじみの「スクラム」は、現状を可視化し、下記の状態を保つように努める業務の進め方で、役割、会議体、成果物、時間概念に関するルールが定められています。
- 透明性：自分たちの置かれている状況が瞬時に把握できる状態
- 検査 ：置かれている状況の良し悪しが判断できる状態
- 適応 ：状況をより良くできる状態
スクラムで定められたすべてのルールを適用しないとスクラムで開発をやっている状態とは言えませんが、個別のルールを採用するだけでもチームの活動が改善することもあります。
有名どころだと、ふりかえり (Sprint Retrospective) や、デイリースタンドアップミーティング (Daily Scrum) でしょうか。以降、スクラムのルールは英語で書きますので、ルールの詳細についてはスクラムガイドをご参照ください。
これらのルールは導入が容易なため、チーム活動の序盤で取り入れられたりしますが、ルールの背後にある目的や、メンバー同士の理解がない不透明な状態では、導入効果が薄いのではないかと思います。
そこで、私が取り組んでいる、タックマンモデルに則り、スクラムを段階的に適用しながらチームビルディングする方法を紹介します。
タックマンモデル×スクラム
前述の通り、チームのフェーズには段階があるため、スクラムのルールをチームメンバーの透明性の確保、つまり、チームやメンバーのことを理解するために活用します。
チームやメンバーの理解が進み、チームとしての課題の真因が明確になったら、スクラムのルールやエクストリームプログラミング (XP) で提唱されているプラクティスを用いて課題解決を試みます。
このとき、解決すべき課題が明確になっていれば、スクラムやXPの教科書に書かれている模範的な型をどう実践するか、自ずと見えてくるのではないかと思います。
あとはチームに即した形でプロセスを作り上げていけば、チームメンバーの理解を深めながらチーム活動を遂行できるようになります。行き着く先はチームに即したスクラム開発の完成形かもしれませんし、別の手法かもしれません。
タックマンモデルとスクラムの関係をまとめると、以下のようになります。
| フェーズ | 説明 | スクラムのルールを適用する目的 | スクラムの状態 |
|---|---|---|---|
| 形成期 | チームメンバーを理解し、お互いの透明性を確保する時期 | チーム課題のあぶり出しと管理、解決に向けた仮説検証 | スクラムの【前準備】 |
| 混乱期 | チームやメンバーの特性に合わせて、スクラムを形作る時期 | チームに即したルールのテーラリング | スクラム、または別の手法の【開始地点】 |
| 統一期 | チームとしての生産性を向上させる時期 | チームの生産性やビジネスKPIの可視化と向上 | スクラム、または別の手法を【守】 |
| 機能期 | チームが所属する組織の価値を向上させる時期 | 組織を取り巻くビジネス環境の変化への追従 | スクラム、または別の手法を【破】 |
| 散会期 | チームが解散してメンバーが新しいチームを組成する時期 | 組織内へのスケール | スクラム、または別の手法を【離】 |
Impediment Listから始める
さて、本題です。Impediment Listはスクラムのルールで定められている成果物の1つで、チームの活動を支援する役割であるスクラムマスター(Scrum Master)が、チームの活動を阻害する要因を管理するものです。
チームの活動を阻害する要因として、チームの活動拠点のファシリティや他部門との関わり方などチーム外に目が行きがちです。
しかし、チームが形成期でチームやメンバーの特性についての理解が深まっていないようであれば、それらに加えて、チームやメンバーについて理解できていないことも管理して、日々のチーム活動の中で優先度を上げて対応します。チームやメンバーの理解が浅い状態で外的要因を解消しても、その打ち手が本当に効果的か分からないためです。
と、言うのは簡単なので、スクラムのルールの一部を用いて、スクラムマスターが意識するポイントや日々の活動チームやメンバーを理解をするポイントの例を紹介します。（あくまでも、私の取組み例で、個人差があります）
スクラムマスターとして意識するスクラムのルールとポイント
- スタート地点となるスクラムのルール：Impediment List
- 上述の通り、チームやメンバーの不透明な部分を課題として管理し、打ち手を仮説検証する
- 特定のメンバーに対しての課題であっても、チームの課題として扱い、チームで解決する手立てを講じる
- 課題がどうなったかを評価し、新しい施策を講じるスクラムのルール：Sprint Retrospective
- 目の前の課題を解決し、新しい課題を生み出し、また、解決するというサイクルをつくる
- チーム形成の初期段階ではチームメンバーの目線が揃うまでは公式の活動とせず、スクラムマスターの内省に留める
日々の活動からチームやメンバーを理解するためのスクラムのルールとポイント
- 活動のフィードバックサイクルとなるスクラムのルール：Sprint
- 活動のフィードバックサイクルを決めることで、チームの活動にリズムをつくる
- 活動の良し悪しの評価軸となるスクラムのルール：Sprint Planning
- フィードバックサイクルに対して計画を立てることで、予定と実績が把握できる状態をつくる
- タスクの組み方、見通しの立て方、課題解決の方法から、業務の進め方や保有スキルを確認する
- 日々の活動に対するコミットとなるスクラムのルール：Daily Scrum
- チームメンバーの日々の状況を確認する場をつくる
- メンバーの物事の捉え方や業務の進め方を観察する
- 活動結果を評価するスクラムのルール：Sprint Review
- 計画に対して、どれだけ達成できたかを確認する場をつくる
- メンバーが活動結果をどのように捉えているかを観察する
赤裸々告白：OPAのエンジニアチームについて
最後にOPAチームの状況を紹介したいと思います。フェーズとしては混乱期で、チームが抱える最大の敵、認識のズレを打破する施策を試行錯誤しているところです。書き出してみると当たり前のことではありますが、チームの課題に則した形でスクラム開発の手法を作り上げています。
チームの課題とその対応
- メンバーのキャリアやバックグラウンドが異なるため、同じ単語を使っていても意味が異なっている。
- 受容するしかないので、使われている単語が何を指しているのか、会話の中で探りながらイメージをすりあわせる。
- ゴールイメージがチームメンバーで揃わないまま着手してしまい、タスク完了まで持っていけない。
- スプリントプランニングでタスクへの落とし込み、完了条件の設定に注力する。
- メンバーの保有するスキルが偏っており、タスクが平準化できない。
- プロダクトコードを用いて、読み解き方やコードレビューの観点、設計思想を理解する勉強会を定期開催する。
最後に
チームが機能しない、上手くスクラム開発ができていないと感じる場合、メンバー同士の目線が合っていないことが原因で混乱期から抜け出せていないのかもしれません。今回の取り組み例が一助になれば幸いです。
GitHub Actions 依存関係キャッシュを検証する
こんにちは。最近GitHub Actionsをいじりはじめた、「みやまえゆたか」です。
GitHub Actionsには依存関係をキャッシュする機能があります。 -> 依存関係をキャッシュしてワークフローのスピードを上げる - GitHub ヘルプ
キャッシュするとどれくらい効果があるのか？ 検証してみました。
続きを読むプロジェクトレトロスペクティブでワールドカフェをやったので全部見せます
こんにちは。エンジニアリングマネージャーの さとうだいすけ です。
アスクルではプロジェクトのはじめにインセプションデッキを作成し、プロジェクトのおわりにプロジェクトレトロスペクティブを行っています。 本記事では、プロジェクトレトロスペクティブにて、ワールドカフェを実施したお話を（できる限り）全部お見せしようと思います。
ワールドカフェとは
ワールドカフェとは、カフェのようなリラックスした空間と雰囲気の中で、少人数に分かれたテーブルで対話を行います。ただ対話をするのではなく、他のテーブルとメンバーをシャッフルをして対話を繰り返すことで参加者全員の知識と意見を集約することができるという対話手法です。
続きを読むCustom Metric の StackDriver Monitoring Slack 連携
こんにちは。ASKUL ごましおらぶです。
何をやるのか
GCP (※Google Cloud Platform) 上の何らかの処理が、正常に処理されているはずなのに異常な状態になることもあります。そのような時には簡単な設定だけでアラートを飛ばして検知したい。すなわちモニタリング環境を簡単な手順で構築してみましょう。
簡単な方法は何か
GCP 上のログをモニタリングする方法として、エラーログをフィルターしてエクスポート(Cloud Pub/Sub, Cloud Storage)エクスポート先から通知処理(ex: Cloud Functions から Slack Webhook を叩く)を行う方法があります。
※ ログのエクスポートについては公式ドキュメント:ログのエクスポートの概要を参考
※ エクスポートしたログの利用については公式ドキュメント:エクスポートしたログの使用を参考
Stackdriver の Notifications の設定を利用すれば前者の方法よりもっと簡単に Slack と連携させることが出来ます。
この記事のポイント
Default Metrics の Monitoring の構築方法は公式ドキュメントなどに載っていますが Custom Metrics の Monitoring 設定 + Slack 連携をまとめた資料が見つからなかったので、記事を書こうと思いました。それでは、構築方法を解説していきます。
続きを読む第30回高専プロコン 都城大会 に行ってきました！ #procon30
アスクルの こたにん@Kotanin0 です。
先日、2019年10月13日（日）～14日（月）に宮崎の都城で開催された、高専プロコンのレポートです！
プロコン？
全国高等専門学校プログラミングコンテスト、略してプロコンをご存知ですか？
その前に「ロボコン」はご存知ですか？
学生がロボットを自作して競技をする、地上波で中継してたり、過去には映画化されていたりして、聞いたことある人多いかも。
全国高等専門学校ロボットコンテスト、略してロボコン。
ということは。
プロコンは、プログラミングで競い合うイベント？
その通り。
プロコンは、全国の高専の学生がプログラミングを武器に、競技したり作品展示したりするイベントです。
1990年から始まっている本大会は、今年で30回目の開催、意外に歴史ありますね。
冒頭で話した高専ロボコンは1988年からはじまっているので、実はそんなに差はなかったらしい。
プロコンの3大部門
プロコンは、3つの部門に分かれています。
競技部門
ルールに従った競技を行う部門、AI将棋をもう少しライトにしたようなイメージ。
リアルタイムでプログラミングを行うものではなく、あらかじめ決められた競技ルールに対して、いかに最適な解を導くことができるか。
そのアルゴリズムを持ち寄って、競技に臨む感じ。
課題部門
ある課題に対して、作品を制作して展示・発表する部門。
今年は昨年に引き続き「ICT を活用した地域活性化」という課題、課題に対してアイディアを出してソリューションを作る。
課題は2年に1回アップデートされます。
自由部門
ノンジャンル、とにかく自由な発想で作品を作り展示・発表する部門。
日常生活の中からの着想、最新技術を取り入れたものなど、様々な作品があります。
余談ですが、私は学生のときに課題部門で予選落ちを喫しました。。。
プロコンに協賛しました！（2年連続2回目）
実は弊社アスクルは、このプロコンに昨年から協賛しています。
そのときの記事がコチラ。
tech.askul.co.jp
このときの本文に、こんなことを書いていました。
次回の第30回大会、都城。
断言はできないですが、来年以降も引き続き協賛したいきもちです！
みなさん、来年またお会いしましょう！！
1年前のフラグ、ちゃんと回収できました！
続きを読む社内ポータル徘徊にさようなら！Webスクレイピングで更新自動通知
こんにちは。みやまえゆたかです。
導入
当社の社内ポータルサイトはSharePointで作られています。
各種申請書類やマニュアル、規定などへのリンクが集まっていて、 その中でも、新着情報が流れてくる「掲示板」のページは「更新がないか？」1日に1~2回は見に行くようにしています。
ただ、業務や会議がたてこんでいると「掲示板」を見ることを忘れ、重要な情報を見過ごしてしまうことがありました。
「なんで新着をスマホに通知してくれないんだ！！！」
更新が有るか無いかも分からないサイトを定期的に見る作業に疲れた私は、 「ポータルサイトをWebスクレイピングして、更新があったらSlackに通知する」機能を作りました。
処理は以下のようになっています。
ポータルサイトの「掲示板」を定期的にWebスクレイピングする
更新がないかチェックする
更新があったら、記事のタイトルとURLをSlackにPostする
これで、社内のSharePointポータルを定期的に見に行く必要がなくなりました！
