ブログ

サイト管理人兼開発者のブログです。

ブログ一覧

品質(Quality)

神戸製鋼、日産、スバル…ここの所、連日、品質問題が報道されている。

 

「品質なんかずっと前から蔑ろにされている」「ルールの方が現実に合っていないんだ」という意見も見かけるが、まぁ、そういう人が多くなれば、ルール軽視、品質軽視になるんだろう。

信号を守らない社会人の歩行者、自転車、ドライバを見かけるが、日常のルールを軽視している人が、会社のルールを尊重するかも怪しいもので。

 

少し、言いたい事から外れたので、話を少し戻そう。

 

モノづくりの現場では、よく「QCD」という言葉が出てくる。

 

Q…Quality、C…Cost、D…Delivery

 

この中でCost(費用)とDelivery(納期)は、意味は明確で、数値でも表されるので非常にはっきりしている。

しかしQualityは何かあいまいだ。

「品質じゃないか!」と思いきや、人によっては、性能や機能、利便性(ユーザビリティ)まで「Q」に含めて話をする人がいる。そうして、そうしたものは数字に表れにくい。

 

そんな状態で、「QCDは守らなければならない」と言われる。

 

「納期厳守だ」と言われれば、残業したり、増員したりして納期までの作業量を増やすことで対応するだろう。

 

「経費削減!予算オーバーはまかりならん!」と言われれば、部材を安く調達したり(仕入れ先を変えたり、部品自体を安いものに変えたり)、仕事を効率化して(?)残業を減らしたり、いろんなモノをケチったり、、、。

 

「品質第一だ!」と言うのは「売れるものを作れ!」と言っているものに近い。

・性能の高いものを作る。

・こんな機能を持っている。

・使い勝手が良い。

こういったものは、他人の人にもアピールしやすいだろう。しかし、

・壊れないモノを作る。

・基準に合うモノを作る。

というのは、会社の内部の人間にも、一般のユーザーにもアピール力が低いだろう。そんな事は当然だという認識もあるのではないか?

でも、そういったモノには、それなりのコストがかかる事(かけないといけない事)を多くの人が蔑ろにしている。(忘れているのかもしれない)

 

さて、何が言いたいのかと言うと、まず、「Q」は純粋にQuality(品質)を示す言葉にすべきという事。

モノを作るときに、達すべき品質基準を規定する事が大事である。

性能や、機能性は「P」…Performanceや「F」…Functinalityのような言葉で分けるべき。

 

なので、「QCD」ではなく、「QCDPF」の様に製品として満たすべき基準を明確にすべきであろう。

そして、「Q」(=品質)に重きを置き、それなりのCostを掛けるべき。

 

・・・

 

というのは正論であるが、正論を通すと、必ずどこかに矛盾が出てくる。

 

売れる価格帯は決まっているので、掛けられる費用は決まっている。品質にコストを掛ければ、他に掛けるコストを下げないといけない。

下げられないとなると、労働者にしわ寄せが寄ってくる。

 

納期も基本的にずらせないだろう。

品質=信頼と言うようなことも言われているが、納期を守れない会社はそれこそ信頼をなくしてしまう。

納期を伸ばしたとしても、その分、固定費・人件費は増えるだけだし、他社の競争に負ける可能性も増えるので、よい事は何もない。

 

じゃあ、どうするか?

 

・・・

 

「見えない所(表に見えにくい所)を削れないか?」という悪魔のささやきが聞こえてくる。

そう、品質にかかわる部分や検査の手を抜いてしまえと。

そこに一旦手を染めてしまうと、もう、抜け出せなくなるのに。

一度、コストを掛けなくても良い、楽ができると体験した人間、企業が、あえてコストのかかる、苦労するところに戻る事は非常に困難だろう。

 

大企業になると、部門が分かれてしまい、品質部門が独立していると、目が行き届かないのかもしれない。

個人や小さい会社だと、自分たちの作っている物の品質は身に染みて分かるのだろうけど、部門からの報告だけ聞いている経営者や会社責任者はどうなんだろうか?

 

「そもそも、品質の高いものを作っているのだから、多少いいじゃないか?」という考えは非常に危うい。

人の作るものだから、必ず、間違いはある。それが誤って世間に出ない様に、自社で定めた検査や、国や自治体が定めた検査やルールがある。そういったものは、長年の経験などに基づいているので、軽視する事は危険。

でも、あまりにも無駄な部分や、時代に合わない部分も出てくるだろう。そういったモノは、変更しても問題のない事を業界・自治体と議論の上変えていくべきで、自社で勝手に解釈をかえてはならない。

そういうのは、「事故を起こさないから、赤信号や一時停止を無視しても問題ない」という考えに近い。ルールを守っていてさえ事故は発生し、ルールを守らなければ、事故の発生の危険性は必ず上がるという事を改めて認識する必要がある。

 

そして、ユーザー側も、価格ばかり重視するのではなく、品質に掛かるコストを再認識すべきである。

 

「ブランド物は品質が高い」のではなく、「品質が高い物がブランドとなる」である。

 

2017年10月27日

Google(TM)提供のライブラリ

Google(TM)提供のライブラリを利用すると、簡単に色々な事が出来るようになる。

 

・音声認識

・音声合成

・GPSの利用

・などなど

 

ただ、たまに気づかないうちに、仕様が変わっている場合がある。

Jogging Partnerでは、経度・緯度情報から現在地情報を取得しているが、取得できるデータ形式がずいぶん変わっていた。

かつ、フォーマットの統一性も今一つ分からないので、ずいぶん困った。

(結局、複数地点の情報を取得して、普通と思われる形式を出力できるようにした)

 

さらに、よくわからなかったのが、住所を音声合成しようとすると、途中で

「エルオーシーエーティーアイオー…」

とか言い始める始末。

何をしゃべっているのかと思ったら、「LOCATION_CONTEXT」と言っているようだ。

そんな文字列は渡していないのだが、、、。

どうやったら、「LOCATION_CONTEXT」と言わなくなるかを、文字列のパターンを変えながら対応。(泥臭い…)

 

便利なんだけど、時々不便。それが、Google(TM)提供のライブラリ…。

2017年08月18日

アプリストアのレビュー

アプリストアのレビューで気になった事を少々。

 

メーカーがプリインストールしているアプリに対するレビューで

「使わないからアンインストールできる様にしてほしい」

「アンインストールして、増えた容量を別に使いたい」

というものをよく目にする。

 

気持ちは良く分かるが…。

 

そもそも、なぜアンインストールできないかというと、プリインストールアプリは、後でダウンロードしてインストールするアプリのもともとの格納場所(パーティション)が違うから。

 

プリインストールアプリは/system、後でダウンロードするアプリは/dataに格納される。

/system側は名前の通り、主にシステムが利用するので、セキュリティ上、基本的に上書きが出来ない(という事は消すことも出来ない)。

/data側は名前の通り、アプリを含めデータを格納するので、上書き(消去)が可能(ただし、一般ユーザーの権限では読み書き不可)。

なので、/system側にもともとプリインストールされている(書き込まれている)アプリはアンインストールが不可能という事になる。

もし、アンインストールが出来たとしても、/systemパーティション側の容量が増えるだけで、ユーザーがアプリをインストールする/data側の容量が増えるわけではない。

 

ただ、プリインストールアプリも、アプリアップデートや、アプリ固有のデータを利用する場合などに/data側を利用している(はず)。

なので、アンインストールできないからと言って放置しておくと、それはそれで、ユーザーが利用できる容量が減ってしまうという事になる。

 

この辺りの情報があまり議論されないのはなぜだろう?

 

利用していないプリインストールアプリの容量を最小限にするための解決策としては、設定から利用しないアプリを「無効化」しておくこと(動作もさせない、アップデートもさせない状態にしておくこと)だが、OSやシステムに必要なアプリを「無効化」してしまうと、スマホ自身が操作不能になったり、他のアプリとの連携でうまく動作しなくなる場合があるので、あくまで自己責任で設定変更して欲しい

そのアプリを停止・無効化したらどういう影響があるか分からないのであれば、無効化しない方が良い。

メーカーは、利用して欲しくて、または、ユーザーの利便性を考えて、プリインストールアプリを入れているので、「このアプリを利用したくないなら、無効化してください」という事はないだろう。

 

それよりも、iPhoneが128GBをラインナップしているように、メーカーがスマホのストレージの容量を増やしてくれる方がうれしい。

その分、端末の値段は高くなるだろうけど…。

 

マイナス意見のレビューは凹むが、それも、貴重な意見。

ユーザーの不満を適切なタイミングでなくしていけば、逆に、よくぞ対応してくれたという事になると思うが、まだ対応しなくても大丈夫だろうと日和ったりしてると、信頼をなくしていくんだと思う。

2017年04月19日

フリー素材のありがたさ。

今回はUnityでSliding Puzzleを作成しましたが、いろいろとフリーの素材にお世話になりました。

 

[フォント]

 自家製 Rounded M+

 URL: http://jikasei.me/font/rounded-mplus/

 

 Google Note Fonts

 URL: https://www.google.com/get/note/

 

[アイコン]

 Google Material Icons

 URL: https://material.io/icns/

 

[音楽素材]

 Music-Note.jp

 URL: http://www.music-note.jp/

 

[効果音提供]

 Sound Effect Lab

 URL: http://en.soundeffect-lab.info/

 

アイコンの一部や、効果音の一部は頑張って作ってみましたが、全てを作るのは無理だったので、上記のサイトの素材にお世話になりました。

 

もちろん、ネットに情報を掲載頂いている皆様にもお世話になりました。

欲しい情報そのものという物はなかなかないですが、調べるとっかかりになるので非常に助かりました。

 

2016年12月08日

AndroidかiOSか

開発するデバイスに関して。

 

Androidで開発する場合、機種によって振る舞いが違う事が多々ある。

新しい機種、古い機種、メーカが違う機種で同じプログラムでも挙動が違う。

ソフト処理の部分はそうでもないと思うが、ハードの差でくる振る舞いの違いは如何ともしがたい。

・歩数計機能がない!

・カメラ画像を回転してくれない!

などなど。

まだ、機能がない事が事前に分かれば、プログラムで処理を分ける事が出来るが、サポートしてるのかしてないのかわからないと、どうしても、サポートしてない機種を前提に開発しなくてはならなくて、余分なコードを追加しないといけない。

そうすると、余計な処理時間が掛かって遅くなる。

それが、今のところの不満点。

(メーカーが自社向けのアプリしか作らないのはそういうのもあるんだろうけど)

 

iOSで開発する場合は、ハードもソフトも同一会社が作成しているので、Androidデバイスよりも、サポートしているしていないという情報がはっきりしている。

(とは言っても、最近は機種が増えてきたので、似たような気もする。)

もっとも苦労するのは、画面内の部品のレイアウト。

部品が少ない時はいいが、複雑な画面レイアウトをしようとするとAutoLayoutで苦しめられる。

(AndroidのようなRelativeLayout/LinearLayoutがあるといいんだけど)

 

後は、両方にいえるのが、非推奨(Deprecated)のクラスやAPIに関して、説明が少ない。

どう移行すべきかを分かりやすく解説したページを用意して欲しい。

 

どちらにしても一長一短はある。

両方のいいとこどりなデバイス・開発環境があるとうれしい。

2016年11月01日
» 続きを読む