ラベル 企業 の投稿を表示しています。 すべての投稿を表示
ラベル 企業 の投稿を表示しています。 すべての投稿を表示

2020年8月9日日曜日

システム会社への依頼からサービスの現場投入までの流れ


こんにちは。

ここ数年、DX(デジタルトランスフォーメーション)と言う言葉をよく耳にします。
DXについては、以下のWikipediaを参照してください。

Wikipedia:デジタルトランスフォーメーション


そのような中、「システム化したいけど、どうしたらいいのだろう?」と言う声も聞こえて来ます。

そこで、今回は、システム会社への依頼からサービスの現場投入までの流れについて、依頼する側の目線で書いていきます。

私は、プログラマーとして10年以上の経験があります。
私の場合は、システム会社で実際にシステムを作のが仕事なのですが、依頼する側の動きによって、システム開発の成否が決まる事があります。
なので、今回は、依頼する側の目線で書いていきます。


システム会社への依頼からサービスの現場投入までの流れ




では、早速ですが結論です。

  1. 仕様を作る
  2. 見積もりを取る
  3. 契約する
  4. 検証する
  5. 現場に投入する

これが、システム会社へ依頼して現場投入するまでの流れになります。

以下で、詳細について書いていきます。

1.仕様を作る


まずは、自分の会社の業務を棚卸から始めましょう。

以下を整理するのです。
  • 仕事がどのように流れているのか。
  • どういう作業をしているのか。
  • そこにコストはどれだけかかっているのか。
その上で、どこをシステム化すれば、本来の業務に集中できるのかを検討するようにしましょう。

ちなみに、システム化しやすい作業としては以下になります。
  • 計算
  • 単純なチェック
  • データの整理
仕様の作成が難しい場合は、仕様の作成のみをシステム会社に依頼するのもありだと思います。

2.見積もりを取る


仕様をもとに、システム会社へ見積もりを依頼しましょう。

見積もりを依頼する会社は、複数あった方がいいと思います。

仕様については、詳細に説明をし見積もりに漏れがないようにしましょう。

また、契約する会社を検討する場合は、金額だけではなく、詳細を見るのが必要です。

よく必要な機能が含まれていなかったり、納品物が思っている物と違っていたりする事があります。

システム会社もビジネスなので、見積もりに含まれていない機能は、追加で請求されます。

終わってみたら、思っていた以上に請求されたという事がないように、この時点できちんと確認するようにしましょう。

見積もりで詳細が分からない場合は、詳細について直接聞くのがいいと思います。

3.契約する


見積もりについて十分に納得できたシステム会社と契約することになります。

契約する際の注意点は以下になります。
  • 納期の確認をする
  • 問い合わせ窓口を明確にする
  • 進捗報告の方法について明確にする
納品の時期というのは、使用を作る際に決めていると思うのですが、改めて具体的に日付について確認します。

また、システム開発中に、いろいろな質問が双方に発生するので、その窓口を明確にしておく事が必要です。

窓口は、基本1本化した方が、システム全体が統一されていいと思います。

それと、質問についてはリスト化しておくことをお勧めします。

あとで言った言わないの問答になる事がなように、質問はリスト化して双方で管理しましょう。

進捗報告については、定期的な報告を受けるようにした方がいいです。

システム開発は、依頼する側からすると見えないので、今どういう作業をしているのかを確認できるようにしておきましょう。

4.検証する


システムが納品されると、すぐに現場へ投入したくなるでしょう。

その気持ちはよく分かります。

しかし、納品されたシステムが期待通りの動きをするのか検証する必要があります。

もし、現場へ投入した後で、不具合が発生した場合、多いな損失が発生する事があるからです。

検証の流れは以下になります。
  1. 仕様と照らし合わせ検証する
  2. 実データを使って検証する
  3. エラーデータを使って検証する

まずは、仕様と照らし合わせて検証しましょう。

ここで不具合が発生するようであれば、再度、結合試験のやり直しを依頼しても良いと思います。

次に、実データを使って、実際の運用に耐えうるかの検証をします。

もし、実運用で複数のPCを同時で使用するのであれば、同じように複数のPCを使用することをお勧めします。

次に、エラーデータを使って検証します。

実運用するようになると、エラーデータも扱うことになりますので、そのための検証となります。

よくあるのは、エラーを検出できなかったり、システムが落ちてします事があります。

5.現場へ投入する


検証まで終わったら、実際に現場へシステムを投入することになります。

その時は、検証で使用したデータは削除するようにしましょう。

現場へ投入する手順は以下になります。
  1. 並行でシステムを稼働させる
  2. 問題ないかの確認をする
  3. システムへ切り替える
検証が完了したからと、システムをすぐに本番稼働させるのは危険です。

実際の業務では、想定外の負荷がシステムにかかったり、想定外のデータが入力される事があります。

その時、システムが不具合を起こすと大きな損失が出る可能性があります。

なので、初めの数ヶ月は、これまでの作業と並行でシステムを稼働させるようにしましょう。

並行でシステムを稼働させて、問題がないかの確認をします。

その時、実際に使用している方にヒアリングするのも良いと思います。

ただし、この段階での使い勝手などは不具合にはなりませんので、追加案件としてシステム会社へ依頼することになります。

並行でシステムを稼働させて問題ないようなら、システムを切り替えて業務することになります。

システムを開発した会社へフィードバックする


これは、テーマとは少し外れてしまうのですが、一度システムを開発した会社とは、その先も繋がっておいた方が良いと思います。

なので、本番稼働したら業務がどのように変わったのか、現場はどう変わったかと言ったフィードバックを返すようにしましょう。

これって、実際に開発した側からすると、本当に嬉しいんですよね。

依頼した側から見ても、システム会社と繋がりがあるというのは、次のDXへの強い味方になると思います。

まとめ


今日は、システム会社への依頼からサービスの現場投入までの流れを説明しました。
  1. 仕様を作る
  2. 見積もりを取る
  3. 契約する
  4. 検証する
  5. 現場に投入する
これは、基本的な流れになります。
実際には、問い合わせの対応など細かいことで検討が必要になります。

ここまで読んでみて、どう感じたでしょうか。
  • システム化には時間がかかる。
  • 面倒。
  • 全てシステム会社がやってくれるわけじゃないんだ。
そんな声が聞こえて来そうです。

しかし、あなたの事業は、システム会社は知りません。

システム会社かシステムを依頼通りに作り上げる会社なのです。

なので、仕様の作成も、正常に動作するかの確認も、依頼した側が責任持って確認するしか方法がないのです。

そこまで見込んでシステムへ投資すると、金額は大きくなるかもしれません。

しかし、システムが実際に稼働すると、回収できるから依頼したと思いまし、回収が思った以上に早く終わったという会社も知ってます。

なので、DXへの投資を検討してみてはどうでしょうか。

では、今日はこの辺で。

2020年4月3日金曜日

企業で働くエンジニアが注意しないといけない言葉


こんにちは。

今日は、企業で働くエンジニアが注意しないといけない言葉について書いていこうと思います。

結論から言うと以下になります。
  • できません
  • 簡単です
  • すぐできます
この3点については注意しましょう。

お客様とミーティングしていると、つい言ってしまいそうになる言葉です。

しかし、このような言葉に注意しないと、無駄な作業が増えることになりますよ。

私も、何度もこのような言葉で失敗してきましたので、その経験も含めて書いていきます。

できません

お客様からしてみると、企業で働くエンジニア はプロです。

なので、欲しい機能をどんどん言ってきます。

簡単な機能ならばまだしも、難しい機能になると、つい「それはできません」と言ってしまいそうになります。

でも、よく考えてください。

論理的な機能であれば、手間がかかるかもしれませんが、ほとんどが作り込むことが可能なのです。

私の場合、つい「できません」とその場で言ってしまったばかりに、仕事を失注してしまったことがあります。

あとで知ったのですが、そこまで手間をかけずに作ることができたのです。

論理的な機能なら作り込む事もできますし、一般的な機能ならばWebで調べると簡単にロジックやプラグインがあったりします。

なので、「できません」と言う言葉は控えるようにしましょう。

では、難しい機能の場合どう対応するかと言うと、「難しいです」と言うことを正直に行った上で、「検討させてください」と伝えましょう。

あとは、必死に調べる、または、聞き回ることで、簡単に作り込む方法を考えましょう。

簡単です

システムを発注する企業は、ITの知識が低いことがよくあります。

そのため、どうでもいいような機能をどんどん追加してきます。

その大半は、エンジニア にとっては簡単に作り込むことができます。

ただし、企業でエンジニアをしているということは、自分がプログラミングしている時間はビジネスの時間なのです。

作っているシステムは、企業の商品なのですよね。

私も、「その機能簡単にできるので追加しましょう」と言って、最終的に時間が足りなくなったことがあります。

そしてどうなったかと言うと、開発チームから外されることになりました。

結局、開発チームの利益を使ったことになるんですよね。

ただ、個人的には、お客様が欲しいと言っている機能は、できるだけ組み込みたいと思っています。

すぐできます

この言葉も気をつけた方がいいです。

自分の裁量で判断できるくらいの簡単な機能なら、私もこっそりと組み込んだりもします。

ただ、企業でエンジニアとして働いていると、スケジュールがありますよね。

スケジュールって、他の機能との兼ね合いもあるので、遅れると結構怒られます。

それが自分の技術不足によるものなら、まだスケジュールが悪かったと言えるのですが、こっそりと機能を組み込んだばかりに遅れると、かなり問題になります。

これは、私の経験です。

その時は、隠すことができずにバレてしまい、大目玉をくらいました。

なので、こっそり機能を追加するのであれば、スケジュールとの兼ね合いを十分に考えてから行いましょう。

企業で働くエンジニア としては、これも御法度なのですけれどね。

まとめ

企業でエンジニアとして働いている人は、このような言葉は使っていないと思います。

この3つの言葉、「できません」「簡単です」「すぐできます」は、結局企業の利益を潰しちゃうんですよね。

個人で仕事しているのであれば、普通に使っていいのかもしれません。

でも、企業でエンジニアとして働くのであれば、この3つの言葉には注意しましょう。

では、今日はこの辺で。

おまけ

エンジニア で働くのに役立つ過去の記事を紹介します。



2012年9月16日日曜日

企業のビジョン

昨日、ある企業の今後のビジョンについて話を聞く機会があった。その企業は、「5年後に上場したい」というビジョンを持っているということだった。しかし、その背景を聞いてみると、「その時の状況に柔軟に対応し利益を上げていく」ということだった。

私は、企業のビジョンは夢を語るようなことではないと思う。「例えば、10年後。企業を囲む状況がこうなっているから、我社はその状況の中でこういう位置でありたい。」と、背景がありビジョンがあるのではないだろうか。

もちろん、将来どのような状況になるか正確に分かるはずはない。なので企業のビジョンはその都度修正が必要になる。

企業のビジョンは、その企業の方向性を示すもので、社員はその方向を向いて業績を上げていくことになる。企業の方向性と、社員の方向性が異なっていると摩擦が生じ、社員間でギクシャクしてくるのではないかと思う。

このようなことを考慮すると、企業が社員にビジョンを話す際は、必ずその背景を説明し、ビジョンに向けた動機付けが必要になると思う。