owkyのブログ

マネジメントについて勉強するブログ

スクラムをやってみての Good と Bad

社内でアジャイルスクラムの勉強会をやることになった。事前にテーマなどをヒアリングしたときに「スクラムをやってみて感じた Good と Bad は?」というテーマが出てきたので、ちょっと考えてみた。

自分は10年の歴史があるプロダクトの開発組織のマネージャーをしている。最近はスクラムの導入に取り組んでおり、組織内の一部のチームでスクラムをやり始めた。今年は新規プロダクトをスクラムで開発している。社内でも活動が認知され、アジャイルスクラムの勉強会を依頼されるという経緯だった。

Good

主体的に改善が進む強いチームが生まれた

スプリントの最後に行うふりかえりがとても良い活動だった。チームは、どうしたらコミットしたプロダクトバックログを全て完了させることができたか?を議論する。各自の視点から課題点と改善策が次々と提案され、チームとしてのNext Actionを決定する。一人ひとりが、品質や納期に関して当事者意識を持って議論していたことが印象的だった。スプリントという短期間にフォーカスすることで、自分たちの手に収まるサイズの問題になったんだと思う。これをスプリントごとに繰り返すので、チームはどんどん成長していく。

ふりかえりが流行った

組織内の一部のチームでスクラムを始めたとき、スクラムチームのふりかえり活動を見て、他のチームが自発的に定期のふりかえりをやりはじめた。Fun Done Learnの模造紙がいくつもオフィスの壁に貼られるようになった。

組織の一部にスクラムという刺激を与えた結果、良い効果が他のチームや組織全体に伝搬していく光景は、自分のマネジメント経験の中でとても貴重なものとなっている。

開発と検証の連携・一体感強まる

スクラムを始めた当初は組織が職能で分かれており、QAチームと開発チームが上手く連携できない課題があった。スクラムチームを作ることで、QAと開発者が同じ目的を持つチームで活動するようになり、上流工程からしっかりと品質を作り込むことができるようになった。設計段階においてチームでテスト観点を読み合わせるというような活動が自発的に行われるようになった。

柔軟な戦略変更にも前向きに対応できている

スクラムの良い効果としてはベタなものになると思うけど、やはりこれは大きい。新規のプロダクトは、市場の反応に応じて製品戦略が激しく変動する。開発したけど捨てることになった機能もそれなりにあった。それでも、反復的に学習しながら開発を進めていくというアジャイルな土壌があったので、前向きに取り組むことができていたと思う。市場からの学びをスクラムチームに説明し共に理解を深めたときに、あー透明性ってこういうこと?と思ったりした。

Bad

Badはない!本当に思いつかない。強いていうなら、スクラムを実行するのってけっこうパワーを使うよねというくらい。でもこれも必要なところに必要なだけのパワーをかけられてると理解しているので、別にBadってわけでもないんだよなあ。

マネジメントって何をすればいいの?

エンジニアとしてある程度キャリアを積んでいくと、マネジメントに携わることを求められるときがくる。弊社のキャリアパスにも、組織やチームを導いて事業に貢献するというようなマネージャーになるコースと、より優れた技術力をもって事業の課題に取り組んでいくというエンジニアを極めていくようなコースとの分岐点が存在する。私はマネージャーとなり、現在は自部門のラインマネージャーも勤めているが、分岐点を迎えたエンジニアが急にマネジメントというものを求められて迷走しているのをよく見る。

よくあるのは「マネジメントする=タスク管理する・スケジュール管理する・進捗管理する」だと思っているパターン。自分もこう考えていたときがあって、マネジメントって退屈だなーとそのときは思っていた。でもこれは間違っていた。実はこれは手段と目的が逆転しちゃっている。

「マネジメントといっても何をすればいいのかよくわからない」という相談を受けることもよくある。マネジメントというのは結局のところ「何とかして結果を出すこと」である(これは様々な記事やPodcastからの受け売りだけど、端的に本質を述べていて好きな表現)。そして、そこには求められる結果を阻害する「何とかしないといけない課題」がある。その課題を見つけて解決するために行うあらゆることが具体的なマネジメントの手段になる。なので、タスク管理もスケジュール管理も進捗管理も一つの手段に過ぎない。大事なのは、求められる結果をよく理解し、それを阻害する課題を見つけ出すこと、ということだ。

意識せずマネジメントに取り組んでいたということもあると思う。新人のメンターをとして、面倒なタスクでも背景や必要性をきちんと説明し、前向きに仕事に取り組んでもらえるように計らった、みたいなことも立派なマネジメントだと思う。

マネジメントとは?

  • 何とかして結果を出すこと!
  • 求められる結果とは何かをよく理解しよう
  • 結果を阻む課題を見つけよう
  • あらゆる手段を使って課題を解決しよう

これに気付いたとき、自分はマネジメントって楽しいかも!と思えた。結果を出すための手段、課題を解決するための手段っていろいろあって、それらを勉強して身に付けて、今回はこれが使えるかな?と試行錯誤しながら適用していくのは、エンジニアリングと近いものを感じている。

最初はわからないことも多いと思うので、マネージャーにどんどん質問すれば良いと思う。「私が/私のチームが出すべき結果はこれで合ってますか?」とか「この課題を解決しないと結果を出すことはできませんが、どう解決しようか悩んでいるのでヒントをください」とか、こんな相談が来たら嬉しいし、安心するので。

『今日もていねいに』を読んだ。自分なりの「ていねいに生きる」を見つけてみよう。

松浦弥太郎さんの『今日もていねいに。』を読んだ。

忙しすぎて自分の時間が取れてないなーとか、やりたいことがやれてないなーとかモヤモヤしながら過ごす日々。この本を読んでみたら「あー俺、雑に生きてんなー」と気付いてしまった。「ていねいに」生きたら、人生が何か良い方向に変わりそうな、そんな気にさせてくれる本だった。

ていねいに生きる

ていねいに生きるというのは、日々の暮らしが豊かなものになるように、自分自身に向き合うこと。自分なりのていねいな生き方を考えることが、その第一歩になるのだと理解した。

日々の暮らしというのは、一つずつ自分で選んだ行動の積み重ねで成っている。つまり、ていねいに生きるとは、その一つ一つの行動をていねいに選ぶこと。

そもそも「ていねいに」とは何なのか、Weblio辞書で引いてみると、このようにある。

丁寧(ていねい)とは、細かい部分に注意や気配りが行き届いているさま、入念に丹精込めて行うさまなどを表現する言葉です。

日々の暮らしにおいて、何に注意や気配りが行き届くようにするか。これは一人ひとりの人生において大事にしているものとか、達成したいものとか、そういう個人の価値観によって変わってくる。

なので、ていねいに生きるために重要なのは、自分自身と向き合って、自分なりの「ていねいに」を見つけ出すことなんだと。

ていねいに生きるためのヒント

「はじめに」の章ではこのように述べられている。

暮らしのなかの一つ一つの出来事と向き合い、じっくりと考え、頭だけでなく自分という存在すべてで取り組むためのやり方を、たくさん並べてみました。 慌しい世の中や人間関係でブレてしまった心の矛先を、そっと自分自身に向けなおす僕なりのやり方を、紹介しようと思います。

自分なりの「ていねいに」をどうやって見つけるか。この本では、松浦弥太郎さんの「ていねいに」の実例がたくさん紹介されている。その価値観に触れることで、自分なりの「ていねいに」のヒントを得ることができた。

私が共感したものをいくつか紹介する。

毎日が自分プロジェクト

仕事でもいいし、毎日の暮らしのなかの、些細なことでもいい。「これができたら、すてきだろうな、面白いだろうな、きっと新しい発見があるだろうな」そういった小さなプロジェクトをいくつもこしらえ、あれこれやり方を工夫し、夢中になって挑戦し、順番にクリアしていくことです。

—『今日もていねいに。 (PHP文庫)』松浦 弥太郎著 https://a.co/dFJUzcB

自分プロジェクトになりそうなのは、アジャイルやチームマネジメントの文脈の知識に触れたり実践を通して学びを得ることだったり、最近始めたエレキベースの練習かなあ。

暮らしの引き算

増やしたら、減らす。ごくシンプルなこのやり方が、ていねいに生きる秘訣です。新しいものを一つ手に入れたら、部屋のなかにあるものを一つなくす。そうすると、いつも余白がある暮らしとなります。

—『今日もていねいに。 (PHP文庫)』松浦 弥太郎著 https://a.co/dFJUzcB

やりたいことはやればやるほど増えていくので、厳選してあえて何か捨てるというのは、見落としがちな価値観だ。毎日やっていたゲームをやめてみた。

自分の使い道

たとえば自分は、フライパンなのか、まな板なのか、土鍋なのか――。つぶさに観察し、自分のことをできる限り正しく理解しましょう。そのためには、家族、会社、地域、社会、すべての人間とのかかわりのなかで、自分という道具はどう役に立ち、何に貢献できるかを考えてみるといいのです。

—『今日もていねいに。 (PHP文庫)』松浦 弥太郎著 https://a.co/gfSilcX

自分が本当に力を発揮できるものは何なのか。ていねいに自分を見つめ直す。ちょっと怖いけど、自分がまだ知らない"自分"を見つけられそう。

まとめ

松浦弥太郎さんの『今日もていねいに。』を読んで、ていねいに生きるという価値観に共感した。どうやって「ていねいに生きる」のかは個人の解釈があると思うが、それを考えることが「ていねいに生きる」ことの第一歩だと思う。この本には、そのためのヒントがいろいろと書かれていた。

GTDの実践 ― タスク管理の具体例

タスク管理の手法であるGTDについて、その方法論についての文献は多いが、以下のような実践するうえでの具体例はあまり見つからない。

  • 使っているツールは?
  • リストのレビューをやるタイミングは?
  • どういうときにリストにタスクを出し入れする?

実際にGTDを1ヶ月やってみて、自分の生活や仕事のスタイルに合うようなやり方を見つけることができたので、 ひとつの具体例としてここに残しておく。 これからGTDを始めようという人や、いまいちやりにくさを感じている人にとって、良いヒントになれば幸いだ。

GTDのツールはtrello

ツールはtrelloを使っている。

GTDでは、タスクなど気になることの全てを頭の外に取り出す。 取り出したものは「カレンダー」や「連絡待ち」といった入れ物に分類して保管しておく。 このタスクと入れ物の関係性、データ構造を持っている電子的なツールを考えたときに、手に馴染みがあったのがtrelloだった。 trelloに「GTD」というボードを作成し、そこに「次に取るべき行動」や「連絡待ち」という名前のリストを作成する。

仕事用のMacか私用のiPhoneのどちらかは必ず手元にあるので、trelloであればいつでもタスク管理ができる。 また、Office365との連携が可能だったりと、外部ツールとの親和性が高いのもtrelloの良いところ。

インボックスにタスクを集める具体例

trelloに「インボックス」というリストを作成する。

タスクや気になることが生まれたら、すぐに「インボックス」リストにカードを作成する。 例えば「今週中にこれをやってほしい」という依頼が来たとき、依頼内容をインボックスに入れてから「わかりました」と返事をしておいていったん忘れる。

メールチェックは午前中の一日一回で時間を決めている。 詳しく読む必要があったり、返信が必要なものは、とりあえずインボックスに入れておいて、あとから処理する。 会社のメールはOffice365なので、Power Automateを使って、メールにフラグしたらtrelloのインボックス・リストにカードを作成するように自動化した。

通勤中の電車の中でメールチェックを済ませて、会社に着いたらインボックスにあるタスクを各リストに分類する、という流れが定着した。

「連絡待ち」リストを管理する具体例

これもtrelloの「連絡待ち」リストにカードを追加するのだが、カードには連絡待ちとして日付を書くようにしている。 日付を書いておくことで、返信がない場合のリマインドがしやすくなる。

インボックスを空にするときに、連絡待ちリストもチェックするようにしている。 1週間連絡がないものはリマインドする。 例えば、3/9(月)に出したメールの場合は 3/9(月) (mail) ○○○○○について というカードを作成する。 1週間経った翌週の月曜にリマインドを行う。

リマインドしたときには、リマインドした日付を更に先頭に追記する。

「カレンダー」を管理する具体例

カレンダーは、会社で使っているOffice365のOutolook予定表をそのまま使う。 期日があるタスクは、そのタスクを完了するための予定を予定表に入れておく。

さらに、今週中には終わらせておきたいと思うタスクもカレンダーに入れている。 こうすることで、タスクを完了させるための作業時間を確保(スケジュールブロック)できるので、タスクを進めやすくなる。

「プロジェクト」リストを管理する具体例

プロジェクトの完了条件をカードに明記しておき、毎週末にプロジェクト・レビューをしている。

完了条件とは、何を実現したらそのプロジェクトは完了するのかという条件。 ここで完了条件の一つ一つが大きかったり、数が多かったりする場合は、プロジェクトを分割する。 プロジェクトが大きいといつまで経ってもカードが減らないので、だんだんモチベーションが低下してくる。 プロジェクトを小さくしておくと、それを完了したときに小さな達成感があるので、続けやすくなる。

プロジェクト・レビューではプロジェクトを全て見直して、今週進んだ分と来週に進めたい分を整理する。 来週に進めたい作業は、このタイミングでカレンダーに入れてしまう。

レビューにはまとまった時間が必要になる。 会社にいる間にこの時間を取るのはなかなか難しいので、週末に家でゆっくりやっている。 会社でもできる人は、もちろん休日を使わない方がいい。

まとめ

  • GTDを実践するための、私の場合の具体例を紹介した
  • まず1ヶ月やってみて、このやり方に落ち着いた
  • Office365を使っている職場では馴染むやり方だと思う

Vueの単一ファイルコンポーネントでAPIリクエストした結果を表示する

APIから取ってきたデータを表示するVueコンポーネントを作ってみる。 その際に、APIモックのサーバーをmockyで立てる。

前回はVueの単一ファイルコンポーネントのサンプルを学習した。 Docker環境などはそちらも参考に。

mockyでAPIモックのサーバーを立てる

github.com

mockyのREADMEに従って簡単にAPIモックサーバーを実行することができる。 今回はjsonファイルを読み込んで、それをAPIレスポンスとして返すようにする。

["aaa", "bbb", "ccc"]
var mocky = require ('mocky');
var fs = require('fs');

mocky.createServer([{
  url: '/api/projects',
  method: 'get',
  res: function(req, res, callback) {
    fs.readFile('./mock/projects.json', 'utf8', function(err, text) {
      callback(null, {
    status: 200,
    headers: {'Access-Control-Allow-Origin': 'http://localhost'},
    body: JSON.stringify(text)
      });
    });
  }
}]).listen(4321);

APIモックはフロントエンドのアプリとは別ポート(4321)でアクセスするので、Access-Control-Allow-Originヘッダーの指定が必要。 これが無いと、ブラウザ上でCORS(Cross-Origin Resource Sharing)のエラーが出てAPIリクエストができない。

docker runするときは、フロントエンドのアプリとAPIモックのそれぞれ用にポートフォワーディングの設定をする。

$ docker run -it -v ${PWD}:/usr/src/app -p 80:8080 -p 4321:4321 my/vue /bin/bash

APIリクエストした結果を表示するVueコンポーネント

公式のクックブックを参考にしてaxiosを使う。

jp.vuejs.org

<template>
  <div>
    <h1>Project List</h1>

    <ul>
      <li v-for="title in projects" :key="title">{{ title }}</li>
    </ul>
  </div>
</template>

<script>
import axios from 'axios'

export default {
  data () {
    return { projects: [] }
  },
  mounted: function () {
    axios.get('http://localhost:4321/api/projects')
      .then(response => (this.projects = JSON.parse(response.data)))
  }
}
</script>

これ↑はWarning解決済みのコードだが、前回のサンプルを参考にpropsオプションを使ったらWarningが出てしまった。

[Vue warn]:
Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders.
Instead, use a data or computed property based on the prop's value. Prop being mutated: "projects"

propsオプションは親コンポーネントからデータを受け取るためのオプションなので子コンポーネントでデータを変更するとバインディングが壊れてしまうからダメ」みたいな意味のWarningらしい。 あまりちゃんと理解できてないので、まだ勉強が必要。

コンポーネントの中で扱えれば良いデータなのでdataオプションを使えば良さそうとして解決した。 前述のクックブックの例でもdataオプションを使っている。

Dockerfile

FROM node:13

WORKDIR /usr/src/app
RUN npm install -g @vue/cli && \
    npm install mocky && \
    npm install axios
$ docker build -t my/vue
$ docker run -it --name myvue -v ${PWD}:/usr/src/app -p 80:8080 -p 4321:4321 my/vue /bin/bash
root@d6be785fef88:/usr/src/app# npm run serve
$ docker exec -it myvue /bin/bash
root@0c96160127e3:/usr/src/app# node mock.js

DockerでVue CLI実行環境を作成して単一ファイルコンポーネントのサンプル実装を試す

Vue.jsの勉強をしている。 単一ファイルコンポーネントを利用する場合にVue CLIを使うと良いと見たので、Dockerで環境を用意してサンプル実装をしてみる。

cli.vuejs.org

DockerでVue CLIの実行環境

node.jsのdockerイメージを使う。

$ docker run --name vue-sample -it -v ${PWD}:/usr/src/app -p 80:8080 node:13 /bin/bash

Vue CLIをインストールする。

root@ffaa7ad72bd6:/# npm install -g @vue/cli`
root@ffaa7ad72bd6:/# vue --version
@vue/cli 4.1.1

Vue CLIでVueのプロジェクトを作成

root@ffaa7ad72bd6:/# cd /usr/src/app
root@ffaa7ad72bd6:/usr/src/app# vue create .
  • オプションはDefaultを選んだ
  • Package Managerはnpmを選んだ
root@ffaa7ad72bd6:/usr/src/app# npm run serve

http://localhost/にアクセスするとサンプルが表示される。

f:id:owky2413:20191208190146p:plain
Vueプロジェクト作成時のデフォルトページ

自作のコンポーネントを追加してみる

新たな単一ファイルコンポーネント "Members" を追加してみる。

<template>
  <div>
    <h3>Members</h3>
    <ul>
      <li v-for="name in members" :key="name">{{ name }}</li>
    </ul>
  </div>
</template>

<script>
export default {
  props: {
    members: {
      type: Array
    }
  }
}
</script>

<style scoped>
h3 {
  margin: 40px 0 0;
}
ul {
  list-style-type: none;
  padding: 0;
}
li {
  display: inline-block;
  margin: 0 10px;
}
</style>
<template>
  <div id="app">
    <img alt="Vue logo" src="./assets/logo.png">
    <HelloWorld msg="Welcome to Your Vue.js App"/>
    <Members :members="['AKihiro.H', 'Sei.M', 'Masato.M', 'Tsuyoshi.W', 'Ryoya.O', 'Hirotaka.M', 'Kento.H', 'Yojiro.T', 'Keigo.H', 'Diego.O', 'Kensuke.N']"/>
  </div>
</template>

<script>
import HelloWorld from './components/HelloWorld.vue'
import Members from './components/Members.vue'

export default {
  name: 'app',
  components: {
    HelloWorld,
    Members
  }
}
</script>

<style>
略
</style>

こんな感じにメンバー一覧が追加される。

f:id:owky2413:20191208222919p:plain
プロジェクト作成時のサンプルにコンポーネントを追加

Dockerfile

FROM node:13

WORKDIR /usr/src/app
RUN npm install -g @vue/cli
$ docker build -t my/vue .
$ docker run -it -v ${PWD}:/usr/src/app -p 80:8080 my/vue /bin/bash
root@c598fbfb1771:/usr/src/app# npm run serve

プロダクトマネジメント・トライアングルを見て、もしかして自分はプロダクトマネージャーなのではと自覚した

プロダクトマネジメント・トライアングルというものを知った。 これはすごいな。 プロダクトマネージャーって「何でもやるんだな」とか「人によってやってることが違うな」とか「結局何をやる人なんだ」とか、役割が掴みきれない印象があった。 そんなモヤモヤしていたところの理解が整理されて、とても頭がスッキリした。

今の会社ではプロダクトマネージャーという名前の役割は存在しないが、自分がやっている仕事はプロダクトマネージャーなのではないかと思った。

プロダクトマネジメント・トライアングル

プロダクトマネジメントの責務を表現するためのグラフィックモデル。 「プロダクト」を中心に、その要素となる「開発者」「ユーザー」「ビジネス」を三方に配置したトライアングルで表現している。 翻訳記事がとても分かりやすいのでオススメ。

ninjinkun.hatenablog.com

プロダクトマネージャーの責任として以下の2点が述べられている。

  1. プロダクトマネジメントはプロダクトネットワークの要素間の重要な空白領域を認識し、埋めなければならない。

  2. プロダクトマネジメントはプロダクトネットワークの各要素に影響を与えるために、異なるインプットを統合しなければならない。

この2点を意識して必要なアクションを取ろうと思うと、確かに何でもやる人みたいになる。 でも一人では空白を埋めきれないこともある。 だから複数人でプロダクトマネージャーを務めることもある。 それぞれの得意不得意を補完し合いながら全体をカバーする。 だから色んなタイプのプロダクトマネージャーがいるのだろう。

プロダクトマネジメントトライアングルは、プロダクトマネージャーが自分の役割を効果的に説明したり、自信の強みと弱みについてより良い認識を持つためにも使うことができる。

自分の仕事もプロダクトマネジメント・トライアングルの上にプロットすることができそうだ。

いまの仕事をプロットしてみる

実際に自分が抱えている仕事を、プロダクトマネジメント・トライアングルの上にプロットしてみた。

f:id:owky2413:20191110131847p:plain

空白領域を埋める仕事
  • 開発ロードマップの検討と実行管理
  • プロジェクトマネジメント
  • アジャイル開発を取り入れる
融合領域の異なるインプットを統合する仕事
  • 組織設計
  • 仕様の検討や決定
  • 開発と保守の対応優先度やコストバランスの管理
  • 顧客マネジメント

それぞれの仕事の意義や性質を、再認識することができた。 やはり自分はプロダクトマネージャーなのではないか。

ちなみに、プロットできない他の仕事も抱えている。 それらの仕事はエンジニアリングマネジメント・トライアングルにプロットできるのでは? という気付きもあるのだが、それは別の記事に書くことにする。

自分の強みが見えた

プロダクトマネジメント・トライアングルの上に自分の仕事をプロットしてみて気づいたことがある。 自分が興味があったり社内で評価されている仕事は色付きの部分になる。

自分の強み

  • 開発者とビジネスの間の空白領域を埋める(図の赤色網掛け部分)
  • 開発者の元に来るユーザーとビジネスからの異なるインプットを統合する(図の青色部分)

今はいろいろと手広くやっているが、内容が薄まっている感もある。 もっと強みを伸ばして行きたい。