■

2ヶ月前のエントリ、だいぶ病んでるな笑 件のプロジェクトは一旦開発中止ということでメンタルは落ち着いている。

2年半越しの別のプロジェクトも無事クローズできたし、もう一件のプロジェクトもリリースまでの道筋が見えてきた。

プライベートにおいても子供がだいぶ英語ができるようになり、学校も楽しめているようだ。筋トレとかテニスも習慣化できていて、テニスの方では友達っぽい人たちもできてきた。

これらの状況改善により、メンタルはだいぶ健全になった。

振り返ると渡航直後のオンライン授業しながらのテレワークは本当にやばかったな。仕事も問題山積みな上に、子供のサポートで十分な時間がとれず、かなり精神的にはつらかった。周りの支えはもちろんあるが、本当よくがんばったと自分を褒めたい。

さてメンタルが健全になったところで次どうするか。筋トレはいい感じに習慣化でき、強度も少しずつ上げられているので、同じようにして勉強を習慣にしたい。何かしらコードは書かねばと思うので、まずはプロコンでコードを書く感覚をつけつつ、作るべきプロダクトを模索したい。なるべくアウトプットしながらね。勉強会みたいなのにももっと出たりしたいなぁ。人生マラソンのペースを少しずつ上げていこう。

子供を久しぶりに屋内遊園地に連れてきたが、二人とも自分とは遊ぼうとしないことに成長を感じつつ、少し寂しくもある。最初にここに来てからもう2年近く経つことに驚く。そりゃ二人とも変わるよな。子供の2年は大きい。

■

久しぶりに書く。2年ぶりか。コロナ禍では全く書いてなかったのだな。

昨日、運用中のシステムで割と重大な不具合が見つかってしまいストレスで眠れない。やれることはやったつもりだけど。

どうすれば防ぐことができたのかを振り返ってもちょっと無理そうである。起こるべくして起きたという感じはする。でも怒られるんだろうなー。あーやだやだ。

もう自分ではこのプロジェクト無理なので辞めたい。メンタル持たない。裁判でも何でもやってくれという気にすらなっている。引き継ぐとなったら相当大変だけど。

色々と学びはあるが、お客様に迷惑をかけつつ、自分もこんな痛い思いをしてまで学ぶことなのかと思う。

まぁネガティブな気持ちの原因はだいたいこんなとこ。はたしてこれからどうなるのやら。

とりあえず吐き出したのであとは思うことをつらつらと。

最近子供に頭ごなしにに怒ってしまうのもやめたい。子供が言うことそのまま聞かないのは仕方ないので、その際に一旦落ち着いて怒る以外の選択肢で対応すべきなのはわかるが、余裕ないと無理。在宅で仕事しながらそんなこと自分にはできない。

何かとため息が多くて自分でも嫌になる。ぶっ倒れてしまえば楽になるのになーとか思いつつ、根性がないので頑張りきれずに逃げちゃうから、そうもならないのよね。それはそれでいいのかもしれないが。でもほんともう投げ出したい。

どうしたらいいのか誰か教えてくれ。カウンセラーとか検討してみるかなあ。

何をつくったらよいか

ITは好きだが、いつも困るのは何を作ったらよいかがわからない問題。勉強のためだけのモノを作るのにはモチベーションが沸かない。

どうやったら何を作ったら良いのか見つけることができるのか、思いつくことができるのか。

結局普段からアンテナを張り巡らしておく、ということになるのだろうか。

開発プロセス考え中

レビューのときに動画作ったりスクショ貼ったりしているのだから、これをコード書く前にできないもんだろうか。できれば仕様書として。そしてテストケースも一緒に作ってしまう。で、コーディングとテストを一緒に作ってもらう。

今仕様書がなくて困っていることは何だろうか？

  • テストが書けない
  • プロジェクトが引き継げない

朝回と夕回はやっていい気がする。ほぼ毎日朝と夕方に話してるので。

 

おこもり生活

数日前から発熱がありドキドキしていたが、医者に診てもらったところ新型コロナではなく別の細菌によるものだった。とりあえず一安心。とはいえこれも家族に移してしまう病気なので、自室で家族からは隔離された生活を送っている。

家族と話ができないんは寂しいが、思う存分読書やゲームやネットサーフィンができるこの環境はたまには悪くない。家族には悪いけど。

そろそろ隔離生活も終わりなので、やったことのまとめや感想など書いてみることにする。

  • 機械学習の勉強 筑波大学のオープンコースウェアを利用。動画を見るのもいいが、アウトプットが大事なので先に演習問題を解くつもりでスライドを何ページか読んだ。

  • 失敗の本質 (読書) 読めてなかった本。全部読破できてないが、仕事で参考になりそうな記述いろいろ。図3-1は会社でも適用できそう。

  • アート・オブ・プロジェクトマネジメント (読書) 7章の優れた仕様書の記述のところを中心に読んだ。仕様書については日々考えているが、銀の弾丸はやはりありませんな。

  • まんが日本の歴史 (読書) 最近は歴史も勉強してみたいと思っているので読んだ。昔は歴史好きじゃなかったけど、大人になって勉強してみると面白い。たぶん中学生とか高校生の自分には、歴史を面白いと思えるだけの人生経験が足りなかったのではないかと思う。

ソフトウェアの品質について

これまでは開発しているソフトウェアの規模やチームのサイズが小さかったため、それほどソフトウェアの品質について問題となることは少なかった。もちろん最低限度のことは行なっている。が、そうも言っていられなくなってきたので、書きながら考えたい。

ゴールとしては、今のチームにおいて品質に対してどのようなアクションをとればよいかを決めたい。とはいえ自分1人で決めるわけではないので、チームで議論できるような基礎知識がまずは欲しい。

品質とは何か。今のチームにそこまで人員的な余裕はないので、多くのことはできない。しかしいつかはISO13485を満たせるプロセスにしたい。しかしそれは何年後だ？とはいえ判断を行うため少しISO13485の知識が必要だ。

以前聞いたセミナーで言っていたのは、徹底的なレビューを行うことと、開発者とテスターは別にすべきであるということだ。

プロジェクトによって品質にかけられる予算は異なるので、やることの優先度はつけなくてはならない。

現時点で表面化している問題はないが、考えられるリスクとしては何だろうか。

最近の経験から絶対にやっておかなければいけなそうなのは、見積もりと提案書のレビュー。ここをしっかりしておかないと、追加要求がでてきた場合に予算内でできるかどうかの判断ができず、トラブルの元になる。

あと海外の外注先にユニットテストまで書いてもらいたい。お願いできる仕事の範囲が限られるので、どうしても今のプロセスだと手が空いてしまう。手が空いた分を品質を高めることに使いたい。

そろそろ横のリーダーと連携してみてもよい気がする。