思考と決断のPM力

IT報酬の実態

海外と比べて日本のITエンジニアの報酬が低いという記事をよく目にする。それもそのはずで、ハイクラスIT人材は都合のいい「何でも屋」にはならないからである。

導入時の誤解

ユーザー企業やシステムのユーザーは、IT化を行うことで業務が減るという先入観を持っていることがある。システム導入を着手したときの目的を忘れて、その時、その場の課題を優先して都合よくITエンジニアを動かしてしまう。また動くITエンジニアもそこにいたりする。

システムと医療

たとえば、「お腹が痛い」と病院にいって「すぐに切開しよう」とはならないはずだ。このようにシステムにもその他にも色々な条件が絡まり合っている。システムは取り扱う情報量や関連する業務が多く導入に時間がかかる。時間がかかる結果、最初の導入目的を忘れてしまうのである。

真のIT人材価値

ハイクラスIT人材はユーザー側の状況と心理を配慮しつつ、現場のプログラマーの状況と心理を考慮して陣頭指揮できる人材といってもよいだろう。心理というのは物の言い方だけではなく、無形の財産を構築したり業務にフィットさせたりするので、プロジェクトの円滑さが変わるのだ。

まとめ

小手先だけでシステムに関するプロジェクトを推進しようとすると、「言われた通りにやった」という受動的な参加者が増えてしまう。情シスのSIer化を回避するにはITエンジニアを「何でも屋」にさせて疲弊させないことも大切である。開発チームの雰囲気作りも非常に効果がある。

内製化が注目される背景

「アプリ開発は外注するもの」という考え方が変わりつつある。ローコードツールの普及により、プログラミング経験がなくても自社で業務アプリを開発できる時代になった。しかし、ツールを導入しただけで内製化が成功するわけではない。実際には「ツールは入れたが、誰もアプリを作れない」という状態に陥る企業も少なくないのが現実だ。

内製化が止まる原因

ローコード内製化がうまくいかない原因は、ツールの問題ではなく環境の問題にある。まず、操作方法を学ぶ機会が限られている。公式ドキュメントは英語中心で、実務に即した日本語の教材が少ないのが現状だ。次に、学んだ知識を実践に移す場がない。研修を受けても、日常業務に戻ると時間が取れず、スキルが定着しないまま終わってしまう。さらに、推進担当者が社内で孤立しがちだ。周囲に相談できる人がおらず、一人で試行錯誤を続けるうちに疲弊してしまうケースが多く見られる。

一気通貫が必要な理由

内製化を成功させるには、「セミナー・サポート・教材」の3つを一気通貫で揃えることが必要だ。セミナーで基礎知識を学び、教材で実践的なスキルを身につけ、サポートで困ったときにすぐ相談できる体制を整える。この3つが揃って初めて、現場の担当者が自信を持ってアプリを作れるようになる。どれか1つだけでは不十分だ。セミナーだけ受けても実践で使えず、教材だけあっても疑問が解消されず、サポートだけあっても基礎がなければ質問すらできない。内製化は「点」ではなく「線」で取り組む必要がある。個人の頑張りに頼るのではなく、組織として学びと実践の仕組みを整えることが成功の鍵になる。

成功企業の取り組み方

内製化に成功している企業は、最初から完璧を目指していない。まず1つの業務でアプリを作り、小さな成功体験を通じてノウハウを蓄積している。そして段階的に対象業務を広げ、社内に開発できる人を増やしていくアプローチを取っている。大切なのは、最初の一歩を正しい方向で踏み出すことだ。独学で遠回りするよりも、経験のある専門家に相談することで、最短ルートで成果にたどり着ける。「まず何から始めればいいか」を一緒に考えてくれるパートナーがいることが、内製化成功の最大のポイントだ。

まとめ

ローコード内製化の成功には、セミナー・教材・サポートの一気通貫が欠かせない。ツール導入だけで終わらせず、組織として学びと実践の仕組みを整えることが重要だ。まずは専門家に相談し、最初の一歩を正しい方向で踏み出そう。

素人仕様と開発遅延

なぜ、システム開発の進捗が悪いのか？
それは、ずばり素人が考えた仕様を開発者に伝えてしまうからである。
すべての原因ではないが、もしシステムのユーザー側の現場担当者や営業担当者がシステム仕様を決めている場合は、ほとんどの場合で満足のいくスピード感はだせていない。

潜む技術的負債

システム仕様さえ伝えていれば、きちんと動くものを作ってくれるので、あとはスピードを上げるだけ。と考えているようであれば、技術的負債が溜まっていることに気付けていない。非エンジニアが決して理解できない技術的負債の怖さは、開発スピードが遅いということだけではない。開発者側から見てシステムが複雑になっていて、メンテナンス性も低い状態になっている。

「できます」の罠

非エンジニアには技術的負債は見えないし説明もわからないことと思う。しかし、技術力でカバーしてくれているから、きちんと動いているのだと思っているなら、それは実は技術力ではない。
「技術的にはできます」このような言葉を聞いたことはないか？
システムエンジニアは「できない」と言えない。「できないことはない」ということが価値なので、素人が考えたシステム仕様でも、言われた通りに作ってしまう。

持続可能な開発へ

システムエンジニアから「技術的にはできます」を聞いたときは、いったん立ち止まるべきである。
エンジニアには、様々な影響範囲や未来のメンテナンス性への懸念などが見えている。これを必要以上のコストだと考えるのか、必要コストと考えるのかで、技術的負債は変わる。

まとめ

自分の理解の範囲でしか人間は発想しないので、システムのことを知らない非エンジニアは、システム仕様を考えるべきではないと言える。また逆に、システムにおいてはシステムエンジニアの方が発想の幅は広いが、業務に関する知識は乏しい。
システムをよく知り業務のこともわかるシステムエンジニアがシステム仕様を考えるべきだが、そんな万能な人は多くはない。だから、その間を取り持つ人間が重要なのである。