すべてのカテゴリ

ワイ「昔は『お客様は神様』なんて言われてました。」助手「でも最近はお店もNOを言う風潮だね。」ワイ「いわゆるカスハラってやつですね。」助手「お客側も金払ってるからって偉そうにしちゃダメだよね。」ワイ「人格・モラルが疑われますしね。」助手「そう考えるとお客様は神様と考えるのは古いのかもね。」ワイ「古くはないですよ。考え方自体は正しいと思います。」助手「そう？そんなこと言ったらまた客がつけあがるよ。」ワイ「少なくとも販売する商品やサービスに利益を乗せている以上はその気持ちを持つことは大切です。」助手「その利益で生活が成り立ってるから？」ワイ「そうです。ボランティアで提供されるなら話は別ですが利益を乗せている以上はお金を落としてくれる相手は敬わねば。」助手「そうなんだ。」ワイ「ただし、それは相手によりますけどね。」助手「？」ワイ「いわゆる害のないお客様にはその考え方で臨み、そうでない客には店側の権利を行使すればいいってことです。」助手「あぁ、使い分けろってことね。」ワイ「そうです。万人を神様扱いする必要はありません。だいたい客の権利をことさら主張するヤツにロクなのはいませんから。」助手「そう言う奴って金さえ払えば何でも通ると思ってるからね。」ワイ「ただ、お店にも心地よく通えるところもあれば、そうでないところもある。」助手「スタッフの態度が悪いとか？」ワイ「そうです。例えば飲食店に行くとしましょうよ。それは食べ物をお腹に詰め込むためだけに行ったわけではありませんよね。」助手「うん。味だけじゃなくて店の雰囲気とか気持ちよく食べる時間とかも含めてお金を払ってる気がするわ。」ワイ「メニュー表

品質管理って、みなさん、どんな風に行っていますか？私の所では、お客様の品質目標（レビュー密度、バグ密度、試験密度）があり、それに従って行っています。開発作業は人が行う作業で有る為、どうしても障害が発生し、品質目標が守れない時があります。対お客様に対しては、品質目標を上回る様な障害を検出した場合は、強化施策を提案・実施し、他に潜在している障害が無いかを確認し、品質が問題ない事を説明しています。内部としては、品質目標内，品質目標以上であっても、一つの障害に対して、下にあげる「＜障害発生時流れ＞」の様な作業を常に行い、品質の確保と次回開発時に同様の障害が発生しない様な施策を実施しています。長年、品質管理を行ってきましたが、それでも無くならないものだと痛感しています。＜障害発生時の流れ＞あるフェーズで障害が発生した時は、以下の様にして、本来の原因を突き止める様にしています。　①障害が発生　　ex)単体試験で発生　②直接原因を特定　③直接原因を作りこんだフェーズを特定　　ex)直接原因が「製造」だとする　④作りこんだ原因を更に分析し、根本の原因を特定　　ex)分析すると、直接原因が「製造」だったが、実際は詳細設計と判明　⑤根本原因のフェーズで修正を行い、順次各フェーズを実施　　ex)「詳細」→「製造」→「単体」を順次実施　⑥根本原因となった「詳細設計」で、今後の開発において　　同様の障害を混入させない為の施策を作成し、　　次回開発作業にて生かす様に資料化する

昨夜、仕事から帰ったら一番下の娘に『ニュージーンズって知ってるか？』なぜか上から目線で言われた。『そりゃ分かりますよ。　新しいジーンズが欲しいのね。　買ってあげませんよ。』って答えたんだけど、『えー？知らんのー？』って忌々しく小馬鹿にされました。なんか腹立ちました。彼女が言ってるのは韓国のアイドルグループのことらしい。I'm Japanese!!!で、その動画も見せられたんだけど。（見たいと要望は出したワケではない）それ見て思ったの。『ジーンズ履いてないじゃん。』娘いわく『そーいう意味じゃないから！』そーなのか。違うのか。しかし、ウィキペディアで調べたら「いつ穿いても飽きない　ジーンズのような時代のアイコンに　なるという抱負が込められている」って書いてた。これは、もう１度娘に苦情を申し立てる必要がありそう。ってことで今日もブログ始めまーす。☆━━━━━━━━━━━━━━━━━━━☆私はかつて、客商売もしていたし債権管理の仕事もしていた。そーすると苦情に出くわすシーンも多かった。延べ１８年ほどその仕事に携わっていたのでそれなりに分かることも多い。世の中、苦情とクレームを「同じもの」と考える人が多い。しかし「苦情」と「クレーム」は別物。（英語圏でもそれぞれ別の単語）最近よく耳にするカスハラは「クレーム」だと思う。・相手の非を際限なく責め、・無理難題を押しつける。・そして対価を要求する。これは「クレーム」に他ならない。いわば【権利の主張】なんです。では「苦情」ってなんなのか？それは、・期待への落胆・不安や怒りこれは【感情の表明】です。ー 期待を抱きながら行ったお店でー クチコミ見てワ

昨日はクリスマス仕様。なのでパーティスタイルで飯つくったワケです。が、メチャクソ時間かかったわ！うーん、チキンカツのChicken🐔を買い過ぎたのが原因ですな。『うーん、足りるかなぁ？』とChicken野郎になったのがダメだった。自宅なのにまるでクソ忙しい飲食店の厨房。なので、今日は少しお疲れモード。さて、疲れを癒すべく本題へGo!☆━━━━━━━━━━━━━━━━━━━☆人事として取引先と話すと、他社の情報を耳にする。で、採用絡みで取引先がこぼすのが『各社の人事さんお忙しいよーで』って言葉。この背景には、→ 提案した内容が進まない。→ 商談する時間を得づらい。と言うのがある。それを聞く私はいつも思う。『みんな何に忙しいの？』イヤミっぽく書いたけど、みんなが『忙しい』と言い訳する理由も状況も分かってます。企業によっては、人事って総務を兼ねていたり、他の業務を兼務していることもままあるから。『人手が足りないんだ！』『猫の手も借りたいよ！！』はい、猫の手↓🎁しかーし、かくいう私も総務兼任です。人事採用しながら色んなことやってるんで事情は同じです。ではなぜこの差が生まれるのか？それは、リソースを自分で作り出すために取り組みを続けてきたから。亀岡の思考は、『手間暇かけたから正しいとは思わない』『いかにラクするか考える』『ムダなく気持ちよく仕事したい』です。『アイツ、仕事ラクしやがって！』と言う言葉は最大の褒め言葉です。実は、今の会社で入社直後からそのための環境作りをしてきました。例を挙げると、・管理データの整理、統合・労力を省く環境づくり・業務や仕様ツールの定型化です。この取り組みを足

壊れかけのRadioが懐かしい。徳永英明ですな。「レディオ」と読むのが正しかったっけ？「レィディオ」だったかな？しかしまぁ、「ラヂオ」と表現した途端に三谷幸喜感がハンパなくあふれ出てくる。あぁ不思議。摩訶不思議。そんなこと考えてる12月中旬。皆さんいかがお過ごしでせうか。☆━━━━━━━━━━━━━━━━━━━☆さて今日のお題は「壊す勇気」。質問です。・自分が手塩にかけて育んだ企画を捨てられますか？・自分が取り組んだ仕事をイチからやり直せますか？自分が必死になってつくったものだったらそれをやり直すなんて「ありえねー」ってなっちゃうもの。しかし、その仕上がり（成果物）が・本来の目的からズレている・自分の考えていたものとちがう。そう感じてしまったのなら、それはぶっ壊すのも一つの方法。「ぶっ壊す」と言ってもこの人ではなく。↓『なんかズレてるよなー』って感じたときそれは自分がイメージしてたこととかけ離れているから感じる違和感。そう感じた瞬間から、成果物に対するやる気も低下。クオリティもどんどん低下。新聞・書籍はもちろん定価。そんなものをだましだまし続けたとしても良いものにはならない。チョコチョコいじって体裁ととのえる。そんな方法もあるけども、思い切ってリセットするほーがグッとクオリティが上がることもある。なぜなら、一度作ったことで考え方やイメージが整理されて華麗なスタートダッシュを切ることもできるから。実はこのブログ記事、２回やり直してます。『納得いかんわー』って感じるとそのままリリースするのが気持ちわるい。なので、スクラップ＆ビルドしちゃった。まるで陶芸家の心境。そんな、現状をぶっ壊

　日記を読み返していたら、これまで起きたことと、今日 起きたことが線につながって、この先 どのようなことになるのか、想像ができた経験はありませんか。 過去と現在のその先へ改善を見つけよう 　ある事業所の品質マネジメントシステムを発展させようと思うと、ISO9001の要求事項は、思いのほか狙うべきマトが大きいことに気づき、マトのどの部分を狙うと良いのか迷うことがあります。あるいは、複数のマトが思い浮かび、どのマトを狙うことが正しいのか迷うことがあります。 　このようなときに、簡単に実現できるマトやそのポイントを狙って改善の矢を射るのではなく「過去はどうであったのか」「現在はどうであるのか」を知って、過去と現在を結ぶ延長線上のマトに狙いを定めるようにしましょう。 内部監査では現在と過去を知って将来を考える 　内部監査において、ほとんどの監査員は現在の状況について観察やインタビューを行います。また、観察によって、変わらないまま現在に至っている過去からの状況を調べたり、インタビューによって過去はどのような状況であったのかを尋ねてみることがあります。そして、文書や記録から当時の様子を調べることで過去の状況を知ることがあります。 　過去と現在の状況を踏まえて、将来をどのようにしたいのか相手に尋ねてみて、過去と現在を結ぶ延長線上に改善を探してみるようにしましょう。                                                                                2022年11月26日

プログラムのテストプランの作り方プログラムの品質を確保(検証)するのにテストは欠かせません。しかし、フリーランスで開発をする場合は、専門のテストスタップがいない場合も多く、一般的な企業で開発する場合よりテストも限られたものになる場合が多くなります。この記事では、最低限のテストプランをどのように作成したら良いのかをまとめてみました。大切なドキュメント当たり前ですが、どんな場合でもプログラムがサポートする基本機能の確認は必須です。基本機能が動かないというのは、大きな問題です。従って、どんなに時間と人手が限られていても、基本機能の確認のテストは絶対に必要です。ところで、会社などでテストの専門チームがテストの計画を作る場合、どのように作るかご存知ですか？通常は、プログラムのドキュメントを基に作成します。実はこのドキュメントが無いとテストを考えるのは難しくなるのと、テストを行うのも難しくなります。プログラムを開発する場合、求められる機能があるのが普通です。これらの要求事項を満たすようにプログラムを開発します。ところが、その機能を利用する場合、どのような手順でプログラムを使えば良いかは、プログラムをどのように実現するかで変わってきます。プログラムの開発者は、最低でも２種類のドキュメントを作るのが基本です。＊　プログラムをどのように作ったか（プログラムの仕様書）＊　プログラムをどのように使うか（操作マニュアル）　プログラムをどのように作ったかをきちんとドキュメントに残しておくと、将来の保守やトラブル時にプログラムを見直す場合などに役に立ちます。きちんとドキュメントを残すことが重要です。作成し

良い品質のプログラムとは何か？いろいろな製品に品質があるように、プログラムにも品質があります。では、良い品質のプログラムとはどんなプログラムでしょうか？この記事ではプログラムの品質について考えてみました。プログラムの品質はどのように示すか？あなたの作ったプログラムの「品質」が良いことを他の人に伝えたい場合は、あなたならどうしますか？ 実は、プログラムに限らず品質が良いことを示すのはとても難しい事です。例えば、たくさん売れている製品の場合、利用している人の評判が良ければ、多くの方はこの製品は「良い物＝品質が良い」と思う場合が多いと言えます。ところが、余り売れていない製品だったらどうでしょうか？プログラムの場合、多くの人が利用するアプリを開発してそれを大量に売るというビジネスモデルがあります。この場合ある程度利用者が多くなれば、利用者の評判は上でも書いた通り、品質の指標になります。しかし、新たに参入して余り利用実績がない場合は、こうした指標が使えないため別の方法を考える必要があります。また、ソフトウエアの開発を受注して開発する場合は、そのプログラムの実績はないため、同じように別の方法でプログラムの品質を示すことが受注の鍵になることもあります。品質の悪いプログラムとは何か？別の方法といっても、簡単には行きません。では、まずは品質の悪いプログラムは何かを考えてみることにします。 つまり、品質が悪くなければ、間接的に品質の良いプログラムと言えるのではという論理です。ところで、「良いプログラム」と「品質の良いプログラム」は少し意味合いが違います。 良いプログラムとは使いやすくて、必要な機能

小さな作業でも、基本的に以下の事を行っています。【１】確認　①サイトのシステム構成の確認　　Chromeの拡張機能を用いて、WordPress、サーバーOS、ミドルウェア　　　のバージョン、使われているプログラムの構造を確認します。　②テーマの種類の確認　　WordPressにインストールされているテーマの名前、発行元を　　確認します。実際そのテーマのデモ画面を見て、お客様のサイトとの　　違いを確認します。【２】ヒアリング　　以下の点を確認します。　　・作業の要件　　・バックアップ環境の有無　　・本番環境アクセスの可否　　・サーバーへの直アクセスの可否【３】バックアップ　　バックアップ用プラグインがあればそちらで。無ければインストールして　　バックアップを取得します。【４】ローカル開発環境の構築　　バックアップを基に、PC内のサーバにお客様の環境と同じサイトを　　構築します。ここで作業していきます。　　※極力本番環境を直接更新はしません。【５】作業　　ローカル環境で作業しつつ、不明点については質問させていただきます。【６】お客様用テスト環境の構築　　確認ポイントが多い場合、実際にお客様が操作できる、本番のコピー　　環境を所有しているサーバー内に立てます。　　ある程度開発が終わったら、こちらに反映して確認いただきます。　　※開発環境をお持ちでないお客様向けです。　　※Basic認証やIP制限をかけ、お客様のみ操作できるようにします。　　※シンプルな内容であれば画面イメージをお送りして確認いただきます。【７】確認　　諸々問題が無いか、【６】の環境でテストします。　　また、以下のタス

ココナラで最低販売価格の見直しが行われた。正直、出品者側にとっては不利な改正だと思うが、総合的に考えたらいい改正だったのかしれない。最低単価が引き上げられたので、購入者は購入しづらくなったと思う。自分の売れ筋サービスである商品紹介も、最低価格の引き上げの対象になりました。よく注文がくるサービスなので、価格の新設定は済ませましたが、時間のあるときに再度サービス説明を見直したい。購入者が購入しづらくなったのは事実だけど、今後は価格に見合うサービス内容にしたいですね。予想ですが、今後のココナラは稼げる人と、まったく稼げない人の二極化が進むと思います。最低価格が引き上げられたので、購買者は以前よりも厳しい目で出品サービスを見ます。そうなれば、価格に見合わない出品サービスは自然に淘汰されますね。自分の出品サービスが今後も選ばれるように、日々精進します。

飲食店などで注文を復唱してくれる際、気になる言葉がある。 「〇〇でよろしかったでしょうか。」と復唱してくれるのだけれど、 「よろしかったでしょうか」は過去形。 現在進行しているなら「〇〇でございますね※物なのでございます」を 使うのが正しいのです。