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

2015年2月の記事

良い名前を付けようじゃないかっ!

「良い名前を付けよう!」

...といきなり言われたら、誰かに子供が生まれるから名前を考えようってことか??
みたいな想像をしてしまいますが...。

IT業界において「良い名前」と敢えて言う場合は、まあ「プログラムのソースコード上の命名規則」を思い浮かべるのではないでしょうか。

12月の定例会で行ったコンテンツ群(「クソコード撲滅!」)に関連して、参加者から「クラスとかメソッド、変数名とかの名付けのワークショップ的なものをやってみたい」という意見が出たので、「はい!、じゃあ決まり!!」ってんで、2ヵ月後の今回(2/20の定例会で)実行に至ったってわけです。

「名付け」と言っても範囲は広いのですが、そもそもが「クソコード撲滅」から派生しているので、必然的に&実質的に「ソースコード上の命名」に絞りました。

...と簡単に言ってみても、まだまだ範囲が広過ぎる...。

そもそも言語は?

これはまあ、社内的にも現状で全員が習得済みのJavaとPHPに絞られるのかなあ、と。
(未だRubyistは少ないし、C#習得者は多いんですがアクティブな案件が無いし...)

で、クラス名?、メソッド、パッケージ、変数?、前提とするフレームワークは?、とか、分類し出すと切りが無い...。

かと言って、事前に条件を限定してしまうと活発な意見交換の妨げになりそう...。
なにより、司会側でスコープを限定してしまったら「やらされてる感」が出てモチベーション下がるのは間違いない。

という事で、もう無理やりですが、「思いついたことを書き並べていく」、「過去に出会った(或いは過去の自分?)クソな実例」、「ほほーう!と感心した例」等々をとにかく吐き出してもらい、散発的にでも関連意見が続けて出るようなら、そこでディスカッション

止まったら次の話題を誰かに吐き出してもらう。

出てきた内容は、リアルタイムにマインドマップに書き残して、プロジェクターで写しながら進める(これなら、話題が前後したり、相互に関連性が見えてきても整理し易い!)。

...と思ったんですが、
「リアルタイムにマインドマップ書く」(勿論ソフトウェアツールで)ってのは、
ツール自体をブリブリ使いこなす&文字入力に気を使うだけで、時間効率が悪そう!
(って言うか、私が進行役になってしまったので無理!!(...ゴメンナサイ))

なので、私はとりあえず白板に意見・見解を書き出す
⇒後でマインドマップとして整理して、次回以降に再度ディスカッションする!

...という筋書きを考えてました(実際には、ほぼオンタイムで山内さんがXMindを使ってマインドマップ化してくれてました!!、山内さん有難うっ!!!)。

さて、そもそも何で、今回のセッションを設けたのか?

やろう!って意見が出たから?.....そうじゃないでしょ。それだけじゃない。

・見識・経験の交換をしたい
・良いものは共有したい
・良いもの(或いはパターン)も、悪いものも記録して残したい。 ⇒ 後で使える!
  ・悪いもの(アンチパターン)を記録に残すってのは、結構大切!
・自社で規約を決められる場合のベースに使いたい(案件毎に考えるのは無駄)
・客先案件でも、混沌としている場合には提案のベースにしたい!
・記録しておけばブラッシュアップ出来る!

そもそも短時間(今回はタイムテーブル上で100分)の、たった1回で意見が収束するはずもない。

最初っから「結論」は目的としませんでした(セッションの最初に宣言した)。

Pict2699Pict2700Codename
で、当然のごとく、白板には書き切れず、一回消して書き直すという...
で、消す前に都度デジカメで撮影して(←スマフォじゃないところが俺らしい)、
白板をきれいに消して書き直したのが、写真のような有様です。

この有様を、ほぼオンタイムでマインドマップ化してくれた画像も貼り付けておきます。

さて、予定時間を過ぎても収束の兆しすら見えない(100分の予定が、前のコンテンツが短めに終わったことも手伝って、120分位に膨らませたのに...)...。

これを見た勇者が1名、「デブナイで続きをやりましょう!」と高らかに宣言したのでしたっ!!!

「デブナイ」は「Developers Night」の略

有志が(大抵は定例会の後)に残って、余り堅苦しくならずに(結構ゆるーく)一晩をかけて、好きな人が好きなことをやるって企画です。

以前にも、スマフォアプリの開発、LT(ライトニングトーク)、その他諸々が一晩の間に行われました(終電までの間で可能なセッションに参加して帰宅した人、夜を明かして始発で帰宅した人、様々でした...)。

次回・続報のアップは、前述の勇者が「デブナイ」の開催日時を宣言し、実施した後に行いたいと思います!

乞うご期待!!(...ハードル高くしてるなあ)


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

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

OJTってのはいつまで?

OJTOn the Job Training)って、いつまで行うんでしょう?

「実務を通して、業務・業界内での初期段階の習得を目指す」と定義してしまえば、せいぜい業界入りしてから最初の1~2年、長くても3年程度が目安になりそうな気はします。

しかし、指標は「期間」ではなくて、「習得目的を達成できているかどうか?」(或いは、途中で方向性を変えるべきと判断したなら、その方向での習得要素やレベルを設定し直す)で判断されるべきです。
「期間」は結果に過ぎません(まあ、企業として「稼ぎ手」として立ち上がって貰わなければ困るラインってのは有るでしょうが)。

さて、アスペアでは(大抵の企業でも同様だろうとは思いますが)週報を各人に書いてもらいます。

週報は社員専用のWebサイトに書込み(基本項目セットは定義済み)、社員であれば誰でもが参照できます。
「上長に報告」とかではなく、「全員と一気に共有」です。

で、OJT中のメンバーには、別途で日報も書いてもらいます(これもWeb共有)。

日報の方は特に「日」単位で「振返り」を行ってもらい、少しだけ時間を割いて「今日は何をやった(進捗率はどの位か?)」、「明日は何をやる(予定進捗率は?)」、「何が問題になっているか?」、「その他・雑感(気付き)」という視点で頭の中を整理して貰います。

と同時に、「何をやった」の認識に実態との齟齬が出てしまっていたり、理解できていないかも?、と感じ取れるときは、メンター担当者や周囲からフォローするきっかけにもなります。

また、そもそも前述のような視点で整然と記述が出来る(簡易で社内的なものとは言え、報告文書を書ける)ようになる為の訓練にもなりますね。

口語体ではなく、簡潔に手早くが基本(「雑感」は口語体でも全然OKなんですが)。

で、おおよその進捗率も書いてもらうようにしています。

これは、「【工数】という意識自体を持って貰う」、「タスクの所要工数の見積感をつかむ練習」、「進捗をどんな指標で計るべきか?(これはタスクの性質によって様々です)」を把握して貰う
...そんな目的があります。

当然のことながら、個々のメンバーによって日報提出を求める期間は違ってきます
どんなプロジェクトで、どんなロールで、何処までフォローが細かく得られるか?(得られない方が伸びる猛者もいますが)など、様々な条件でも変わって来ます。
...ので、必ずしも本人の力量と、日報作成の期間とは一致しません。

また、「ファイアープロジェクト」に参画してしまったメンバー(客先に出る場合)で、自社からフォロー出来るメンバーが一緒に行っていないケースも発生します(残念ながら...でも、完全には避けられません)。

そんな時は、日報を書いてもらうことで日々の状況を把握し、対面でフォローに入る・営業的な交渉や調整に臨むことも出来ます(ただ、ファイヤープロジェクトの最中では日報を毎日書くこと自体に無理が生じるので、そんな時は電話報告・調整にもなりますが)。

あ、それから、経験年数の割に非常に多くのロールを同時に持つ結果になったり(アジャイルな開発を行うと、顧客の声を聴く窓口になったメンバーが、そうなり易いですね)。

そんな時は、「共有」という意味と、「混乱・勘違いの早期修正」の為に日報を書いてもらうことも有ります(リアルタイム・チャットも当然使いますが。今は自社環境を使う場合は slack です)。

リモートで、プロジェクト参画の為の準備ハンズオンを行う場合なども、チャットや社員専用サイトの他に、日報を組み合わせる場合もあります(この辺も、対象メンバーの特性次第で個別に判断してます)。

ただ、注意しなければいけないのは(日報に限らないことですが)、「書くと決まっているから書き続ける」こと

目的と効果が有るから、それに応じた手段を取っているんです。
手段自体が目的になってしまったら、無駄以外の何物でもない(とまでは言い切れませんが、勿体ない・効率が悪いのは確かですよね)。

けれども、この「惰性習慣」に気が付くってのはなかなか難しいです。

だからこそ、社員用Webサイトで同時公開・共有したり、チャットのメンバー数を絞り過ぎないようにしたりして、「あれ?、これって違うんじゃない?」って気が付いて&発言してくれるメンバーが出て来るように気を付けています

逆に言うと、そんな指摘をしてくれるメンバーは貴重ですね!

本当に有難いことです!!

「いつから、いつまでがOJT」ではなく、「必要な時に、必要な密度や内容でフォローし合う」ことが目的です。
なので「OJT」って言葉自体が「紛らわしいんだよ!」というか、しっかり用語の定義して共有しとけ!、って話ですね。

うん、うん。 改善します! (あれ?)


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

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

Wicketって知ってるかい?

定例会の中で、山下さんから「Wicket」の概要紹介をしてもらいました。

Pict2690現場実務で使っている状態(プロトタイプ開発で、彼がアーキから要求定義の補助、各種オープンソースの選定利用、実開発の殆どの部分を担当してます!(画面デザイン、RDBの物理設計のみ他の方))で、開発上の実感を聞ける良い機会です。

実際上は、Wicketの他に(山下さんの選定判断により)GoogleGuice、DBFlute、BootStrap、jQuery等も利用するそうですが、その辺との絡みは今回の話ではパス。
(「じゃあ別枠で次回以降にでもお願いしたいかな~」とは呟いておきましたけども...)

Wicket

あまり聞きませんね。

ググれば直ぐに分かることですが、元々は Jonathan Locke 氏の開発により2005年にVer1.0が発表されています。
その後、2007年にApacheのトッププロジェクトになりました。

Strutsが「設定ファイル指向」で動的に開発可能になるようにしよう、という方針であった(その後、更にSpringに代表されるように「設定ファイル地獄」とも呼ばれるヒートアップを迎える...)のに対して、
HTMLページ/各オブジェクトの殆ど全てを、Java言語のクラス/オブジェクトとして扱えるようにした(コンポーネント指向でステートフルな)フレームワークが Wicket です。

Pict2691
JSPのように、「HTML構造中に、タグで括っているとは言え、要はプログラム/制御構造を混在させる」のではなく、HTMLファイルにはせいぜいWicket専用のIDを埋め込む程度で済ませる。
画面デザイナーとの協働作業を効率的に、何度でもやり取りできるように、という点を売りとしているようです。

実際、JSP/*.java/各種設定ファイルの間を繋げながら画面遷移・各種機能の実装を行っていくのは煩雑であり、生産性が(クラサバのアプリに比較して)大きく低下したり、属人性を増したり、スパゲッティどころかミートボール状態の成果物に至る元凶でもあります。

その点、WicketでWebアプリを書くというのは「プログラミングしていても非常に楽しいもの」という感想を聞けました。

現時点(未だ開発途中)で見えているデメリットとしては、概ね下記のような点とのこと。
 ・今までのMVCフレームワークと書き方が違いすぎるので、未知の人には戸惑うことが多いだろう
   ・Swingでのプログラミング経験があると、ソースを読み易いかな?、という感じ
   ・実際、Wicketのクラス名がSwingのそれに準拠して名前付けされている
 ・JavaScriptとの相性が今一つ
 ・BootStrapとの相性が良くない
 ・メモリの消費量に不安がある (BtoCのような開発に耐えられるか?)
 ・(おまけ)DBFluteとの相性が今ひとつ...

実装・テストが進んで、各種負荷テストなども行った時点で、再びレポートを聞きたいと思います!

山下さん、有難う御座いました!


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

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

有言実行か?、内緒で実行か?

大抵の会社さんで、社内SNS的なモノ、情報共有・告知系などの機能を併せ持った、社員専用のWebサイトを構築・運用されていることと思います。

アスペアの場合も同様です。

※各人の簡単なプロファイルから、
※業務的な全社共有ニュース、イベント予定、
※社内・社外研修の告知、参加者募集、
※開発業務や研修で得られたナレッジ群を集めたページ(全社定例会で実施したコンテンツ等も含む)
※所属プロジェクトの概要&顛末&振返り内容など、
※各人の思い思いを好きに書き連ねるブログ、
※就業規則のような、ほぼ静的なコンテンツ
※等々.....

これらの他に、各人が自分で作成した、自身の計画や目標なども公開・共有しています。

※キャリアプラン(概ね10年をスパンとして設定)
※MBO(Management By Objectives);1年分の目標設定
  ・全社目標とリンクした設定(1つ以上)
  ・個人目標(キャリアプランとリンクした内容)(1つ以上)
  ・自己啓発(必ずしも業務に直結する要素でなくて良い;外国語習得とか、体力向上とか...)

これらを共有することで、
ああ、公開しちゃったんだから頑張らないとな...」とか、「あ!、これ目標にしてたんだっけ」とか。
業務が多忙になると(特にロールが高かったり、担当ロール数が多かったり、コミュニケーションや調整タスクが業務の多くを占めたりするとするとなおさら)、
せっかく設定していた目標を忘れがちです。

無我夢中で業務にまい進することで得られるものも有るとは思いますが、やはり「自分が進みたい方向」・「身に付けたいスキル」は意識のどこかに置いておかないと、結果を得るのは難しくなります

その点では、社内専用サイトで公開してしまう!、というのも1つの手段(各メンバーにとってメリットのある)なんじゃないかと考えてます。

ちなみに、前述のMBO(年間の目標設定;実現方法やマイルストーンなども書ける範囲で書くようになってます)は、考課にも適用されます(しかも、考課上の比重が高いです)。

得られた成果(内容によっては「プロセス」自体も含みます)は、主に賞与に反映されます。

ここで、得られた「成果」と書きましたが、何を以て成果(=達成)と判断するのか?
達成を判断する為には、指標とレベルの事前定義&認識の共有(考課する側と、受ける側との間で)が必要です。
が、これもMBOの中に記述するようになっています。

年度初めにMBO設定をするプロセスで各グループの上長や、必要であれば適宜で他のメンバーなどと相談して仕上げて行きます。

勿論、キャリアプランとリンクした目標を達成して行けば、基本給のランクがアップしていくことにも繋がります!

目標設定でよくある勘違い、と言うか本質から外れてしまうケースなのですが、
例えば「○○の検定試験(情報処理系)に合格する」を目標に挙げる...。

これは、望ましい目標設定としては「ある方面の知識的なスキルを一定基準満たす(設定したキャリアプランから導出される内容である)。それを公的な基準で証明する」でなければおかしい。

所属する会社組織の全体方針・指示として「○○の検定試験に合格せよ!」(そのこと自体が会社の収益に結び付き、各個人へも反映されるとか)とある場合には、「合格」が目標になっても良いかも知れませんが...。

通常ならば、「○○の検定試験合格」は、本来的な目標達成の為の指標であり基準の一つです。

手段を目標に据えてしまっては拙いですよね


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

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

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