・今年の反省点から入ります 今年一番うまくいかなかったもの・・・やはり1on1ですね。 新人とのコミュニケーションは難しいというのもありますが、筆者は1on1が下手だとほんのつい最近気づいてしまったのです。 本当に今更なんで、今まで本当にすみませんで…

・何が大事なのか わかっています、本当は。売り上げの数字ですよね。（違うかもしれないけど・・・。） でも、ソフトウェアの品質は融通が利くものではないのです。 でも納期には勝てないかもしれません。でもダメなものはダメなんです。 でも出したいから…

・悪いと思えるならそれは改善の余地があるということで 何かを作る上で、生産性という言葉からは逃れられません。 効率よい開発をするのがベストですが、完全な開発はできないものです。 悪いと思えることがあるのに、流されてそのままの状態を続けているこ…

・テストをして送り出しても、あと工程で差し戻されてくる まあ、局面では、ままあるのですが、製品を出したい という意向が強すぎて・・・ もっと時間をかけて、しっかり見ることもできたのになあと悩んでしまう不思議な状況が起きたり・・・することもある…

・反省会になっても意味がないと思うのだけど・・・ よかった点と悪かった点考えれば、エンジニアというものは、悪かった方ばかり考えてしまうものです。 反省会になってしまうような場にならないためにはどうするか、悩みが尽きませんでした。 ・どこに重き…

・振り返りのファシリテーターをすることになりまして やれと言われればやりますが、基本的にライトに前向きに追われればいいと思っています。 KPTという手法を使いますが、これだってきっかけぐらいにしか考えていません。 ・振り返りが盛り上がらないとい…

・てっきりdiscordの問題だと思っていました 案内にあったdiscordをインストールしてチャンネルがつながって、メモも見えて、会話の音声だけが聞こえない。てっきりインストールがダメだったか何かだと思っていたのです。 先日も確かめるべくちょっとだけ繋…

・参加しようとしたのです。 エントリーして、discordをインストールして、動きました。 メモも読めます。 声が全く聞こえません。 設定がおかしいのかなあ・・・ 格闘することしばらくの数時間？ 再起動すれば直ったかもというネットの記事に触れたのはずっ…

振り返りは大反省会とか懺悔の時間や、罪の糾弾とかのために行うものではありません。 やるべきは次に勝つかもっとうまくやるために、今何を決めるかです。 それ以外のことは必要ありません・・・と、個人的には思っています。 決めたらやるだけです、 起こ…

システムレベルのテストをしているのに、やっている内容が個別の機能確認と大差なくなっている場合は、仕様から得られる情報が圧倒的に足りないのだと思います。 要求仕様書があまりにも貧弱だったので、自分ならどんな要求仕様書を書くか、少しだけ書いてみ…

なんと面白そうなタイトルなのだろうか、激しく興味を惹かれるではありませんか。 とはいえ、それほど高度に専門的な知識があるわけではないので、あまり難しい話にはついていけないだろうなあなどと考えてしまう自分がいたりして、興味はあるけど・・・ こ…

東証のトラブルの記者会見の対応は見事だったようで、日本中の発注者がこのレベルであれば、日本がIT後進国となることもなかったと思われるほどの内容でした。 残念ながら、今の日本にはこのレベルの発注者はいないので、受注先の責任という言葉を吐いて、責…

悪い開発を１００回繰り返してもそこで得られるスキルは、偏ったものになりがちだと思います。 人が成長することを望むなら、それができるプロセスを構築しなければならないと思います。 とはいえ、環境要因の部分をの問題が先に立ってしまうと、自分は悪く…

実際問題設計がベストあるか検証したければ、頭の中で最後まで作り上げてみるしかないように思います。 もちろん絶対のベストはわかりませんが、自分の思いつく範囲でのベストはそれで出せるとは思います。 その際の評価基準が一定だったとしてという条件が…

うまくいかないことは、開発の現場においては当たり前のようにある。 問題が起きて、それに取り組むのは当然として直るかどうかは大事だが、直った後も大事である。 問題がある、不利な状況にある、どんな状況もそうなった理由もそこに至るまでの経緯がある…

モノづくりの現場には、いろんなことがある。 現在置かれている環境に、自分が居合わせるのは偶然だが、その環境が今に至ったのは必然だと思われます。 そうなるからにはそうなった理由があり、そこに至るだけの理由も存在していると思います。 草の根レベル…

試作の段階では仕様があいまいで、要求を段階的に取り込んでいくような作り方をしていると、ソフトウェアの構造は複雑化する傾向が高くなります。 仕様を決めるためにソフトを作るなら、量産のためのソフトは改めて作らない限り、非常に不幸な運命をかかわる…

開発終盤に、最低と呼べるようなソフトウェア構造に吸い取られるように労力を奪われながら、気力を奮い立たせて開発行う現場は見ていても気の毒に見えます。 中にいる人は、今更どうしようもない状況で、泥仕合を続けているような感じでしょうか。 そんな時…

開発とは品質を作りこむことに他ならないと考えています。 機能を増やすことも品質の向上ですが、それで不具合が増えるのは困りものです。 限られた時間で、売れる商品を作りたい気持ちはよくわかりますが、本当のところ開発費は膨大な数字に膨れ上がってい…

いや、本当によく遅れます。（筆者の周りではの話ですが） 考えられる原因はなにか？ そもそも希望納期だけがあって、何を作るか作りながら決める方式は計画とさえ呼べなかったりすると思うのですが、まあ、いろいろなことがいろんな場所で起きているのでし…

プロセスとして残っているものは、生き残る価値があるから残っていると考えています。 完全に淘汰されたものは、名前すら消えていきますが、生き残ってきたプロセスにはその価値があるのだと思います。 プロセスも守れない会社や組織はそこに重きを置かない…

概ねの場合、組織に問題があります。 それでも会社は持っているなら、開発以外の部分がすごいのでしょう。 不可能を可能にするのが開発ではありませんし、誰かがついた嘘を、みんなで本当にするのが開発というわけでもありません。 ただ、経験至上主義という…

No.12でテストケースに「正しく動作すること」という記載の撲滅運動をしていることを書いていますが、ツイッターで同じようなことを言われている人がいるのだなあと思って感動しました。 何故、書いてはいけないのかと、問われた場合、こう答えることにして…

不具合は検出して直せば良いというやり方では、体力勝負になることも作戦の内になってしまう。 品質は作りこむものであり、せっせと不具合を作りこんで、せっせと直すのは、しなくていい苦労を自分から好んでしていると言われても仕方ない。 良いものを作る…

開発においてデータの蓄積がない組織は、毎回同じ目にあっていることになるのですが、これが意外に多いように思えます。 ということは、改善する必然性がないことになります。 何かのせいにしておけば、全員責任が不問になるシステムがあるのかもしれません…

前回の明日のためにもその一つですが、今やらなければならないことに手を抜くことはできません。 全員がそこで手一杯のチームでは、本当にいいものが作れるかどうかは未知数になります。 プロセスが悪ければ、個々の処理が完璧にできたとしても、本当に顧客…

毎日の繰り返しの中で、流されてしまうことは簡単です。受け身でいれば、そのままの自分でもなんとなく流れ着く場所にたどり着くでしょう。 すごい人は努力しているのではなく、自分で望んで、その苦労を苦労とも思わず、楽しんでいるかのような勢いで突き進…

何事も、すべてうまくいくということはありません。 そして何事も、完璧を突き詰めたところまで至れることはありません。 そこで責任を自分以外に押し付けてしまうと、改善する理由が失われ、次も同じ目に合うことを許容することになります。 事実は受け止め…

ソフトウェア開発において、装置の目的と機能の果たすべき役割の関係を完全に理解しないで作らざるを得ないことは、時折起きたりします。 装置がその通り動きさえすれば良いわけですが、作る時にそれはすることができるのですが、システムテストをする人は要…

テストをしていると、再現しない不具合に直面することがあります。 再現しないんだからしょうがないで済ませるわけにはいかないのが現実としてあります。 ボーイング社のバッテリー発煙事故も原因が不明のまま、現在再現しない状態で飛行機は飛んでいます。 …