中小エンドユーザーの業務効率化とアジャイル

岡島です。こんにちは。

今回は、究極のアジャイル同人誌である「Ultimate Agile Stories　-Iteration 5」に寄稿させていただいた記事を転載します。記事をまとめるにあたってKAIZENクラウドでの経験も大きかったからです。

私はここ最近、地元福井の中小企業の業務効率化を支援するプロジェクトをいくつか担当しています。今日はいくつかのお客様の事例を題材に、業務効率化プロジェクトにアジャイル開発を適用することの意義について語ります。

ちなみにここでの「業務効率化」プロジェクトの典型は、①帳票メインの事務システム、②リプレイス案件、③低予算で短納期、です。

「利益を生み出すシステムではないので費用はかけられない」＆「現場で広く使われている帳票や画面の変更は抵抗が大きい」などといった理由（言い訳）でディフェンシブな開発になりがちで、既存システムを新しいバージョンの技術に置き換えただけの失敗プロジェクトで終わることも多いです。

開発が始まる前から現場担当を巻き込む

そうならないよう、もっとも意識するのは「現場の声の収集」です。業務効率化と一言でいってもお客様の思いは様々で、それらを全て受け止めていては収拾がつきません。かといって、我々開発者との窓口となるシステム部門の声だけで進めても、大概は最後に「こんなんじゃない」と言われて四苦八苦することになります。

それを防ぐ意味でも、現場で実際にシステムを利用する現場担当をプロジェクトに巻き込まなくてはいけません。具体的に一番困っている人を紹介いただき、現状の業務ヒアリングをしつつ、以下に挙げるような項目を握っていきます。

  • システムで実現したい具体的な効果とそれを実現しうる機能
    • 例えば「1日かかっている作業を1時間で終わらせたい！」
  • これだけは譲れないこと
    • 例えば「外部に出しているのでこの帳票のフォーマットは変更できない」
      実際は一度の打合せで終わるようなことはないので、何度かに分けて、「実現したい業務効率化の形」を両者で徹底的に整理していきます。

業務効率化のMVPは何か？

業務効率化プロジェクトでリーンキャンバスやインセプションデッキなどの道具を使うことは（めったに）ありませんが、MVP（Minimum Viable Product）に相当するものはあります。

MVPは先ほど挙げた「システムで実現したい具体的な効果とそれを実現しうる機能」・「ここだけは譲れないこと」の中にあります。本当にお客様が欲しいと思う新機能や機能改善をMVPとして抽出し、お客様と合意しましょう。私の場合、現場の方から「これだけで相当お仕事楽になりますね！」と、納得いただけた段階でお見積りをし、ご契約いただいて、プロジェクトを開始します。

現場密着開発ならではの難しさ

やることリストを合意し開発に着手した後は、（開発するシステムの規模にもよりますが）一週間から二週間に一度はデモを実施し、フィードバックをいただきます。これがスクラムでいうところのスプリントなのですが、現場のお客様に密着し開発するプロジェクトの場合は、以下のようなことが発生することがあります。

  • 複数プロダクトオーナー
  • 受け入れテストしてくれない問題

まず、お客様の担当業務によってプロダクトオーナーが分かれることがあります。お客様によってはIT部門がなく、窓口を一本化することが難しい場合も多いのです。この場合はスプリントごとにフォーカスする業務を分け、バランスよく開発を進めていくと良いでしょう。さもないと、「あちらの担当分ばかり進捗している」などと不安がられ、余計な気を遣う羽目になります。

さらに悩ましいのは「受け入れテストしてくれない問題」です。現場のお客様がスプリントごとに受け入れテストしてくれるので良いフィードバックが早期に得られる。理屈ではそうなのですが、実際は業務が忙しい方が多く、テストを頼んでも実施できていないことがあります。

それで結局、「ごめんなさい。全部できてから最後にまとめてテストします」となりがちなのですが、それだとフィードバックの機会が減り、お互い辛い思いをすることになります。この問題の解決は難しいのですが、私は「スプリントのサイズを小さくする＝毎週なんとか時間をとっていただく」、さらに、「確認いただきたいポイントを絞る＝アジェンダとなる資料を作りこむ」ことで時間短縮を図っています。デモの場のコントロールをしやすくする策に心を砕きましょう。

これ以外にも、「ごめんなさい！大事なこと伝え忘れていました」問題や、「突然打合せに偉い人が出てきてひっくりかえす問題」などの問題も発生しがちです。

前者は、優先度をお聞きしたうえで後々のスプリントで対応することで納得いただき、後者はプロジェクトバッファを設け、スケジュールに余裕を持たせることで対応します（そんなにうまくいかないことも多いのですが…。現場担当の方としっかりコミュニケーションを取ることで人間関係を把握し、大物には早めに話を通すなどの手立ても必要です）。

また、規模が小さいシステムの開発をお客様に密着して行うと、いわゆる「カウボーイ開発」っぽくなりがちです。お客様の業務に精通してくるほど、トリッキーで属人生の高い 成果物やプロセスが増えるのです。
このような状況はお互いのためになりません。たとえ一人プロジェクトとなってしまってもコードやドキュメントの管理は怠らず、お客様への報告や相談も記録に残せるよう意識してください。

一発でうまくゆくことなんて稀

エンドユーザー、さらに現場担当のお客様に密着する開発案件はやりがいが多く楽しいことも多い反面、問題も発生しがちです。
プロジェクトにおける問題で一番苦しいのは「お客様の期待する価値を実現できないこと」ですが、アジャイル開発はこの問題を回避することができる。というより、「この問題を発生させないことを目指して生まれた手法」です。

私は、アジャイル開発はユーザーに価値を届けられる手法として強力だと考えており、今後も、お客様のために試行錯誤しながら活用していきます。
何事も一発でうまくゆくことはありません。アジャイル開発が繰り返しフィードバックを得てゴールに近づいていくように、私たちもより良い開発者になれるよう、試行錯誤を続けていきましょう。

以上