restofwaterimpのぎじゅつMemo

SIerに所属。企画から運用まで幅広くやってます。C#中心に書いてます。

スクラムを始めました【#1】

スクラムの研修やセミナーを受けたことはないですが、

書籍から得た知識を元にスクラムを導入しようと決意し、明日からスプリント1を

始めることになりました。

何もかも初めての経験なので、忘れないように一定のタイミングで経験したことを文書に起こそうと思ってます。自分向けの振り返りの意味合いが強いので、他の方の参考になるかわかりません。。。 

■なぜスクラムを取り入れようとしたのか

理由1:要求がぼやけているため

基幹系の仕組みではなく、「あると便利なもの」というものを作ることになった(あまり具体的には書けないです)ためです。

現行の仕組みはあるのですが、まあ不満もあり、システム都合でコードの改修もできず。で、新しいのを作り直しましょうとなったのですが、「こういうのがあったらいいな」くらいの感覚でしかユーザから要求が無いので、WF型は無理だなと判断し、アジャイル型開発を取り入れることにしました。

 

理由2:今のチームの力量がわからない

これまでシステム改善や運用保守をチームとしてやっており、WBS書いてガントチャートで見積もってやりくりしていました。ほぼ「この仕組ならこの人」状態になっており属人化しつつある状況でした。

また、今回のチームでやろうとしている言語などの技術スキルがチーム内でバラバラ過ぎ、見積もりの基準が作れなかったのもあります。リーダーが見積もっても当たるはずも無いし、根拠もないので、開発者自身が構築すべきタスクの規模と難易度を見極めて、「自分ならこれくらい」と見積もれる形が良いと思い、スクラムを選びました。

 

■取り入れるにあたっての準備

私自身、「アジャイル」「スクラム」という用語は聞いたことはあったのですが、具体的に語れず・・・の状態でした。そのため、まずは『本から学ぼう」と思い、昔に購入した書籍と新たに購入した書籍でイメージを掴みました。

書籍と、あとはWEBで検索かけまくっていろいろな情報を掛けあわせながら自分自身で言葉などを解釈することに努めてました。

 

インプットに使った書籍・・

 

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理
エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)
スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)
貝瀬 岳志 原田 勝信 和島 史典 栗林 健太郎 柴田 博志 家永 英治
技術評論社
売り上げランキング: 2,679
アジャイルソフトウェア開発の奥義
ロバート・C・マーチン
ソフトバンククリエイティブ
売り上げランキング: 100,909
(終了)ESD21/JASA共催「TPS/Agile組込システム」セミナー(資料と写真公開) - お知らせhttp://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf日本で唯一のアジャイルコーチの江端さんの講演があるということで聞いてきました。むしろ、書籍よりこちらを先に聞いてました。アジャイルスクラムの幻想と間違った解釈を解読してくる良いセミナーでした。資料も上記のサイトに記載されています。
 

 

つづく・・・(予定)

【システム開発】画面検討とユーザインタフェース検討は違う?

SI業界に入り、10年以上経つのだが、今までホストでの開発や、クラサバ系または現行アプリの改修を中心に実施して来ており、あまり画面について深く考えることはありませんでした。

 

私の頭のなかにはビジネスアプリ(Webなどとか関係なく、一企業の中で使うアプリ)は

「無駄をそぎ落として」

「必要最低限の機能で・・・」

「使う側が仕組みを理解して・・・」

 

というのが染みこんでいたのだろうか、「ユーザビリティ」という視点を持っていたようで抜けていることに気づいた。

 

私なりの認識で画面検討というと

「入力」「表示・参照」を「どのような項目で行うか」というのを考え、

モックアップを作成し、ユーザに確認、合意を行う。

というプロセス。

 

しかし、これって、画面のイメージや業務ストーリーはすべてユーザ任せ何だよなと

最近気づきました。

受託案件でも常駐型でも、「使いやすさ」「見やすさ」というのは大いに求められていると思われる。

 

スマホアプリや私用のPCでWEBサイトなどを利用し、登録・参照を行うときの画面の使いやすさ(使いやすさに気づかず、使いやすくなっているのだが・・)に慣れていると新たに企業システムを作ると不都合さのギャップにハマり、使ってもらえないならまだしも、画面イメージでNGを受けるのではないかと。

いくらシステム開発がメインで、WEBデザイナーでないとしても、多少の嗜みを持って、UIを考える時代になっていると実感しています。

 

そこで、今参考にしているサイトは・・・


デザイニング・インターフェース: パターンによる実践的インタラクションデザイン - Jenifer Tidwell - Google ブックス

google booksで一部参照できるので

 


【インタビュー】クックパッドのUIデザイナー:「エンジニアの仕事が0を1にする仕事なら、デザインは1を100にする仕事 」 - THE BRIDGE(ザ・ブリッジ)

・UIってcookpadかなと思ったので、ググった。

 この記事に付いているui-patternでデザインパターンを知る

 


UI/UX JAPAN - UIデザイン・UXデザインのいろいろを発信するブログメディア

・シンプルに、何を伝えたいのかという原則を考えるのに使ってます。

 51のチェックリストに記載の内容を元に画面を複雑にしないように意識しています。

 

他にも優良な情報というのはあると思いますが、今は限られた中で消化中です。

 

画面を考えるときには、言われたとおりに考えるのではなく、

「利用ユーザになりきって、想定される使い方をイメージし、システムの利用動線を

 考えながら画面のラフ案を作る」

ということがユーザ・インタフェース検討になっていくのかと今は思っております。

 

現在進行形で、動いていますので、また経験値を積んだら、

おさらいをしようと思います。

運用って・・・ただこなすだけじゃないだろう!


ITILとは - itSMF Japanオフィシャルサイト

 

ITILのサイトにも書かれているように、

ITサービスに対するユーザと顧客の満足度の向上
サービス可用性の向上、事業の利益と収益の増加
やり直しと損失時間の削減、リソースの管理と利用の改善によるコスト削減
新しい製品やサービスの市場投入までの時間の短縮
意思決定の改善とリスクの最適化

 

ってのが運用担当には求められている。

 

作業手順書に従って、日々、ユーザからの依頼にしたがって、淡々とこなすのは

何か違う気がしています。

 

エンタープライズ・・アプリケーションの保守運用であれば、日々運用に携わりながら、

・システムの特徴

・データの特徴

・発生しやすいこと

などを掴み、システム改善の提案やシステム品質を保つための提案を

先んじてできると感じています。

 

せっかく仕組みを作っても、システムとともに人が劣化させて行ったら元も子もないので、運用は運用でしっかり考えていただきたいものである。

【R】ggplot2のインストール

Rを勉強しようと

 

 

RとRubyによるデータ解析入門
Sau Sheong Chang
オライリージャパン
売り上げランキング: 51,695

 

でRの学習開始をし始めてます。

 

昔にRをインストールしており、バージョン3.1.0で開始。

一個一個やっていたのですが、ggplot2のパッケージインストールをしたところ、

digestが見つからないと。

 

よく見ると

http://cran.ism.ac.jp/bin/macosx/mavericks/contrib/3.1/digest_0.6.6.tgz

を指している。

 

実際にサイトを見ると、0.6.7が置いてある。

下位バージョンのRだと、パッケージは取れない仕組みなのか??はたまた自分がやり方をまだ知っていないからなのか?

 

今はよくわらかないので、ひとまずRを最新の3.1.2にあげたら、0.6.7を指すことができたのでよしとしよう。

まだ課金されていた in AWS

もう、大丈夫だろうと思っていた、AWSが課金されていた。。。

 

何じゃと思ったら、SnapShotが削除されていなかったようである。

 

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/deregister-ami.html

 

Amiの管理下であったため、SnapShot情報が削除できず残っており、

まあ、1$にも見ていないが、月額で細かく取られていた。

 

スタートアップは便利だが、クロージングが結構面倒なのかもしれない。

 

先日も、食事していた時に聞いた話だが、試しにResionサイトを日本とアメリカでインスタンスを立ち上げ、データ通信のテストを検証していた人がいた。

 

その後、自身ではインスタンスを落としたつもりだったそうだが、

請求で4000$が来たようである。

 

話を伺うと、バックアップ処理が残っており、結構大容量データを検証していたため、データ使用量を取られたそうな。

 

一応、悪意はないことをAmazon Japanにダメ元で確認を取り、本国で対応してもらい、請求されたお金は、返金されるみたいですが・・。

 

便利な分、使う方も気をつけて使わないと、余計な出費になりそうである。

【メモ】ETL系のデータ生成での調査の段取り

本日ハマったので、段取りを残す。

 

1.登場するファイル、データベースの一覧を取得する

2.登場するファイル、データベースのER図(関係図)をまとめる

3.ETLツールを調査し、生成元ファイルと生成先ファイルの関連性を整理する

4.トリガーイベントが隠れていないか・・・確認する

5.ETLツール以外にデータにアタッチしていないか確認する

 

トリガーイベントは基本使わないだろう・・・とう認識があったので、

完全見落としており、ずっと「なんでこのDBのデータが生成されているんだろう?」と

悩んでいた。

ホスト系の開発ですと、トリガーを利用する意識がなく、調査のフレームに入っていなかたのですが、GUI系のシステムならばどうも使っている傾向があるようである。

 

SQLServerでは、このサイトで確認方法を見たので、記述。

リンク先

select tr.name as trigger_name, ta.name as table_name, tr.is_disabled as disabled
from sys.triggers as tr
inner join sys.tables as ta on tr.parent_id = ta.object_id

リンク先のSQLにはdisabledの記述は記載がなかったが、トリガーが無効になっているか否かも調べておいたほうが後々説明する場合、及び自身の仮説を作成するのに利用できます。

 

【メモ】リバースエンジニアリング(ETL編)

ここ、1、2年くらい、いろいろなお客さん、社内の誰かが作った現行システムの調査、分析を行ってます。

開発を行うよりも、ソース見て、設計書見て、「不具合?」「なにこれ?」「へ〜〜そういうこと」ということが多く、びっくりと発見を繰り返しながら

・今の状態を極力可視化する

・設計書とソースの差異を洗い出す

・問題点を出す

・解決の方向性を示す

 

というのも意識して、実施しています。

 

今回は、タイトルのとおりETL。。。の分析。

今までETLツールを実際に扱ったこと無い(HULFTはあるが、設計はしたこと無い)という状態でしたが、基本、データを加工するだけなので、見方さえ覚えれば、なんとかなるもんなんだと。

 

さて、実際に解析して気づいたのですが、こういうことがあると調査がとまどるな〜〜ということがあります。

・意味のないカラムや項目が紛れている(なんであるのかな・・・調べたのに使ってない)

・意図通りに動いているのか判断できない条件文(バグかな??)

 

では、どうやって乗り越えるのか。

 

世の中にはたいそう便利なリバースエンジニアリングツールが多くあるのは知っております。しかし、実際にそのツールを使って分析しているお客さんにいまだあったことはございません。

 

個人的には、実際のソースはツールを利用すれば、見えるのだが、本当に知りたいのは、

「なんでこんなことしているんだろね」

「今をベースもしくは新しく作りなおすには何を気にしないといけない?」

といったことを知りたいものかと。

それを起点に考えると、いくら現在のシステム状態を見せても「で??」と聞かれるのが落ちなんでしょうね。

 

では、私は何をしているか・・・。

 

と、言っても画期的なことをしているわけじゃないです。

 

やっていることは3点

・ER図の作成(ETLの元、先のシステムのDBの)

・ETLの処理のマッピングを人がわかるレベルで記載

 (ツールでうまく出しているのもあるが、I,P,Oで記載)

・ETLのJOBの関連性を記載して、時系列で表現する

 

と、いうことです。

 

要は、点ではなく、線や面で表現して、ユーザが利用している業務の言葉や、表現、流れに以下に近づけて、今の業務の問題点を炙りだしてもらうか。次の新システムの考えをイメージしてもらうか・・・が勝負かと。

 

地道な作業ですが、データの移行などの肝となる作業なので、早く、正確にやらんとなと。。