« 2014年4月 | トップページ | 2014年6月 »

2014年5月の記事

RDBMS;温故知新

「DB設計に付いて;~正規化ほか編~」と題して、Jinさんのセッションがありました。

当初予定の時間枠は45分だったのですが、60分にまで膨らんで、なおかつ収まり切れないという、相変わらずの密な内容はさすがです!(...と、手前味噌ですが...)

中身は大きく分けて3部構成、
※リレーショナルデータベースの考え方
※正規化
※アンチパターン

Pict2658ワークショップ形式というわけでは無いのですが、全員に向けての質問(設問)あり、白板に回答ER図を(参加者に)描いてもらったりと、決してボ~ッと聞いていても終わってしまうようなダルいセッションではありませんでした(←まあこれは、Jinさんセッションでは毎回のことなのですが)。

で、いきなり講師側からの質問。

★「今作っているアプリケーションのテーブル設計。第何正規形を満たしているか言えますか?」

...正しく即答できる人はいませんでした。

Pict2659
で、次に、Web上で話題になっていた記事(ちょっと過激な(正直な?)タイトルですが)をキーに話題を展開。

フィールドの設定で、...予備1 ~ 予備50(全てVARCHAR(1000))、なんて名称のフィールド群が有って、頭の方の幾つかのフィールドは既に謎の値の格納に利用されていた.....(ぞぞ~~っ)。

おかげで(?)、SQLのスキルが跳ね上がった!
(こういったケースって、有りますよね。下手に馴染んでしまうと危険極まりないのですが...)

★「リレーションって、正確に言うと何だろう?」

ヒント;「テーブル間の関連性...ではない」。

⇒答え;テーブルそれ自体、列と列の関連。

適切なリレーションとは...
・行に上下の順番がない
・列に左右の順番がない
・重複行を許可しない
・すべての列は1つの型をもち、各行に1つの値を持つ
・行に隠されたコンポーネントがない

★「正規化の目的は?」

答え;
・正規化の目的(1)
  ・人間が理解できる形で、現実世界の事実を表現する。
・正規化の目的(2)
  ・事実の格納方法から冗長性を排除し、データの異常や不整合を防ぐ。
・正規化の目的(3)
  ・整合性制約をサポートする。

正規形とは?...
・正規化のルールを満たしているテーブルの状態。

Pict2660これ以降、第1正規形違反のテーブルが表示され、その改修案を白板に書くなりして回答する、といったパターンで、更に、
・第2正規形違反のケース、
・第3正規形違反のケース、
・ボイスコッド正規形違反のケース、
・第正4規形違反のケース、
・第正5規形違反のケース、
・第正6規形違反のケースについても、同様に繰り返されました。

途中、「え?、こうだったっけ?」、「もう忘れてるな...」とか、多くの実務を乗り越えてくれば来るほど、本来の正しい(?)論理からは疎遠になっていくようです。

また、実務上では、
・正規形として問題なくても、論理的に重複がある場合。
・正規形だけではなく、運用を考慮してテーブル設計した方が良い場合もあります。
.....と、ここはもう少し具体的に掘り下げておきたかった所ですが(実例ベースで)、時間が余りにも押して来てしまいました...(今回の定例会は、ただでさえ通常よりも拡大バージョンで実施していたので...)。

この辺に関連しては、もしかしたら次回の定例会(6/13)で多少の補完情報のやりとりが出来るかも知れません。
同じく、Jinさんの時間枠が、「データ移行」を中心としてですが15分間取ってあります。
質疑で15分を大きく超える可能性が大ですが...
まあ、全然盛り上がらないで、予定時刻よりも極端に早く定例会が終了するよりは良いでしょう。
(無駄に引き伸ばすような事はしていないので)

最後に、書籍紹介がありました。
※SQLアンチパターン(オライリー)
 特に正規化を勉強するには大変良い本で、特に付録部分に必見の価値があるとか!
 和訳:http://www.amazon.co.jp/SQL%E3%82%A2%E3%83%B3%E3%83%81%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3-Bill-Karwin/dp/4873115892/ref=sr_1_1?s=books&ie=UTF8&qid=1401244600&sr=1-1&keywords=sql%E3%82%A2%E3%83%B3%E3%83%81%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
 英文:Kindle版:http://www.amazon.co.jp/SQL-Antipatterns-Programming-Pragmatic-Programmers-ebook/dp/B00A376BB2/ref=sr_1_cc_1?s=aps&ie=UTF8&qid=1401244600&sr=1-1-catcorr&keywords=sql%E3%82%A2%E3%83%B3%E3%83%81%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

KVSが多用される昨今ですが、RDBMSも早々無くなるという事は考えにくいでしょう。

それぞれの特性を活かして、使い分けていくだけのアーキ的な形式知と暗黙知を溜め込んで、共有して行ければ良いのだろうと思います。


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

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

誕生日と帽子とボール(?)と...

定例会の最後に、毎月の誕生日の人達を祝って(小さいですが)バースデー・ケーキを用意してます。

Pict2661
Pict2663_3Pict2664年齢分のロウソクを立てて、ってわけにもいかないので、数本のロウソクを立てて、執務室の照明を消してケーキ入場!
祝われる側の本人達を除いた全員で、「ハッピーバースデーイ、トゥーユー♪」と歌います!

5月の対象者は池田さんと鈴木さんだったんですが、鈴木さんは別件の用事があって早退してしまいましたー(残念)。
ので、池田さんの独占パーティでーす!

今回は「Sweet Time」のフルーツケーキ!
美味しそうです!!

Pict2657
と、ここで、山内さんが秘密兵器(?)を持ち出した!
(写真は、ご本人がジャグリング・ボールを持ってポーズを取っているところ。何やらのイベントに参加した際に、イベント運営側のスタッフの方から「特別に」売って頂いた帽子だそうです...)

Pict2665Pict2666Pict2667
出て来たのは、昨年にインドに訪問した際に入手した帽子。
何となく、みんな被ってみたくなる不思議な力を持った帽子?(山内さんの強力なオススメに拠る、とも言える?!)。

まあ、とりあえず仕事中以外は楽しくやってます!
(仕事中も結構楽しくやってるという話もありますが.....)

何にしても、楽しく無いよりは、楽しい方が良いに決まってます!!!


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

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

新卒研修者はスピーチもお勉強だあ!

新卒者の研修は、基礎研修(社会人としてのマナー云々はアウトソース研修、セキュリティ研修、コンピューターの仕組み、ネットワーク、言語(今年はPHP・以前はJava)、HTML、CSS、UML、SQL、その他)に大体2ヶ月間をかけます。
(かなりハイペースな詰め込みになりますが、1人以上の先任者がチューターとして付くので結構手厚いフォローが入ります(「気が抜けない」とも言えるかも知れないけど?、メンタルなチェックもしながらペースの加減・配分もしますよ!))

その後、擬似開発プロジェクト(演習・汎用フレームワークを含む;今年はSymfony2)に1ヶ月間をかけます。

今年の新卒新人、速形さんは、IT系専門学校の卒業生なので、余りに基礎的な事項はスキップ。

基礎研修:言語(&環境)の段階では、簡単なWebアプリまで作成します。
(この中で、RedmineやSVNなどのチケット管理・版数管理なども行います)
(社内では、未だ残念ながら?、Gitは標準的には使ってません)

で、擬似開発プロジェクトは、その時の社内のプロジェクト状況によって大幅に内容が変わります!
基本セットを1ヵ月で作ってから、参画に適したプロジェクトが無い場合は、最大3ヶ月程かけて、開発対象のWebアプリケーションの機能拡張やリファクタリングを行ったり。

逆に、社内持帰りの請負開発がバリバリ走っている場合には、チューターがメンターに変身して、研修者と一緒にプロジェクトに参加。
メンターが請け負った担当機能から更に一部を切り出して貰い、実務ベースでのOJTを行うことになります。

今年は後者のパターンになりました!
今日(5/27)からOJTスタートです!
速形さん、頑張って下さいーっ!!(って言うか、メンターの渡辺さんの方が大変なので、宜しくお願いします~!!)

あ、ちなみに、この場合のメンターさんに割り振るタスク量ですが、大体2人分(メンター+研修者)として「0.75人月」を割り当てます。

研修者は、当面は生産上のプラスとは計算できないので、このような係数をベースにタスク配分するわけです。

さてさて、基本的な研修を進めていく内にも、毎月1回の定例会を何度か経験していく事になります。

Pict2650
学生時分には余り経験することが無かったであろう、「多くの人前で発表を行う(単なる事実の伝達などではなく、自分の視点・経験・意見を反映したもの)」ことも経験して頂きます。

具体的には、レギュラーコンテンツである「IT-Tips 又は5分間スピーチ」(原則の時間枠は、質疑時間を含めて10分間)を、研修期間中は毎月、担当して戴きますです。

初回は5/16(金)。
「DvorakJ(キーボード配列変換ソフト)の紹介」でした。

つまりは、「5分間スピーチ」ではなく、「IT-Tips」を選択したという事になります。

内容は、読んで字の如くですが、キーボード配列(機種依存のボタン類は除く)を任意に設定変更可能にするフリーソフトの紹介で、彼自身が個人的に利用しているツールの紹介でした。

Pict2649
確かに、自分の使い易いキー配列パターン、と言うか、最初に慣れてしまった(気に入ってしまった?)キーボードと配置が違うのは結構なストレスです。
増してや、複数台のマシン(最近は開発マシンも殆どがNotePCですからねえ)を1日の内に何度も使い分けるようなケースでは、そのメーカーやサイズが違っていたりすると辛いモノがあります!

インストールは不要!
常駐と解除を行うだけ(レジストリ等の書き変えも必要なし)という手軽さが良いっ!!、とのこと。

デメリットは「他の人とマシンを共有しつつ、頻繁に利用者の交代が発生する」ような場合に、「あれっ?!」ってことになったり、「.....どのキーに何を割り当てたんだったっけ?...」と自分自身で忘れたり...。

キー配列の定義は、テキストファイルベースで簡易な記載を行うだけの簡単登録!

「自分が会社で使っているマシンにも入れたいんですが、勝手に入れたら拙いと思って、未だ入れていません...」って、おい!
聞きなさい!、相談しなさい!!

怪しげなサイトから入手したものでなく、アスペア標準で利用しているウィルススキャン・ソフトでスキャンしてもアラートが出ない(当然、最新のアップデートをかけた状態で)アプリなら使って良いんだよ!

自分の「手」に相当するツールなんだから、作業効率にモロ影響します!
快適に、そう、精神衛生上も快適な方が宜しいに決まってます!

という訳で、真面目だけど未だちょっと遠慮がちで堅い(アスペアの空気に染まっていない、とも言える?!)速形さんからの、第一回目のIT-Tipsでした!

上がっていたと言う割には、落ち着いて見えて、間違いもなく質疑にもそれなりに応じることが出来て、十分に及第点の出来だったと思います。

次回は「5分間スピーチ」でもいいんだからね!?


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

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

「サービスデザイン思考入門」ワークショップに参加してみた

若手でありながら、アスペア社内で唯一のデザイナーであり、プログラマーでもある佐藤(M)さん。

単にビジュアルなコンテンツの「作成を行う」訳ではなく、UI/UXの質にも拘りつつデザイン提案(画面遷移を含む)をし、機能とのリンクなども提案し、実装・テストまで進めてくれる貴重な人材です。

Pict2654
さて、先日、株式会社オージス総研さんで開催されたワークショップ「サービスデザイン思考入門~カスタマージャーニーマップからビジネスモデルキャンバスへ~」(https://www.ogis-ri.co.jp/event/1212254_6738.html)に参加して来てくれました。

実は、このワークショップには、事業開発部の部長である青柳さん(30代;新婚さん)と、このブログに頻繁に名前が挙がっている山内さんと、合わせて3名がこのワークショップに参加させて戴きました!
(定員が30名なので、アスペアの面子が1割を占めてしまったことになります...、申し訳ない)

で、折角他社の方々と交流する機会でもあるので、アスペアメンバーが同一グループに属することはやめよう!、ということで、別グループに分散しました!
(1グループは6名で定員(30名)満員でしたので、都合5グループが存在します)

内容の方は、題名の通り全てがワークショップ!!
基本的に座学は有りません。

で、そのワークショップの概要を、若手の佐藤(M)(トミー)が定例会の中で紹介してくれました(ちなみに、彼女のワークショップへの満足度評価は80点(かなり良い!)でした)。

Pict2655
題名こそ「カスタマージャーニーマップ」となっていますが、ツール(基本的に全てアナログ)群は幾つも使ったようです。

目的は、「ビジネスの企画を、各種の分析手法から合理的に導出してみよう」というものです。

決して完成された手法・体系ではなく、「いろいろと試行錯誤している状況だけれど、これでやってみるのも1つのアプローチじゃない?!」といったものです。

全体の流れをざっと紹介すると、

※エンパシーマップ(ペルソナ)で、主なビジネ・スターゲットと想定する仮想の個人を想定して、具体的な特性(欲していること/恐れていること/考えていること/見えるもの/言っていること/していること/聞こえていること)を書き込みます。
と、ここでは特性の分割数が多かったのですが、4分割にして人物の基本特性を書くというアプローチもあるようです。
何れにしても、「こんな風な人達をターゲットに...」というモヤッとした基準で満足度もソコソコのサービスを作るよりも、「具体的にこんな人に刺さる!」満足度の高いものを考える、というのがポイントになります。

※カスタマージャーニーマップ(AS-IS)
現状として挙げられる、サービスに触れたユーザーの体験事項と心の反応(プラス/マイナス両方向)を時系列に書き起こしたもの。

※ブレインストーミング
前述のAS-IS(現状)のカスタマージャーニーマップをベースに考えて、何をどう変えたら良いのか?、どんなものを・どのタイミングで提供したら良いのか?、などのアイデアを出しまくります。
ブレインストーミングのポイントは、敢えてここで挙げるまでも無いのですが「否定的な意見を言わない」こと。
この時点では、一旦は「何でも有り!」でアイデアを出しまくります!

※カスタマージャーニーマップ(TO-BE)
前段のブレインストーミングで出たアイデアを、提供するサービスに当てはめて、時系列に見たユーザーの体験と心の動きを書き出して見ます。
良い効果に至らないと判断されたアイデアはボツになりますね。

※寸劇。
前述のカスタマージャーニーマップ(TO-BE)に従ってのプレゼン、かつ、実際に組み立てたサービスを体感してみる。
他の班のメンバーからフィードバックの意見も戴きます。
グループ外からの客観的な視点での反応・意見が得られるので、貴重な段階の一つですね。

※ビジネスモデルキャンバス
自分たちが組み立てたサービスが、ビジネスとして現実的に成り立つのか?検証するステップ。
ビジネスモデルキャンバスに、自分たちのサービスで考えられるコストやリソース、期待できる収入元などを当てはめていく。
これまでで最も現実的な条件で叩くステップでもあるので、ワークショップとしてワイワイ楽しくやって来たグループも、現実の壁を改めて思い知るステップでもあります。

※振り返り(KPT)
Keep(継続すべき良いこと)、Problem(問題点)、Try(挑んでみる項目)を挙げる。

Pict2656
現実のビジネスシーンとして行う場合には、そもそも時点での市場調査・アンケートが必要だったり、最後に叩くステップでは実際に想定するタイプのユーザー(被験者)の協力を得て評価を貰ったり、といったことが必要になるだろうとのこと。

でも、これだけのステップをグループ/チームとして体験共有できるだけでも、様々なメリットが得られるように思えました。

これを、自社サービスベースで、自社内でもやってみたい.....。
アンケートを取ってみたら、賛同者は8名。
実施には、ほぼ丸1日が必要とのこと。

う~~~ん、どうする??


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

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

テストケースの自動生成と最適化!?

システムの構築・保守開発などにおいて、テストはとても重要な位置を占めます。

テスト項目を、どの視点から、どのように設定するか?
開発における、どの段階での、どんな粒度でのテストなのか?
開発プロセスに対して、どんなポリシーで、どのように組み込むのか?
目標品質とコスト・納期のバランスをどのように判断するのか?

ただ「テスト」と言っただけでも、数え切れないほどの書籍やWebサイト・コンテンツが溢れます。

Pict2651
5月の定例会で、紀さんから「PictMaster」の紹介がありました。
http://sourceforge.jp/projects/pictmaster/

システムの動き(流れ)は、Input(入力値群)-Process(処理)-Output(出力値群) とも表せますが、その「Input」は大抵の場合に多くの項目・多くの値の選択肢、或いは値の範囲を取り得ます。

それら、様々な値を取る項目の合わせ(ケース)を網羅してテストを行おうとすると、天文学的なケース数になってしまい、コスト枠も納期も全く守れなくなってしまいます。

Pict2652
では、どう組合せれば良いのか?
リスクを抑えつつ、コストも抑えながら、最適な品質を得るためのテスト項目&項目数を得るためには、どうすれば良いのか?

...そんな時のお役立ちツールの1つが「PictMaster」。

Excel(マクロ群の仕込みあり)と、Pictという実行プログラム(Microsoftから無償提供されているソフトウェア)を組合わせることにより、簡単にテストケースを自動生成できます!

PictMaster(Excelの表)に、「パラメータ名称」と「取り得る値の並び」(数値入力の場合等は、境界値やゼロ、マイナス値(異常値)などもここで設定する)を入力しておいて、「生成」ボタンを押すだけ!

Pict2653
ハイ!、テストケース(入力値のセット群)が、完全網羅ではなく適度に間引かれたケース数として生成されました。

実際にプロジェクトに適用する際には、利用前提となるガイドライン/正常値と異常値の設定・生成の仕方(利用の仕方)のポリシーなど、事前にしっかり決めて、ガッチリ守って運用しなければ意味を成さなくなります

さてさて、ここでテストケースのレビューの問題!

膨大な数に膨らんだテストケース群を、注意力散漫になりながら&疲弊しつつレビューするよりも、PictMasterの設定値がガイドラインに沿っているか?/仕様との齟齬が無いかをレビューする方が、格段に低コストで、レビュー精度も高く保てるだろうと思います!

また、作成したガイドライン自体も重要な成果物として転用できる(プロジェクトの性質に応じてカスタマイズする)点も大きなメリットですね!
(ガイドラインを決めた際の前提事項や、どのように判断して決めた結果・内容なのか?も残しておくと、後々でのカスタマイズが楽になりますね!)

PictMasterの入力値も、設定サンプルとして転用できます。

これが万能だ!、ということは無いでしょうが、1つの選択肢として記憶しておくことは重要なことだな、と思いました。


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

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

アスペアに中途入社するってえと、どうなるんだい?

「Web系アプリ/サービス、或いはスマートデバイスのアプリ開発経験者を募集してますっ!!」

んで?
入社したら、その後は何がどうなるんだい?、ええ?

公募情報にゃあ、何処にでも書いてあるような募集条件しか書いてねえじゃねえかい!
まあ、多少の違いは有るだろうけどもよう。

公開Webサイト見たって、その辺のところは分かりゃしねえじゃねえかい?!、おう?

とまあ、何となく落語調に(?)書いてみましたが、この辺の所が分からないと、そもそも応募してみようって気にはなって戴けないでしょうね...。

世間に広く知れ渡った大企業ってわけじゃなし、著名なアプリを配信しているわけでもなし(個人でそこそこのダウンロード数を取って、広告収入をお小遣いにしているメンバーもいますが...)。

別業種の企業さんとコラボして、Webサイトの機能拡張・活性化・ビジネスチャンス拡大の提案&サービス展開とかもやってはいますが、「多くの業界人に知れ渡る」レベルには至ってないです。
正直言って。ハイ。

なので、「今、アスペアに入社したとしたら、どんな具合で仕事をしていけるのか?」「どんな具合にキャリアアップして行けるのか・成長できるのか?」を、大雑把になりますが紹介してみましょう。

あ、ちなみに、これを書いている私は、社内では「キャリア開発グループ」のグループ長を務めさせて頂いております(まあ小さな会社なので、「グループ」と名が付いてはいますが、所属メンバーは私1人だけです)。

入社時には、まあ何処でも同じようなものでしょうが、
社長・会長と改めての会話、
社内業務フロー(各種申請書の提出・承認など)の説明とか、業務規定、給与規定、休日、転職に際しての手続きあれこれ、その他諸々のお話があります。

更に、実務フロー(週報とか月報)、社内共有の専用Webページ(各種ナレッジ共有やら、予定表やら、過去の定例会議事録&今後の予定、その他諸々;CMSで運用されてます)の説明。
GoogleDocs&Appsベースで文書共有や提出フローを行うこととか(前述のWebサイトからリンクもしてます)。

そんで、人事考課面からの運用フローの説明と併せて、キャリアプランを作成してもらう(一往10年先までが目安)ことのお話をします。

1つの目安として、IPAが規定しているITSS(ITスキル・スタンダード)を簡易化したもの(オリジナルは複雑で重過ぎるので、組織毎にある程度のカスタマイズをした上での運用が現実的です)ベースで、役割を選択します。
勿論、複数の役割選択もOK
と言うか、現実的には複数の役割を担えなければ、上流工程から下流・運用までを良い形で実現できません(最近で言う、DevOpsってヤツですね)。

さてさて、キャリアアップの為には、その機会が必要
機会を選ぶ為には、営業部隊との連携が必須です(プロジェクト参画後の調整・依頼・交渉なども含めて)。

また、アスペアメンバーである程度の体制を組めている場合、役割(ロール)やタスク配分の決定権がある場合(←この辺は適用する開発プロセスにも依存しますが)は、そのプロジェクト内での上長とのキャリアプラン共有も必要になります。
だから、プラン作りは必須!
これは、社員専用Webの社員名簿のページからリンクして、誰でも相互に参照が可能になってます(文書の実体はGoogleDocsですね)。

で、キャリアプランってのは長いスパンの話なので形骸化し易いし、実感が掴み難い。
時間的に近いところに、具体的な目標を置いとかないと(&達成度を判断できる指標を想定しておかないと)、プランは実現しにくくなります(「絵に描いた餅」ってヤツですね)。
営業サイドも判断の選択幅が広くなってしまって、結局は技術者各人との思惑に開きが出てしまいます。
これに対処する為に、前回書いたMBO(Management By Objectives)を利用するんですね。

さて、「ごたくはいいから、実際に何処でどんなふうに働くんだい?」って話をば。

現状、自社内・全技術者の約4割はSES契約で、客先に常駐して作業をしています。
顧客数は3社ですが、1社に意図的に集中させています(他は、新規顧客に対して尖兵として1名、後述の請負案件群の発注元の顧客先に1名です)。
ロールは、アーキテクトから協力会社側のリーダー/サブリーダー、開発要員、サービスリリース、一部運用など。

約5割は、顧客1社からの請負案件群(インクリメンタルな開発)に、複数サブグループに分かれて対応中(グループとしては1つです。朝会・夕会も全員一緒に行います)。
業務の殆どは自社事務所で行っています(新規案件説明・打合せ、システムテスト/受入テスト、納品、定例打合せのみ客先に赴きます)。

以前に書いた「新卒新人」と、そのチューター役のメンバーも、仮にこの中に含めています(朝会とかも一緒にやってますね)。
研修終了後は、この請負案件群のインクリメンタル開発の何処かに配置してOJT出来ればと考えています。

残りの1割は、自社企画サービスに対応。
まあ、実態は(実作業を主に行うのは)2名なんですが、内1名はデザイナーを兼任して、社内横断的に活躍してます。

中途採用された方は、特に事前の学習・要習得項目が無い限りは、上記プロジェクト群の何れかに配属になります(自社企画サービスは、現時点では未だ拡充できませんが...)。

判断基準は、プロジェクト側からの要望人材の有無・スケジューリングとロール/タイプ、本人自身の指向(前述)と照らし合わせ、適宜で本人を交えて会話しながら決定されます。

と、駆け足で説明してきましたが、感触はつかんで頂けたでしょうか?


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

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

« 2014年4月 | トップページ | 2014年6月 »