記事

運用の昇華

開発現場の想定外

基幹システムの開発現場では、最初に想定した仕様とは異なる業務フローが後から発覚することが多い。

マネジメントの試金石

後から発覚した業務フローは、すでに構築が進んでいるシステムに組み込むことが難しいため、どのように対応するかがプロジェクトマネージャーの腕の見せ所である。

プロジェクトの舵取り

プロジェクトマネージャーとは何かと問われたときに、一言で言い表すならば、不測の事態にどのように対応できるか、ということではないかと考える。プロジェクトが何の問題もなく、完遂できることは少ない。したがって、イレギュラーケースが発生した時にどのような手立てを打てるか、迅速に行動できるかがプロジェクトマネージャーのレベルとなる。

パートナーシップの重要性

プロジェクトマネージャーがシステムの完成しか考えていなければ、途中から発覚した仕様は「運用でカバーせよ」とユーザー側に責任を押し付けてしまうことがある。しかし、より良いシステムを目指す、パートナーとしてであればこの回答は好ましくない。

まとめ

どのような事象がきっかけで、途中で使用漏れが発覚したのか、プロジェクトの進行状況を見ながら、ひも解くことが重要である。運用でカバーというユーザー側だけにだけ負担をさせるのではなく、運用をカバーするようなシステムを構築できるのが理想である。

マニアの逆効果 前の記事 フルスクラッチは体力 次の記事

関連記事

記事

市民開発とは何か

市民開発の正体

市民開発（Citizen Development）とは、IT部門やSIerに依存せず、業務部門などの非エンジニアが自らアプリケーションを作成する取り組みを指す。従来は「プログラミングができないと無理」と思われがちだったが、現在ではノーコード・ローコードツールの登場により、非技術者でも業務に必要なツールを構築できるようになった。代表的なものとして、SaaSベースの業務アプリやMicrosoft Power Platformなどがあり、これにより業務現場の課題解決が加速している。

IT不足とマクロの功罪

市民開発が注目を集める背景には、深刻なITエンジニア不足がある。人手が足りないなら自ら開発するしかない——この流れが市民開発を後押ししている。その原型とも言えるのがExcelマクロである。かつて現場では、個人PC上で動作するマクロが業務改善ツールとして使われていたが、多くが属人化し、結果として保守不能な“遺産”となってしまっている。

マクロの限界

Excelマクロの最大の弱点は「ファイル単体依存」である。複数人での同時使用や、プログラムの共有に極めて不向きである。マクロ付きファイルをコピーすれば、そのコピーごとに独立した修正が可能となり、誰がどのバージョンを使っているのか把握が困難になる。しかも、更新履歴の管理も難しく、組織全体の業務統一を図るには限界がある。こうした特性が、非効率と混乱を招く要因となっている。

マクロの呪い

属人化の果てに起きるのが「ブラックボックス化」である。Excelマクロにパスワードがかけられ、開発者も不在、しかし業務には不可欠——そんな状態が現場には数多く存在する。これらは情報システム部の管理外にある「野良プログラム（シャドーIT）」と呼ばれ、セキュリティリスクを高める要因でもある。結果として、誰も触れず、誰も捨てられず、今も現場の根幹に鎮座している。まさに、手遅れになる前に対処すべき課題だ。

まとめ

市民開発は、Excelマクロに代わる次世代の業務改善手段となり得る。ローコード・ノーコードの活用により、野良プログラムの乱立を防ぐには、組織としての運用ルールとガバナンスの確立が不可欠だ。アタラキシアDXでは、Power Appsを活用し、手遅れになる前にブラックボックス化したマクロのリプレイス支援を行っている。

続きを見る >
記事

リーダーの多忙による弊害

危険な繁忙化

なぜか忙しくしているPMやリーダーとなるSEがいれば危険信号である。リーダーが忙しくなると全体的な最適化や効率的な運用ができていない可能性がある。結果として、無駄に費用がかかったり、技術的負債が大きくなったりする。

役割分担の歪み

システムのユーザー側から見ると、SEという見え方しかしないと思われるが、実際はシステムの運用や開発には細かな作業分担が発生する。この作業分担ができていない場合は窓口のSEが余計な作業を行っている可能性がある。役割分担の不均衡がもたらす忙しさではなく、まったく仕事としてやらなくてもよいような事に時間を使っていて忙しい場合がある。

プロセスの確立

たとえば、プログラムが解析できる人をリーダーとしてしまうと、開発者に手取り足取り指示をしてしまうことがある。もし、リーダーがプログラムレビューなどの作業や、開発者にプログラム上の細かな指示をしている場合は注意が必要である。何を基準にプログラムレビューや指示を行うのか、という仕事を見える化し、仕組化することがリーダーの務めである。

俯瞰的視点

木を見て森を見ずという言葉があるように、リーダーとなる人は指針を作ったりメンバーをプロジェクト成功へ導く役割がある。リーダーが開発メンバーと同じように木ばかりを見ているようであれば、森を見る人が非エンジニアであるユーザー側となってしまうことが考えられる。

まとめ

誰が森を見るのか、リーダーやPMが常に忙しそうにしている場合は、何に時間を使っているのか調査する必要がある。実はここがボトルネックになっていてプロジェクトの進行が思うようにいかなかったり、頻繁にリスケが発生していることも多くある。しかし、これは本人にヒアリングするだけでは表面化しないため、ユーザー側の担当者やプログラマーなどの周辺人員から浮き彫りにすることが望ましい。

続きを見る >
記事

熱意の共有

提案と負担

「なぜ、自社のシステム担当者や社外から常駐するSEは、システムの改善提案をしてくれないのだろう？」と思うことはないか。それは、提案することで自分が大変になってしまうことを理解しているからである。

現状維持の理

自分たちが大変になるだけであるため、普通に考えれば、それを「やろう」と思うはずがない。それがシステム担当者から提案が出てこない理由であろう。

知と意欲

そうなると、非エンジニアやシステム営業が発想する提案は、システムの要件や縛りを無視した案になってしまう。問題解決意欲の高い非エンジニアが指揮するシステム開発を成功させるには、同じ温度感を持つエンジニアを味方につけるほかない。

人材の見極め

システム担当として向いている人材を探すことは非常に困難である。仮に全社的な問題解決意欲の高いエンジニアを採用したとしても、本当のスキルがどの程度であるか知ることができない。システムの開発のほとんどは巻き戻すことができないからである。

まとめ

システム開発や運用の大変さを知る人材ほど、モチベーションがない限り全力を出し切らせるには、相当の熱量を伝えることが肝要である。

続きを見る >