Webデザインを中心に手掛けてきた会社がシステム/業務アプリ開発に進出すると、従来とは異なる危機管理意識が必要になります。どんなリスクがあってどんな備えをしておくといいのか、富山・東京でWeb制作/システム開発を行っているウエブルさんに聞いてみました。

- 増子 愛さん
- 株式会社ウエブル 代表取締役
https://weble.tokyo/
ホームページの制作から始めて学びながら事業を拡大
システム開発やアプリ開発には、Webサイトの構築・運用とは違ったリスクがあります。ここでは、私の実体験などを織り交ぜながら、Web制作会社が開発に踏み出す際の注意点をご紹介しましょう。
私たちウエブルが会社を設立したのは2016年のこと。当時はホームページやランディングページを中心にしていました。創業メンバーには私ともう1人システム開発の経験者がいましたが、どちらも企業内エンジニアとして自己流でやっていたため、システム開発を事業化するのは不安があったのです。しかしその後、近しい知り合いから同窓会の会員管理システムの相談を持ちかけられ、システム開発へと進出しました。
やはり最初は自分の知識に不安があったため、開発者向けの勉強会に参加して実践的なノウハウを学びました。さらに、ある開発会社とのつながりができ、半常駐の形で関わることになりました。代表取締役をしながら、半日はそこで実務をして経験を積んだのです。
こういった経緯の会社ですので、大手のシステム開発会社に比べると歴史も実績も浅いです。しかし、制作会社からシステム開発に進出した会社の事例という形で、自分たちの気づきをお話したいと思います。
Webサイトの制作・運用にもいろいろなリスクは存在しますが、システム開発案件では、相手の業務により密接に関わることになり、その分リスクも増大します
ベストエフォートの対応をあらかじめ理解してもらう
ウエブルは、創業当時わずか4、5人ほどの小さな会社でしたが、今では総勢18人の規模になりました。インフラエンジニアなどさまざまな人材が加わり、システム開発の実績も増えてきました。
しかしそれでも、大手の開発会社に比べると、私たちができることは限られています。開発案件を受注するときは、その点をクライアントにご理解いただけるよう、しっかりと説明を行なっています。
業務システムの場合、プログラムの不具合やトラブルにより業務が止まってしまうと、金銭的な被害が生じる可能性もあります。しかし、ウエブルではこうした金銭的な補償に発展するような案件や、業務の基幹を担うシステムは、そもそも受注しないようにしています。
私たちの規模では、365日24時間の対応を保証するのは不可能です。よく「ベストエフォート型」と呼ばれたりしますが、「できる範囲で可能な限りの努力をする(即時対応は保証できない)」という対応になります。何かトラブルが起きた時は、発生後の営業時間でできる限りの努力をすると説明し、クライアントに納得してもらいます。
このとき、生じうるリスクはなるべく漏れのないように話し合いのテーブルに並べるようにしています。例えば、システムにはエラーが起きうるという点や、エラーに対して原因を説明するとき、どうしても専門的でわかりにくいケースが出てくるといった点です。こうした話は、受注時やキックオフのタイミングなど、なるべく早い段階ですることが大切だと思います。あらかじめリスクを共有することで、何か起きたときにも信頼関係を保つことができます。
また、オープンなコミュニケーションを心がけることも大切です。人為的なミスでトラブルや遅延が発生することは意外とあるものですが、この時変に隠そうとすると、発覚したときに大きな問題になりがちです。なんでも早めに伝えられる関係を築くことで業務が円滑に進むようになり、結果的にお互いの負担が軽減されます。

システムの保守・管理では、しばしば「ベストエフォート型」という表現が使われます。「できる範囲で最大限の努力をする」という意味です。例えば、トラブルが夜に発生した場合でも、対応は翌日の営業時間になるといった形です。クライアントには、自分の会社ができるトラブル対応の範囲をあらかじめ伝えて理解してもらう必要があります
当たり前のことはしっかりと。バックアップとセキュリティ
データや開発環境の保全はWeb制作でも重要ですが、システム開発ではより慎重さが求められます。
データの保全対策としては、「Git」などのバージョン管理システムの利用が考えられます。プログラムソースをサーバにバックアップできるだけでなく、複数人による共同作業でも役立ちます。
作業環境の保全では「Docker」などのコンテナ型仮想化プラットフォームの構築をオススメします。Dockerでは作業環境をコンテナという単位で構築・管理します。もし自分のマシンが不意のトラブルで動かなくなっても、コンテナをほかのマシン上で動かすことができれば同じ作業環境を再現できます。
また、運用中のシステムをトラブルから守るには、サーバの備えが重要です。ウエブルの場合、大きく3つの対策を組み合わせてトラブルに備えています(上図参照)。すべてを実施するのが理想的ですが、現実的にはプロジェクトの予算と内容によって使い分けます。この場合、あらかじめクライアントに対して、どのレベルの対策を施すのか、対策によってリスクがどれくらい違うのかを説明し、理解してもらうことが大切だと思います。
セキュリティに関しても、まずは基本的な部分をおろそかにしないことが大切でしょう。例えば、システムのログインID+パスワードに推測されやすいものは使わない、ミドルウェアは最新の状態を保つ、CMSは脆弱性のあるプラグインを使用しないなどです。さらに、必要に応じてアプリケーション層とデータベース層を分離し、データベース層をグローバルアクセスから遮断するといった対策を行っています。
とはいえ、セキュリティに「ここまでやれば十分」という線引きはありません。前ページと重なる話ではありますが、会社の体制で責任を負いきれるかどうかを見極め、自分たちにできる範疇のものを請け負うことが肝心でしょう。

1から3まですべて実施するのが理想的ですが、現実的には難しい場合もあると思います。とはいえ、最低限の部分的バックアップだけは実施しておきたいものです
外部の知見を取り入れて社内にノウハウを蓄積
システム開発など新しい分野に進出する時は、なるべく自己流を避けて、外部の知見をしっかりと取り入れることが大切だと思います。
冒頭でお話したように、立ち上げの頃は私自身が半常駐で開発会社に勤務しました。このおかげで、自己流ではわからなかった実践的なノウハウを習得でき、会社に還元できました。
もう一つ、弊社が外部の知見を取り入れるために行ったのが、メンターの導入です。メンターとは、指導者や助言者を意味する言葉です。身近に知識の豊富な人がいればいいのですが、ウエブルの場合は、インターネット上のスキルシェアサービスを活用して人を探しました。
メンターになってもらった人には、開発の初期段階で設計をチェックしたり、構築中のコードを見てフィードバックしたりといったことをお願いしました。その中で、データベースの構造や関数の命名規則などで避けたほうがいい方法を指摘してもらい、自分たちだけではわからない気づきを得ることができました。
優れた技術を持った方にCTO(Chief Technical Officer 最高技術責任者)として入ってもらうのが理想的ですが、思ったような人にすぐ巡り合うのは難しかったり、巡り合っても条件の折り合いがつかないケースがあったりします。そのような場合でも、プロジェクト単位でメンターを依頼することで、外部の知見を取り入れることができます。
ノウハウの蓄積という点では、社内の人材育成も重要なポイントです。弊社では、スタッフに自身のスキルアップ目標を設定してもらい、シートに記入して提出してもらいます。そこから定期的に目標の達成状況をヒアリングしたり、指導したりといったことを行なっています。個々のスタッフのスキルを上げることで、会社としてより幅広い対応ができるようになればと思っています。

ウエブルが利用したのは、もともと法人向けに特化したスキルシェアサービスではありませんでした。その中で個別に連絡をとり、「法人だけれどメンターになってほしい」と交渉しました