「これくらいなら自分で作れる」という誘惑。でも開発費だけでなく、保守・引き継ぎ・障害対応まで考えて判断するようになりました。
はじめに：「これくらいなら、自分で作れる」
現場から相談を受けたとき、頭の中でほぼ反射的に浮かぶ言葉があります。
「これくらいなら、自分で作れるな」
画面は二つか三つ。データベースから取り出して表示して、必要ならCSVで出力する。条件を絞り込める検索欄があれば十分。そんな話を聞くと、私の頭の中では、もう画面の配置と処理の流れが組み上がり始めています。技術者としての習性であり、同時に、内製のSEとして長く仕事をしてきた人間の、ちょっとした自負でもあります。
実際、作れます。作ること自体は、そう難しくありません。数日、長くても数週間あれば、現場の方が「おお、使える」と言ってくれるものが形になります。ベンダーに見積もりを依頼して、仕様を詰めて、発注の手続きを経て、納品を待つよりも、はるかに早い。費用も、人件費を別にすれば、ほとんどかかりません。
でも、五十代になって、私はこの「作れる」という感覚を、以前ほど素直に信用しなくなりました。作れることと、作ってよいことは、別の話だと思うようになったからです。
この記事では、「ベンダーに頼むか、自分で作るか」という、内製を担当するSEなら誰もが迷う判断について、私が今どんな基準で考えているかを書いてみます。結論から言うと、判断の中心は、開発にかかる費用や時間ではなく、「作ったあとに何が起きるか」に移りました。保守、引き継ぎ、障害対応。作った瞬間ではなく、その後の何年かを想像して決める。そう考えるようになった経緯を、反省も含めて書いていきます。
なお、記事中の場面は、実際の経験をもとにしつつ、特定の事案が分からないよう再構成しています。部署名や数字などは一般化しています。
誘惑の正体：なぜ「作れる」と思った瞬間に動き出したくなるのか
まず、あの誘惑の正体を考えてみたいと思います。
一つ目は、技術者としての楽しさです。何もないところから、動くものが生まれる。現場の困りごとが、自分の手で解消される。この体験は、何年やっても、やはり楽しいものです。この楽しさは、判断を静かに歪めます。「作りたい」という気持ちが、「作るべきか」という冷静な問いを、後ろに押しやってしまうのです。
二つ目は、速さへの魅力です。内製なら、現場の要望を聞いたその日に試作を見せられる。ベンダーに依頼する場合の、見積もり、仕様確認、発注、納品という流れに比べれば、圧倒的に速い。現場からも感謝されますし、自分の存在価値も実感できます。
三つ目は、費用が見えにくいことです。内製の場合、開発の人件費は、請求書という形では現れません。もともと給与として支払われているので、組織の帳簿の上では「無料」に見えます。ベンダーに依頼すれば、数十万円、数百万円という金額が目に見える形で出てきます。その差が、「自分で作ったほうが得だ」という感覚を生みます。
四つ目は、自分ならうまくやれるという自信です。過去に似たものを作ったことがある。環境も慣れている。現場の事情も分かっている。この自信は、多くの場合、間違っていません。作るところまでは、確かに、うまくやれるのです。
ただ、この四つの動機に共通するのは、どれも「作る瞬間」の話だということです。作ったあとの話は、そこにほとんど含まれていません。誘惑の正体は、「作る瞬間の楽しさと速さに、判断の重心が引っ張られること」だと思っています。
内製の価値は、本物である
誤解のないように書いておきたいのですが、私は内製を否定したいわけではありません。むしろ、内製には、ベンダーに頼むのでは得られない、本物の価値があると思っています。
現場の言葉が直接届くことは、大きな強みです。ベンダーに依頼する場合、現場の要望は、情報システム部門を介して、仕様書という形に変換されて伝わります。その過程で、ニュアンスが抜け落ちることがあります。内製なら、現場の方と直接話しながら、画面を見せて、「こうですか」「もう少しこちらです」と調整できます。この往復の速さと密度は、内製ならではです。
小さな改善を積み重ねられることも、内製の強みです。ベンダーに依頼すると、小さな修正でも、見積もりと手続きが必要になります。「ボタンの位置を少し変えたい」「この項目の並び順を変えたい」といった小さな要望は、費用対効果の面で、頼みにくいものです。内製なら、そういう小さな改善に気軽に応えられます。その積み重ねが、現場の使いやすさを、大きく変えていきます。
病院の業務を理解した人間が作ることの価値もあります。病院の業務には、独特の事情がたくさんあります。時間帯による忙しさの違い、職種ごとの役割分担、紙の運用との併用、監査への備え。こうした事情を肌で知っている人が作れば、後から「そんな運用はできません」と言われる手戻りが少なくなります。
さらに、組織の中に、技術的な知識と経験が蓄積されることも、大切な価値です。システムを作る過程で得られた知識は、障害対応や、次期システムの仕様検討にも活きてきます。ベンダーに任せきりにしていると、組織としての技術力は育ちません。
だから、内製を選ぶこと自体は、決して悪くありません。問題は、「何でもかんでも内製にする」「作れるから作る」という判断の仕方にあります。内製の価値を活かすためにも、何を内製し、何をベンダーに任せるか、その線引きを意識的に行う必要があるのです。
ベンダーの価値も、本物である
同じように、ベンダーに頼むことの価値も、きちんと認めておきたいと思います。
まず、組織としての体制があることです。ベンダーは、複数の技術者を抱えていて、担当者が休んだり、異動したりしても、サービスを継続できる仕組みを持っています。夜間や休日の障害対応の窓口を用意しているところも多く、一人の技術者の都合に左右されません。この「個人に依存しない」という点は、病院のように止められない業務を支えるシステムでは、非常に大きな価値です。
次に、責任の所在が明確になることです。ベンダーに依頼したシステムで不具合が起きた場合、契約に基づいて、修正や対応を求めることができます。内製のシステムで同じことが起きれば、責任は、作った自分と、自分の所属する部署に返ってきます。これは、重い責任です。
また、専門性と経験の蓄積があることです。医療分野に特化したベンダーは、多くの病院での導入実績を持っています。法令や指針への対応、他システムとの標準的な連携方式、運用上の落とし穴など、一つの病院の内製では得られない知見を持っています。
そして、自分の時間を、別のことに使えることです。システムをベンダーに任せれば、自分は、現場との調整、全体の設計、障害時の対応、次の改善の検討といった、本来の役割に集中できます。すべてを自分で作っていては、手が回らなくなります。
ベンダーに頼むのには費用がかかりますし、小回りもききにくくなります。でも、その費用は、個人に依存しない体制、責任の明確さ、専門性、時間の余裕という価値に対する対価でもあります。単純に「高い」と考えるのは、片側しか見ていない判断だと思っています。
開発費は、氷山の一角だった
では、なぜ私は、判断の重心を「作ったあと」に移すようになったのか。それは、開発費が、システムの生涯にわたる費用の、ほんの一部にすぎないと痛感したからです。
システムは、作って終わりではありません。作った瞬間から、運用と保守の期間が始まります。そして、その期間は、作る期間よりも、はるかに長いのです。数年、場合によっては十年以上。その間、システムは、使われ続けます。
使われ続ける間に、さまざまなことが起きます。
まず、現場の運用が変わります。診療報酬の改定、院内の体制の変更、新しい機器の導入。それに合わせて、システムにも変更が必要になります。「この項目を追加してほしい」「帳票のレイアウトを変えたい」「集計の条件を変えたい」。こうした要望は、システムが使われている限り、永遠に続きます。
次に、周辺の環境が変わります。電子カルテや部門システムが更新されれば、連携の仕組みも見直しが必要です。OSの更新、端末の入れ替え、ネットワークの変更。システムの周りの世界は、常に動いています。
そして、障害が起きます。どんなに丁寧に作っても、システムは止まることがあります。入力データの想定外のパターン、データベースの容量、ほかのシステムとの相互作用。原因は、無数にあります。障害が起きたとき、現場は、すぐに直してほしいと言います。夜間でも、休日でも、です。
さらに、問い合わせへの対応があります。「使い方が分からない」「エラーが出た」「数字が合わない」。作ったシステムが使われている限り、問い合わせは来ます。そのたびに、作った人が対応することになります。
こうした運用と保守にかかる時間と労力は、開発そのものにかかった時間を、あっという間に超えます。内製のシステムが増えれば増えるほど、保守の負担は積み上がっていきます。五つ作れば五つ分、十作れば十分の保守が、毎日の業務にのしかかります。
開発費が「無料」に見えるのは、保守の費用が、見えない形で、自分の時間を少しずつ削っているからです。それに気づくまでに、私は何年もかかりました。
失敗から学んだこと：作った人しか分からないシステム
具体的な失敗を、ひとつ書きます。
以前、ある部署の要望で、小さな集計ツールを作りました。現場の方は、とても喜んでくれました。毎月数時間かかっていた作業が、数分で終わるようになったのです。私も、役に立てたことが嬉しく、その後も、小さな改善要望に応え続けました。
しばらくして、そのツールは、その部署にとって、なくてはならないものになっていました。月次の報告の元データとして使われ、他の部署の人たちも、そのツールの出力を参照するようになっていました。作った当初は、「ちょっとした便利ツール」だったものが、いつの間にか、「業務の一部」になっていたのです。
ある日、そのツールで、数字が合わないという問い合わせが来ました。調べてみると、データベース側の項目の仕様が、ある時期から変わっていたことが分かりました。連携先のシステムの更新で、データの形式が少し変わっていたのです。その事実に、誰も気づいていませんでした。ツールは、エラーを出さずに、間違った数字を出し続けていたのです。
原因を突き止めて、修正することはできました。問題は、その後でした。「いつから間違っていたのか」「どの期間のデータが影響を受けたのか」。それを確認するために、過去のデータをさかのぼって調べる必要がありました。その作業には、思った以上に時間がかかりました。そして、報告に使われていた数字の訂正という、現場にとって負担の大きな対応が必要になりました。
このとき、強く思いました。もし、このツールを作った自分が、すでにここにいなかったら、どうなっていただろうか。誰が原因を調べられただろうか。ソースコードはあっても、背景を知る人がいなければ、手がつけられなかったでしょう。
そして、気づいたのです。このツールには、きちんとしたテストも、仕様の記録も、変更の履歴も、十分には残っていませんでした。「小さなツールだから」と、手を抜いていた部分が、すべて、後から自分に返ってきたのです。
もうひとつ、別の失敗もあります。自分が休んでいる間に、障害が起きたことがありました。作った人間にしか分からない部分が多く、他のメンバーが対応に苦労しました。連絡を受けて、休みの日に対応することになりましたが、そのとき思いました。「これは、私がいなければ回らない仕組みになっている」と。
それは、一見、頼りにされているように見えて、実は、組織にとっても、自分にとっても、危険な状態です。一人にしか分からないシステムは、その人が病気になったとき、異動したとき、退職したときに、突然、組織の弱点に変わります。
この経験が、「作れるから作る」という判断を、疑うきっかけになりました。
判断基準その一：止まったとき、誰がどれだけ困るか
こうした経験を経て、私が今、判断の際に最初に考えるのは、「このシステムが止まったとき、誰がどれだけ困るか」です。
止まっても、数日、誰も気づかないようなものなら、内製で気軽に作っても、リスクは小さいと考えます。たとえば、自分の部署内だけで使う作業用のツールや、一時的な集計のためのプログラムなどです。
一方で、止まったときに、診療の現場が困るものは、慎重に考えます。患者さんの診療や、投薬、検査、会計といった業務に、直接関わるものです。こうしたシステムは、止まったときの影響が大きく、復旧のスピードも求められます。夜間や休日でも、すぐに対応できる体制が必要です。
私一人の体制で、そうした要求に応え続けられるか。これを、正直に自問します。夜間に呼び出されたとき、すぐに対応できるのか。自分が休暇を取っているとき、誰が対応するのか。自分が体調を崩したら、どうなるのか。
この問いに、自信を持って「大丈夫」と答えられないなら、そのシステムは、一人の内製で抱えるべきではないと判断します。ベンダーの保守体制や、複数人での運用体制を考えるべきです。
「止まったとき」の影響の大きさは、システムを作るかどうかを決める、一番大きな物差しになっています。
判断基準その二：使う人の数と、広がりの見込み
二つ目の基準は、「使う人の数と、これから広がる可能性」です。
最初は、ある部署の数人だけが使うはずだったシステムが、気づけば、院内の多くの部署で使われるようになる。これは、よくあることです。便利なものは、口コミで広がります。広がること自体は良いことですが、それに伴って、責任も重くなります。
利用者が増えれば、問い合わせが増えます。要望が増えます。障害の影響範囲が広がります。最初は個人の便利ツールのつもりだったものが、病院全体の業務基盤の一部になってしまうのです。
そこで、私は、作る前に、「これが広まったらどうなるか」を想像するようにしています。この仕組みを、他の部署でも使いたいと言われたら、対応できるか。利用者が十倍になったら、運用は回るか。こうした想像は、時に面倒ですが、後々の苦労を減らしてくれます。
もし、広がる可能性が高いのであれば、最初から、きちんとした体制と設計で進めるべきです。逆に、広げないと決めるのであれば、その範囲を明確にして、関係者に伝えておく必要があります。「これは、この部署の作業用です。他の用途には使わないでください」と。
範囲を決めずに、なんとなく広がっていくのが、一番危険です。気づいたときには、手に負えなくなっています。
判断基準その三：ほかのシステムとのつながりと、責任の線引き
三つ目の基準は、他のシステムとの関係です。
病院のシステムは、単独で動いているものはほとんどありません。電子カルテ、検査、放射線、薬剤、会計など、多くのシステムが連携しています。内製のシステムも、多くの場合、これらのどれかとデータをやりとりします。
ここで問題になるのが、責任の線引きです。内製のシステムが、電子カルテのデータを読み取って加工している場合、電子カルテ側の仕様変更が、そのまま内製システムの不具合につながります。逆に、内製システムが誤った処理をして、他のシステムに影響を及ぼすこともあります。
こうした連携がある場合、ベンダーとの関係も考えなければなりません。電子カルテのベンダーに、内製システムとの連携について、どこまで説明し、どこまで了解を得ておくか。仕様変更があるときに、事前に連絡をもらえる体制があるか。こうした調整を怠ると、思わぬ障害を招きます。
また、「障害が起きたとき、原因がどちらにあるのか」を切り分ける難しさもあります。連携しているシステム同士の障害は、責任の所在が曖昧になりがちです。内製の部分が原因なのか、ベンダーのシステムが原因なのか。切り分けのための情報を、普段から整えておく必要があります。
他のシステムとの連携が深いものほど、内製で作る際の責任は重くなります。連携の仕組みが複雑になるようであれば、ベンダーと共同で設計するか、ベンダーに任せる選択肢を、真剣に検討します。
判断基準その四：医療情報を扱うことの重み
四つ目の基準は、扱う情報の性質です。
病院のシステムは、患者さんの医療情報を扱います。この情報は、極めて機微なものであり、取り扱いには、法令や、国の指針に沿った、厳格な安全管理が求められます。アクセス権限の管理、操作の記録、データの保護、持ち出しの制限、バックアップなど、考えるべきことは多岐にわたります。
内製のシステムでも、これらの要求を満たさなければなりません。「小さなツールだから」「院内でしか使わないから」という理由で、安全管理を省略することはできません。作る側は、システムの機能だけでなく、安全管理の面でも、責任を負います。
私は、医療情報を扱うシステムを内製する際には、特に慎重になります。権限の制御や、記録の仕組みを、きちんと設計に入れられるか。監査の際に、説明できる状態にできるか。万が一、情報漏えいなどの問題が起きたとき、組織として対応できる体制があるか。
こうしたことを、一人の技術者の判断で背負いきれるのか、という点も考えます。責任の重さを考えると、第三者の目で設計や運用を確認してもらったり、専門のベンダーの知見を借りたりすることが、結果的に、組織を守ることにつながる場合があります。
扱う情報が重要であればあるほど、「作れる」という技術的な可否よりも、「責任を持って運用し続けられるか」という組織的な判断が、優先されるべきだと考えています。
判断基準その五：自分がいなくなったとき、誰が引き継ぐのか
五つ目の基準は、私が五十代になって、特に重みを感じるようになったものです。それは、「自分がいなくなったとき、誰が引き継ぐのか」という問いです。
若い頃は、この問いを、ほとんど考えませんでした。自分がこのシステムを作って、自分が保守していく。それが当たり前だと思っていたのです。
でも、年齢を重ねると、自分の時間が有限であることを、実感として理解するようになります。いつか、異動するかもしれない。いつか、定年を迎える。あるいは、突然、仕事を続けられなくなるかもしれない。そのとき、自分が作ったシステムは、どうなるのか。
引き継ぎ先がはっきりしていて、引き継ぐために必要な資料と時間を用意できるなら、内製を選ぶことに、大きな不安はありません。しかし、引き継ぐ人がいない、あるいは、引き継ぐ仕組みを用意できない場合、そのシステムは、自分の退職とともに、孤児になる可能性があります。
これは、システムを作った人間の、倫理的な責任の問題でもあります。自分が作ったものを、後に残す人たちに、負債として押しつけてはいけない。そう考えるようになりました。
ですから、新しく何かを作ろうとするとき、私は、「このシステムを、他の人が引き継げるように作れるか」を問います。ソースコードの読みやすさ、環境の再現方法、仕様と変更の記録、データベースの定義、運用の手順。これらを、引き継ぎができるレベルで整える時間と余力があるか。
もし、その余力がないなら、作らないという選択肢も、真剣に考えます。作らないことは、逃げではなく、責任ある判断のひとつです。
判断基準その六：変化の頻度と、保守に使える時間
六つ目の基準は、システムの変化の頻度と、自分が保守に割ける時間です。
業務の内容が、頻繁に変わるものは、システムも頻繁に変更が必要になります。診療報酬の改定に連動するもの、院内の運用がまだ固まっていないもの、現場の要望が次々に出てくるもの。こうしたシステムは、作ったあとも、継続的な保守の時間が必要になります。
一方で、業務の内容が安定していて、ほとんど変更が必要ないものは、一度作ってしまえば、保守の負担は小さくなります。
この「変化の頻度」を見誤ると、苦労します。「ほとんど変わらないだろう」と思って作ったものが、実際には、毎月のように修正が必要になることがあります。そして、そのたびに、自分の時間が取られます。
そこで、私は、自分が一年間に使える保守の時間を、現実的に見積もります。すでに抱えているシステムの保守、日々の問い合わせ対応、障害対応、会議や資料作成。それらを差し引いた上で、新しいシステムの保守に、どれだけ時間を割けるか。
この見積もりをすると、思った以上に、余裕がないことに気づきます。そして、「新しく作ること」には、「今ある保守の時間を、さらに削ること」が含まれていると、実感します。
作るたびに、保守の負債が一つ増える。そう考えると、「本当に、今、作るべきか」と、慎重になります。すでに保守しているものを整理して、不要なものを廃止してから、新しいものを作る。そういう順番を考えることもあります。
ベンダーに頼むときの落とし穴
ここまで、内製の判断について書いてきましたが、ベンダーに頼めば安心、というわけでもありません。ベンダーに頼む場合にも、気をつけるべきことがあります。
一番の落とし穴は、丸投げです。「専門家に任せたのだから、大丈夫だろう」と、仕様の検討や受け入れの確認を、十分に行わずに進めてしまうことです。現場の業務を一番理解しているのは、ベンダーではなく、私たちです。要求を正確に伝えなければ、現場に合わないものができあがります。
次に、仕様の伝え方の難しさです。現場の要望は、しばしば曖昧です。それを、ベンダーに伝わる仕様書にまとめる作業は、簡単ではありません。この作業を軽く見ると、納品されたものが、期待と違った、という事態になります。そして、仕様の変更には、追加の費用がかかります。
また、システムがブラックボックスになる危険もあります。ベンダーが作ったシステムの内部が分からなければ、障害が起きたとき、原因の切り分けも、ベンダーに頼るしかなくなります。ベンダーの対応が遅ければ、現場の困りごとが長引きます。ソースコードや設計資料の開示範囲、データの持ち出し方法などを、契約の段階で確認しておくことが重要です。
さらに、保守の契約内容についても、注意が必要です。どこまでが保守の範囲に含まれるのか、夜間や休日の対応はどうなるのか、対応にかかる時間の目安はどうか。契約書を読み込んで、現場の要求と照らし合わせておかなければなりません。
そして、ベンダーとの関係が長くなると、依存の問題が生じます。他のベンダーに乗り換えようとしても、データの形式や、仕組みの独自性のために、簡単には移れなくなります。いわゆる、ロックインの状態です。これは、費用の面でも、交渉力の面でも、不利に働きます。
つまり、ベンダーに頼むというのは、「楽をする」ことではありません。別の種類の責任と、別の種類の労力が必要になるのです。ベンダーとの付き合い方を学ぶことも、現場のSEの大切な仕事だと思っています。
それでも「自分で作る」と決めたときの条件
では、判断の結果、「自分で作る」と決めたときに、私が自分に課している条件を書きます。
一つ目は、ビルドして動く状態を、一式で保管することです。ソースコードだけでなく、必要な設定、参照している部品、アセンブリ情報まで含めて、いつでもコンパイルできる状態を保ちます。「ソースはあるが、ビルドできない」という状態は、引き継ぎの際の最大の障害になります。
二つ目は、ソースコードを、読みやすく書くことです。適切に改行を入れ、処理の区切りを分かりやすくし、名前の付け方も、後から読んで意味が分かるようにします。自分しか分からない書き方は、避けます。
三つ目は、仕様と変更の記録を残すことです。何のために作ったのか、どんな前提で動いているのか、いつ何を変更したのか。簡単なもので構いませんので、必ず書き残します。特に、「なぜそうしたのか」という理由を、できるだけ書いておきます。
四つ目は、データベースの定義や、環境の構成を、文書として保管することです。データベースを再構築するための定義文、必要な設定、運用の手順。これらがあれば、環境が壊れたときにも、引き継ぎのときにも、助けになります。
五つ目は、利用範囲を、はっきりさせることです。誰が、どの業務で、どこまで使うのか。それを関係者に伝え、記録に残します。範囲を超えて使われそうになったら、立ち止まって、判断をやり直します。
六つ目は、引き継ぎ先を意識することです。具体的な誰かが決まっていなくても、「次に見る人」を想像しながら作ります。その人が、このシステムを理解するのに、何が必要か。それを準備しておきます。
七つ目は、終わらせ方を考えておくことです。システムには、寿命があります。いつか役目を終えて、廃止するときが来ます。そのとき、データをどう扱うか、現場の運用をどう切り替えるか。作る時点で、出口も、少し想像しておきます。
これらの条件を満たせないなら、その時点で、「やはり内製は控えるべきだ」と判断します。条件を満たす余力があるかどうかが、内製の可否の、最終的なチェックポイントです。
ベンダーに頼むと決めたときの条件
反対に、「ベンダーに頼む」と決めたときにも、守りたい条件があります。
一つ目は、要求を、自分たちの言葉で、きちんと整理することです。何を実現したいのか、なぜそれが必要なのか、現場でどんなふうに使われるのか。これを明確にしてからでなければ、ベンダーに相談しても、話が噛み合いません。仕様書の作成には、時間をかけます。
二つ目は、受け入れの確認を、現場と一緒に丁寧に行うことです。納品されたものが、実際の業務で使えるかどうか。現場の方に実際に触ってもらい、確認します。忙しい現場に時間をもらうのは大変ですが、ここを省くと、運用開始後に大きな問題が出ます。
三つ目は、保守の範囲と、連絡の方法を、あらかじめ明確にしておくことです。障害が起きたとき、誰が、どこに連絡し、どれくらいの時間で対応してもらえるのか。これを事前に確認し、現場にも共有しておきます。
四つ目は、データの扱いについて、確認しておくことです。データベースの構造、データの出力方法、将来的に他のシステムへ移す際の手段。これを確認しておかないと、後で、身動きが取れなくなります。
五つ目は、技術的な理解を、手放さないことです。ベンダーに任せていても、システムの仕組みを、ある程度は理解しておく。そうすれば、ベンダーとの対話が、対等になります。完全に理解する必要はありませんが、「何がどう動いているか」の大枠は、把握しておきたいと思います。
ベンダーに頼むときも、結局は、自分たちが主体的に関わる必要があります。「任せる」と「任せきりにする」は、別のことです。
間の選択肢：試作を作り、仕様として渡す
実は、「ベンダーか内製か」という二択以外にも、現実的な選択肢があります。
その一つが、内製で小さく試作を作り、それを土台にして、仕様をまとめてベンダーに渡す、という方法です。
現場の要望は、言葉だけでは伝わりにくいことがあります。「こんな感じ」と、動く試作を見せると、現場の方も、「ここは違う」「これは必要」と、具体的に意見を言いやすくなります。この試作の過程で、要件が整理され、仕様書の精度が上がります。
その後、本格的な開発や運用は、ベンダーに任せる。こうすれば、仕様の曖昧さによる手戻りを減らしつつ、運用と保守の責任は、ベンダーの体制に預けることができます。
この方法は、次期システムの仕様書を作る際にも、役に立ちます。現場の実際の使われ方を、試作を通じて把握しておけば、仕様書の質が上がります。更新費用を確保するための説明資料も、具体的な画面や動きを示せるぶん、説得力が増します。
もう一つの選択肢は、内製を続けつつ、ベンダーの協力を一部得ることです。たとえば、設計のレビューや、安全管理の観点でのチェックを、ベンダーや外部の専門家に依頼する。完全にお任せするわけではなく、弱い部分を補ってもらうという関わり方です。
「自分で全部やる」か「全部任せる」かの二択で考えるのではなく、役割を分担する発想を持つと、選択肢は広がります。
組織に説明する言葉を持つ
判断の際には、組織に対して説明する言葉を持つことも、大切だと思っています。
内製か、ベンダーかという判断は、情報システム部門の中だけで完結しません。予算を管理する部門、責任を持つ管理職、現場の部署と、調整が必要になります。そのとき、技術的な理由だけで説明しても、理解されにくいことがあります。
私が心がけているのは、「業務への影響」と「リスク」の言葉で説明することです。
たとえば、「このシステムを内製すると、費用は抑えられますが、夜間の障害時に、対応できるのが私一人になります。その間、診療に影響が出る可能性があります」と伝える。あるいは、「ベンダーに依頼すれば、費用はかかりますが、二十四時間の保守体制が得られ、個人の異動や退職の影響を受けません」と伝える。
こうして、費用だけでなく、リスクと安心を、並べて示すと、判断する側も、全体像をつかみやすくなります。「安いから内製」「高いからやめる」という単純な判断ではなく、組織として、何を重視するのかを、議論できるようになります。
そして、判断の結果を、記録に残しておくことも大切です。なぜ内製にしたのか、なぜベンダーに頼んだのか。後から振り返ったときに、その判断の背景が分かるようにしておきます。記録があれば、将来、状況が変わって見直すときにも、助けになります。
五十代になって、変わったこと
最後に、年齢と判断の関係について、少し個人的なことを書いてみます。
若い頃の私は、とにかく作ることが楽しくて、頼まれればなんでも作っていました。自分の腕が上がっていく実感があり、現場の役に立っている手応えもあり、それが仕事の喜びでした。保守の負担や、引き継ぎのことなど、ほとんど考えていませんでした。
年齢を重ねて、さまざまな経験をするうちに、判断の基準が、少しずつ変わっていきました。障害で夜中に呼び出された経験。自分にしか分からないシステムに、苦しめられた経験。現場の方に、迷惑をかけてしまった経験。そうした経験が、「作れる」という感覚に、慎重さを加えてくれました。
また、自分の時間が有限であるという実感も、大きいと思います。残りの勤務年数を考えたとき、自分が責任を持って保守できるシステムの数には、限りがあります。何を作り、何を作らないか。その選択は、自分の時間をどう使うかという選択でもあります。
この変化を、「衰えた」とは思っていません。むしろ、「見える範囲が広がった」と思っています。作る瞬間だけでなく、その前後の、長い時間を見渡せるようになった。それは、経験を積んだ人間の、ひとつの成長だと考えています。
もちろん、慎重になりすぎて、何も作らなくなってしまうことは、避けなければなりません。現場の困りごとに応えることは、私たちの仕事の核心です。内製の価値を、忘れてはいけません。大切なのは、バランスです。作るべきものは作り、頼むべきものは頼み、作らないと決めたものは作らない。その判断を、冷静に、自分の言葉で説明できるようになること。それが、今の私の目標です。
おわりに：誘惑に、問いで答える
この記事の内容を、あらためてまとめます。
「これくらいなら自分で作れる」という誘惑は、技術者としての楽しさ、速さへの魅力、費用の見えにくさ、自分への自信から生まれます。でも、それらはすべて、作る瞬間の話です。
開発費は、システムの生涯にわたる費用の、氷山の一角にすぎません。保守、引き継ぎ、障害対応、問い合わせ。作ったあとの長い時間にこそ、本当の負担が現れます。
私が判断の際に問うのは、次のようなことです。止まったとき、誰がどれだけ困るか。使う人は、これからどれくらい広がるか。ほかのシステムとの連携と、責任の線引きはどうか。扱う情報の重みに、責任を持てるか。自分がいなくなったとき、誰が引き継ぐのか。変化の頻度に対して、保守の時間を確保できるか。
そして、内製を選ぶなら、ビルドできる一式の保管、読みやすいコード、記録、環境の文書化、利用範囲の明確化、引き継ぎ先の想定、終わらせ方の想像を、自分に課す。ベンダーに頼むなら、要求の整理、受け入れの確認、保守範囲の明確化、データの扱いの確認、技術的な理解の維持を、怠らない。
内製とベンダーは、対立するものではなく、役割を分け合うものです。試作を内製で作って仕様に落とす、設計のレビューを外部に頼む、といった中間の選択肢もあります。
「これくらいなら、自分で作れる」と思ったとき、私は今、いったん手を止めて、自分に問いかけます。「作ったあと、五年後の自分と、その次の誰かは、これを抱えられるか」と。
その問いに、自信を持って「はい」と答えられるなら、作ります。答えられないなら、別の道を探します。それが、五十代の現場SEとして、私がたどり着いた、今の判断のしかたです。
同じような立場で、同じような迷いを抱えている方が、もしいらっしゃれば、「うちではこう判断している」という経験を、ぜひ聞かせてください。現場の知恵を持ち寄ることが、一人で抱え込まないための、一番の方法だと思っています。
最後まで読んでいただき、ありがとうございました。
