« 2015年3月 | トップページ | 2015年5月 »

2015年4月の記事

調査しました;JSテーブル群

要件定義支援からアーキテクトまで務めている山下さんから、業務上で必要になったJavaScript系のテーブルライブラリの選定・調査・評価結果の発表が有りました。

Pict2714Webアプリだからと言って、「ネイティブアプリよりも使い勝手(UI)が悪いのは仕方が無いんですよー」なんてのは遥か昔の話。

見た目も操作性も、実行速度(反応)も、ネイティブに劣らない(現実的には「気にならない」と言うべきなんでしょうけれど)ことが普通に求められています

見た目上でWebページの遷移を伴わずに動的な処理を行いたいという要望も根強いものが有ります。
そんなUIを構成する要素の中に、古くからあるモノで、ユーザーにとっても開発者にとっても身近なモノの1つに「テーブル」が有りますね。

Pict2715行と列で現される、2次元の表です。
列毎に並び替えを行ったり(昇順・降順)、入力を行ったり、フィルタリングを行ったり...

これを自作するのは大変(不可能ではないにしても工数が掛かる)。
既存のJavaScriptライブラリは無いものか?

これはもう、当然の如くに存在するんですねー!
それも、幾つも、幾つも。

機能も様々、有償/無償、ソースの公開の有無、性能・消費リソースは実測してみないと分からない、安定性は耐久テストをするか・試験運用などでじっくり付き合ってみないと分からない...。

Tablesで、幾つかを選択して比較表にまとめた上で、性能評価試験を行ってみたとのこと。
当然ながら、ここに挙げられているモノが、現時点で存在する同機能ライブラリの全てという訳ではありませんが、概ねネット上で検索してヒットする主要なモノを対象とするのが必然的な選択手段でしょう。

で、調査・抽出の上で、更に候補を幾つかに絞った上で処理時間を実測した結果.....、
jqGrid」(http://www.jqueryhelp.net/を採用!!、と決まりました!

無償(商用利用もOK!)の割に最も高性能を叩き出しましたし、今回の必要機能要件を十分に満たしています!

折角なので、今回作成した比較表の内容を共有させて戴きます。
誰かしら・何がしかの参考になれば幸いです。


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

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

我々にとっての「ナレッジ」って何だ?

4月の定例会は17日(金)でした。

前回の定例会で行った「ゲームストーミング」から、「そもそも、ナレッジって何だ?現実的に我々にとって有意義な定義は何なのか?)」って話題が持ち上がりました。

Pict2706
...で、それじゃ次回の定例会でそれについてディスカッションしてみようじゃないか!
ってことになって、今回に至ってます。

前回に引き続き、三文字さんが司会・進行、と言うかファシリテーター?!

Pict2710
「ペルソナ」を想定することで具体的な視点からアプローチしてみよう
(白板の上では、自社内の(丁度、業務都合で遅れていて未だ席に付いていなかった)「徳田さん」をペルソナとして仮設定してますね...)という流れ。

しかし、出席者達が思い描いていた展開と違っていたのか、「ペルソナ」を設定して思考するというパターンに慣れていない為なのか?、意見が活発に出ません。

そこで、三文字さん。
進め方を変えて、「ペルソナ」というキーワードは使わず、要は各人自身が思い描くペルソナ(大抵は自分自身かな)が「どんなナレッジなら利用するか?」という方向からのアプローチに切り替えました。

これで、通常のディスカッションの勢いが出て来ました!!

以下に、出てきた意見を要約します。

どういうナレッジだったら利用するか?
  ・寿命の長いもの
  ・英語の最新情報
  ・調べて出てこないこと
  ・実際にやってみた結果、成果物、チェックリスト
  ・アプローチ、感覚的なこと、経験・判断プロセスの方が知りたい(←暗黙知ですね)
  ・仕組み、体制、決断した理由、経緯(←プロセスや背景に潜む暗黙知?)
  ・生々しい情報(←具体例)
  ・作業など効率のよい方法
  ・表面だけでなく途中の試行錯誤も知りたい(デザインなど)(←これもプロセスに潜む暗黙知か)
  ・完成形だけでなく、途中で没になった裏図面。(←ボツや失敗事例にナレッジが多い!)
情報が多くて何が有効かわからない。
  ・その中から選択した経緯を知りたい。
  ・プロセス、過程、結果、テーマ
得られたナレッジを外部公開して世間の荒波にもまれるのも良いのでは?
  ⇒調査結果とか、まとまったモノは幾つか出させて戴いてますが...。
QA用の掲示板が欲しい
  ・自社内でも質問を出せる状況にしたい!
調べ方自体をが知りたい!

以上を踏まえて、ToDoとして下記のモノが挙げられました。

⇒SlackにFAQチャンネル、knowledgeチャンネルを作成する!
  ⇒週報を待たず、即時性のある発信・記録手段
  ⇒スマフォアプリも存在し、新着通知機能も有る
⇒週報に苦労したことの詳細を書く!
  ⇒プロセスなどの共有に活用
⇒事前に話題を決めず、定例会の中で話題を出してディスカッションするというパターンも有用では?
  ⇒次回は、今回の話題フォロー、&適宜で新たな話題出しを行う!
  ⇒箕方さんが次回ファシリテータ。(三文字さんが指名しました!)

    ⇒次々回以降は、当日のファシリテータが指名していく

今までも適宜で散発的に行われていた事ではあるのですが、明確に手段とフローを具体化&共有したことに意義が有ると思います。

どんなふうに回るか分かりませんが、先ずはやってみましょう!
何回か回してみて、振返って考え直す・改善して行けば良いのですから!


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

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

JJUG(2015)に行ってみた!

去る4月11日に「JJUG」(Japan Java Users Group2015 が開催されました。
http://www.java-users.jp/?page_id=1647

ベテランだけど好奇心や向上心豊かで勉強熱心な忠さんと連れ立って、小障子さんも参加。

昨年入社した速形さんもタッチの差で遅れて入場。

知り合いの方と挨拶・会話していた忠さんには声を掛けそびれてしまった様子...。

...という事を、自社内の週報(社員専用Webサイトで同時共有)で後日に知りました。

「上長に提出する」週報では不可能なコミュニケーションが「Webサイトでの同時共有」ならば可能になります(大分以前のアスペアでは、やはり「上長への報告」パターンでした...)。

勿論、「上長に、或いは特定対象者にローカルに連絡を取りたい」場合には不向きでしょうが、それは別枠で、別の連絡手段を取れば宜しい。

で、速形さんが、その週報の中の「トピックス」欄(アスペア週報の標準項目です;何も無ければ「特に無し」で構いません)の中でJJUG参加におけるレポートを含めてくれました

全般的に、速形さんの週報(現時点では日報も書いてくれている)は情報満載で、読む方も実は結構楽しみにしてます

しかし、本人にとっては重荷じゃないのかな??
...と気になっていたので、先日の考課面談の時に聞いてみました。

「思いつくまま書きたい事を書いているので、特に重荷とは感じていない...」とのこと。
使われている語彙が比較的豊富だし、表現の幅も広い(堅かったり・超崩したり)ので、「ああ、言語能力が高いんだな」と感じてます。

この週報にも、「ステキ!」投票がたくさん付いていました
そんな週報の中から、レポートの締めの部分だけ転載させて戴きます。

「総評:
参加して良かったです。色々圧倒されました。まさに「百聞は一見にしかず」ですね。「星屑の砂時計」が頭に流れました。」

ところで、JJUGに登壇した久保雅彦さん(DBFluteの設計・制作者)と、お仕事の関係上で忠さんは面識が有ります

速形さんのWeb週報に対して、忠さんからフォローが入りました。

「JJUGは素敵なイベントですね。
フレームワークを設計している人の思想を直接聞けるなんて、なかなか無いですから。

うちらは最前列で聞いてました。
つーか。発見したなら声掛けてくれても良かったのよ(笑)
あの後、久保さんと関係者の方々と少しお話しもしましたし。
(紹介できたのに~)」

多くの業界人に(良い意味で)広く知られる方々とほんの少しづつでも顔繋ぎが出来る事は、後々で何処でどんな広がりに繋がるか分かりません!

少なくとも、自分の中に「こんなに凄い人がいる!」という1つの指標が残り、自身への刺激となり続けます。 ←これだけでも今後の自身にとって十分に有用なインパクトが有りますよね。

あ、ちなみに、小障子さんからの報告(速形さん週報へのコメント)を1つ紹介させて戴きます。

「講演前に久保さんが指慣らしでやっていたタイピング、思わず見入ってしまいましたw」

速形さんコメント:
「本当に、あれだけでも見に行った価値があると言って過言でないくらい鮮やかなタイピングでした。」

小障子さんからは、
「DBFluteフェスというのも開催していますので(年1回ですが)、興味があれば行ってみるのはいかがでしょうか。
去年の開催は、秋のJJUGの翌週11月22日でした。」

...との情報提供も有りました。

オンラインとオフラインがシームレスに(言い過ぎか?)リンクして、
連続していく、枝分かれしながら広がって行くってのは良いものですね


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

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

リモートでのソースコード談義。

とある都内の顧客先で、常駐で開発作業を行っている速形さん(昨年春に入社)から、毎日・日報を社内専用Webサイトに上げてもらっています
これは、同顧客先に対してアスペアからは、結果的に1人で参画することになってしまった為です。
ほぼリアルタイムに近いタイミングで、全社共有&適宜でのリモートフォローが可能になるからです)

また、自身に関して、日々の振返りにより得たこと・気付きの誘発という目的も有ります。

その速形さん、連日チケットベースで開発タスクを消化している(ソースコード・レビューなども含めて)のですが、あるタスクで「なるべく速く動作して欲しい」との要望が有りました。

実際の仕様を見ると、処理対象となるデータ件数が決して多くないので、どう組んでも大差は無いとも思えたのですが、「この機会に試してみよう!」という事で幾つかのサンプル・パターンでプログラムを組んで処理速度の計測を行ってみました
決して暇だったわけではないのですが、調査時間は限定的な量なので着手したようです)

で、その結果を社内サイトに共有してくれました
(注:決して「業務ロジック」を掲載したわけではありません。あくまで単純・汎用的なサンプルコードを元にしたものです)

概要だけ、下記に転載します(原文のまま)。
 実験環境
  OS : Windows 7 x64
  CPU : Core i5 2500K (割り当て1コア、1.6GHz固定)
  PHP : 5.5.23 x32
  やってる(やりたい)こと
  ① 配列の宣言($datas = array();)
  ② 2次元配列の宣言($datasの中身にarray()を代入(列長の決定))
  ③ 2次元配列の初期化($datasの中身の宣言array()に(行長の決定))
  ④ 2次元配列に値の代入
  ⑤ 2次元配列の値を出力

その結果に基づき、考察や疑問も一緒に書いてくれました

さて、上記の書込みの翌日に、産休・育休から復帰直前のJinさん(数名グループ開発の、リーダー、要求定義、アーキ、RDB関連もチューニングまで含めて丸っと任せられるデキる技術者です!)から(サイト上に)フォローメッセージが入りました

サンプルコードの処理内容の分析と、評価の為の改善点の指摘、補完的な追試とフォローコメントを書き込んでくれました(下記に、まとめ的なコメント部分のみ転載)。

「配列宣言は速度としては誤差の範囲のようですが(今回のサンプルコードの範囲では)、宣言しないと予想外に再利用されて、結果が変わってしまうことがあります。
特に、他の人が作ったソースに改変をする場合など、定義した変数名が、後のほうで初期化せずに使われていた変数名と重複していた、などということになると、バグを産みます。
なので、(極端な場合を除いて)速度は気にせず必ず宣言することを原則としたほうがいい、と言えそうです。」

ほうほう。

で、このようなサイト上でのやり取りに対して、「いいね!」と感じた書込みには「ステキ!」を投票することが出来る仕組みになっています(若手の渡辺さんが、オープンソースのCMSに拡張を施してくれた機能です!)。

オリジナルの速形さんの書込み、フォローしたJinさんの書込みに「ステキ!」が多数集まりました
良い感じですね!
まさに「ステキ!」です!!

その後、Jinさんからのフォロー発言を受けて、速形さんの方も翌日に反応しました!
Jinさんから指摘のあったサンプルコードの問題点を修正し、再度・計測&サイトに集計値をアップ(&感謝の言葉を下記に転載します(原文のまま))。

「コードレビューまでして下さり、ありがとうございます。
大変勉強になりました。
再度実験してみましたところ、全くもって仰るとおりでした。
今後ともきちんと宣言するよう気をつけたいと思います。」

更に、同日中にJinさんからも反応有り!
下記に原文のまま(一部省略)転載します。

「確認と再試行、元記事の修正まで、丁寧にありがとうございます!
そして、あれ、私がやった結果と違う…w
(差異の説明:省略...)。
なんで違うんだろう。単純なコードの違いならいいんですが、メモリ割り当ての違いで、とかになってくると嫌ですねw
(中略)
$datas[][] = 'hoge';
でいきなり二重配列が出来るとか、array_fillの処理内容とか、私も勉強になりました。
また何か実験したら、結果が予想通りでも予想外でも、ぜひまたアップしてください!」

この後は、速形さんから感謝の書込みと、反省点・今後の留意点などが挙げられていました。

日単位にはなってしまってますが、リモートでフォローのキャッチボールが出来るってのは素晴らしいと思いました!
「ステキ!」を投票してくれる仲間がいることも嬉しいですね。
(あ、ちなみに、よりリアルタイムに近いフォローの為には slack を使ってますー!)


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

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

先輩から後輩へ・巡る巡る…

アスペアの年度は、毎年3月1日から、翌年2月末までです。
多くの日本国内企業が4月1日からであることを考えると、微妙~にずれてますね。
これには特に深い理由は無い(はず)です。
たまたま、1991年3月1日にアスペアが起業されたということでして。

...なので、ここ暫くは、2月末で2014年度が終了した後の年度末の人事考課の季節でした。
(まだ完全には終わってませんが...)

現在のアスペアでは、未だ客先常駐での開発作業割合が高い(徐々に下げるように動いていますが)ので、常駐先ごとに「グループ」を設定して、その中でグループ長を設定します(大抵の場合に、上級職者が1人以上は含まれるので、グループ長を務めてもらうのに支障はありません)。

で、現場での稼働状態を一番身近で見ているグループ長に、考課面談をしてもらってます提出文書(オンライン)や考課文書、面談の基本的なパターンや評価のガイドラインは全て公開・共有しています)。

考課面談の結果は考課者内で事前にオンラインで共有し、グループ長や相当層の全メンバー&社長も顔を突き合わせて、判定水準のバラつきや不公平感、解釈・認識のバラつきが無いようにしています
考課システム自体の問題点があれば、この中でも話題に挙がります(改善策は別の機会を設けて検討していきますが)。

今回の考課面談では、筆者自身が面談を担当したのは4名(作業現場がばらけてしまったメンバーに対して、私が一括して対応しているのです)

単純に「人事考課」という目的に限定せず、色々な話もするのですが、
その中で、印象に残った事柄を1つ書きたいと思います

昨年に、専門学校を卒業してから入社した速形さんとの会話の中で

彼は、アスペア入社後に社内研修を約2ヶ月間行った(IT系専門学校の卒業者だったので、かなり短く済みましたが...)後に、自社内持ち帰りでの請負開発プロジェクトのメンバーとして途中で参画しました。

チケット駆動の開発で、余り大きな要件単位ではなく、インクリメンタルな開発プロジェクトでした。
比較的、ドキュメント量(&質も当然!)やエビデンス量を求めるお客様だったのですが、朝会は必ず実施
稼働時間数が増えて来てからは、夕会も行い、問題やリスクを早めに吸収するようにしました。
要件単位の開発終了時点で、振返り(KPT:Keep、Problem、Try)も行い、次回の開発単位(イテレーション)へのインプットとなるようにしました。
要は、よく言われる「アジャイル風」ですね。
当然のことながら、Tryは次のイテレーションの中で実施していきます。

で、上記のプロジェクトが一通り収束した後は、数年先輩のメンバー1名(池田さん)と一緒に「あるプロジェクト(終盤案件)」に参画しました(客先常駐型です)。

で、これが......
残念ながら、入ってみたら、俗に言うデスマーチ・プロジェクト.....
「絵に描いたような」とは正にこのこと?!

当然のことながら詳細は書けないのですが、参画早々に1日の稼働時間数が10~12時間と一気に上がりました。
(直前プロジェクトでは、原則定時になるよう各種の情報共有&最適化の工夫・適宜でのタスク再配分を行ってました)

しかも、系統だった情報も無く(有っても正しくない)、そもそも情報が集約もされていませんでした。

経験の少ない速形さんとしては、何をどうして行ったら良いのか、さっぱり分かりません。
とは言え、指をくわえて待っている訳にもいきません。
情報を抱えている人に聞取りに行く
でも、情報を抱えている人って、デスマーチの中ではボトルネックになっていて、極超多忙
こまごまと質問や確認をしてくる速形さんに対して、良い感情を持てないのは仕方が無いのかも知れません...。

そんな中、「とにかく、このプロジェクトの中で一定の役割を任されたのだから、何とかしなければ!」と奮起した(危機感にドップリ浸かった?!)池田さん

先ずは周囲のメンバーとの人間関係を円滑にすることで、情報の入手は勿論のこと、提案やある程度の調整も可能として行きました。

時には、速形さんに徹夜作業の依頼が飛びそうになるのを防いだり池田さん自身の単純な自己犠牲とかではなく、妥当性が無いことを説明し認識共有をしてくれた!)。
次々と襲いくる危険から、池田さんが速形さんを守ってくれました(必要な時にはフォローし、孤立しないように声を掛け続けてくれました)

池田さんが周囲との人間関係を醸成する上で行った行動とは?、.....
一緒に昼食に行ったりとかも有りますが、夜・「周囲のメンバーに人数分の缶コーヒーを買って来て、配りながら軽く雑談して一服入れてもらいつつ、気分が張り詰める・自己収束するのを改善した」らしいんですね。
速形さんが教えてくれました。

それと、とても感心していました!;「あの状況の中で、池田さん、どんどん周りの人達と仲良くなっていっちゃうんですよね...、凄いなあと思いました!」

プロジェクトが「孤立した個々人の集合体」と化してしまったら、上手く行くものも行かなくなります
アジャイル系のプラクティス群の中で共通して言われることの1つとして「十分なコミュニケーション、相互理解」が有ります。
まあ、これはアジャイル系プロセスで進めるか否かとは別に、必要な前提事項だとは思いますが。

で、この「缶コーヒー」作戦。
実は池田さんが自ら考えて始めたものではなかったのですね

「個々人を孤立させない」というポリシーと共に具体的な行動も、
更に以前のプロジェクト(デスマーチではないが、かなり近い状態だった)で一緒だった、当時サブリーダーを務めていた
徳田さんの考え方・行動に感化されて、見習っていたのでした

(こちらの話[↑]は、私が池田さんと面談している時に聞いた内容です)

1人のメンバー(ここでは徳田さん)の持つポリシーと普段の行動が、後輩に、後輩の後輩に、脈々と受け継がれていく

ああ、良い形になって来ているなあ

良いメンバーに恵まれているなあ、と、改めて思った出来事でした


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

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

産休・育休から復帰します!

2014年6月下旬、出産・育児の為に休暇に入ったJinさん(旧姓)。

平成14年に、新卒でアスペアに入社しました。

あ、ちなみに、Jinさんと同期で入社した青柳さんは現在のアスペアの社長です(2015年1月から)。

さてさて、無事に出産を終えて、お子さんもすくすくと育ち、首尾よく保育園への入園も決まりました!
(ここ[↑]が結構な難関なんですよね...)

それでは現場復帰
リーダー格でアーキテクトとしても稼動でき、RDBMS(特にMySQL)関連スキルも高いJinさん。
今までに関わってきた顧客からも、自社内メンバーからも、何処からも引っ張りだこです!!

さーて、バリバリ働くぞーっ!!!

.....てな訳には行きませんよね、現実は。

もちろん、ご主人の理解・協力を得ることは前提として、ある程度は実家のお母様の協力も戴けるようですが、お子さんに何かがあれば(発熱、怪我、その他諸々)先ずはお母さん(Jinさん)に連絡が入ります。

家事に関しても、ご主人との分担は必要だとしてもゼロにはなりませんね(「主夫」がいればともかく)。

出産・育児休暇として9ヶ月余りでの復帰ですから、ゼロ歳児はいつ何が起こるか分かりません。

幸い、アスペアの町田事務所から近い所にお住まいなので、当然、自社内勤務が最善です。
勤務時間数・時間帯も調整が必要になりますから、自社ならまだ気が楽です。

それから、「現場を離れてから9ヶ月以上、出産・育児に専念していた」状態から「IT開発の現場に戻る」ってのは、それなりのハードルが幾つかあると思います。

特に女性は、身体的にも心理的にも大きな変化を経て来ますので、現場復帰の負担は、男性には想像できない難しさも有るのではないかと想像してます(恐らくは個人差も大きいのでしょうけれど...)。

「技術面での空白期間」としては、それほど長くはないとは言え、案件によって「何をどう使うか?」は違ってきます。

ので、技術面でのキャッチアップ、生活パターン(&体のリズム)のシフト、業務へのリハビリ(?)期間が必要です。
以前にも出産・復帰の社内例が(別の女性で)ありますので、この辺はしっかり確保。

時間拘束も確実性は担保できないので、当面は(お子さんの成長状態とか周りの支援体制次第で)あまりリーダー的な立場は割り当てない、もしくは常にバックアップ側に回ってもらう(役割の複数人数化で)などの考慮をします。

様々な周辺条件が許せば(顧客側の政治的・心情的な了解とかも含む)、在宅での作業も一部は許容できるかも知れません。

さて、それでは「どのプロジェクトにアサインすれば条件を満たせるのか?」。

いまどき、数年単位の請負プロジェクトなんて有りません。
と言うか、そんなでかいプロジェクトを自社に持ち帰れるほど大きな組織じゃありません!(自慢じゃ有りませんがね)

そこで登場したのが......
パパパ・パッパパー(古い?)、「町田ラボ構想」!!

・顧客先で要求・要件を固めてタスク化⇒チケット化し、町田に投げる。
・町田工場で詳細設計・製造・各種テストされ品質の担保された成果物が出来上がったら、顧客先に戻す。
・顧客先で上流&下流(受入れ)担当のメンバーが受け入れチェック(コードレビュー、動作確認等)を適宜で行い、本体にマージする。

これを、今年の3月から開始しています

Jinさんには、4月から前述のスタートアップ/リハビリ等を始めてもらい、5月から本稼動の方向で動いて行きます(「町田ラボ」体制は、逐次増強していく方向)。

また、町田ラボが顧客とする企業さんは当面は1社のみですが、別のお客様にも展開していく方向で考えています。

ので、先ずは当面のJinさんの参画により、ラボ体制独自に必要となるナレッジ群の積み上げ、自社環境面(リポジトリ管理、CI、各種コミュニケーションツール見直しとCIツール連携、その他諸々)の整備・構築等、恐らくやるべきことが沢山あります!

女性に限ったことではありませんが、「子供を儲ける・育てることに負担の少ないビジネス形態」を実現したい!

「言うは易し」ですが、既に走り始めている道です。
どんな曲がり角や景色が待っているのかは分かりませんが、より良いゴールを目指して・信じて、進み続けて行きます!!


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

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

« 2015年3月 | トップページ | 2015年5月 »