お客様に・社会に喜んで受け入れられるソフトウェアを開発し、提供し続けよう!

それがソフトウェア開発技術者達の理念です。
開発した本人が、開発に加わった本人が真っ先に使い続けたくなるソフト開発を目指しています。
開発した本人達がワクワクしながら、先を争って使い続けている姿が創造できるソフト開発が理想です。
開発した本人達が、先を争って使い易さを追求し続けるソフト開発が理想です。

ソフトウエア開発

1年間ほど記事を書いてませんでしたので、使い方を忘れております。
そんな訳で、暫くの間は触りまくる事になります。
読者の方には申し訳有りませんが、お見逃しください。

これまでは、世界的に評価され売れているシステム商品のお客様要望のカスタマイズを担当しておりましたが、この度、次世代機の開発部隊に配属になりました。
機能にしても/内部設計にしても/開発環境にしても、現行の最先端トレンドが数多く採用されており、技術者として非常にエキサイティングに感じています。

次世代の設計手法をや、これからの普及を目論む新フォーマットの対応など、業務知識においても現行の最先端トレンドを扱う事が多く、絶え間のない自己学習が欠かせません。

今まで以上に、やりがいのある仕事に推薦して頂き、感謝しております。

最近、ベクトル、三角関数、微分などの数学を復習しています。
連休に実家に帰ったので、本棚から大学時代に使用した教科書の数冊を持ち帰りました。
忘れている部分も多いですが、単に定理などを理解するのではなく、実際にどのように利用できるかが仕事をしてゆく中で解るようになってきましたので、定義なども理解し易いのです。

アプリケーションの機能でも単に作るのと、何故この機能が必要かを理解して作るのでは完成度が変わります。
何事も、なぜ必要なのかが解っていないと効率が悪いと改めて感じています。
グローバル化している製品開発に携わっている者として、数学にアレルギーが無いのは強みだと実感しています。 もう一つ、英語アレルギーの克服チャレンジもしています。

製品作りの工程において、その製品が正しく動作するかを検証する工程があります。
検査(テスト)工程です。 検査を行う上では、チェックリスト(検査仕様書)を作成し、そのチェックリストに基づいて検査します。 ところが最近、メーカーから提出されているチェックリストのクオリティが低すぎると感じています。

誤字脱字は当たり前、理解不可能な記述、仕様書とは全く異なる記述などです。
そのようなチェックリストでは、当然、製品の品質が良くなる訳がありません。
この様な現状を発注社側のリーダーに何度か伝えてますが、なかなか良くなる傾向が見えません。
製品を使う側/ユーザーの意識でチェックリストが作られていないジレンマ!

納品後に製品を使う側の作業工程を、中途半端に理解している当社への発注社。
エンドユーザーの使用現場を知らな過ぎる発注社の検査仕様書。

当社取引先の極一部の案件事例です。 大半の発注社は、シッカリしています。
くれぐれ誤解無きようにお願いします。

プログラムのテストをしていますと、同じ操作をして、あのPCでは障害が発生し、あのPCでは障害が発生しない!という事があります。 今回も、その様な事が起きました。

原因は、”テストするPCに開発現場特有の設定をしていないと障害が発生しない”というものでした。
その設定を知っている社員も少数で、更に、その少数の中でも「ほぼ忘れている状態!」であり、言われて何とか思い出す・・・でした。

折角このような事が起きたのだから、資料に残すとか/開発者全員にメールでもよいので連絡するとかをするのかと思っていたのですが、一切行われませんでした。
日が経ち、同じ様な現象が起きたとき、今回の様に原因調査に時間が掛かるだろうな~と想像できます。
この様なことは、今の職場に拘らず、意外と多くの会社で見受けられる光景です。 特定の人しか知り得ない事があるというのは、同じ開発に携わっている者には困ったものです。

間接的であれ、目にして/耳にして意識する貴重な体験でした。

約10年振りに機械系CAD/CAMシステムの開発を担当することになりました。
先ずは、これから開発に携わるCADの操作を覚える事にしました。 同時に、主に担当することになるCAMの基本知識を再学習しています。
この操作機能は何のため?を確実に理解していないと、現状認識を間違えることにつながり、トラブルの源になってしまいますので、シッカリと把握する様にしています。

午前に1回、午後に2回の質問/確認タイムを取ってもらってますので、あやふやな理解にならない様に、しつこく質問しています。 その質問タイムとは別に、操作が解らない時には直ぐに質問して覚えるようにしてきました。

来週からですが、簡単な修正開発から始めることになりました。

1年ちょっと前になりますが、今の職場に配属になりました。
初めて触るシステムということもあり、機能設計まで終わっている案件だったので、プログラム書きのみばかりでした。
その後、気が付くと、機能設計から任されるようになっていました。
慣れてきたという自覚と、学ぶべきことの多さの両方を実感しています。
さらに充実したいので、PM試験の勉強をしています。
参考書の『~という仕様書を書いた』ではなく、『~という仕様書を書くように指示した』が正解であるとの記述に、ハッとした。
合格のためには勉強だけではなく、自分の意識を変えてゆく必要があると実感しました。

客先の技術本部キックオフに参加しました。
1日を使って全セクションの発表形式です。 前期の反省・今季の目標・現状の課題といった事が主な内容です。
どのセクションでも話題に挙がったのが『品質向上』です。
現状ではセクション毎の取り組み方も様々です。 何故、良い結果を残しているセクションを見本とし、全セクションで取り組み方を統一しないのかな?と素朴な疑問が残りました。
セクション毎の切磋琢磨は必須ですが、他セクションの良い所は積極的に取り込む姿勢が必要では?と感じました。

No.119です。 現在の仕事状況をご報告いたします。

私はいま、某社の設計標準作りのサポート役で客先に常駐しています。
お客様からのスキル条件は「設計図面を読めること」「データベースの構築経験があること」が最低条件だった様です。
私は理工系出身ですが、当初からソフトウエア部門に配属されていたので、残念ながら図面は読めませんでしたが面接の結果、やってみますか?と問いかけられ、ハイと返事をしました。

あれから2ヶ月が過ぎ去ろうとしてますが、設計標準書が出来上がって行く時の達成感で、仕事に面白みを感じられるようになってきました。 未体験の連続ですので、気が付くと随分疲労している時があります。
今は、モーターに関する基本知識吸収に苦闘していますが、薄ぼんやりながら判ってきました!
当社の社長からは、「判らない事は知ったか振りせず、直ぐに聞け!」と叩き込まれていますが、引いてしまうこともあります。
そんな時、鬼の形相で睨み付けている社長の顔を思い浮かべては速やかに聞く事を心がけていますと月報に書いたら、
アホ! 心がけてるでは遅い! 直ぐ実践しろ!と携帯にメールが飛んできました・・・。

東北・関東大震災後、顧客別CAMソフトの開発は一時的に減っていたのですが、最近は随分増えてきました。 お陰さまで残業も増えているのですが、深夜残業まではしておりません。
平均すると2時間程度ですが、サマータイムを実施していますので、午後8時前には帰れます。

独身には、ちょうど良い残業だと思います。
何故って? 朝は早い出社時間ですので、夜遊びはしなくなりました。
土日には、近くにある温泉でゆっくり休んでいます。
サマータイムも悪くないですね。 こんなに健康的な休日を過ごせますので!