トラブル

作業の中心にエンジニアを置くための情報と技術のあり方

人は起きて欲しくないことが起きるまでは、たとえそれが起きた時にどうなるか類似の経験をしていても見向きもしないし、どちらかと言えば思い出したくもないような経験であればあるほど自分の視界からそれを遠ざけるものです。 システム開発でのそれはトラブ…

スーパーエンジニアやエバンジェリストはロクロで何を捏ねているのか

システム開発でデスマになった後に行われるプロジェクト報告会は実質、戦犯を探すために行われているようなものだ。その目的が果たれようとするとメンバ同士がそのプロジェクトで自分が被害を受けた些細な出来事を論い、言い合いになりそうになると大人なん…

品質管理の知識を持たないエンジニアはモグラ叩きのループから抜け出せない

ソフトウェアの品質管理というとエンジニアは何を頭に思い浮かべるのでしょうねぇ。設計書やコードのレビューかな。それともバグのチケットの書き方が面倒だなーということかな。 どれを取り上げても品質管理はエンジニアから見ればやらされている感が満載で…

やることだけを見える化しているとトラブルの原因を可視化し忘れる

プロジェクトを回していて、思うように進捗できていないと相談を受けて話をよくよく聞くと、一方向でしか作業を見ていないということに気づかされることが多いいのです。 まあ、第三者の視点で見られるので、この点はどうなのとかそっちから見たらどうなのと…

「助けたいが何を手伝おうか」と言ってエンジニアの仕事の脆弱性を診断する

どうももう1つのチームの進捗が今一っぽい。ランチタイムには、リーダ役が愚痴を垂れ流すし、セカンド役は一緒になって現状の酷さを盛るように話すのですが。 愚痴を言いたければ好きなだけ話したらいいじゃないと基本的にはスルーしているけれど、他にタイ…

エンジニア自身がテーラリングに参加することがチームの状況を適切に把握するための近道

ウォーターフォール型のシステム開発手法は、極論を言えば労働集約型の特性を持っているプロジェクトに適用するのが適切です。一方、プロジェクトの要件が曖昧であったり、市場の反応を捉えながら要件を変えていく要件を持っているのであればアジャイル開発…

仕掛かり中のお仕事フローを把握せよ

仕掛かり中を増やすと作業負荷が見えなくなり更に仕事が増えるんですよ。だって、ギブアップしないんですから。で、大抵は溢れかえった状態で誰かが見つけるんです。ボトルネックになっているって。 いや、それボトルネックじゃないし。 そうなった原因を、…

上辺だけの再発防止策がエンジニアをスポイルしていく

作業ミスをすれば再発防止策を暗黙で求められるので作業ミスをした方も決まりきったように再発防止策という名のアクションプランを添えて双方の担当は手打ちをするのがすっかり様式美になっている今日この頃ですが週末にトラブルを起こしたエンジニアの方々…