見出し画像

「市民開発者」に思うこと〜EUCの辛酸を添えて〜

Pやま＠情シス

この記事は「【初心者優先枠】corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#2」の18日目の記事となります。

　こんにちは、あるいはこんばんは、Pやま＠情シスと申します。
IBM Notesからの移行プロジェクトに途中参画し苦しんだ話と、最近流行りの「市民開発者」について思うところを徒然と書いてみます。

自己紹介

  • 従業員○000人規模の中堅製造業で情シスしているアラフォーです（一応まだ30代…！）理系卒でモノづくりがしたいと入社したはずが、なぜかもうずっと情シス。

  • 部署はパートナーも含めて約50人いますが、平均年齢は40後半・中央値は50前半？いや下手すると…そんな中自分はアラフォーでも下から数えて○番目なTHE・少子高齢化社会の縮図のようなところです。

  • 専ら社内SE、基幹・周辺システムのアプリ運用から小改善〜業務プロセス改革のようなことを中心にやってきました。

  • 先任者が退職したり（ほぼ定年）炎上して人手がほしいチームやプロジェクトにアサインされがち。「○○チョットワカル」になったら別のチームに移り「●●なんもわからん」になるを繰り返してキャリア詰んでます積んできました。　

「市民開発者」と「EUC」

　今後DX人材・IT技術者が不足すると言われていて、その解決策のひとつが「市民開発者」＝IT部門（情シス）やITの専門職でない各ユーザ部門の従業員がアプリケーション開発者になることだそうです。
　一方、ひと昔前にブームとなりタイトルにも入れたEUCとは「End User Computing」の略で、情シスや開発者ではない業務部門のエンドユーザがアプリケーションを構築すること、あるいはそのシステムを指します。
　あれ？気のせいかな「市民開発者」と同じこと言ってるよね…？

IBM Notesって？

　元は1989年にLotus社が開発した、クライアント・サーバー型のおそらくグループウェアの元祖的なプラットフォーム。掲示板、予定表から複雑なデータベースまで、いろんなアプリケーションを構築することが可能です。メールクライアント機能も内包していて、Exchangeに移行するまでは自分も使っていました。
　IBM NotesもEUCを指向しており、Lotus Scriptというプログラミング言語でアプリを作れ、VBAを使いこなせるような人であればユーザ側でも構築が可能でした。
　これが製造業によくある現場でのカイゼン活動と相性が非常に良かったのです。

エンドユーザーによって練り上げられた約１０００本のアプリ

　製造業の「カイゼン」といえばトヨタ式が有名ですが、へーしゃでも似たような取り組みをしております。この活動に合わせてNotes導入当初から、現場も自分たちで業務効率UPでき、情シスもリソースが空くので希望者には開発者ライセンスとツールをどんどん配っていました。
　ただいつからかこの活動が数値化・ノルマ化されるようになると、アプリを作ること自体が目的になり、また開発できる人でどんどん重箱の隅をつつくように細かいところまで小改善を積み重ね、大した仕様ではないものからフルスクラッチなシステムまで移行当初は1000本を超えるアプリが存在しました。

Notes事業売却とEUCの末路…👤「Notesをやめさせろ！」

　Web化・クラウド化な時代の流れもあって、IBMがNotes事業を売却することが決定したあたりから「Notesからの移行」や「脱Notes」等のキーワードがIT系のニュースにも掲載されていました。
　へーしゃももれなく某偉い人から「早くNotesをやめろ！」と号令がかかったらしいです。※ただ私は直接聞いたことがない都市伝説。。。

😓「やめるには1000本のアプリをどうにかしないといけないのですが…」
👤「情シスが責任持ってやめさせろ！」
😇（？？？）

　EUCの反省もあって、方針として「部門に開発はさせず、情シスで精査し巻き取ること」と「終わり」だけが決まっていました。次の体制のこともあって移行はなかなか終わらず（２回延伸）ユーザからも「某偉い人がやめろって言っているらしいけどホントなの？」「そんなこと言って〜まだ使えるんでしょ？」な状態でした。

そんな移行プロジェクト…体制はどうだったの？

　ヘルプ要員で補充された自分を含めて４名、少数精鋭！と言いたいところですが下記よりお察しいただきたく（白目）あとは上に部・課長がいましたが残数のマネジメントだけでした（吐血）

  • リーダー
    Notes時代からの主力古参・情シス開発でのアプリもこの人が開発〜保守していたのですが、身体的な理由で入院が必要になり休みがちに…

  • サブリーダー
    親会社からの出向で「一応」Notes開発・運用経験者。自称Microsoftヲタクで知識はあるようなのだが、手は動かしてくれないタイプ…

  • ワークフロー担当
    メンバーの中では情シス最古参も、設計も開発も超がつくスローペース。週頭にお願いされていたことを週末に確認すると「まだやっていません」「今日やっていきます」（そして終わらない）スケジュールが意味をなさない…

移行の進め方…？

　リーダがどうしても休みがちなのとサブリーダのモチベーションが低いこともあって、進め方が「移行したいアプリがあれば相談にのる・案件がなくなったらまた募集する」みたいなやり方だったので（いやいや皆どないして終わらせるつもりやねん…）と思いながら動き始めました。

　まず形しかなかったアプリの一覧を、ログや使用容量など機械的に取れる情報と、アプリ管理者・部門とその上司をリスト化、Lotus Scriptは満足に読めないので片っ端からアプリを開き外部仕様から目的を想像しながら機能で大まかにカテゴライズするなどして情報を充実させていきました。
　それらの情報を頼りに明らかに使ってなさそうなものは「移行対象外にさせてねーいきなり削除はしないけど一旦権限取り上げるからビックリしないでねー」とヒアリングしながら母数を減らしていきました。あとは細かい仕様は一旦無視してそれぞれのカテゴライズごとにテンプレート的な移行先候補を用意。

  1. リンク集、部門などのポータル的なもの　→　 SharePointサイト

  2. 掲示板　→　 SharePointリスト（タイトル、本文、添付）

  3. ファイル・情報共有目的　→　SharePointドキュメントライブラリ

  4. 予約管理　→　 SharePointの某テンプレート（購入）

  5. 申込系　→　SharePointのアンケート（→365に移ってからはFormsも利用）

  6. e-learning　→　親会社のwebシステムに相乗りへ

  7. 承認ワークフロー　→　某システムその１

  8. フルスクラッチ（システム間連携等）→　某システムその２

ある程度情シス側の準備もできたところで、テンプレートでいけそうか・移行のタイミングはいつ頃がよいか等ヒアリングをしていくのですが、２つの問題が…

仕様を確認したいのですが…「開発者、もういません」

　蓋を開けてみれば全体の2割程度しか開発者・引継者が残っておらず、属人化・ブラックボックス化の典型例をやっていました。

👥「今まで通りで」「情シスだからコード見ればわかるでしょ？」
😇「わからないのと時間がいくらあっても足りないので聞いています」

　上記カテゴライズの１〜６くらいまでは、紆余曲折ありながらも細かい仕様はユーザ側にも”飲んで”もらえましたが、承認ワークフローとフルスクラッチはそうはいかず…ヒアリングしながら１〜６を移行し、２段回での移行を進めていきました。
　なんとか方向性も見えてきて、スケジュールも頑張れば行けるんちゃう？というところで、そうは問屋が卸さないとばかりにまた事件は起きます。

リーダ退職とリーダ拝命、サブリーダの離脱…

　入退院を繰り返してきたリーダが、残念ながら治療に専念するため退職されることになりました。次リーダは順当に行くとサブリーダなのですが頑なに断り、結果ユーザとの調整を直接していた自分がチームリーダになりました。
　サブリーダも始めのうちはノウハウを共有してくれていたのですが、ユーザとの調整や実際のアプリ移行段階になると休みがちになり、それを部・課長がつめると更に休むという悪循環に。どんなネゴがあったかわかりませんが途中で出向戻りになりました。ん？ということは都合メンバー２人…？

　結局は界王拳使いまくって力技で移行しつつ、システム化が間に合わなかったところは情シスのTHE☆運用でカバーというワーストプラクティスの権化のような策で乗り切りました（青色吐息）

EUC＝市民開発に思うところ

　昨今のローコード／ノーコードのブームは、基幹系の開発保守もしていた身からすると「本当に簡単にアプリが作れる良い時代になったなぁ」と思う反面、ユーザ側で無秩序にアプリが作られると属人化・ブラックボックス化のリスクと表裏一体だなと身を持って実感しました。
　ユーザ側で業務効率化やシステム化に興味を持って積極的に取り組まれる姿には頭が下がりますし、少ない情シスのリソース面でも本当に助かります。が、将来またEUCの尻拭いをするような人が現れないことを祈るばかり／モヤモヤする気持ちも正直あります。

属人化はどうしたら防げそう？ → 市民開発者間での情報共有

　情シスと市民開発者がアプリの仕様レビューや開発ノウハウを共有できる場があればよかったのではないか？と１つ思います。現に、アプリをカテゴライズしたときに、開発手法はバラバラだけどやりたいことは結構似てたり、今まで部門で閉じてそれぞれシステム化していたけれど隣の部門と一緒にシステム化するともっと効率化図れそうだよねということがありました。
　お客さんに納めるシステムであれば守秘義務等の関係で社内でも仕様はオープンにできないことはままあると思うのですが、社内の業務効率化であればむしろ社内に積極的にオープンにしていった方が「あのアプリってそう作っているのか」とか「そのアプリのアイディアいいね！真似させて」、「一緒にやろう」と何倍も効率化が図れたり、他の開発者がサポートもできるなんて好循環がうまれるのではと妄想※しています。
※注：色々あって現在は違うチームに移ったため、実践には至っていません…

あとがき

　アドベントカレンダー初チャレンジということで初心者優先枠に申し込んでみたはいいものの、皆様の知見に富む記事で埋まっていくカレンダーを見ながら焦り、ネタを変え・書き直しまた焦る…結果、納期いっぱい使っての記事となりました。。また身バレや社外に情報を持ち出すのが怖いので所々表現を変えるのにも一苦労…まとめきれず見苦しいところだらけと思いますが、結論としてはトライしてみて良かったです。最後までお読みいただきありがとうございました。

この記事が気に入ったらサポートをしてみませんか？