マガジンのカバー画像

つれづれw 気

1,386
感じたこと、大事にしたいことを書き込んでいきます。ご意見賜れば最高です。
運営しているクリエイター

2021年1月の記事一覧

#26 お客様先から  〜改善〜

#26 お客様先から  〜改善〜

ソフトを作れば終わりというわけではなく
発生するエラーを分析し発生が多いエラーから、
改善していくサイクルを半年ほど繰り返していました

忍び寄る契約満了。

次の新機種開発は別の会社が受注していました。
改善サイクルは永遠に続くことはなく、
予算の終わりとともに
突然の終わりを迎えます。

忙しい時ほど、次の仕事を確保しておかないと、
そのまま契約満了で契約終了です。
契約満了したこの時、
隣の

もっとみる
#25 お客様先から 〜先祖返り〜

#25 お客様先から 〜先祖返り〜

商品機能を当社で受けもち
メンテナンス機能を、
お客様先子会社のソフト担当者で
受けもつことになったシステム。

ある時、ソフト担当者からクレームが来ます。
「私が治したソースコードが消えている」
「先祖返りした」
そう言われても悪びれないもっちゃん先輩。
どうやって作っているんだろう。

見ていると
コーディングするとき
自分のパソコンに入っているソースコードを
何の躊躇いもなく使い始めるではあ

もっとみる

#24 お客様先から 〜慣れるまで〜

担当になる前の印象は
「お客様から
 よく呼び出しがあって
 即対応しなければならない、
 厳しいところ。」

いざ、担当になってみると、実体は
「設計、検証するだけの時間は
 あるのにも関わらず
 設計、検証が満足にできずに
 ソフトリリースしている」

リリースする。動かない。クレームが入る。
不具合対処をする。のサイクルが回っている。

準備の時間を、開発で大事な地道な積み上げに
使えていな

もっとみる
#23 お客様先から 〜打ち合わせ〜

#23 お客様先から 〜打ち合わせ〜

今度リニューアルするシステム。
もっちゃん先輩、私に加え、
協力会社さんを2人加えて始まります。

プロセスなんてありません。
設計書もありません
もっちゃん先輩の頭の中にあります。

2人はドライバ担当。
私ともっちゃん先輩は、制御部担当です。

2人と私は
「設計がハッキリしない。やりづらい」
と話していました。

ある時、
お客様に設計の実現方法を説明する会議が
予定されました。(結構重要な

もっとみる
#22 あなたならでは

#22 あなたならでは

初めてやる事は、当然初心者から始まります。
経験がない中で「こいつ。できるな」「こいつ。できないな」依頼する側が、どちらかに分類するわけです。(0、100ではないので、程度は色々です)

「こいつ、できるな」と、依頼する側に思ってもらうためにはどうすればよいか、ずっと考えていました。

依頼する側に回ってみると、
話していて違和感があると進めるのが難しい。

少ない言葉で情報が共有できる。
意図が

もっとみる
#21 お客様先から 〜説教〜

#21 お客様先から 〜説教〜

私はお客様先に常駐して仕事をすることが
ほとんどでした。

自社に帰るのは三ヶ月に一回
納品物を作る時でした。

私より前から担当されていた先輩がいます。
その名も「もっちゃん先輩」
いつも夕方5時にあらわれて、
説教しはじめる鬼軍曹。
説教中はタバコ部屋に缶詰です。

二言目には、
「あいつはできない。」
「こいつはできない。」
「俺ってすごい」
 (直接は言ってないがそう聞こえる)

上司には

もっとみる
#20 それやる?やらない?

#20 それやる?やらない?

昔、ある搬送するシステムに携わっていたときのこと。

ものを置いておく場所があり、A→B→C...と搬送して
いきます。Bが空いたら、AからBへ物を搬送する。
そんなシステムでした。

私は、リスト構造を採用。
A、B、C、、を0からのインデックスとして、
場所別にもの情報を覚えておくやり方で
作りました。

全く新規ではないため、
昔採用していたフラグ制御のやり方もありました。
昔のやり方は知っ

もっとみる
#19 こんな風にできたらいいな

#19 こんな風にできたらいいな

私が携わっているもの
・センサがあり、定期的にデータを集めている
・スイッチがあり、押すと、分析を開始する
・分析が終われば、結果を表示する
・通信があり、外へ分析データを転送する

表示するのは、LCDや有機ELがあります。
通信は、BLEやUSBがあります。

物は色々ありますが
組み合わせはだいたい似通っています。
データを集計、分析するエンジンだけが、
異なります。

「表示」「通信」「分

もっとみる
#18 うまく使って速く作る

#18 うまく使って速く作る

毎回、一から作るのは、難儀です。
早く作るには、いろんな塊を持っておいて
塊を組み合わせて作るのが一番早くて確実です。

昔から部品化と言われていますが、
組織的にはできなくとも、
個人的にはやっておいたほうが
スピードは違います。

また、関心事に注力できます。

教訓
塊は作ったら、整理して持っておく。

#4 ソフトは人が作る

#4 ソフトは人が作る

人は平気で矛盾する生き物です。
それでも何の支障もなく生きていけます。

ソフトは、矛盾はバグとして跳ね返ってきます。
考え方は全般にわたって
同じでなければなりません。

まは、人はすぐ気が変わる生き物。
どんどん変えたくなってしまい、
そのうち収拾がつかなくなります。

自分をルールの箍にはめ、
何でこうしたかを反芻しながら、
気分でソースコードを変えないように
自分を律していかないとどんどん

もっとみる
#17 なかなか決まらない機能

#17 なかなか決まらない機能

機能は、なかなか決まらない。
決まっても、また変わる。

なぜそんなに変わるのでしょうか?
市場、競合の動向もありますが
人は元来変えたがりなのです。

どんどん変えたくなる。
収拾がつかなくなる。
だから、「何をしたら終わりか」を意識しないと
終わりません。

「作業は始めたらどう終わらせるかを意識する」

昔、私はエリザベス2世号(船)の絵を描いた時
全然終わりませんでした。
何をしているか、

もっとみる

#16 機能を決める

ソフトウェア開発は、
仕事の依頼主から、
「こんなもの作ってね。」
と言われて、始まります。

商品開発をしている所では、
営業から「こんなものを売りたい」と言われて、
商品企画といった部署が、
デザインや動作仕様を決めていきます。
その仕様をインプットにして、作っていきます。

今までの商品をもとに、
追加する機能を決める。
という制約があるため

今まで、どんな仕様だったか、
これをどう変えて

もっとみる
#15 機能を追加する

#15 機能を追加する

元々ある機能に、別の機能を追加する。
前からある機能と矛盾が生じないか、
気になる所です。

商品を企画する人は、
こんな人が使って、
こんなシチュエーションで使われる。と想定し、
新しい機能を追加しようとします。

しかし、
今までの機能には、なかなかフォーカスが
あたりません。

機能追加による影響がないか
は、自分で確認する必要があります。

教訓
めんどくさい割には
あまり魅力的に見えない

もっとみる

#14 売れる商品を作りたい

高・中・低で商品の売価を変える時、
何を持って高い、低いを決めればよいでしょう。

部品を高・中・低で変えるより、
部品の構成を同じにして、
部品の装着/取り外し、
機能入り/切り
によってバリエーションを持たせることが多いてす。

では、
人がお金を出してでも
欲しい機能とは何でしょう

昔は、ウォークマン、ビデオ、
生活を変えるような商品があった。

バブルがあり、それが弾け、
そこから、何か

もっとみる