「昔、作ったシステムがあって何かあったら心配になったので…」
という相談でした。
実際にお伺いしてヒアリングしてみた結果の問題点は

• 社内のパソコンをサーバーにして運用していた
  (OSが古くサポートが切れた場合にリスクが大きい。またハードウェアの故障時などそのままサービスが停止してしまい、復旧コストがとても大きい)
• セキュリティが十分ではなかった
  (ハッキングなどの危険性が大きい状態だった)
• 元々の開発会社に指示されていたバックアップ内容では不十分だった
  (手動でやっていた上にそのままでは使えない状態だった)
• メンテナンスされてなく、バージョンが古く脆弱性の対応等が出来ていなかった
  (セキュリティアップデートなどをしていないのでウィルスなどを防ぎきれない)

という所で、セキュリティの大切さやメンテナンスの必要性を説明。
このまま使い続けた場合、何かあった場合の損害額はもちろんですが、何よりも社内の古いマシンを維持、 管理する時間といった「見えないコスト」が無駄にかかってしまっている事も説明して理解をして頂きました。

理解も頂き、発注という事になりました。
今回のミッションは

1. セキュリティ面の向上
   SSL等の導入をきちんと行う
2. 環境の整備
   サーバーを外部に移し、死活監視や待機系の整備
   メンテナンス性の向上
3. システムのリニューアル
   機能的な要望もあったので作られた当時のjava
   ではなくRubyで元のシステムを踏襲しつつ作り直し。
4. データの保護
   バックアップの整備

に決定！

見積りを行って予算調整。
予算の都合があるので、リニューアルについては画面や動きなどは基本、既存システムを踏襲し新機能は加えない方向で決定。
どうしても修正や追加が必要な機能やデザインについては予算を追加するのではなく「やる事」を次のフェーズにするか保留にする方向で調整。

開発にあたり、今回はサーバーをすぐに用意してもらい開発した物をすぐに触って確認してもらえる環境を用意しました。

イテレーション(作業のサイクル)は1週間に設定し、クライアントと顔をあわせて打合せを必ず1回以上取るというルールで、 普段のコミュニケーションはチャットツールを使いながら開発したものを確認、次のイテレーションのやる事を調整という流れを繰り返しながら進めていきます。

この方法の利点は

• イメージのズレを直ぐに修正できる
• バグの早期発見
• 必要の無いものを切り捨てて、必要なものを組み込める
• 早い段階で動くもの触れるものが共有できる

というものがあります。
「思ってたのと違う」「この機能、変更したい」「バグがでた」というのが後になればなるほど軌道修正のコストは莫大になっていきます。
アジャイル開発の手法でのプロジェクト進行をお願いしているのは、 こういった問題を予防し顧客も巻き込んで一緒に開発していく事でイメージ通りのより良いシステムを作りあげていこうと思っているからなのです。

「作業を効率化したい、作業の進み具合が見えるようなシステムが欲しい」
という相談でした。
工場の作業工程をシステム化したいという具体的なご相談でしたが、更にヒアリングをさせて頂きました。

• 各工程間の作業伝達を紙でやっている
• フロアを人が移動して作業の段取りをしたり作業の調整をしたりしてる
• その日のノルマがどれくらいで終わっているのか大雑把にしか把握できていない
• 遅れている時に何が原因で遅れているのか把握しきれず「頑張れ」としか言えない
• 品質向上、業務効率化したい

というのが主な課題と要望でした。
業務の流れを聞かせて頂いて、紙で行っている工程間の作業伝達は画面で共有できるように。 業務効率化、品質を向上させる為には分析の素地になるデータが必要なので各工程の作業時間を取得したり、引継や連絡を円滑にする為にメッセージ機能を提案。
また経営層向けの原価計算等に使えるように保持しているデータを集計したEXCELファイルを出力できる機能などを加えて開発をスタートさせる事となりました。

今回のミッションは

1. 業務を可視化したい
   紙で行っていた業務をシステム化
2. 時間を可視化したい
   作業時間を取得、可視化して効率化をおこなう
3. 基幹システムとの連携
   扱うデータは基幹システムにあるため連携が必要
4. コミュニケーション向上の仕組み作り
   各工程間、管理者と作業者間のコミュニケーションを円滑にする仕組みを提供

に決定！

見積りを行って今回のトレードオフスライダーで固定するのは「時間」
ボリューム的にオーバーしそうな要素については次のフェーズにするなどそこに間に合うようにスコープ(要望)を調整。

今回はサーバーがすぐに用意できない都合があったので、急遽、自社内のサーバーをテスト用として公開し、確認してもらえる環境を用意しました。

イテレーション(作業のサイクル)は1週間に設定し、クライアントと顔をあわせて打合せを必ず1回以上取るというルールは変わらず、 普段のコミュニケーションはチャットツールを使いながら開発したものを確認、次のイテレーションのやる事を調整という流れを繰り返しながら進めていきました。

この方法の利点は

• イメージのズレを直ぐに修正できる
• バグの早期発見
• 必要の無いものを切り捨てて、必要なものを組み込める
• 早い段階で動くもの触れるものが共有できる

「全ての機能が全て正しく、確定している」なら別に従来通りの開発方法でいいのですが クライアントも全部が全部、構想が組み上がっている訳でもないので、試行錯誤が必要な部分は必ずあります。 こういった変化に柔軟に対応できるのが強みでもあります。