サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。2017.10.29Tweetシステム開発プロジェクトでは、仕様変更は程度の差はあれどあるものです。その仕様変更決定までの過程によっては、(SIerも含めた)プロジェクト関係者の納得感のある/なしが大きく変わり、それはアウトプットの質まで左右することがあります。#「モチベーションが下がる」ってやつです。仕様の検討/決定をSIer(自分達)とお客様情報システム部と行っているとします。この情報システム部はお客様エンドユーザから要望をヒアリングし、(SIerと一緒に)仕様に落とし込むのが主なタスクとします。その仕様確定後に「エンドユーザからこういう要望が出たので変えてください」と、あっさりと仕様変更を出されるとゲンナリしてしまいます。#これがモチベーションが下がる原因です。最初に書いたように仕様変更自体が悪いわけではなく、その過程がポイントです。(SIerと情報システム部が)決めた仕様も(サイコロを振って決めた適当なモンでなく)、いくつもの案のメリット/デメリットや、プロジェクトの目的に沿っているか?等、様々な側面を少なくない工数、期間を使って検討して決定したわけです。#もちろんエンドユーザへのヒアリングも含んでいます。その仕様変更を要求してきたエンドユーザに対し、現状の仕様となった背景や理由を説明して...1:「それでもするのか?」という問いかけ2:「(いったん決めた)自分の判断を覆してまでする意味があるのか?」をジャッジ...をした上で、答えて欲しいものです。そこまで考えていない...ひどい時には、思いつきで言っている...エンドユーザに限って、自分達((SIerと情報システム部)がその仕様変更に対して、QCDに対する影響、メリット/デメリット、他の仕様との整合性等を検討し、少しでもネガティブな要素が含まれる回答...例えば「OKですが、工数が1人日増加します」...をすると理不尽に怒り出したりします。いうことが繰り返されると「何いうても、すぐに根拠のない仕様変更されるし...」という気持ちになり、アウトプットの質が下がっていくと思います。逆に「なぜその仕様変更が必要なのか?」をキチッと関係者で共有でき、落とし込むことができると「それなら、こちらの仕様もこうなるのでは?」「(その理由であれば)こちらの仕様がより良いのでは?」と自分達も積極的な提案、フィードバックを行い、プロジェクトの目的をより高いレベルで達成するアクションを取ると思います。※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。BY関連するエントリメンテナンス作業で感じたことあるフリカエリにて。【引継ぎ】タスクへの考え『トラックナンバー』について以前書きました。そのトラックナンバーを意識して取り入れたプロジェクトの効果に『引継ぎタスクをスムーズにできた』というのがあります。ほとんどのプロジェクトでは、後工程になるにつれてメンバーが減っていったりします...コミュニティ仕事と勉強会の源泉の関係ここ1年ほどいくつかの勉強会に参加して、時にはスタッフだったり、スピーカーをさせてもらったりした中で「仕事と勉強会の源泉の関係」について感じたことです。「今日の勉強会でエネルギーをもらったので、明日からまた現場で頑張れます!」という声を時...仕事のやり方あるプロジェクトで工夫したこと(QCD的に)成功したあるプロジェクトで工夫したことを備忘録のために書いておきます。そのプロジェクトの特徴は以下の通りです。【納期】サービスインの時期は確定しており、それまで約3.5ヶ月。未来の自分を信頼し過ぎないプログラミングにおいて他者のことを考えて「分かりやすいコードを書きましょう」「適切なコメントをつけましょう」というのは基本的なことです。この「他者」には、そう遠くない「未来の自分」も含まれています。忘れてしまいがちです。「可視化」と「見える化」で書いた勉強会で、「朝会」について考えることがあって、その後もチームで話すことがあったのでちょっと書いてみます。今のチームでも、もちろん朝会をやっています。朝...旧館より自分のテンションを維持する方法コンピュータは基本的に調子の波がなく、いつでもいつまでも同じポテンシャルを発揮してくれます。#CPU100%は「調子が悪くポテンシャルが低い」と表現できますが、ここではそんなことを言いたいのではなく...。コメントをキャンセルコメントを投稿するにはログインしてください。サウスポーなエンジニアの独り言.ホーム検索トップサイドバータイトルとURLをコピーしました。