木曜日

障害調査の続きをしたり、
今後の要件定義の企画を練ったり。

障害は、アプリログにMySQLのロックタイムアウトエラーが出ているのだけど、
なぜかロックが解除されたタイミングでタイムアウトエラーが記録されている。
タイムアウトは50秒のはずなのに、300秒くらいたっている。
DBでは50秒後にタイムアウト発生したのに、アプリにそれが伝わるのが遅いというように見えるのだけど、誰がその遅さの原因なんだろう。
ネットワーク？OS?アプリ？今のところ、見れるログは全部見て、
おかしいところが見当たらず。次回発生時にもっと詳しいログが出るようにして
様子見しかないのだろうか。

要件定義では、機能要件をヒアリングするためのたたき台資料を作り始めてます。
いつものように、会社の標準FW(フレームワークのフォーマット)をそのまま使うのでなく、
今回必要な項目だけを集めたエクセル表を作って。
(標準FWも参考にして作ってますが。)
小規模開発には標準FWは重過ぎる。。

社内SNSでブログを書いた。
それは、ある新聞記事を元にした内容。
(システム開発を自動車生産ラインをまねして、
工程を細かく厳格に区切って進捗や品質を管理するということを
やりはじめた会社があるという記事)

それで他の人からコメントもらったりして気付きました。
システム開発のメタファに「生産」とか「工場」とかいうことを考える人がいて、
でも私はその考え方を全然理解できてないってこと。
だからこの前の提案で、いろいろ突っ込んできた人と話が通じなかったのだなぁ。
自動車生産のラインとシステム構築。
自動車生産ってラインに入ったら、
その自動車の色とか形とかもう変更できないし、変更する必要もないような気がする。
でもシステムは違う。作り始めて、作りながら変えていく。
自動車製造ラインが創造的でないわけではない。
いかに効率よく品質よく作るかを考えることが創造的。
でもシステム開発は作りながらどんなものを作っていくか試行錯誤するところが創造的。だから、生産メタファで語っちゃいけないような気がしている。
でも、そんなことないと思う人もいる。
実際記事では、生産性があがったと書いてある。
(プログラマが楽しいかは書いて無いけど)

私が小規模なシステムばっかりをやってるからなのかな。
(最大でもピーク時人数が20人くらい)
何百人もかかわるシステムだと生産と思った方がよいのかな。
その場合、会社内で標準化するときってどうやっていくのかな。

標準化とかQMSとかCMMIとかを語っている人と話ができるようにならないといけない
状況になってきた。
コミュニケーション訓練＆システム開発を一歩ひいた立場で見直すチャンスと思おう。