1 | 2 | 3 | 4 | 5 |最初 次ページ >>
2016-11-15 08:45:00

サービスの品質について考えるテスト以前のこと

テーマ:エンジニア魂

自分一人がエンジニアとしてシステムの開発に携わっている頃はそれほどサービスの質というものをあまり意識したことがなかったのですけど、ある程度チームを管理する立場になってくると下から上がってくるその質というものに敏感にならざるを得ないことは日常よくあることです。

しかし、そのサービスの質をどうやって向上させればいいのかというのはなかなか難しいもので日々頭を悩ます問題でもあります。

 

 

サービスの質を意識する

 

もちろんサービスの品質を上げる手段というものは世の中たくさんソリューションが出ていたりもします。

単体テストのツールからSeleniumのようなブラウザを使ったテスト自動化ツールであったり、Redmineのようなバグトラッキングシステムで情報を管理したりと多角面からサービスの質を向上させる取り組みというものを取り入れたとしても、当のエンジニアたちがそれをうまく活用し、効率的に不具合を見つけて改善することを開発のサイクルの中で実施していかないと質の向上には結びつきません

 

しかし、エンジニアは納期などの制約からテストをおざなりにしているケースはよくある話で、テストそのものに時間を割かれることを嫌う人もいたりします。

それがリリース後に不具合として発見され、バグの修正だけでなく面倒な報告書の作成や上司やお客さんへの謝罪など、テストをすること以上の時間が割かれることになるとしても。

品質への意識が薄いと言ってしまうことは簡単ですが、なかなかエンジニア自身が率先してテストをするというのは本人たちの意識が高くないと無理ですし、多くは開発工程の制約としてテストをする際のルールを厳格化し、それを順守しているように整備されているのだと思います。

 

結局のところ、テスト自体も開発工程の一作業としてでしか認知されず、形骸化した作業の中ではサービスの品質はそれほど上がることなく、リリース後に多くの不具合が発見されたりもします。

システムは多くのモジュール化されたプログラムの寄せ集めであり、その1つ1つが正しく動いたとしても結合した際に不具合が出たり、また動作はするもののそれが仕様通りではないというケースもあったりして、不具合を発見することは実際に人が見て触れて判断を下さないといけない場合も多くあります。

これは、単に動作が想定通りかどうかというものではなく、実際に動くものを目にしたときにより良いものに作り替えるための判断も含まれているわけです。

 

テスト自体が一作業として成り下がってしまうと、テストがパスしているから問題ないとスルーされ、受け入れや実際にユーザーが使い始めた際に不具合だけでなく仕様バグとしての指摘を受けたりします。

それが許される環境ならそれでブラッシュアップしていけばいいでしょうけど、それはそれでエンジニアとしても「不具合があれば誰かが報告してくれる」という受け身の癖がついてしまったりして問題です。

これは、開発者とテスターを分けるような体制で構築を進めた際もよく起きたりして、とてもテストする品質でもないのにそれがテスト工程に持ち込まれたりしてひと悶着あったりもします。

 

 

品質を上げる意味と意義

 

最初に自分一人がエンジニアとしてシステム開発に携わっていたころはこのサービスの質について意識しなかったというのは、もちろん経験が少なかったということもあるのですが、もう一方の視点として自分がその質を担保するしかない状況にあったことや、自分が作ったものだからある程度そのシステムに愛着があったからというのもあります。

なので、実際には無意識にそれを意識せざるを得ない状況だったのだと思います。

まぁ、その質とやらは置いとくとして。

 

これはある意味環境に恵まれていたのだと思いますが、自分たちで何かを生み出しそれを進展させることができたからそれに伴う品質というものも意識することができたというもので、現状のエンジニアを取り巻く環境というのは「新人エンジニアの教育を悩ませる7つの環境と課題」に書いたように、何かを一から生み出すということはやりづらい状況であったりもします。

もちろん、日々何か新しいサービスを生み出し、開発の案件を受託して仕事をしているのだと思いますが、それは自分が考えたものではなく誰かが作ったものを保守したり、自分とは遠く離れた場所で出来上がった設計仕様に基づいて構築をする話であったりして、それに対して愛着なんてものもなく、また多くの関係者がいる中でその責任の所在というものも曖昧になったりもします。

 

自分が担当している領域はある程度明確にはなっているので、その範囲で問題が起きないよう、怒られない程度に品質を担保していこうとする意識は働くと思いますが、積極的に品質を高めていく取り組みというのはなかなか行われません。

ひどく整備された開発のタスクや役割の中ではその品質を高めるための取り組みというのは、担当チームや組織が用意されていたりもして、開発チームでは余計なことはするなとばりに、自分の領域の仕事を全うすることに注力をさせられたりもします。

 

結局のところ品質を高めるためのツールや手法というものは世の中にたくさんあるわけですが、それをエンジニアたちが積極的に採用し品質を高める行動を自発的に促していくという意識を持ってもらうことに課題があったりします。

自分たちが作っているものが何なのか、実際にお客さんや利用者と対話しそれを実感してもらうことも大事なのかもしれませんが、規模が大きくなってきたりすると末端のエンジニアまで同行させることが難しかったり、ヘルプデスクのような現場の声を聴ける業務を担当してもらうことも本業が忙殺される中ではなかなか難しかったりもすることです。

 

しかし、やはりそのような意識の変革をもたらすためにはエンジニア自身が担当としての役割だけでなく、何に貢献をしているのかその意味をきちんと理解してもらう必要があるのではないかと思ったりします。

繰り返しにはなりますが、如何にエンジニアがテストツールなどを積極的に採用をしたとしてもそれを継続的に利用し、日々サービスの品質を向上しようとする取り組みを維持しなければ結局のところ目立った成果がでなかったり、テストがなおざりにされている頃に戻ってしまうわけです。

 

 

 

 

いいね!した人  |  コメント(0)  |  リブログ(0)
2016-11-10 00:09:37

[PHP] 簡単に画像の加工ができるintervention/image

テーマ:PHP

ユーザーがアップロードした画像を加工したいといった場合、Linux系なら「ImageMagickを使ってコマンドラインからCAPTCHAを作ってみる」に書いたようにコマンドラインから画像を加工する方法もありますが、 intervention/imageを使えばPHPのプログラム内で簡単に加工をすることができたりします。

intervention/imageを利用する場合、PHP5.4以上でGDまたはImageMagickがインストールされている必要があります。

 

 

intervention/imageを使ってみる

 

まずは、インストール方法ですがcomposer経由でインストールができます。

composer.jsonを使う場合は、下記のような定義ファイルを用意しcomposer updateを実行します。

 

{
    "require": {
        "intervention/image": "2.3.*"
    }
}

 

または、直接composerコマンドから指定してインストールします。

 

$ composer require intervention/image

 

Laravelから使いたい場合は、app.phpにサービスプロバイダに追加すれば使えます。

 

'providers' => array(
    -snip-
    'Intervention\Image\ImageServiceProvider',
),

 

簡単なサンプルプログラムとしては下記のようなものになります。

 

<?php
require 'vendor/autoload.php';
use Intervention\Image\ImageManagerStatic as Image;

$image = Image::make('./foo.jpg')->resize(150, 100)->save('./hoge.jpg');

 

autoload.phpを呼び出し、名前空間の定義をしてstaticでメソッドを呼び出しています。

staticではなくクラスオブジェクトを生成して使うことももちろん可能です(公式のサンプル参照)。

上記の場合、画像の加工としてはfoo.jpgに対して150x100pxにリサイズし、hoge.jpgとして保存しています。

その外に出来ることは、公式マニュアルのAPI一覧を見ればわかるかとおもいますが、代表的なものを紹介します。

 

□ 画像を曇らせる(ぼかす)

 

$image = Image::make('./foo.jpg')->blur(50)->save('./hoge.jpg');

 

blur()の引数で曇らせる度合いを指定します。

 

 

□ 明度を変える

 

$image = Image::make('./foo.jpg')->brightness(50)->save('./hoge.jpg');

 

brightness()の引数で明度を調整できます。

 

 

□ モノクロにする

 

画像を白黒にするあれです。

 

$image = Image::make('./foo.jpg')->greyscale()->save('./hoge.jpg');

 

□ 透明化する

 

Image::make('./foo.jpg')->opacity(50)->save('./hoge.jpg');

 

opacity()の引数で透明度を調整できます。

 

□ 画像の一部を切り抜く

 

$image = Image::make('./foo.jpg')->crop(50, 50, 45, 25)->save('./hoge.jpg');

 

crop()の第1、第2引数は切り抜いた画像のサイズ、第3、第4引数は切り抜き位置(X座標、Y座標)を指定します。

 

□ 画像の余白を削除する

 

キャンパス内に余白がある場合にそれを削って画像の大きさにフィットさせることができます。

 

Image::make('./abc.png')->trim()->save('./hoge.jpg');

 

□ 画像を反転する

 

Image::make('./foo.jpg')->flip('v')->save('./hoge.jpg');

 

flipの第1引数にvを指定すると上下反転させます。デフォルトは左右反転です。

 

 

□ 画像のフォーマットを変更する

 

専用のencode()というメソッドがあるようですが、save()で指定したファイル名でフォーマットを決めて保存することも出来ます。

 

Image::make('./foo.jpg')->save('foo.gif');

 

encode()メソッドの特徴としてdata-urlオプションを指定するとRFC 2397形式のdata://のURIスキームを返してくれたりします。

 

$image = Image::make('./foo.jpg')->encode('data-url');
echo "<img src="$image" />";

 

□ 画像の情報を取得する

 

下記は、画像のサイズを取得します。

 

$size = Image::make('./foo.jpg')->filesize();

 

下記は、画像の高さや横幅を取得します。

 

$height = Image::make('./foo.jpg')->height();
$width = Image::make('./foo.jpg')->width();

 

下記は、画像のMIMEタイプを取得します。

 

$mime = Image::make('./foo.jpg')->mime();

 

下記は、画像のexifを取得します。

 

$exif = Image::make('./abc.jpg')->exif();

 

出力例。

 

array(48) {
["FileName"]=> string(7) "abc.jpg"
["FileDateTime"]=> int(1478581452)
["FileSize"]=> int(188983)
["FileType"]=> int(2)
["MimeType"]=> string(10) "image/jpeg"
["SectionsFound"]=> string(46) "ANY_TAG, IFD0, THUMBNAIL, EXIF, INTEROP, WINXP"
["COMPUTED"]=> array(10) {
    ["html"]=> string(24) "width="640" height="480""
    ["Height"]=> int(480)
    ["Width"]=> int(640)
    ["IsColor"]=> int(1)
    ["ByteOrderMotorola"]=> int(1)
    ["ApertureFNumber"]=> string(5) "f/2.8"
    ["UserComment"]=> string(1) " "
    ["UserCommentEncoding"]=> string(9) "UNDEFINED"  
    ["Thumbnail.FileType"]=> int(2)
    ["Thumbnail.MimeType"]=> string(10) "image/jpeg"
}
-snip-

 

□ 画像を一から作る

 

かなり手間にはなりますが、画像を一から作ることも出来ます。

 

// 300x300pxの灰色のキャンパスを作成
$image = Image::canvas(300, 300, '#999');
// 左上から右下にかけて線を引く
$image->line(0, 0, 300, 300, function ($draw) {
    $draw->color('#0000ff');
});
// 長方形を描く
$image->rectangle(20, 20, 250, 250, function ($draw) {
    $draw->background('#00ff00');
});
// 中心部に円を書く
$image->circle(50, 150, 150, function ($draw) {
    $draw->background('#ff0000');
});
$image->save('./hoge.jpg');

 

それぞれコールバック関数を指定できるのでその中で線や塗りつぶしの色を指定することができたりします。

 

 

まぁ、正直よく使いそうなのは画像のフォーマットの変換やリサイズぐらいかなとは思うのですが、導入も簡単なので画像を加工したい場合に使ってみると良いかと思います。

 

 

 

 

いいね!した人  |  コメント(1)  |  リブログ(0)
2016-10-06 08:30:00

運営体制とサービスの衰退

テーマ:情報システム部門のお仕事

社内でもいくつも業務改善のプロジェクトなんかが立ち上がっては推進されていくわけですけど、数年もしないうちに一気にしぼんでそのサービス自体が衰退してしまうケースってよく見受けられます。

こういうのってプロジェクトオーナーがかじ取りを誤ったり、予算取りがうまくいかずにとりあえず現状維持をしていくうちに使われなくなってきたり、軌道に乗ったのを見るとあとは惰性で何とかなるんじゃないかと一気に熱意が失われていったり色々なんですけど、結局のところしっかりとした運営体制を最初に作りそれを維持できるのかという点が結構大きいと感じたりします。

 

 

サービスの裏に人

 

当たり前ですが、何らかのシステムとか仕組みを作ってサービスを始めたところで、それを支える裏の人というのは当然必要になります。

システムは道具であるわけですから道具を手入れしたり、活用方法を広めていかないと誰も使われなくなります。

 

プロジェクトの開始にはこういった体制をしっかり意識しようとはするものの、月日の流れとともに役割や組織の変遷を経てそれを維持するための裏の人がどんどんとポジションを離れて行ってサービスを維持することができなくなるのはよく見かけます。

かろうじて維持できていたとしても、そこに何らかの意思をもって対処する人はいないわけで、そんなサービスに未来などないわけです。

当然、中の人も「これやってだれか見る人はいるのだろうか」「この作業に意味はあるのだろうか」などとモチベーションも低下することになります。

 

サービスというのは作ることが目的ではなく、それを活用し維持し発展していくことが前提としてあって、その先に求めていた成果があるはずなのに多くは作ることに注力して、できればあとは何とかうまく回っていくだろうという楽観的な発想を持っている人が多かったりもします。

たぶん、当初の計画の中ではサービスのロードマップとして、何をどうしておけば集客や利用率や成果を得ることができるだろう絵空事が描かれているのだと思いますが、当然そんなものは計画通りにいくとは限りません。

また、月日の流れやニーズの移り変わりとともにそのサービスも姿を変えていかなくてはいけないわけですが、そういったことは当初の計画の中には当然盛り込まれていないことで、運用していく中でその部隊がうまく考えてやっていくでしょうというかなりグレーゾーンとして考えられたりもします。

 

結局のところ、サービスの裏には人が必要だというごく当たり前のことがちゃんと考えられていないせいで維持することができない状況になったりするわけです。

 

 

目的・目標を語る人

 

プロジェクトを開始した当初はあれほどそのサービスの必要性を訴えていたのに、いざできてしまうとそれに満足して主力部隊を次のプロジェクトに回してしまうケースもよくある話です。

中の人が変わると引継ぎの過程でそのサービスの目的や意図を正確に把握できなくなったり、新しい人にそのサービスの未来を描くモチベーションを持ってもらうのはなかなか難しいことではあります。

 

また、サービスイン後にプロジェクトで描かれた目標というものを定量的に評価しながら、ずれなどがあればうまく軌道修正する役割の人というのは必要なわけですけど、多くはサービスを作ってしまえば当初の目的や目標というのは忘れ去られてしまうケースが多いのではないでしょうか。

まぁ、数年後に似たようなプロジェクトが立ち上がったりして、「その目的ってどっかできいたことある・・・」とか「あのサービスを作ったのはなんだったのだろうか」とかになるわけです。

それでも「あのサービスはここがよくない」とか「あれ、もう誰も使ってないでしょ?」とか言われてよくわからない道路工事のように掘っては埋めるという誰も得しないプロジェクトが生まれては消えていくことになります。

 

かしこまって目的や目標などを語りだすと周りが距離を取り出すことはあったりもするのですが、それでも誰かがそのサービスの未来というものを描かない限り、何を指標に進めばいいのかわからなくなり混乱を招きます。

こういった混乱は継続するとそのサービスを維持することの意義が失われることにもなってくるので、単純な話そのサービスを誰が何のためにどこに向かわせるのかということを定め、それを常に示すことができる人がいるということが大事なのではないかと思うわけです。

 

 

 

いいね!した人  |  コメント(0)  |  リブログ(0)
1 | 2 | 3 | 4 | 5 |最初 次ページ >>

AD

Ameba人気のブログ

Amebaトピックス

      ランキング

      • 総合
      • 新登場
      • 急上昇
      • トレンド

      ブログをはじめる

      たくさんの芸能人・有名人が
      書いているAmebaブログを
      無料で簡単にはじめることができます。

      公式トップブロガーへ応募

      多くの方にご紹介したいブログを
      執筆する方を「公式トップブロガー」
      として認定しております。

      芸能人・有名人ブログを開設

      Amebaブログでは、芸能人・有名人ブログを
      ご希望される著名人の方/事務所様を
      随時募集しております。