« 2013年12月 | トップページ | 2014年2月 »

2014年1月の記事

2月の定例会開催日をシフト(デブサミ)

2月の定例会の開催日を、うっかり14日に予定していました(半年を目処に、定例会の実施予定日を決めて、社内アナウンスしています)。

1月の定例会の後で、あるメンバーから「2月の定例会がデブザミの開催日とぶつかっているので、変更できないか?って意見が出てますよ!」と言われました。

おおおおお!?、ノーチェックだったあっ!

Developer Summit 2014」、通称「デブサミ」。

参加の奨励はしていますが、義務化まではしていません。

最新の(或いは現場実践的な)、技術、開発プロセス、ビジネス、いろいろなセッションが有りますね。

壇上に上がった方と直接お話ができたり、共通の関心事項がある仲間から刺激を受けたり、雑談しながらお友達になれたり(Facebookとか)。

とりあえず、2月の定例会は1週後にずらして、2/21(金)に即変更しました
(社員専用Webサイト上の記載変更)

全員宛の、次回定例会の開催予定の告知メール配信前だったので助かりました。
忘れない内に、早速変更した日付でしれっと次回開催日の告知を済ませました。


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

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

誕生日のお祝いと謎の玉!?

1月の定例会の最後に、当月が誕生日であるメンバーのお祝いをしました!

山内さんと渡辺さん、誕生日おめでとう!!
そして、これからも宜しくっ!

Pict2616
.....というわけで、何度かお世話になっている「ブール・ミッシュ」からケーキを調達しておいてもらいました。

渡辺さんが一瞬にして全部のロウソクを吹き消したので、融けたロウが一緒に飛び散るというダイナミックな結果になりましたが、幸いにしてケーキ本体には降り注ぎませんでした。
良かったね~~。
(確か、先々月はケーキ本体にロウが撒き散らされて、ちょっと大変でした...)

Pict2617
さてさて、小さなナイフで一生懸命ケーキを切り分けてくれている、その真っ最中・真後ろで、何やら野郎共が集まって円陣を組んでいる...?

何をやっているのかと覗いて見れば、なんと!、こぶし大の玉っころ、赤・緑・黄色などのボールをコロコロコロコロコロコロ........(以下同文)。

Pict2618
山内さんが始めた「コンタクトジャグリング」がっ!!!
http://www.geocities.jp/yoss_tessy/cjlec/
http://www.youtube.com/watch?v=XsuzjcfRQbM
伝染った(うつった)んです.....。

発病者が2人。
それぞれが違った色のボールを買い求めた模様。
それと、.....どうやら更なる感染者もいる模様で、これから発病者がもっと増えるかも知れません!?

まあ、仕事中に回すのに熱中して働いていないというわけでもないので、実害は有りません。
むしろ、よい気分転換、脳の活性化の効果もあるかも知れません。

手・指の感覚器官・運動に関わる脳の領域は広いので、結構プラスの効用も有るかも知れないですね。

勿論、当人たちは各人各々が好きで、別個に入手して来ているので、あくまでも自由意志(やっぱり感染・発症?)です。

確かに、上手に扱っている人の技を見ると、自分もやってみたい!・出来るんじゃないかな?、という気になって来るから不思議です。

普段から形の無い「ソフトウェア」というものを扱っている(苦労している?)から、余計に「形のある物に触れたい!、自由自在にしたい!」のかも知れないですねえ。

なんにしても、業務以外でも相互に影響し合える関係ってのは、とても良いと思います!  大切にしたいですね。


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

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

自社内サイトに「ステキ!」機能を拡張!

大抵のIT系の会社さんでも(他業種でも概ね?)同様かと思いますが、アスペアにも社員専用のWebサイトが有ります。

ナレッジの共有や、技術系に限らずのネタで非同期コミュニケーションして盛り上がったり、議事録を残したり、あれやこれや...(GoogleApps for Business も利用しているので、目的に応じて使い分けてます。その他のオープンソースともリンクして利用してますけど...)。

同サイトには、あるオープンソースのCMSを利用していますが、各種プラグインが非常に豊富に揃っています。.....が、
.....Facebookで言うところの「いいね!」機能が無いっ!!

類似した機能を持つものは有るのですが、使い勝手が悪いというか、「良い!」旨の投票をしても全然目立たない!
他の人が見ても投票されていることに気が付かない!(書いた本人も同様)

これじゃあ全然、完全に、全く意味が無いじゃないかっっ!!

それだったら、自分達で作ってしまえ!、と言うことで、若手の渡辺君が1人で拡張モジュールを作ってリリースしてくれました!!

「いいね!」じゃパクリそのものなので、「ステキ!」ボタンになりました。

ログイン後のトップ画面に、各種記事の新着一覧が表示されるのですが、その中に「ステキ!」ポイントが赤文字で表示されるようになりました!

効果はてき面ですね~。
「ステキ!」が付いた記事(特にポイント数の高い記事)は、参照数もグンと高くなりました。

うん、いい感じ。

記事毎に、誰が投票しているのか?もポップアップ表示できるようになってます(JQuery使ってるそうです)。
うん、うん、いい感じ!  

ちなみに、この機能作成は、アスペアの5%ルール(Google社の20%には遠く遠く及びませんが、「月間基準稼働時間の5%を自由なモノ造りに使って良い」という制度です)内で作ってくれたものです。

ありがとー、渡辺君!! (*^ω^*)ノ彡

一層楽しく使わせてもらうよ~。(自社内ネタで済みません...)

Pict2612


あ、さらに付け加えると、昨年末12月に入籍したそうで、共済会からしっかり結婚祝い金もゲットした渡辺君でした。


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

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

インクリメンタルに開発・リリース

現在、全社の1/3以上のメンバーが請負・自社内開発を行っています(事業企画部の自社企画プロジェクトのメンバーが部分的に兼任しているので、延べ人数では全社の約半分の割合になります)。

全体としては大きな案件(群)なので、ステップに分かれたり、フェーズに分かれたりで、社内でもサブグループを構成して、インクリメンタルな開発に対応させて頂いています。

今時のプロジェクトらしく厳しい納期要求で、しかも「全くサラの新規開発」ということではありません。
既にWeb上でのサービスが活発に活動しており、顧客にとっては重要なビジネス基盤になっています。
既存のシステムへの機能拡張と共に、旧資産の問題発見(地雷や不発弾を、意図せずに発見してしまうことがあるので...)・場合によってはその解決・整合性の確保なども仕事に含まれます。

そんなこんなでバタバタと始まり、メンバーが続々と増えたプロジェクトなので、「全体概要がどんなもので、一体どんな役割分担で、どんな進め方をしているのか?、今はどんな状態なのか?」が社内共有されていませんでした。
Pict2615
...ので、同プロジェクトの長として佐藤(忠)さんに、(導入時点は事業開発部が関わったので青柳さん(画面左端)からも)社内発表をして貰っているところです。
(画面には、たまたまソースコードの一部が映っていたので白抜きにしました)

受注規模が大き過ぎる場合は、ウォーターフォールでの開発は危険過ぎます!
ので、弊社からフェーズを分けて開発することを提案し、数フェーズに分割開発・納品することで顧客合意を得られたプロジェクトも含まれます。
(開発プロセス的な面での望ましい・希望する方向と、契約・営業面を同期させるのは現実的になかなか難しいものですね...)

顧客側の発注習慣がウォーターフォール前提の一括見積・一括発注である場合には(話題に出しても全く受容れられない場合には)、短いサイクル(2週~1ヶ月程度)での顧客の巻き込み・開発スコープの決定・動作検証などを望むのは無理です。

ので、せめてフェーズを比較的短く分割して、リスク・コストの肥大化を防ぐ方向に動きます。

しかし、この辺が難しい...。
顧客側での受入れ・検証フローが非常にガッチリした(工数も時間も掛かる)ものだと、フェーズ分割が逆に開発側の首を絞める結果にもなり兼ねません。
大量のドキュメントを要求される場合も同様ですね。
(しかも、納品ドキュメントに対するレビューが極めて厳しい場合は、更に輪をかけて厳しい結果になります...)

当初は「かんばん」方式を採用していたのですが、顧客とのオンライン上での各種の情報共有(タスク毎の細かな進捗状況の共有も含め)を求められたので、結局、Redmineに全ての情報を集約・管理することになりました。
(Subversionとの連携を含みます)

二重管理になってしまうのは意味が無いので、「かんばん」は運用中止になりました。
アナログ・ツールのメリットを失ったのは非常に残念です.....。

しかし、前述のサブグループ全体を含めた朝会、更に、リスクやコスト問題の早期吸収の為の夕会(どちらも数分~10分の範囲内)は毎日行っています。
ここで個別の問題が明らかになった場合には、この後に別途の個別打合せなどを行います。

フェーズ毎の「振返り」も行っているので、より生産的で快適な開発が行えるようになっていければと思いつつ見守っているところです。

プロジェクト的には厳しい部分もあるのですが(特に納期)、メンバー間はワイワイと冗談やボケ・突っ込みなどを交えて、結構楽しくやってます!!


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

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

Gitの導入・運用事例を共有

新年早々の全社定例会は1/10(金)に行いました。

今回は、山下さんから実務ベースでの版数管理ツールの設定・運用のお話をしてもらいました。

それまで複数の版数管理ツールを使用していた大手顧客が、全社一斉にGitに置き換える!!、ということになりましたが、まあ実際上は移行時間が必要になるわけです。

Gitの特徴を活かす、と言うよりも、それ以前の運用イメージからのシフトで版数管理業務がまごつかないよう、利用者には出来る限り「何も変わっていない」ように見せる、というポリシーを採るところもあるようです。

Pict2614
ウチのメンバーが入ったプロジェクト内にはGitに詳しいメンバーがいない。
山下さんが興味津々の姿勢を示し続けたところ、必然的な流れでGit環境構築・ポリシー策定を担当することになりました。

彼自身もGitを利用するのは初めてでしたが、そこは立ち上がりの早い山下さん。

用語が独特で混乱しやすいGitの考え方・運用方法を早期に把握し、環境も整え、ポリシーも策定しました。

各メンバーにGitスキルを要求せずに済むように、版数管理フローを統一し、簡便な操作説明を作成しました。
それでもメンバー内から「?」が生じた場合には、問合せ対応も行いました。

「Git」

そもそも、なんて読むの??
 ⇒これは、「ギット」だそうです。「ジット」じゃないんだな...。

リポジトリの管理方法が、中央集中ではなく、分散共有になる(原則として各開発マシン全てがリポジトリのコピーを保持する)とのこと。
有る意味、リポジトリのバックアップが、そこいらじゅうに出来るということになる。

但し、分岐した各人ローカルの枝版を持つことが出来る。
「中央のサーバー」という考え方が無いので、ネットワーク上に常にオンラインでいる必要は無い。
自分ローカルの枝版ソース(或いは文書)は自由に編集できる。

この、枝版の生成・その後の作業・枝版の消去が手軽に(処理自体も軽い)出来るため、版数管理に煩わされずに、快適に開発に専念することが出来る。
(内部の仕組み的に、版数の差分情報のみをやりとりしている為に軽いらしい)

但し、共有ソースの編集結果をローカルではなく公開する際には、競合の管理が必要になる場合がある(当たり前)。
そのような場合の支援機能も充実しているのだが、知らずに不効率な運用を行ってしまい兼ねないので要注意だそうだ。

版数の運用・管理に非常に自由度が高く、ポリシーさえしっかり立てていれば強力なツールになる(言い換えれば、ポリシーを誤ると(或いはノン・ポリシーだと)大変なことになる!、という事なんでしょうね...)。

今回立てたポリシーでの運用の反省を踏まえて、次フェーズの開発時のポリシーを変更したそうです。
その変更が功を奏するか否か?
運用を進めてみないと分からない、ですね。

Gitを実務で利用した経験のある者は、全社員の半数を割っています。

プロジェクトの特性により最適なポリシーは違ってくるのでしょうが、Gitの基本特性やポリシー策定ノウハウは、今後とも共有して行きたいと思いました。


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

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

« 2013年12月 | トップページ | 2014年2月 »