ITプロジェクトにおけるカンバン方式について勉強した。

「カンバン」というと「トヨタ」しか連想されなくて、生産管理の手法と思いこんていたので改めて勉強した。

カンバンのポイントは以下のとおり
※ちなみにWikipediaは、難しすぎてよくわからなかった。

1. この方式の導入の大きな目的は、プロジェクトの見える化。
2. 何（タスク）を、いつまでに、誰が、今どこまで、を見える化する手法。
3. 最低限、ホワイトボードと付箋紙があれば実行できる。
4. （おそらく一番単純な書き方では）ホワイトボードに縦に３本線を引く。
5. 左の列は「ToDo」何をするのかを付箋紙で貼っていく。
6. 真ん中の列は「Doing」仕掛り中の付箋紙を「ToDo」から移動させる。
7. 右の列は「Done」終わったタスクを「Doing」から移動させる。
8. 付箋紙にはだれが、いつまでに、どんなことをするのかを書く。（はず）
9. ホワイトボードではなく、コンピューターのツールを使ってももちろんいい。
• チームの人数がすこし多くなるとその方が良いのだろうと思う。

上記は、単純なパターンだが列を増やしプロセスを細かくすることも可能。

上記をみて巷でいうチケット駆動では？と思ったがそちらも詳しくないので後日調べてみる。

しかしこれは自分が関わったような大規模プロジェクトでは、導入しにくいのではと思った。やり方に問題があるのではなく「見える化」を良しとしない人がいるためだ。表向きは、「プロジェクトなので見える化は推進されるべき」となるが、実際は見えると困る人達がいる。プロジェクトの進捗状況は、その人自身の評判や人事考課に関わってきたりする。なにしろ一目で「できない人」がわかってしまうので、日本人の性質なのか赤裸々にそれを明確にすることは難色を示されることがあるのではと感じた。

個人的には、ITプロジェクトにおける「できる」「できない」は、向き不向きの問題なので、赤裸々になっても恥じることはないと考えているが。

SEOの勉強会にいってきた

最初にSEO(Search Engine Optimization 検索エンジン最適化)の勉強会にいってきたので記録として残しておく。

全体は２部構成で
1.Webマーケティングの考え方
2.Google Analysticsの概要について
となっていた。２部はツールの簡単な紹介だったので省略する。

１部のWebマーケティングの考え方が非常に面白かった。
例えば、自分が有料自習室（最近は図書館で受験勉強とかしづらい）を経営しているとして、その宣伝のWebサイトにどのように誘導するのか？

カスタマージャーニー（顧客行動と訳すのかな？）という考え方で誘導の方法論をかんがえる。

1. まず顧客像を定義する（ペルソナというそうだ）
1. 例えば浪人生で集中して勉強する為の施設を探している（毎日喫茶店は高すぎる。また長時間いるのは気がひける）という人が顧客像
2. 次にそのペルソナがとる行動を定義する（フェーズとタッチポイントという、行動の際に顧客がどのように思考するかも仮説を立てる。）
1. フェーズ１　浪人生が自習施設を探す。
• タッチポイント１　Webで、「自習室」「無料」「有料」「最寄の駅名」などで検索をかける。
2. フェーズ２　浪人生がヒットした中でHPを開いて中身を確認する。
• タッチポイント２　ヒットした中で上位のサイトを開き、自分の予算、駅近か？どうか、設備などを確認する。
3. フェーズ３　実際に一度行ってみる。
• 条件に合致していた場合、見学の申し込みをする。
3. 上記は非常に簡単な例だが、フェーズ１、２においてどれぐらい顧客に訴求するか？また検索上位に位置するかがWebマーケティングのポイントとなる。
4. 上記の例だと
1. 自分が想定する顧客の検索にヒットしているか？
2. 自分が想定する顧客が求める情報が自身のWebサイトに盛り込まれているか？
3. をツールを使い分析していく。

なのでブログタイトル、副題、記事タイトルなどが非常に重要であるとわかった。

これまで記事タイトルは、漠然と書いていたところがあるので改善していきたいと思う。

※勉強会では触れられなかったが、どれだけ他サイトからリンクされているかも重要じゃなかったかな？

ITプロジェクトにおける計画立案（アーキテクチャとリソース計画）について（過去のプロジェクト振り返りその6）

今回は、計画立案の設問について述べる。

"
計画立案
10.アーキテクチャと設計についての詳細な文書を作成してあるか。
"

アーキテクチャをプロジェクト全体として共有することは重要である。しかし計画段階でそれを設定することができるプロジェクトは多くない。また実現可能性の高いアーキテクチャ（本を丸写ししたようなアーキテクチャではなく）を設計できる人も少ない。


"
13.プロジェクト計画には休日、休暇、病欠、教育などの時間が見込まれているか。さらに、リソースの使用率が100%未満で計画されているか。
"

20年前ならいざ知らず、近年は人的リソースについては、上記のことを考慮して計画することが多い。しかしながらそもそも「計画時におけるプロジェクト規模の見積もりの難しさ」という問題があり、余裕をもってリソース計画を立てたつもりであっても、結局工程が進むにつれリソースを食いつぶしてしまうことが多い。計画と実際の規模の間に借りが大きい場合は、そのプロジェクトはデスマーチとなる。

JSONを勉強した

Web越しのデータの受け渡しにJSON(JavaScript Object Notation)という形式が使われると聞いたので勉強してみた。かつてはXMLが主流とおもっていたのが、必ずしもそうではなくなったらしいので勉強しておかねばと思った。（特にJavasScriptを勉強するにあたって）

XMLは構造をあらわすのに便利な形式ではあるが、ちょっと冗長なところがあるとは思っていた。入れ子構造をあらわすには便利だと思う。しかし可読性はそれほど良くないところもあり、単純なデータ構造をあらわすためにJSONという形式ができたのではないかと思う。単純な設定ファイルなどのためには、XMLは大仰なのかもしれない。

JSONの簡単な記載例を以下に示す。

{
    "年齢":50,
    "住所":"東京都杉並区",
    "ペット":["犬","猫","猿","雉"],
    "既婚":false
}

左側にデータ名、コロンで挟んで右側にデータ値。超簡単ですね。
ペットの記載例のように配列も取り扱い可能。記載例には書かなかったが入れ子構造も可能な様子。（オブジェクトというものを使うのかな？今回は割愛）

確かにXMLよりは可読性に優れているように思います。
RDBMSでJSONをサポートしたというニュースを聞くのもなんだかわかる気がします。

SOAについて考えてみた

これまで関わった２つのプロジェクトで基本的なアーキテクチャにSOA(Service Oriented Architecture)を採用していた（とされていた）。

まずSOAとは、概念であり、技術や製品ではないと記述をあるところで読んで、ひっくり返りそうになった。

SOAの概念、利点は以下とおり。

• 業務（領収書を発行する等）単位でプログラムを部品化し再利用できるようにして、システム単位のみならず企業単位で最適化を図る。（例えば組織変更によるワークフロー変更への柔軟な対応とか）もうすこし詳しく書くと、
1. 業務の部品化する。
2. 部品を組み合わせてアプリケーションを構成する。
3. オープンな技術による（SOAP等）標準的なインターフェースを備える。

と理解した。

とすると、関わった２つのプロジェクトは、いずれも（かなり有名な）パッケージ製品を利用することが決まっており、外部からアクセスする為のAPIも当然備わっていた。それぞれのプロジェクトは、別途アプリケーションサーバーを立て、APIにかぶせる形でSOAサーバーを立てていた。（SOAは概念であるとするとSOAサーバーって変な感じ）

パッケージ製品のAPIは、部品化され標準にのっとったインターフェースを備えており、さらにSOAサーバーが必要な理由がよくわからなくなってくる。

真に企業においてSOAの概念が必要なケースは、全く新規にシステムを一から再構築する場合のように感じる。

つまりバズワードであるSOAを営業的に使って、SIerから余計にサーバーを買わされただけなのが真実なのだろうか？

Visual Studio Codeを使ってみた。

node.jsを練習するために、入力補完のあるEditorを使いたいと思った。
クラウド開発環境のCloud9は、結局インストールがめんどくさく諦めて、練習のための環境整備の為に労力を割くのもバカバカしいと思い、割り切ってローカルでIDE(Integrated Development Environment))を使うことにした。いろいろなIDEがあるが今回は新進気鋭のVisual Studio Code(2016/08/15 v1.4 Microsoft製OSS)を使ってみようとインストールしてみた。インストールは凄く簡単でだった。

余談だが商用のIDEも検討してみたが、だいたい300、400ドルもするので断念した。これだけの価格差の価値のある機能なのかわからずチュートリアルのためにそれだけの出費をすることは納得できなかったので諦めた。（グループワーク機能や各種フレームワークへの対応が充実しているように感じたが、チュートリアルそこまでの機能は必要としていない）

node.jsの入門本のチュートリアルをやってみるだけなので、とりあえず20行〜30行ぐらい編集できれば良い。なのでエクステンションはまったくインストールせずにそのままとりあえず使ってみた。４、５年前にはEclipceをPythonの為につかったことがあるが、そのときよりもかなり進化しているように感じた。（Pydevってエクステンションをインストールした記憶がある）

まずチュートリアルの為の簡単なhtmlを作成しておおっと思ったことは。

1. 入力補完がずっと進化しているような気がする。
1. カッコ(){}の補完が便利。
2. タグの候補が2,3文字入力するだけで表示される。（タグ以外の文字列も補完してくれるのかな）
3. Tabの段落下げをかなり自動でやってくれる。
2. Terminalが内蔵されているので、エディタ内で完結できるので良い。
3. ファイルブラウザ（エクスプローラー）がデフォルトで内蔵されている。
4. 思ったよりずっと軽かった（Eclipceはかなり重かった気がする。昔いた現場では現場ではプログラマーは、ロースペックのPCでEclipceでJava開発をしていた。機能はともかく重くてしんどかっただろうなあ。）

まだまだ使いこなしていないが、いろいろ便利なんだろうな。手慣れたプログラマーにとっては基本的な機能でも、おじさんの手習いとして使うには凄く感動した。

Macにおける仮想化環境（VirtualBoxとParallels Desktopの簡単な比較）

最近Macを買い換えたので、移行アシスタントを使わずに新しいMacに一からソフトウェアをインストールすることにした。

旧Macでは、ちょこっとした仕事にOfficeを使う為、Parallels Desktopを買ってその仮想環境にWindowsをインストールして使っていた。ソフトウェアの見直しに当たってParallels Desktopを使い続けて課金するのもなあと思い始めた。よってかつて使い慣れたVirtualBoxに戻ることにした。そこでとことん使い倒しているとはいえないものの、両者を簡単に比較してみる。

Parallels Desktopの良いところ。

1. （おそらく）パフォーマンスが良い。Macbook Airの1.7GHzで32bitWindows7および10がキビキビ動いていた。バリバリ3Dとかでなければ上記スペックでもゲームで遊べていた。Officeももちろん普通に動く。
2. Guest OS（特にWindows）への対応が早い。
3. 設定とか全然考えずにファイル共有とかクリップボード共有とかが出来ていた。

Parallels Desktopの良くないところ。

1. メジャーバージョンアップ（MacOSのメジャーバージョンアップとタイミングはほぼ同じ。）ごとにバージョンアップの費用が五千円くらいいる。（バージョンアップをしないという選択肢もあるが、最新OSにだんだん対応しなくなっていく）
2. なんか自社製品の広告が時々出てうざったい。（たまにだが）
3. 設定は至れり尽くせりなのだが不要なエイリアスとか勝手に作ってくれたりする。
4. クロスプラットフォームじゃない。（これは結構大きいかも）

VirtualBoxの良いところ

1. ただ（USBまわりの機能拡張を入れると完全OSSではないが無料）
2. クロスプラットフォーム（作った仮想環境を別のPCに持っていける）

VirtualBoxの良くないところ

1. 新しいMacbook Proでは試していないが、過去の記憶ではゲームとか描画系が厳しかったのでゲームとか無理（と思う）
2. 一時期オラクルがサボっていてアップデートが滞っていた気がするので、将来的に不安。
3. 細かいところまでの設定が厳しい（Xubuntu16.04のインストールでは結局サウンドドライバ周りは切った）。HOSTとの共有フォルダとかは自分で設定が必要（その方が良いケースもあるが）

よって今回は、お金とクロスプラットフォームを取ってVirtualBoxにした。

あとOffice365を使っているので、Mac版の最新Officeをインストールできたのも大きい。

余談だがOffice365マジおすすめ。昔は互換性が悪いという話も聞いたが、今のところ問題ない。