はじめに
システム開発からユーザ部署にシステム普及役として異動したが、中々普及しないシステム。広げようにも、そもそも何を目的にどんな機能を作ったのかが漠然として中々ユーザに響かないことを強く実感。使ってみようと思ってくれるにはから地道に進めてみた。まだ道半ばだが、そもそも何が必要だったかを振り返っておきたい。
調査
同じような話を書物から拾いたく、色々読んでみた。
はじめての上流工程
こちらは業務要件、システム要件の説明が丁寧に書かれている。課題分析を5つのポイントで切り分け、達成方策を整理する中で業務要件かシステム要件を区別していた。例題があるので分かりやすい。またシステム設計以降の話も書いてあり、基本設計や詳細設計の説明に目を通すだけでベンダーとのやり取りが腑に落ちてくると思う。
フルスタック
システムを構築するための全てが詰まっている。ドキュメント整備しか目を通していないが、どんなドキュメントを用意して開発を進めるかが理解できる。またフロントエンドとバックエンドの違いによる、各システムの開発のやり方も参考になる。2者は切り分けて考えるべきかなと思う。実際のコーディング含めてまとまっているので、今後実際に手を動かしたい。
カイゼン・ジャーニー
アジャイル開発について書かれている。ユーザが何を欲しているか、吸い上げるためにどんなやり方があるか、ストーリー仕立てで書いてあるので読んでも苦にならないと思う。
やってみたこと
とにかく使いづらい。という声。じゃあ使いやすさを重視しフロントエンドを作ってみた。すると、多少は使えそうかと言う声が出てきた。しかし、作り進めてユーザに見せても何が出来るかイメージ出来ないと言われ、結局パワポエンジニアリングになる。
契機
細々やっていたが、部長からのトップダウンがあり、急に周りがやる気を出した。皆さん本業が忙しいようだが、業務改善も本業になり手段が目的に置き換わったので、色々乗り気になってくれた。こちらで作った拙いインターフェースも使ってくれ、会話も増えてきた。
その後
とりあえず期末報告のためにやってる感じが伝わるものを仕上げた。まだまだ足りないところはあるが、、、
おわりに
業務改善活動はボトムアップだけでは厳しい。トップダウンがあり、かつ上の意向を伺いながら形にする力が重要だ。あと、定期報告で複数の課長級に報告義務を持たせるとよいかな。
コメント