RedoIT 受注時環境調査票のご記入のお願い

受注時環境調査票を使用することによって、貴社の現在の状態を把握することが可能です。それぞれについて、説明します。

入り口について

システムエンジニアにプログラムを書かせないで採用する場合、未経験の方や貴社以外の環境を知らない方が多くいらっしゃると予想されます。

一方で、ある程度の年数のシステムエンジニアさんの多くは、新人教育が業務の一環として取り入れられていることと思われます。

この場合、貴社の開発リソースは新人教育に大きく割かれており、生産性が損なわれている可能性があります。

検証について

プロジェクトが開始する前に、いまからやることがどのようなことなのか、プロジェクトを依頼する側が、しっかりと把握する必要があります。

例えば、料理を注文するとき「本日のおすすめランチで」といえば、何が出てきても「これがおすすめか」と納得できると思いますが、「とんかつランチをご飯大盛りで」と注文したときに、ご飯が少なかったり、とんかつが小さかったり、ソースやからしがいまいちだったりすると、どうして先に言ってくれなかったのか?となると思います。システム開発もまったく同じです。

ただ、1つ違うことは、依頼するほうが「どんなシステムができるのか」を想像することが非常に難しいということです。とんかつランチはわかりやすいですが、業務用基幹システムはわかりにくいです。

この設問でわかることは、このシステムを制作するにあたって、注文をするみなさんが、このシステムを理解するためにどんなことをしているのかがわかります。

スケジュールについて

世間では、システムエンジニアは何をやっているのかわからない不思議な職業だと言われます。それはわかりにくい横文字や、オブジェクト指向や論理的思考による会話が複雑に見えるからだと思います。

「よくわかんないから、適当に見ておこう」と考えてしまうと、プロジェクトは非常に危険な状態になる可能性があります。なぜなら、システム開発はオーダーメイドだからです。

先のとんかつランチの例を思い出してください。あなたのために選んだ豚、キャベツ、お米、からしの選び方はどうあれ、いまなにを選んでいるのか、調理法を試したのかなどは知りたいと思いませんか?まさか味見もしないでお皿に乗っけているとは思いません。

この設問でわかることは、チームの進捗をどのように管理しているか、そしてどの程度任せているかです。

作業について

システムエンジニアはコンピューターを操作したり、自動操縦する仕組みを構築したりしますが、人です。人なのでミスをします。複雑なことや失敗しそうなことはしないほうがいいです。

”ミス” を減らすことは、非常に重要です。「ミスが起こるのではないか」という緊張は、作業担当者の心身をすり減らします。

まずは、できるところから、手順書を作成したり、自動化したりすることが良いと思います。

この設問でわかることは、チームメンバーを必要以上に緊張して作業させているかです。

貴社の環境はいかがでしょうか?
チェックをよろしくおねがいします。

RedoITと作業をしたあとでは、このすべての項目にチェックがつくはずです。作業前後でどうなるか、ぜひご確認ください。

受注時環境調査の項目

社内にシステムエンジニアがいる場合に、ご回答ください。


入り口について

  • システムエンジニアを採用するとき、プログラムを書かせていますか?

 


ここから下は、システム開発のプロジェクトがスタートしている場合に、ご回答ください。

検証について

  • デザイナーはプロジェクトに参加していますか?
もし参加しない場合、CSSフレームワークを採用しますか?
  • プロトタイプ(試作品)を作成していますか?(ペーパープロトタイプ、HTML紙芝居など)
  • 「廊下で使い勝手テスト1)廊下で使い勝手テストとは、プロジェクト外の複数の人間に、簡単にUIのチェックをしてもらうこと。」を行っていますか?
  • 検証(テスト)専属の担当者はいますか?
  • システムの利用者から、フィードバックを得る仕組みがありますか?

スケジュールについて

  • 詳細な(1日2タスク以上の)予定を作成していますか?
  • 更新可能なスケジュール管理システムを使っていますか?
  • システムエンジニアが作業スケジュールの完了日を自分自身で決定できますか?

作業について

  • ソース管理はなにを使っていますか?
  • システムエンジニアはテストを書くことを要求されますか?
  • ユニットテストやビルド、デプロイの作業は、ワンステップ2)ワンステップとは、ミスをしそうな複雑な操作を必要としないこと。ゲートチェックイン方式を使用したり、継続的インテグレーションを使用したりすること。で行えますか?
  • 新しいコードを書く前に、既知のバグ修正を優先しますか?

 

References   [ + ]

1. 廊下で使い勝手テストとは、プロジェクト外の複数の人間に、簡単にUIのチェックをしてもらうこと。
2. ワンステップとは、ミスをしそうな複雑な操作を必要としないこと。ゲートチェックイン方式を使用したり、継続的インテグレーションを使用したりすること。

この話題の知識を共有していただけませんか?