読者です 読者をやめる 読者になる 読者になる

#48_6月13日_ソフトウェア機能要件のミスに気づけない

起きて、歩いて仕事場へ。強い雨だ。

封筒や宅配物を開封する。領収書を整理する。一瞬で返せるメッセージを打ち返す。深く思考する必要のない事柄を打ち返しながら、少しずつテンションを上げる。

ソフトウェア対応。仕様変更を、Qiitaの要件定義書へ反映させる。よく考えたつもりだが、エンジニアから修正の意見が出る。完全に、仰る通り。仕様を変えた時は、最低3回は、ユーザーになりきって、その画面を使う想像をしてウォークスルーをしないと、おかしい点を発見することができない。ちゃんとやろう。

クライアントが、こちらで開発したソフトウェアへ、今使っているものから乗り換えるに際し、データ移行をしなければならず、その打ち合わせのためスリランカSkype。色々と不安になった。大丈夫か。最終的には力技に頼るしかない。できるだけ大きな所、全部を崩壊させない所から潰していくというアプローチが肝要か。及び、最も大きな影響が出る手から順に打っていく。対象✕手段の選択方法は、そんな感じ。とはいえ結局、自分が優秀になることが1番の問題解決であるのはずっと同じだ。おれに死ぬ気でエンジニアリングをやる覚悟があるのか、ということに尽きる。果たして・・・。

銀行から、為替予約の取り組みについて、与信のために更に情報が必要との連絡をもらう。確かにデリバティブには理論上与信が必要だが、預担保をとるんだったら、FXのロスカットみたいに与信なしで預担保の範囲内で取り組んでくれればいいのに、と少し思う。

製造業の財務管理について、チャートを作った。インプット、DBからの抽出方法、抽出先スプレッドシートスプレッドシート内構造をまとめた。この概念図が実質的には設計書で、この通りに業務を流せば果たして最高効率なのか、という点を議論する。

明日から各項目ごと(売上、仕入、在庫)にこれまでの情報のドキュメンテーションをすることにした。バラバラな情報は使い物にならない。完璧かつ完全に整理し続ける必要がある。(早くやれよという話だ)

体重も体脂肪率も減っていた。