つれづれw 気

2021年2月28日 04:38

#54 パワポ

方針や技術戦略をたて、
パワーポイント(以下パワポ)で上司に説明する。

過去→今→未来。

今はこう。未来はこうありたい。

現在の設計や実装を実際にはしない。
パワポを作っている。
パワポだけでは、納得されないので
自分で試作し見せてみる。

パワポは手段。
あくまで理想を掲げて、目標に近づくためのもの。

教訓
自分にある遠い目標を頭にいれながら絵を描く。
絵だけではなく、ものも作ってみる。

もっとみる

中岡　興

2021年2月27日 04:33

#53 歳を重ねていい点・悪い点

いい点は、変にマウントを取られないこと。

10代、20代は、なんか変に
マウント取られて、何かバカにされる。
侮辱したいのか、忠告したいのか
意図もわからない。
そんなに否定するなよと言いたくなる。
怖気付いて何もできなくするため、なんだろうな。
だから、「怒られる」って言って
やりたいことをやらないのはご法度。

悪い点は、わかったような気になってしまうこと。
同じように見えるプロジェクトは

もっとみる

中岡　興

2021年2月26日 05:09

#52 やること増えて工期短縮要求

機器開発は、「ソフト、エレキ、メカ」で
担当が分かれます。

メカは、がわやボタン、基板の位置、線の繋ぎ
エレキは、電子部品、基板
ソフトは、制御を作ります。

ソフト担当ができて、まだ日は浅く
エレキ担当がソフトを作っていた時代がありました。今のお偉いさんは、その時代の方が多く
何で、こんなにソフトを作る工期がかかるのかが
理解できないようです。

昔よりやることが増えて、
処理も格段に速くなっ

もっとみる

中岡　興

2021年2月25日 04:45

#51 レシピ

私の理想はモチベーション0でも、
品質を保ったソフトが作れることです。
モチベで作るものではない。
手順で作るものです。
(料理で言うレシピ)

ソフトは、誰でも作れるものですが
人それぞれのレシピがある。
人それぞれのレシピを同じものにするために
規定を設ける。

大切なレシピですが、
レシピはこうでなければならないと
凝り固まってしまうと
新たな取り組みは難しい。
絶対に正しいということはあり

もっとみる

中岡　興

2021年2月24日 04:36

#50 変な動き

動かし続けると、
たまに変な動きをする時がある。

不具合は、ちょいちょい顔を出す。
よく見ている人にしか微笑まない。

見逃したら、次にも絶対にどこかで、
顔を覗かせる。
顔を出したら、なぜ出るか、
辻褄を追いかける。

その辻褄から何度も動作させ、再現率を上げる。
再現率をあげて、対策して現象が発生しないことを
確認したい。

教訓
変な動きは見逃すな

中岡　興

2021年2月23日 05:20

#49 「優秀さ」とは？

依頼主が依頼してから
アウトプットを
受け取るまでの期間と
アウトプット自体の
質が問われています。

その結果
「またお願いしたい。」
をいただきます。

優秀さ。は他人様が
判断することであって
自分がコントロール
できるものではありません。

自分がコントロール
できないものを
クヨクヨ考えても
仕方がありません。

自分がコントロール
できるものは
こうしたいという意志です。

私には鼻に

もっとみる

中岡　興

2021年2月22日 05:12

#48 ソフトを誰かに作らせる

とあるエンジニアは
ソフトウェア実装(コーディング)を
いつも誰かに頼みます。

なんで人に頼むんだろう。

頼んで出てきたソースコードを見ても
見やすいソフトでもない。
分かりやすい構造でもない。
設計書もなく、試験はやるが、結果がない。
ソースコードのクセが強い。
(おれすげー感満載)
でも、短い納期で確実にでてくるのは
確かなようだ。

傍から見ていて
いくらコーディングを頼んでも
自分達で

もっとみる

中岡　興

2021年2月21日 05:04

#47 IT技術者

今でこそ、花形のように言われる
ソフトウェアエンジニアです。

昔はマニアでコミュ障か
口ばっかりでソフトが作れないか
両極端な人種のいる世界のイメージがあります。
SEやITコンサルと言われる方々の胡散臭さ。
口八丁手八丁

すぐに飛び込める敷居の低さの割には
奥深い世界です。
作ったら、すぐ動かせて結果が得られる。
これが楽しい。

人により考える奥行きも違います。
さらっと作って終わるか。

もっとみる

中岡　興

2021年2月20日 05:16

#46 品質とスピードの両立

プロセスにより人による品質のバラつきを抑える。
もう終わるという直前で、
設計の見直しにならないように、
機能要件にでてこない処理速度や使い勝手を
意識させる非機能要件を考える。

ある決まった時間にコンパイルや単体試験を
自動で並列に実行できるようにする。

いくら自動で動かしても、
動かす期間は、ある程度必要な気がする。
試験で品質を保証するとなると時間がかかる。
試験は品質を作り込まない。

もっとみる

中岡　興

2021年2月19日 04:42

#45 変化か確実か

確実よりも変化についていきたい。
変化するには
要求、設計、ソース解析&実装、試験　→ ☆
各文書を変更する必要がある。

直す箇所が小さければ、修正は小さい。
一つの修正で☆を一回行う。
修正が沢山あると
☆を修正個数分やる必要がある。

☆は即ち
要求を変更する。
設計を変更し、設計が問題ないか
試験を変更し、項目に問題ないか
ソースコードを解析する
ソースコードを変更する
コンパイルして、ソ

もっとみる

中岡　興

2021年2月18日 04:37

#44 内容と紐付けと

仕様書に書いたものを
設計書にブレークダウンして書いて
設計書に書いたものを
ソースコードに反映して、
試験の項目を書く。

所謂、トレーサビリティです。
ただ、トレーサビリティを重視するあまり、
見やすい仕様書、設計書作りが
疎かになってしまうことを危惧します。

仕様書や試験での記載の
漏れ抜けチェックに使えますが、

どのような設計にしているか、
建物の設計図のようなもの。
それを見て、
設

もっとみる

中岡　興

2021年2月17日 04:37

#43 ソースコード解析

ソースコードを開いて、
何度も流れを追いかける。
モジュール、変数をgrep(検索)しまくる。

流れを追いかけても
頭にしみつくどころか
流れがなかなかピンときません。

そう言う時は、図や表で示してみる。
引いた視点を持つことも必要です。

フォルダ、ファイルの名前を把握し表にする
Windowsのdirで出力する手があります。

関数コール表で、呼ぶ、呼ばれる
が分かる表を作ると
どのように

もっとみる

中岡　興

2021年2月16日 04:30

#42 変更に耐えたい

ソフトウェアは変更との戦いです。

こうした方が使いやすい
こう動かしてエレキの不都合を回避しよう
小さな修正から大きな修正まで
さまざまです。

ソフトウェアを変更したら
まずはオカシイ動きがないか、
目を凝らしてみます。
オカシければ、原因に仮説を立てて
一つ一つ追っかけていきます。
オカシイところがあれば、
設計が抜けているということにもなる訳です。

きつい時間でもあり、楽しい時間でもあり

もっとみる

中岡　興

2021年2月15日 04:53

#41 ソースコードの量

ソースコードをどれだけ作ったか(量)は
行(step数)で測ります。

step ✖️ 単価＝金額になります。
かといって、ソフトウェアの作りとして
一行でも多く書ければ良いかと言えば
そうではありません。

よく吟味されたコードは
重なりがなく、短く、簡単(simple)です。

では、ソースコードが
見づらくなってしまう理由として
何が考えられるでしょうか？

読んでいる人の予想を外して

もっとみる

2021年2月の記事一覧