運用保守チームでスクラムをやってみた話

前置き

現在進行形の話なので書けないこともたくさんあるけど、自分があの時こんなことをやっていたと後日ふり返るために書き残しておく。

状況説明

チームメンバ

6名(うち1名は管理職、5名が実務担当)

  • 管理職:スクラムマスター
  • 自分:プロダクトオーナー(実際はスクラムマスター的な動きもしている)
  • 他4名:開発チーム(スキル、経験はかなりバラつきあり)

業務内容

  • とある業務システム(オンプレミス)の運用管理
    • サーバー(物理・仮想)やネットワーク装置のログ管理・リソース監視
    • セキュリティパッチの確認・適用
    • 業務用のマスターデータの更新
  • 他システムとの連携機能の保守開発
  • その他、さまざまな依頼対応

技術要素

使っている技術は以下の通り。物理インフラからDB、webアプリケーションまで幅広く取り扱っている。

こうやって書き出してみると本当にいっぱいある。もうちょっと整理して減らしたい。。。

スクラム導入の目的

【建前】

  • 属人化の問題

    今までは各担当者が守備範囲を決めて個別に作業していたため、業務知識や技術スキルが属人化してしまっていた。 担当者以外は何がどうなっているのか分からない。休みが取りづらい、人事異動が難しい。 →チームで作業する習慣が浸透すれば、属人化が解消できるのでは。

  • 業務の増加

    セキュリティ強化や既存システムの機能追加・新規システムの開発など、顧客の要望が質・量ともに年々増加している。 技術者不足や予算の制限もあり増員することが難しい。 →もっと効率的に業務を遂行できる体制・仕組みをつくりたい。

【本音】

  • 単に自分がスクラムをやってみたかった。

  • 会社としても今年度の取り組み事項として目玉になるネタが欲しかった。

    →両者の利害が一致!

やったこと(時系列)

情報収集

POStudy勉強会 vol.1 に参加(2017年5月)

https://postudy.doorkeeper.jp/events/60455

新規事業創出のための事業企画、仮説検討、プロダクトバックログの作成を学ぶワークショップ。内容が濃すぎて理解が追い付かなかった。。。

運用保守の世界とは全く違うけれど、顧客のニーズを汲み取って改善提案をしていく流れという点では非常に参考になった。

社内アジャイル研修の開催(2017年11月)

外部からプロのアジャイルコーチを招き、社員(事業部内の管理職・技術職・営業職)を対象にアジャイルスクラムの研修を開催した。

また、その前に予習として勉強会を数回開催し、アジャイルスクラムの用語、原理原則、考え方を知識として理解してもらう活動を行なった。

※新しいことを始めるにあたって、前もって上層部に理解を得ておくのは大事。地道に根気よくプッシュし続けた。

POStudy勉強会 vol.2 に参加(2018年2月)

https://postudy.doorkeeper.jp/events/69880

2017年5月のものとほぼ同じ内容。

前回は消化不良だったので再度受講したけど、やっぱり分かるようで理解しきれなかった。

頭で分かったつもりでも実際に手を動かすとあれれ・・・となる。やっぱり実践あるのみか。

開始手続き

稟議書の起案~決裁(2018年2月~4月)

アジャイルスクラム)の実施を承認してもらうため、稟議書を起案。

  • 年間計画
    • インセプションデッキの作成 ○月~○月
    • スプリントの実施 ○月~○月
    • 結果報告 ○月
    • 成果指標、目標値
  • アジャイル導入により増える工数・費用の見積もり

    • インセプションデッキの作成 ○○人日
    • プロダクトバックログの更新 ○○人日
    • スプリント実施(計画MTG、レビュー、ふりかえり) ○○人日
    • 社内報告書作成  ○○人日
    • 管理作業  ○○人日
    • 社外研修の受講費用、および工数  ○○円、○○人日 
  • 実施体制図

    • 責任者
    • 管理者
    • スクラムマスター、プロダクトオーナー、開発チーム
    • 顧客との関係、業務フロー

こんな感じの資料を作成して、直属の上司~社長に至るまで片手に余る数のハンコを押してもらい、決裁をいただいた。

こういう手続きは本当に非アジャイル的だけど、会社のルールはルール。 伝統的日本企業ではこの辺りでうんざりして諦める人も多いと思うけど、自分のやりたいことをやるには折れない気持ちで一歩ずつ前へ。

顧客説明(2018年3月)

アジャイルスクラム)を実施することについて顧客に説明。

  • 顧客と運用保守チームとのやりとり(インタフェース)は変更なし
  • 今までよりも生産性が上がる=同じ費用でより多くの仕事がこなせる

という説明をしたので、好意的に受け止めてもらえた。

スクラムの実践

チーム結成(2018年4月~)

それまでは客常駐と自社内に分かれて作業していたのを、全員一ヵ所に集合させた。

インセプションデッキ作成(2018年4月~6月)

チームの全体像や進むべき方向を明確にしてメンバの意識を合わせるため、インセプションデッキを作成した。

1. 我われはなぜここにいるのか
2. エレベーターピッチを作る
3. パッケージデザインを作る
4. やらないことリストを作る
5. 「ご近所さん」を探せ
6. 解決案を描く
7. 夜も眠れなくなるような問題は何だろう
8. 期間を見極める
9. 何を諦めるのかをはっきりさせる
10. 何がどれだけ必要なのか

一気に全部作るのは無理だったので、毎週1時間ミーティングを行ない、1~2項目ずつ作成していった。 インセプションデッキを作り上げる過程でチームメンバが対話を積み重ねることにより、業務に対する認識が深まったこと、チームメンバ同士がお互いを理解し合えたことが非常に大きな収穫だった。

プロジェクト管理ツール(JIRA)構築(2018年5月)

無償のツールもいくつか試したけど、使い勝手が良さそうなのでJIRAを購入。 初心者こそ、多少お金をかけても良い道具を使うべき。

JIRAサーバー(オンプレミス版)買い切り価格 10ユーザー$10 https://ja.atlassian.com/software/jira/pricing?tab=self-hosted

Scrum.inc 研修受講(2018年6月)

https://scrum.esm.co.jp/

東京で開催されたスクラム研修に、運用保守チームから3名が参加。

  • スクラムマスター研修 1名
  • プロダクトオーナー研修 2名

Scrum Inc.認定スクラムプロダクトオーナー(LSPO)研修を受けてきた話 https://qiita.com/takusamar/items/97c8b734a065312bb310

プロダクトオーナー研修で学んだことを一言でいうと「Courage! 」

プロダクトオーナーは顧客とチームを結ぶ存在。50%を顧客と共に過ごし、残り50%はチームと共に過ごす。  →スクラムを成功させるためにはコミュニケーションが非常に重要となる。

コミュニケーションを取ることを恐れない。スクラムを前進させる勇気が一番大事。

スプリントの実施(2018年5月~)

最初は2週間スプリントでやろうとしたが、

  • 週単位での作業、週単位での報告が多い。
  • 割り込みの依頼が頻繁にあり、2週間だと作業計画の変更がしづらい。

といった現場業務の特性を踏まえて、スプリント期間は1週間に決定。

また、週の始めと終わり(月、金)はいろいろと立て込むので、スプリントは「水曜~火曜」と決めた。

  • スプリント計画ミーティング(水曜AM) 1時間
  • デイリースクラム(毎朝) 5~10分
  • スプリントレビュー(火曜PM) 1時間
  • スプリントレトロスペクティブ(火曜PM) 1時間

だいたいこのような感じでミーティングを行なっている。

5月中旬から始めて、ここまで15回のスプリントを実施した感想。

  • 各作業をスプリント内(1週間以内)で終わるボリュームに分割して、計画を立てられるようになってきた。
  • 優先順位(重要度や納期)を意識して、順番の入れ替えや担当者の変更、作業負荷の平準化ができるようになってきた。
  • 相対見積もり(ストーリーポイント)の判断が難しい。 結局、時間換算(1ポイント=1.0~1.5H 程度)になっている。
  • 運用保守という業務の特性上、どうしても緊急の割り込み作業は発生する。 割り込みの発生確率を予想して、キャパシティ最大まで詰め込まず余裕を持たせるようにした。

今後の予定

  • インセプションデッキの定期更新 1回作ってみたけど、考えが抜けている点や周囲の状況が変わった点もあるので、再度作り直す。

    できれば、定期的に見直す機会を設けて、常に最新の状態を保つようにしたい。

  • 引き続き、スプリントの実施

    まだまだ上手く回っているとは言えない。 特に、現在開発中の新機能がそろそろ総合試験(ウォーターフォールで開発している他社システムとの連携試験)なので、そこをどう乗り越えるかが大きな山場。

  • スプリントレビューの改善

 気がつくと、レビューではなく進捗報告になってしまっている。  顧客にも入ってもらって成果物のデモができるようなスプリントレビューにしたい。

APEX User Group - 第1回Meetup 参加報告

 APEX User Group - 第1回Meetup@東京に参加してきました。最初は5分程度のLTの予定でしたが、当日に急遽30分枠をいただき、たっぷり話してきました。

 

www.slideshare.net

 

参加の経緯

ハッカーズチャンプルー2016のLT「Oracle APEX実践報告」の資料をSlideShareにアップしてたのがオラクルの中の人に見つかってしまい、沖縄でAPEXを使って面白そうなことをやってる会社があるぞ、ということでAPEXのユーザー会に声をかけていただきました。

f:id:takusamar:20170427164033j:plain

 

感想

T字形ER手法×Oracle APEX=超高速開発

当日の参加者がOracle APEXに期待しているのは「簡単な画面やシステムを楽に作りたい」ということで、T字形ER手法が必要なほどの複雑なシステムをOracle APEXで構築しようという人はあまりいなそうでした。ちょっと参加者のニーズを読み違えてた気がします。
 
T字形ER手法について自分自身の理解もまだ浅いためグダグダな説明になってしまいましたが「こんなビジネス解析・DB設計方法があるよ」という点は最低限伝えられたと思います。これまでに開発したシステムや、実際にT字形ER図を書いて実装したAPEXアプリのデモなどAPEX開発の事例紹介ができたのは良かったです。
 
T字形ER手法にしろ、Oracle APEXにしろ、世の中の主流ではないため情報が非常に少なくて大変です。ですが「人の行く裏に道あり花の山」というか、マニアックな所を攻めるのが面白いので、しばらくこのまま進んでみようと思います。
 

APEX5.1.1 ( Oracle Database Cloud Service ) アップグレードよもやま話

 APEX5.1.1いいなあ。自分が使ってるのは4.2.6だけど、既存アプリの修正なしで簡単にバージョンアップできそうなので試してみようと思います。
Oracle 12cでCDB・PDBを使っているときにハマった話など、実際に手を動かした結果の報告は聞いていてすごく勉強になりました。
 

大変便利なAPEX、ORDSの実業務での活用例を見て!(日本オラクルさんアピール不足ですよ!)

AngularJSで超かっこいいアプリを作ってて驚きました。これのサーバ側はAPEXだけ(REST API)だというのがすごいです。
 
APEXではシンプルな画面なら簡単に作れるけど、凝ったことをやろうとすると一気に難易度が上がります。そんなときは無理にAPEXで作り込もうとせず、REST APIを提供して別の言語(AngularJS)で作るのが現時点のベストプラクティスだと思いました。
 
ただ、REST APIのためだけにOracle APEXを使うのはもったいない話。
  • ユーザーの要求レベルが高い画面は、AngularJSなど別の言語で工数かけて作る。
  • ユーザーの要求レベルが低い画面は、Oracle APEXでさくっと生成する。

という使い分けをするのが良さそう。

 

APEXユーザー会について

海外では結構使われていて技術情報や事例が豊富だけど、英語ばかりで日本語の情報が少ない。それでAPEXを諦めた人も多いはず。
日本でユーザー会を立ち上げて、日本語の情報を増やしたら日本国内のAPEXユーザーも増えるはず。使う人が増えたらまた情報量も増えて、という好循環になって欲しいと思いました。
 
第1回のMeetupということで、進め方はまだ手探りな様子。他の勉強会に比べてややお固いかも、という印象(飲みが足りなかった?)
第2回以降、沖縄から毎回参加するのは難しいけれど、何らかの形でサポートしていきたいです。
 

リモートワークジャーニー@沖縄 Vol.1 参加報告

沖縄からでも東京と対等に仕事をするには〜リモートワークジャーニー@沖縄 Vol.1 - リモートワークジャーニー Okinawa | Doorkeeper に参加してきました。 

所感

一言であらわすと「呪いが解けた」です。

 

何の呪いかというと、6年前、私が東京から沖縄の会社へ転職する際に、当時の社長からこんなことを言われました。

  • この会社は良くも悪くも沖縄の空気に包まれている。地縁・血縁・学歴、狭い社会の中で人間関係が濃く、上下関係を大事にする(気にしすぎる)
  • 今までは親会社からの仕事で十分食えてきたので、言われたことだけをやっていれば良い、自分から動こうとしない。技術者として向上心がない。
  • 年次昇給で人件費は毎年増えるが、売り上げは増えない(むしろ減っていく)。このままだと人件費で会社が潰れる。

なんか日本の問題点を凝縮したような会社ですが(笑)

この状況を打ち破るためにわざわざ東京から中途採用するので、新しい風を吹きこんでほしい。異端者として改革を進める起爆剤になってほしい。ということで入社しました。

この6年間働いてきて、理解ある上長にも恵まれて、とりあえず新しい風はだいぶ巻き起こせたかなと思います。保守的な人達からはかなり嫌われてるかもしれませんが。

とはいえ、自分のチームはまだ数名。会社全体を変えるのは相当難しいな、というのが正直な気持ちでした。

 

そんなモヤモヤを倉貫さんに相談したところ、
「嫌だ嫌だと言ってても何も変わらない人は、本当はそれが好きなんだよ」
「変えましょうなんて余計なお世話。彼らは好きでそうしてるんだから」
「『変えましょう』じゃなくて『私はこうします』。自分がやりたいようにやればいい」

「新しいことをやりたいなら、別の場所でやれ。変えたくない人達に迷惑をかけるな」
「こっちの方が良いと他の人が考えるようになれば、向こうからやってくる」
と言われて、なるほど。

 

入社当時に言われたことを真に受けて勝手にプレッシャー感じてたけど、自分が経営者なわけでもないんだし、そこまで背負うことないか。

そう思えるようになったら、取り憑いてたマジムンが一気に消えていきました。

今後の進め方

呪いが解けたことで、今後どうするかをあらためて整理してみました。

  • 別にリモートワークがしたいわけじゃない。リモートワークは働く時間・場所の制約から自由になるための手段にすぎない。
  • とりあえず会社は辞めない。この会社だからこそできる面白い仕事なので。今の制度や環境の枠内で、働く時間・場所の制約を少しでも緩くできればそれで良い。上長・チームメンバと調整すれば十分可能。
  • 変わろうとしない人達は放っておく。無理矢理変えようとして自分の貴重なリソースを消費しない。

どこまでできるか分からないけど、とりあえずこの路線で進んでみようと思います。

 

最後になりましたが、素晴らしいイベントを企画・実行してくださった皆様に感謝。後で振り返って、私の人生の転機だったと言える日になりそうな気がします。 

 

 

 

ハッカーズチャンプルー2016参加報告

報告

ハッカーズチャンプルー2016に参加してきました。今年のLTは真面目にOracle APEXの紹介をしました。

www.slideshare.net

 感想

こういうイケてる人たちの集まりではOracleって受けが悪いだろうな〜と勝手に想像してましたが、意外と反応が良くて驚きました。やる前から先入観を持ってはいけない、とりあえずやってみるのは大事ですね。

ただし、Oracle APEXは画面を作る手間を省くための単なるツールで、T字形ER手法と組み合わせてこそが超高速開発の本丸なんですが、LTの持ち時間ではどうしてもそこまで話せず次回予告となってしまいました。期待してくれた皆様ごめんなさい。どこかで必ず続きをやります。

f:id:takusamar:20160628053035j:plain

話し足りなかったこと

持ち時間ぴったりできれいに発表を終わらせた感がありましたが、じつは1分くらい余らせて以下のことを話したかったんです。

  • 今日はたまたまOracle APEXの話をしたけど、Oracleから何かいただいてるわけじゃないし、目的に合わなくなれば別の方法をとるだけ。
  • ある特定のソフトや言語に愛着を持ち、その道を究めるのも素晴らしい生き方だけど、自分はその道を進もうとは思わない。道具と割り切って、目的に応じて使い分けるのみ。
  • 次から次に新しい技術が出てくる世の中だけど、流行を追いかけてるだけじゃ流行には乗れない。波を追うな、波になれ。

でもこうやって文字にしてみると、なんか気持ち悪いですね。勢いで話さなくて良かったという気がしてきました。

昨年の反省

昨年(ハッカーズチャンプルー2015)は会社に費用を出してもらい開発合宿に参加しました。とてもありがたいことでしたが、そのかわり

  • 開発合宿でいささか微妙な物を作ってしまった
  • それをLTで発表してしまった
  • これは会社に報告できない、LT資料も公開できない

という事態に陥ってしまいました(会社から何か言われたとかではなく自主規制をかけてしまった)。その反省をふまえて、今年は会社から補助はもらわずカンファレンスのみ個人参加ということにしました。

今年のLTは業務に関連する内容だったので、会社的にNGがないか上長にレビューをしてもらい、職場でリハーサルもやり、後で問題にならないよう手を打っておきました。社畜のつらさが滲み出てますね。

1年経過して、そろそろ時効かなという気もするので、こっそり昨年のLT資料もアップしときます。