システム開発の方針
| システム開発やプログラム開発をする場合、コスト管理やスケジュール管理、安定性など考慮しなければならない点は数多くあります。 システム開発に携わる者であれば、当然これらの点を考慮するとして、ここでは私たちが特に気をつけている方針について記述してみました。 |
システム全体の成果を高めること
|
プログラム開発の場では、時としてプログラムの内容にばかり注目してしまい、全体としての機能に悪影響を与えてしまうケースがあります。例えば、装置のトラブルなどでエラーが発生した場合、そのエラーをボタン動作一つで自動復帰するようなプログラム改良を行ったとします。しかし、実際にはエラーの箇所を作業者が簡単に手作業で修正してリスタートした方が早くて確実というケースです。 |
シンプルであること
| システム開発する場合、開発の途中の段階で、つい便利な機能が欲しくなることがあります。プログラムがある程度完成して試運転の時にも「こうなったら便利になるだろう」という思いから機能を増やすこともよくあることです。機械設備と違って、プログラムの場合は、画面へのボタン追加なども比較的簡単に行うことが可能だからです。もちろん、その機能が本当に必要で全体として成果のある場合は当然組み込まれるべきでしょう。 しかし、利用することがないのに機能を増やそうとする場合は、問題といえます。 プログラムの追加コストが増加するのは当然ながら、コードのメンテナンス性やプログラム品質にも悪影響を与える可能性が増えます。そして「使わないボタン」が増えるというのはオペレータにとっても「害」となります。５個のボタンの中から目的の操作を選ぶのと、２０個のボタンの中から選ぶのとではどちらが早くて確実でしょうか。 「使う必要のない機能は盛り込まない」という姿勢はとても重要となります。 |
気持ちよく開発できること
| システム開発という仕事は、見方によっては厳しいものです。迫る納期、遅れるプロジェクト、想定外のトラブルなど、大きなプレッシャーとストレスを感じながらの開発もよく聞く話です。 ただ、開発に携わっているのは全て「人」であることに変わりはありません。 コミュニケーションを十分にとって、お互いを信頼する事で必ずいい成果を残せると思います。 そして、感謝の気持ちを忘れなければ、気持ちよく開発できるものと信じています。 決して馴れ合いではなく緊張感の中にもリラックスする時間とリフレッシュすることを心がけて、気持ちよく開発しようと心がけています。 |
持ち場を明確にすること
| システムの開発では、いろいろな装置が関連し、多くの人がかかわります。代表的なのは、電気、機械、ソフトウェアなどに分類されて、開発が行われる場合です。そして、システム全体を考えた時、「この部分は機械が加工」、「その動きは電気的に処理」というように１つの目的のためにどの部分で処理するかが決められます。 初期の設計の段階では、どの部分（電気、機械、ソフトウェア）で処理するかは比較的十分に考えられて問題ありません。 ただ、ある程度設計が終わり、加工、設置の段階でもシステムの仕様を変更する必要が出てくることがあります。 その時に、その変更をどの部分で吸収するかの判断には注意が必要です。 変更や加工の本質を考えた上での判断をしないと後々のメンテナンスや更に追加変更が発生した場合に対応が難しくなります。 例えば、機械的な加工精度が出ない場合に電気やソフトウェアにて対応しようとするような場合です。 本来は機械の加工精度が上がらない原因を突き止め、その対応を優先すべきなのですが、安易に電気やソフトウェアでカバーしようとするケースです。その担当者の「声が大きい」ような時によく発生します。 もちろん、時間的な制約やコストの関係などから他の部分でカバーしなければならない場合もあります。ただ、どんな場合でも安易な方法に頼ってしまうことのないように注意することが重要です。 |
得意分野と苦手な分野
| どんな会社や部門でも得意とする分野とそうでない分野があります。 私共の得意とする分野と苦手とする分野は次のとおりです。 これらのことをお客様にもご理解いただいて、成果の高い開発につなげたいと考えております。 |
| 得意な分野 |
| ・PCとPLC、他のNC装置を組み合わせた加工装置、計測装置など |
| ・PCに各種のコントロールボードを組み込んで、I/O制御、アナログ計測制御、モーターコントロール装置など |
| ・各種センサを利用しての計測制御装置など |
| ・他のPCとのソケット通信などネットワークを利用した統合システム |
| ・各種計測データに対して、アルゴリズムも踏まえての解析、判断のシステム |
| ・新規に開発、発表されたデバイスやセンサを利用しての装置の新規開発など |
| ・オープンソースでのデータベースを用いての小規模データ管理など |
| 苦手な分野 |
| ・OA処理、仕様の打合せやテスト方法などに慣れていないため十分に対応しきれないことが多い |
| ・大規模プロジェクトの中のモジュール開発、全体のスケジュールや他のモジュールとの関係が掴みにくいため効率が悪くなる |