« 2013年9月 | トップページ | 2013年11月 »

2013年10月の記事

AWS(Amazon Web Service)を使ってます

定例会でのレギュラーコンテンツの1つとして存在する「IT-Tips 又は 5分間スピーチ」。

Pict2589_2


今回は、事業開発部の青柳さんが、弊社アスペアが幾つか運営しているWebサービスの仕組みなどの構成を話してくれました。
(とは言え、特定のお客さんの情報に多少なりとも触れてますので、詳細はここにはかけないのですが....)

サービスにも拠るのですが、AmazonのAWS(EC2、RDS、ELB、etc.)を活用しているケースが多いです。

負荷の状態に応じて、仮想マシンリソース(インスタンス)数を自動拡張・自動縮小することも可能。
...というのが、よく言われる「スケーリングの自由度(自動判断)」。

ただ、アプリケーション側の最適化が行われていないままに自動処理に任せて「スケールアウト」してしまうと、知らぬ間に「無駄なコストを食い続ける」というリスクは有ります。

この辺は、アクセス数・動作状況の監視により、アプリ側のリファクタリングも検討しなければならない点ですよね。

「現状はこんな構成を選択・組み上げている」という話と、「先々はこんな構成にまで発展させたいなー」といった話にも触れました。

自社の社員でありながら、自社で展開しているWebサービスの仕組みを知らなかったり(勿論、開発に携わっているメンバーは別ですが)、なんてことも有り得ます。

その点を社内共有する、良い機会でした。

また、AWSの個々のサービスの前提条件、サービスを組み合わせて利用するには、当然ながら色々とナレッジが必要になってくる点を共有できた、という点でも良い機会を持てたと思います!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

「テスト設計」は大切だよ!!

社内第5の佐藤さん(仕事上ではJinさんと、以前の姓で呼ばせてもらってます)から、テスト仕様書を書く(テスト項目を作る)以前に、「テスト設計」を行うことは大切だよ!!
Pict2593


面倒なように見えても、結局は効率が上がって楽になるし、テスト項目設定の精度も上げられてバグを捕まえやすいし、関係者間での認識共有・理解・納得が得られ易い!.....ということを、実務事例を元に話してもらいました。

ソフトウェアの品質の確保ってのは非常に難しい問題です。
納期も予算もリソースも限られている中で、如何に上手い具合にテスト項目を省略(最適化?)して、重要な部分のテストを厚くするか?

単純にしらみ潰しにテストケースを作成してたら、天文学的な項目数になっちゃいますからね.....。

如何にテスト項目を設定して、漏れ・抜け無く、しかし無駄なく、バグを最大限叩き出せるか?!

ポリシーの一貫した理論的な視点でテスト設計を行うことにより、何とかこれを実践しましょう!
...というのが今回の本題です。

Pict2591


Jinさんは上記のような視点・手法でテスト設計を行い、関係者間での項目設定上の合意を取り付け、テスト項目を具体化し、テストを実施、目標品質を担保して来ました。
その手法を開発プロセスの中に組込み、リリースまで進めてきた実績があります。

但し、言うまでもありませんが「唯一絶対で、あらゆるケースに最善の対応を行なうための手法」という訳ではありません。
そんな魔法は存在しないんじゃないかと思います。

しかし、習得しておけば非常に有効な武器になることは、本人が複数の顧客・複数のプロジェクトでの実績として証明して来ました。

Pict2592_2


今回のセッションでは、前述の内容を、自社の請負プロジェクト(社内持帰り開発)の納品済みの成果物:リポジトリから一部仕様を抜き出し、それを元にして「単体テスト設計書をサンプル作成してみた!」ところで、
どんなふうになるのか?を具体的に(抽象論じゃなくって)共有してみたわけです!

既存の表現をすれば、状態マトリックス、デシジョンテーブルの活用ってことになるんでしょうが、「実務への適用」には「具体的なポリシー」と暗黙値(群)が必要です。

今回のセッションでは、この、共有が難しい「暗黙値」の部分を少しでも共有できないか?(勿論、「形式知」化できた部分;サンプルのテスト設計書の共有もしました)ということで設定したものです。

詳細な内容はちょっと長くなり過ぎるので、ここには書きませんが、この発表の後、自社内で開発中の請負案件に、テスト的に適用を開始しています。

或いは顧客先常駐の場合でも、開発プロセスへの1ステップとして提案していければ!?、改善することが出来ればと思ってます!!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

帰ってきた仕様伝達ゲームっ!

...何じゃそりゃ?、と思われちゃいますかね。

えー、今年の2月の定例会の際に、1回目の「仕様伝達ゲーム」を実施しました。
http://aspire.way-nifty.com/majime/2013/02/post-7bdb.html

定例会の際に帰社できるメンバーがまちまち(平均で全技術者の6割程度かな?)なのですが、第1回目の反応がとても良くて「2回目以降もやりたいね!」って話だったのを、やっと実行したというわけです。

Pict2594Pict2595





ファシリテーターは、前回に引続き山内さんにお願いしましたが、
「これからも継続的に実施する可能性が有るのなら、他の誰かがファシリテーター役が出来るようにしちゃいましょう!」という山内さんからの提案が有りました。

うん、その通り!
素晴らしい提案です!!

「当日のドッキリということで、内緒にしておきましょう!」との付け足しあり。
通常は定例会のタイムテーブルや概要・担当者などの情報は、社員専用サイト上に事前に公開しています。
.....が、今回は担当者「山内」とのみ書いておく、と。

で、当日、「副」ファシリテーターとして指名されたのは、事業企画部の青柳さん。
(ちなみに、先月末頃に結婚式を挙げたばかりです!)

「主」ファシリテーターは山内さんが担うとして、部分的には同じセリフを「副」からも言ってもらったり、「副」が進行をサポートすることで「ファシリテーターとしての行動」を体感していきます。

Pict2596Pict2597Pict2598





今回も3~4名が1チームとなり、仕様書(文字でのみ記述する)を作成する側と、仕様書を元に課題の「図形群」を1枚の紙の上に再現する側に別れて、ワークを進行させます。

ちなみに、前回のワーク(仕様伝達ゲーム)に参加したメンバーは約半数。
経験者が特定チームに集まらないようにチーム分割しました。

Pict2599Pict2601Pict2602








基本的に伝達は、文字だけを使った「仕様書」のみで行う。
会話・発言やジェスチャーなど、上記以外の伝達方法を使ってはダメ!

ファシリテーターは、その辺のルール説明を先に行いますが、ワーク途中でルール違反的な行動を見つけた場合などに注意&ルールの再確認などを簡便に行います。

今回は2回目なので、経験者(2回目の参加者)が先導して、正確で効率的な伝達方法を工夫して仕様書を作成している様子が見られました。

Pict2603Pict2604





たとえば、紙をXY座標に分けて位置指定を伝達できるようにしたり、大きさを表す単位として、使っているマーカーペンの大きさ・マーカーのキャップの大きさを1単位としたり(「1.5キャップ分の幅がある」とか)。

他方では、2回目の出題なので、1回目よりも何気に若干、課題の難易度が上がっているような気がしました。

最後に、ファシリテータを務める上での留意点で、ワーク中に話せなかったことの補完説明がありました。

課題設定を行う場合に、
※簡単に解けそうな要素を入れる(全然出来ないと凹むから)
※微妙な要素を入れる(単純な円でなかったり、三角形が微妙に傾いていたり...)
.....など。

今回は未経験メンバーが半分を占めていたこと、
逆に2回目のメンバーが、経験を活かして工夫を取り入れたこと、
前回から8ヶ月が経過していたので、経験者もほどほどに忘れていること、
.....なども、良い方向(実施意義がある!)に作用したのかなーと感じました。

次回に行うとしたら、やはり8ヶ月以上先で、出来れば新しいメンバー数名を加えつつ実施してみたいですね!!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

| | コメント (0) | トラックバック (0)

« 2013年9月 | トップページ | 2013年11月 »