社外セミナーとか、参加してますか?

自社内でもワークショップやハンズオン、勉強会などを企画・実施していますが、
やっぱり社外の人と接する機会は大切です!
 
ワークにしてもセミナーにしても、やはり場数を踏んだ著名な方が実施するコンテンツは、質の次元が違う!
ということも実質的にありますし。
 
と言うことで、社内コミュニケーションを中心としたslack(有料コース)運用の中で、
社外セミナーなどの紹介チャネルを設けてます。
(特定個人にお勧めのコンテンツの場合には、slackDMで個人宛に連絡してます)
 
slack上で紹介・広報したセミナー類は、別途Googleスプレッドシートにも情報集約しておき、
広報範囲・連絡先(DM連絡の場合)、参加意思の表明者、実際に参加した人、の情報を記録しています。
 
.....が、
参加者少ないっ!
 
いても、同じようなメンバーが参加し続けてるし、
これじゃあ何の為にわざわざ外部セミナー告知してるんだか分からない!!
 
告知する時は、
どんな人に推奨したいか、費用が掛かる場合は会社負担するケースを増やし、内容の重要度によっては
業務時間扱いにするから!と付け加えたりしてますが、
応募少ない.....
 
このまま勝手にセミナー告知を続けていても仕方が無いので、一度、定例会で出席者達にリアルタイムで聞いてみたことが有ります。
 
以下、その時の意見。
・常連が出席していそうで、場違いになりそうで不安。
・人見知りなので1人では行き辛い。
・意識高い系の人ばかり集まりそうで、自分の不見識が恥ずかしくなりそう。
・時間帯が合わない、予定が立たない(育児の都合で無理な女性エンジニアもいる...)
 
あーーーーーーー........
 
気持ちは分かる。
 
分かるけど、そのままで良いの?
それに、そんなに、もの凄い人ばっかりが参加するわけじゃないよ(企画による差は大きいのでしょうけれど)。
 
ワークショップやハンズオンだと、"恥をかく"(?)ってシーンも有るかもだけど、
セミナー形式だったら関係ないでしょ??
 
筆者(50歳オーバーです...)も、そんなに多数のイベントに参加して来たわけではありませんが、
SCRUM系の終日イベントに参加して、全コンテンツがワーク形式でへとへとになったり(でも超面白かった!)、
特定技術や開発プロセス系のセミナーやワークに参加したりして、自社内で情報共有をしたりして来ました。
 
自分自身の経験の中で、社外イベントに参加して最も有意義だと思えるのは、
やはり "社外の方たちと一緒に小さなチームを組んでワークをすると、いろいろととっても刺激的!"
ということです!
 
これは、どんなに頑張って自社内に情報だけ持ち帰って、対面での共有の機会を持っても(イベント時と同じように、
ワークショップの形を模して実施したとしても)得られない体験感覚です。
 
"1人だと行き辛い.."って人の為に、
"気になったイベント"が有ったら、slackの機能で絵文字を付加できる(facebookの「いいね」ボタンが複数から選べるみたいに)
ので、注目顔のアイコンを付けるようにして、2人以上のマッチングを誘発するようにルール付けしたりとか...
.....しましたが、数ヶ月やってもマッチングは成功せず、
そもそも注目アイコンを付けてくれた人が僅少であるとか、
もう止めるか?  要らないか?  意味無いか、全然ダメか??
 
...と自問自答しましたが、
"当日に行けなくても、開催後にスライド情報や関連記事が公開されるので、追って見ている"って人もいたりして。
 
うーーーーーーーーーーーーん.........
 
自分が出ればいいんだよ!
 
そう。 前から思ってたけど、告知ばかりして、現場業務で多忙で疲れているメンバー達に一方的に参加を求めるよりも、
先ずは自分が参加すべきと思った企画に、自分が参加すればいいじゃん!
(体調の関係で見送ってたんですが、少し良くなって来たし、動かなきゃ変わらないし...)
 
と言うことで、
先ず近々では、
 
 
 
...の2つに申し込みました。(勿論、slackチャネルにも告知済み)
 
ついでに、
"こんなイベントに参加するから、何か質問してみたいこととか有ったら連絡頂戴ねー"と書き込んでおいて、
Googleスプレッドシートに書き込んでもらえるようにしておきました。
 
イベント内容に関しても、主催者側のOKを戴ける範囲で、このブログ上でも共有させて頂こうかな、と思っています。


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

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

パワポの意外な能力を知った日。

筆者はtwitterアカウントは持っていますが、"呟き"用には全く使ってません。
専ら情報収集の為のみです。
 
他には、フォローしている方の発言に"ハートマーク"(いいね!相当)をクリックしたり、極たまに返信したりする程度です。
 
で、フォロー対象に、一応の押さえとして "Microsoft"(support.office.com) も含めています。
 
そのMicrosoftから、先日、"図の背景の削除 - Office サポート"という情報が流されました。
 
おお!、あのパワーポイントに、背景の自動削除機能が有ったとは!?
知らなかった!!
 
早速、手元にある画像で試してみましたが、割と単純で明確に浮き出ている画像だった為か、
見事に"ここを切り取りたい!"と思う部分だけを残して背景が消えました!
嬉しいー!!
 
切り取りたい対象範囲の大枠を指定してやることも出来、微妙に背景と混ざってしまっているような場合でも、結構な精度で
イイ感じに切り出してくれるようです。
 
社内のslack:Tipsチャネルで呟いておきました。
 
(筆者) [13:45]
 おおおおー!、これは知らなかったぞおお! PowerPointでこんなイメージ処理が出来たんかっ!?
 (URL貼付け)
 
すると、10分と経たずに自社内で作業をしているメンバーからのslack書き込みが。
 
△△△△ [13:53]
 uploaded and commented on this image: ○○○○
 画像の中から文字部分だけが残るとおもったんですが、
 "〇〇〇一覧" の "覧" の文字だけの、しかも一部分だけのこりました(泣)
 
同日の数時間後に、結構バタバタとタスク切替の激しい顧客先にいる開発メンバーからのslack書き込みがありました。
 
◇◇◇◇ [18:35]
 編集すれば、大分精度を上げられますね。
 (自動に任せた処理画像:⇒あちこち残念...)
 (ある程度の認識対象を枠指定してから処理した画像:⇒少なくとも素人目には完璧!)
 
バナーとか、イベントやキーワードを示す文字列表示を、目立たせる為にデザイナーさんに画像で作成してもらって使用することも多いのですが、
部分的に文言を変えたい、背景画像だけ置換えたい、とかの要望が生じることが有ります。
 
でも、大抵、デザイナーさんは様々なリクエストや変更指示、関連打合せや作業で大忙しの引っ張りだこ状態です。
 
簡単な画像変更程度であれば、開発チーム側で何とかしなければならなくなる(間に合わない/デザイナーさん倒れそう...)場合も有ります。
デザイナーさんが社外にいる場合(外注さんとか)だったりすると、手続き的にも遅延が増えたりします...、リリースに間に合わないっ!!!
こんな時、JPEG画像になっているデータから、特定の部分だけを切り出せたら有り難いなー...
ってことが結構あります。
(PhotoShop や Illustrator 形式のデータを、ホイホイと操作できる開発者は滅多にいません...)
 
意外と身近なところ(既にライセンスを所有していて、利用もしているツール)に、有用な機能があったりするものですね!
 
ケースバイケースではあるでしょうが、とりあえずの選択肢が増えることで、開発者もデザイナーさんも、少しだけ幸せになれるツール・機能は
本当に有り難いです!


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

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

ギルドワークスのセミナーに参加してみた!

いろいろな企業で有償の各種セミナーを企画・開催しています。
 
アスペアでも、以前はいろいろな有償セミナー(個別だったり、比較的軽量なコースが多数セットになっていたり...)に
参加して来ました(コース紹介の社内通知・配信は筆者が行いましたが、参加は各人の自由意志です)。
 
しかし、どうも内容的に余りパッとしない...。
わざわざ参加する時間を取るなら、その分を自己学習に充てた方が効率的だったり・意義が有ったり、参加価値は微妙?...というケースが多々...。
 
それよりも、DoorKeeperやPOStudy、関連情報に敏い人をtwitter上でフォローして情報を追っていくと、
有益な無償セミナーが多いことに驚かされます("ハズレ"も有りますが...)。
(特にDevLOVE関西など、西日本の動きがとても活発なのには羨ましさを感じますが...)
 
開催時刻も、就業後でも参加可能なように配慮され、19時以降の開始だったり(終了も21時以降になりますが)、
場所的にも23区中心部付近が多く、移動も概ね顧客先から近いです。
 
"これはお勧めだな!"、"あいつとか、あの子辺りには参加して欲しいな..." などと思うコースを、
slack上の"出ようぜ!社外セミナー!!"のチャネル(←名前はウソですが..)に紹介します。
 
・どんな人におススメか?、
・概略どんな内容か?(コース名のイメージが、実質的な内容を反映しない場合が有るので)、
・"業務扱いでOKだよー!"(月報に"勤務"時間として計上して良いよ!)とか、
・参加費用が掛かる場合、"先着何名までは会社負担にするよー!"とか、
いろいろ情報流して参加を促してます。
 
自社内でも、定例会の場を利用してセミナーやワークをしたりしますが、やっぱり同業他社のエンジニア・他ロールの人との交流も
とても刺激的だし重要だと思ってます。
 
現在の業務に必要なもの、これからの数年で確実に押さえておかないと拙いもの、
トレンドになるかは分からんけど楽しそうなもの、
バリバリの技術系、開発プロセス系、ビジネス立上げ系、
色々と、敢えて傾向を分散させてます(メンバーの関心も様々ですからね)。
 
ですが、全員がWeb/インターネットの仕組みを前提としたビジネス開発に関わっている(社内外を問わず)ので、
どこのプロジェクト/プロダクトも多忙です...。
 
業務時間数が必ずしも長くなくても、頻繁な要求・仕様の変更、各種の調整(結果がすぐに出るとは限らない)、緊急対応などで
かなり密度が高く&タスクスイッチが多い・並行度の高い時間を過ごしています。
当然ながら、疲労しますね。
 
やっぱり、現実的に時間的・心身的に幾らかでも余裕が無いと、社外セミナー、とくにワークショップやハンズオンなどは、
面白いけれど消耗も激しいので、意識として参加の敷居が高いのも理解できます。
 
.....このところ、参加率が低い.....
 
うーーーーーん、仕方が無い。
メンバーに対して、無責任に?紹介ばかりしていても埒が明かない。
自分自身が参加できるものは、出来るだけ自分(筆者)が参加しよう!(...健康上の都合もあるのですが...)
 
という事で、早速行って来ました!
 
 
ギルドワークス株式会社・代表取締役・市谷 聡啓 氏が講師として登壇されました。
 
目黒の(株)アカツキの会場はとても広く、カーペット敷きの床には多数の円形クッションが。
後ろの方に椅子も1列並んでいました。
 
筆者は近視なので(度の強い眼鏡を掛けたくない)、スクリーンが見易いように、クッションエリアの中程に陣取りました(靴は部屋の入口に有った靴箱に脱いできた)。
 
同氏はtwitter上でもフォローさせて頂いてますし、同社のWebサイトも拝見していたので、大体の話の流れとしては意外な点は有りませんでした。
 
同氏からのお話は小一時間程度で、後は質疑タイム。
 
内容的には、少なくとも表面的には理解できるけど、"本質的な部分は実践して痛い目見ないと分からんな..." と感じました。
それにしても、質問の中身が濃いのに驚きます。
 
セミナー中でも言われましたが、"自分(達)が、何を分かっていて、何を分かっていないのか?" を知ることが重要!、と。
 
これ、自己矛盾なんですよね...。
CMMIのレベル5(最高レベル)とかでも、"未経験の事象に対しても既知のメタ的な方法論からアプローチし、問題解決が可能" と
定義されていたりしますが、まあ、それと同様じゃないかと思います。
 
で、具体策の1つとして、"ギルドワークスが支援するプログラムが有る"というご紹介。
うんうん、もっともです。
 
いや、一緒にやらせて頂いたとしても、今のアスペアの最高のメンバー集めて対応しないと、吸収効率が悪いと思います。
って言うか、実戦的な要素が何も身に付かない危険性すらありますね。
 
そもそも、アスペア内の現有メンバーが、本当の所どんなことを・どんなふうにしたいのか?
本音の本音を改めて、個別に聞いてみないと分からない気もします。
(今回のお話は、"価値0(ゼロ)→1にしていく" が中心ですから)
 
会社的に、「こうしたい!」、「これが出来ないと生き残れない!」って言ったとしても、
各個人の腑に落ちていないと・インセンティブやモチベーションに結び付いていないとダメでしょう。
 
次回の定例会(9/22)で、ちょっと長めに時間枠を取って、筆者からの話もしつつ、皆から色々と話を聞いてみたいと思ってます。
 


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

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

ヘッドレスブラウザとSelenium3

今回もQiitaネタです。
 
 
そして、今回も社内(協力して頂いているパートナー会社の方とか、フリーランスの方を含む)コミュニケーションツールとして
利用しているslack上で呟いてみました。
 
 筆者 [14:42]
 ▼UI含めたテストでは今後の必須知識!、なのかな...(headless Browser)
 レンダリング無しならテスト速いんだろうなあ...
 (上記URLを貼り付け)
 
 ○○○ [14:42]
 現場(客先)のslackにも全く同じ記事が貼られてた。
 
おおー!、見事に社外にいるメンバーからの即時応答!(DM:DirectMessageじゃないのに...)
 
やっぱり自動テストには関心が行きますよね。
レスの有った"○○○"さんは、自社企画・展開のサービスを開発してビジネスを立上げ中の顧客先で開発作業を支援してるメンバーです。
 
UIの自動テストは、従来だとWebブラウザを起動して画面操作のイベントを起こさせて...と、フツーにWebブラウザの画面が
勝手に(=指定通りに)起動されてパラパラと画面遷移していきます...
が、実画面を表示する時間もかかるので、レンダリング時間も自動テストの中に含まれてしまいます。
 
結果、CI・自動テストは良いんだけど、"とにかく実行に時間が掛かる"のがネックでした...。
実行時間のコストを考えて(勿論、UIテストコード作成・メンテの必要性・メンテコスト・適用価値の総合判断もしますが)
画面展開を伴うテストは範囲を限定しようという現実的な制約というか、技術的な圧力が掛かってしまうケースも多々あったかと思います。
 
UIの自動テストを行うPCのグラフィックス系ハードウェアも高性能なパーツにしたりとか...
でも、ヘッドレスブラウザなら格段に効率が上がるだろうと思われます。
(実証していないので断言できないところが、情けないと言うか申し訳ない所ですが...)
Selenium3も、是非使ってみたい!
 
変更や、様々な部分での"必要と判断される変更"を、躊躇せずに行える(少なくとも自動テストの所要時間を余り気にせず)
状態に置くべきですよね。
(勿論、開発対象の各種特性によって判断や基準は違ってくるとは思いますが)
 
まあ、ヘッドレスブラウザも人間(組織)が作ったモノなので、何処まで信頼できるかは分かりません。
 
しかし、存在を知りながら手も出さず・評価もせず、では、改善の可能性にも至りません。
 
小さなチケットを切ってでも、簡易評価をして環境構築・テスト・評価をしてみるべきだよねーと思います。
勿論、得られたナレッジはslack上(&その他の社内的な手段を使って)で共有します。
 
その為には、評価してもらう時に、メモでも良いから必ず要点を残してもらうこと!、ですよね。
チケットなら、それに紐付いて残るし、別枠でナレッジ集約のページなど(プロジェクト/プロダクト横断的なナレッジ集約ページ)
にも掲載していけますし。
 


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

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

AWS認定試験を受けよう!

Qiita(キータ)
 
IT業界、特にコードを現役で書いている人で、知らない日本人はいないんじゃないか?
と言えるくらい、著名で有用なWebサイトですよね。
 
 
アスペア内でも、IT系の各種認定試験、他に簿記や色彩検定なども報奨金の支給対象にしています(適宜で対象や報奨金額の見直しもしてます)。
受験料も、同一試験に対して最大2回までは会社負担としています。
 
認定試験にパスする:合格するという点そのものには、大した意義は無いと思います。
目的は、"基礎から思想を含めて体系的な理解をする" こと。
 
枝葉末節な "操作の断片の幾つか" を知っているだけではダメで、
体系的な理解をしていることの客観的な証明指標として、"認定試験に合格する" という基準を利用しよう、という事です。
 
認定に合格した後も、2年に1度の更新受験が必須になってますね。
どんどん拡張や仕様変更の為されていくものなので、当然でしょう。
 
現在のアスペア内のメンバーは、現状で一般的に求められる:習得済み・経験済みが望ましいクラウド系の知識が全般的に不足しています。
 
"今さらかよっ?!"、と思われる方も多いでしょうね。
 
今さらなんです.....。
既に遅きに失している感も有るのですが、放置も出来ません。
クラウド系サービスは、大手に限らず様々なサービスが展開されていますが、市場占有率が極めて高いままに堅調で、
かつ弱まるスキが見えないAWSは、必須前提で押さえておきたいベンダー/技術要素です。
 
先ずは試しに、社内のコミュニケーションツールの1つ:slack上で呟いてみました。
 
 筆者 [10:38]
 ▼これは、受験費用も報奨金も会社で出したい、って言うか出すべきだな!
 2017年度・最大のおススメだと思う!
 
 ○○○ [10:41]
 えー!こんなのあるんですね。やってみたいです!
 LPICと同じぐらい役に立ちそう
 受験するか?はさておき、対策本を会社で買っていただいてもいいですか?
 
 筆者 [10:44]
 勿論、OKですよー! "書籍買い放題"制度の対象として、立替宜しく・後日清算・当面は個人保管(=利用)、のパターンでOKです!
 
で、早速、現時点での報奨金水準を直近で一通り見直してくれたグループ長さんにお願いをしました。
 
 筆者 [10:59]
 @◇◇◇ 済みません、お願いが1つ。
 報奨金制度に、「AWS 認定」を是非加えたいですー!
 受験費用だけでなく、報奨金も是非出したい!(現状のアスペアでは出すべき!)
 最低でも2017年度内は、特別推奨で+αで上積みしたいくらい!(って言うか、マジで上積み交渉したい⇒○○(←社長の名前)さんへ)
 <お願い> ◇◇◇さんの方で報奨金見直しをして頂きましたが、同じ尺度で、こちらもザっと見て頂いて、大体の報償金額を出して頂けませんか?
 急ぎません。 宜しく、お願い致しますー
 
 ◇◇◇ [11:55]
 わかりました。
 
という事で、実際には筆者と社長で話をして、具体化に向けて進んでいるところです!。
 


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

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

メンローイノベーションズ社を見学した方の記事...

以前の全社定例会の中で、書籍「Joy, Inc.」の紹介をしました。
 
その後、暫くして、情報収集用に持っているtwitterアカウント上でフォローしている方を通して、
「Joy,Inc.」で描かれているメンローイノベーションズ社に、実際に見学ツアーに行った人のレポート(長文・写真多数)
の存在を知りました。(記事)
 
感じたこと:
 ・書籍ではモノクロ写真のみだったので分かり難かったが、カラーだと臨場感ある!
 ・入社の浅い人でも案内役として活動するって本当なんだな!
 ・"Chief Motivation Officer" なる役割が有るらしい、面白いな。
   ・想像するに、役割が先に出来たんじゃなく、能動的に実績を積んでいた人に周囲が役割名を付けたんだろうなあ...
   ・犬が2頭いる...、ネコを執務室に入れている企業をWebサイトで見たことも有るが、さすがに猫はリスキーな気がする...
 ・"素早く失敗して、学びを得ていく" は、しつこく教えないとなかなかできない!、んだそうだ。(そうだろうなあ...)
 ・"通常20-30%ほどのリソースを安全余裕をとっておく" が、顧客にも見える化しているんだそううだ。凄い!
   ・下手をしたら、"どうせ結構なバッファ取ってるんでしょ!?、だったらこれもやってよ!" 的な話になりそう..
   ・↑:勿論、そこも上手く出来ているってことだろう。
   ・"20~30%"って具体的な数字は書籍の方には書かれていなかったので、ほうほう、と思った。
 ・ペアプロ、隣のペアとの距離近い!、これで隣の会話が邪魔にならないって、凄い集中力だなあ...
 ・人材管理的なボードがあるとは!
   ・中身は頻繁に、皆で話し合って決めているそうな。
   ↑これは納得。年に2~3回とかの考課で処理するのは無理。忘れてしまう。
   ・プロジェクト完了時とか、より短いスパンで見直した方が現実を望ましい形で反映できると思う。
 ・離職率は米国平均値である、という点はちょっと意外かな。もっと低いのかと思った。
   ・米国内のIT系人材の流動速度はかなり早いと聞いているので、まあ、メンロー在籍も経験値の内の1つと割り切っているのだろう。
   ・戻って来る人材も、推奨してるしそれなりにいる様子。ウチは今現在は1人だけだな...
   ・"小さな失敗をより早く行い、より多くを学ぶ"、はコストを伴うはず。
     ・まあ、ペアで業務を行う(役割に関係なく?)ので、ナレッジが一気に消えることは無い、のだろう。
     ・その意味でも、"ペア前提"文化はリスクヘッジ・投資効果の逸失を抑えているんだな。
 ・余りにも当然の前提だけど、英語で質疑できる人のレポートである...
 
書籍に書ききれなかっただけなのか、原書の執筆以降に"実験"して"運用されるようになった"ことなのか?
 
後者もいろいろと有りそうな気がする、と言うか、そう思わずにはいられない。
どんどん変化し、成長し続けているのだろう。
 
自分達なりにも、出来る部分は見習いたい、実験・実践して行ければ!という気持ちが湧き上がるけど...
 
1人で盛り上がっていてもどうにもならないので、皆が(顧客も、エンドユーザーも、各技術者も、技術者の家族も...)
喜びを感じる・幸せになるように、
どうステップしていけば良いのか?、目標を粒度と時間軸で細分化して、小さなこと・出来ることから
先ずは自分が動いていくしか無いよね。
(機会を伺いつつ、巻込めそうな人・時間を取り込んでいけるように様子を伺いつつ...)


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

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

Mr.山下のUI講座(React.js+)

9月の全社定例会では、山下さんが React.js & MetalUI の補完的な技術説明を行ってくれました。
 
"補完的な"ってのはどういう意味か?と言うと、
実は前回(8月)の定例会でも説明してくれたんですが、質疑が多く、定例会自体の時間枠を超えても収まりそうになかったので
9月に延長・第2回目、として実施してくれたわけです。
 
現状のアスペアのメンバーでは、Webフロントエンド周りのトレンド近辺の技術は弱めです...
残念ながら...
 
自社内には、デザイナー兼プロダクション、ディレクション的な、要は要件側とサーバーサイド開発側の
橋渡しを行いつつ全体進行を促す・UI側タスクの配分調整なども行えるメンバーが1人(女性)います。
 
Webフロント周りで比較的強いのは、山下さんを含めても2名だけ。
フロント・デザインが出来るのは1名だけという、何とも心許ない体制です.....
 
F1000165 あ、話がずれましたが、React.js 関連の解説・質疑は、今回も予定時間を順調にオーバーしました。
 
山下さんに拠れば、要点は
コンポーネント指向である、"state, props, context" を押さえれば大丈夫・それ自体は難しいものじゃない。
 
言うまでもなく、Rect.jsはSPA(Single Page Application)の為のJSライブラリであり、ページ遷移はそれ自体ではサポートしていない。
(ページ遷移を伴うなら react-router を使おう、という話)
 
見てくれをどうこうしてくれる訳ではないので、別にライブラリ(山下さんの実務例で行くと MetalUI)を組み合わせる。
 
質疑で時間オーバーする位なので、参加者の関心は高いと思うのですが、実務で利用しない状況だと
&業務負荷が量的に・或いは質的に重いと、なかなか独習・習得までは手が回りませんね...
 
技術的なトレンドを追いさえすれば良い、という訳ではありませんが、旧技術のままに埋もれてしまってはIT業界の中では生き残れません。
 
スキルの要素・キャリア的な各人の指向性を考慮しつつ、強みを強化する、必須要素内に凹みは作らないよう
案件の確保(表現はアレですが案件の選別)や人の配置・ロールの割り当てをしていかないといけません。
 
各個人として見た場合に、"同業他社で、多くの会社から欲しがられる"(十分通用する)人材であって欲しいと思います。


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

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

改めてお勧めアクション:"リーダブルコード"

前回の定例会の中で、山内さん自ら立候補した上でのコンテンツ。
 
"書籍紹介" ということだけは、事前に分かっていました、が.....
果たして何を、どんな理由で取り上げるのだろう??
 
F1000155_2 フタを開けてみると.....
対象書籍はリーダブルコード

社内で共有している "推薦書籍一覧" にも挙げられています。
(推薦者は、同・山内さんになってます)

 
業界内では著名な書籍で、多くの方に読まれていることと察しますが、
"より良いコードを書くためのシンプルで実践的なテクニック" を集めたものです。
 
Amazonのサイト上で見ても、とても高評価!(低い評価がごく僅かの割合しかない!、というのも珍しいです)
 
お勧めなのは分かる!
 
分かるけど、敢えて定例会で取り上げたいってのはどうして??...と思ってましたが...
 
Book2Book3Book4Book5 何と、"解説"を紹介するという!
 
「実際にやるとぶつかること」の部分が必読だよ!
是非、先に解説(ココ↑)を読んでから本文を読んだ方が良いよ!、というのが趣旨でした。
 
"読んだだけでは綺麗なコードを書けるようにはならない"
 "そもそも、どこが直すべき箇所かわからない"
...という当たり前の事が書かれている。
 
"まずは何をすればいいの?" ⇒ "実際にやる!"
具体的には、何をどうすれば良いのか?、に関しても、解説に書いてあるよ!、と。
 
それを先に読んでから、本文を、各人の関心のある部分から(考えながら)読む方が良い、ということでした。
(その方が、時間の有効活用度が高くなる:同書籍をより深く活用したことになる)
 
小説などの創作物の場合だったら、解説から読んでしまったらつまらない。
(でも、そういう方もいるのでしょうね。解説内に敢えて"先ずは本文を先にお読み下さい"と書かれている場合もありますね)
 
技術書の場合なら、
"こういう視点で考えながら読むといいよ"的なことは、出来れば"まえがき"とかに書いてあると有難いですが、
そうとも限りません。
 
増してや、ネット上で高評価の書籍だったりすると、普通に先頭から読んでしまうのが人情です。
普段なら目次の構成やまえがき、解説などから慎重に読み進め(品定め)してから入手する人でも、です。
 
なるほど、こういう書籍紹介のパターンもアリなんだなあ...とも感じさせられました。
面白いです。
 


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

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

新人君の、研修レポート。

今年4月の頭から、第二新卒的に転職・入社して来た新人君の社内研修が、7月初旬で一旦終了しました。
 
新人研修と知っても、言うまでも無く、その人の知識・経験値に応じて研修の実施内容やペースが必然的に違ってきます。
 
漏れなく、無駄なく、が原則ですが、
そもそも入社時点での練度によって、研修期間終了時の目標到達状態・レベルなどの設定も違ってきます。
 
F1000150 今回の場合は、1年間の社会人経験は有りますので、マナー研修など個別には設定せず。
専門学校を出て来ているので、"コンピューターが動く仕組み"やら、"プログラムを書いてコンピューターを動かすこととは?"、"処理の手順を組み上げる"、etc.の基礎は不要です。
 
が、"アプリケーションやシステムの開発は初めて"、なので、"DBもWebも知識が無い"状態。
前職で、ツールとしてPythonは少し触ったことがある。
 
ということなので、研修の要素群と到達レベルの設定からして、模擬開発を含めて3ヵ月間を想定しました。
 
少し実戦向けの補完カリキュラムなどを足しながら、7月上旬には入社時研修は完了しています。
 
その後の最初の定例会が7月度(7/21)になりましたので、そこで研修レポートを発表して貰いました。
 
研修レポートは、研修者本人と研修内容・メンターによってレポート内容や方向性が違ってきます。
"必ずこの形!"というのは決めていませんし、決め打ちできるもの・すべきものでもありません。
 
今回の研修では、言語・フレームワーク的には Ruby on Rails だったのですが、諸事情があって、メンターが途中で入替ってしまいました。
特に、最後の模擬開発のメンターは RoR 未経験だったので、研修者本人にはちょっと申し訳ない対応になってしまいました...。
 
窮余の一策として、RoR実務経験のあるメンターがオンライン(slack)でサポートするという一幕も有りましたが、やはり効率は良いとは言えないですね...。
(ソースレビューもオンラインで行ってくれた)
まあ、全く無いよりは格段に良かったと思いますし、オンラインでサポートしてくれた側にも負担が掛かったので、
申し訳ない&とっても感謝していることに変わりはないのですが...
 
レポート当日は、パワポを元に報告してくれました。
模擬開発で作成した小さなアプリの動きも披露しつつ、です。
 
この記事に、本人が作ったパワポのページを画像化して貼ります(自己紹介ページだけは省きました)。
 
Repo01Repo03Repo04Repo05 最終段階でのメンターが、何度もレポートの練習・指導をしていたのが印象的でしたが、
結構良い形・内容になってるんじゃないかと思います。
 
模擬開発に関しては、方針的に悩ましいところも有るのですが、
実務の一部:実際に顧客に納品されるコードを書く方がモチベーションが上がるのではないか?、とか。
 
Repo06Repo07Repo08Repo09 しかし、メンターが張り付いていたとしても、慣れない人間が納品用コードを書くことに対しての不安感は
相当のものだと思います。
 
それに、実際のシステムの一部で研修を行う場合、全体仕様が見え辛いと思います。
仮にも"実際に使われるアプリやシステムの一部分"なので、結局、自分がどんなプロダクトに対して、
何処でどう動く何を作ったのか?、どう貢献しているのか?、見え辛いのでは意味が乏しかろう?、と。
 
Repo10Repo11 それよりは、顧客に使われることは無いとは言え、仕様は事前に決まっている、機能も構成もモジュール構成まで全体が見えるし、自分で作る。
機能追加や改修課題、リファクタリングなども、自分でこなす経験をさせる方がベターだと考えています。
 
色々と悩む機会・要素が増える面もありますが、"どうしてこうなんだろう?"、"もっと良くならないんだろうか?"、いろいろと悩んで欲しいと思います。
 
当面はメンターは継続担当しますし、先に担当したメンターもオンラインや定例会の時などに対面でフォロー
してくれています。
と言うか、熱い質問を投げ続ける新人君を見ていると、"ああ、嬉しいなあ"と思いますね。
 
"自律的に考える"⇒"疑問・質問が生じる" のは、とっても良いことですから!
 


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

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

スクラムマスターロールプレイ。

筆者がtwitter上でフォローしている方の中に、吉羽龍太郎氏がいます。
 
氏のtwitter上での呟きで、スクラムマスターロールプレイなるスライドが公開されていました。
 
内容を拝見してみると、まあ表題の通り、開発スタイルとしてスクラムを適用していることが前提にはなっている
のですが、必ずしも限定しなくても実務ケースでのシミュレーションとして使えるのでは?
 
.....と考えて、6月の定例会の中で60分ほど枠を取って実施してみました
(これまでにスクラム/アジャイル関係の勉強会やワークショップなど、幾つかやって来てましたし...)
 
ちなみに、同日の出席者の中で、スクラムを実務で適用していた経験者は1人のみでした。
 

研修中の新人(第二新卒的な人)もいるので、
同じく吉羽氏の作成されたスクラム概説図を使わせて戴き、用語などの要点のみ"おさらい"を最初に行いました。
 
60分の枠の中で、最初の数分を上記のおさらいに充て、残りをディスカッション形式にしてみました。
 
保険として?、反応が悪い場合に備えて、自分でもどんな回答が考えられるか?、を
可能な限り挙げておいてみました。
場が余りにも展開しないようなら、"例えば"という形で小出しにしてみようかな?、というつもりで.....
 
結果、話題に挙げられたのは最初のスライドから3つ。
 
スライドの p.5:"常態的にスプリントバックログが消化し切れない、何故か?、どうする?" に対しては、
おおよそ下記のような発言がありました。
 
スプリントの振返りの場で、全員で考える。
"完了"としているストーリーの精度も疑問がある。完成の判定基準に問題が有るのでは?
各ストーリー/タスクに対しての見積が甘く、しかも学習&改善がなされていない。
他プロジェクト等からの頻繁な割込みが有るのかも?
 ⇒割込みを抑えられえるなら抑える
 ⇒割込み対応要員を分けてしまう。←の人数は、チームメンバー数としてカウントしない。
  ⇒残業対応で賄うことはしない!
   ⇒プロダクトバックログの全数消化は無理になる、或いはプロジェクト終了日の延期の了承をもらう。
スプリントバックログの各々の単位が大き過ぎるのでは?、見積精度が下がるのを避けられない
 ⇒粒度を小さく、分割する
メンバー間の繋がりが弱いのでは?
 ⇒"個人の集まり"ではなく、"チーム"としてスプリントの完遂を担保する意識を共有できるように
勤怠が悪いのでは?
 
上記に出なかったもので、筆者の方で想定していたのは下記のようなものでした。
 
ストーリーの仕様が不明確(確認に時間が掛かる・矛盾が見付かる等)、プロダクトのinputとして不適切?
メンバー構成が拙い(スキル問題)?
スクラムの各種プラクティスの理解不足?、或いは手段が目的化している?
メンバー中の何名かが?プロジェクトを掛け持ちしている?
タスクへの分解の仕方、タスクの取り方が拙い?
 ⇒複数タスクが同時にDoing(仕掛り中)になると、生産性・品質は低下する。
 
これら↑に関しても、軽く触れてみました。
 
で、3つの課題に関してディスカッションした後に、今回のセッションに関しての振返りを行ってみました。
 
Problem:
スクラムに関して(自分達が)実戦的な理解が無さ過ぎてイメージが湧かない。分からない。
やっぱり回答例(スクラム的に望ましい現実的な例)が欲しい!
Try:
出題されたPOが余りに無能過ぎるので、そのPOのペルソナを作ってみたい。(恐らく半分以上は怒りか?)
スクラム経験者のワークを見学してみたい。
POとしての社内的な教育機会が有るべきでは?!
 
Keepに分類できそうな発言は残念ながら無かったのですが、
スクラムの実務経験が無いメンバーが殆どだった割には、ある程度のディスカッションにはなったように
思うのだけれど...手前みそでしょうかね...。
 
なお、当"ロールプレイ"を実施してみよう!、と判断した筆者の反省としては、
案の定ではあったが、実戦経験が圧倒的に足りない...
 ⇒機会が有れば、請負・自社内で作業がほぼ完結する案件で実践してみたい...
せめて事前にお題を公開しておくべきだった、かも...(タイトルしか事前告知していなかった)
 
最後に、これは言い訳がましくなるのですが、
今回の定例会には、技術メンバーの半数未満しか出席していませんでした。
(繁忙期の大所帯プロジェクトが複数、ピーク状態だったため)
 
先月も同様の状態で、5月度は定例会自体を開催中止にしたんです。
 
さすがに2ヵ月連続で中止はしたくなかったので、コンテンツを少人数でも展開できそうなモノに入れ替えて実施しました。
("実プロジェクトで利用した技術ベースでのUI・UXデモ"も予定していたのですが、勿体ないので次月に繰り越してもらいました...)
 
7月度の出席者は改善されるはず。
...と言うより、改善すべく、"定例会自体の開催時間帯を見直すべき!"、との案が出されました。
小さなお子さんの子育て中のお母さんエンジニアが何名かいて、常態的に出席出来ていないという問題点への改善も必要という事です。
 
現在、Googleフォームベースでのアンケートを配信し終わり、回答待ちの状態です。
 


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

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

"Joy, Inc." & "多動力" だあ。

6月の全社定例会議では、たまたま書籍紹介的なコンテンツが2つ重なりました。
 
1つ目は、
 
 
これは、筆者からの紹介。簡単にスライドに要約してデモりました。
 
当初は個人的に図書館で借りて読んだのですが、予想に反して余りにも面白い!
と言うか、いろいろと刺激的!
 
そのまま、あれやこれやを真似することは出来ませんが、
自社や、顧客との関係など、今のままで問題無いとは到底思えない。
小さなことから実験して、早く間違えて、早く学習することを積み上げる。共有する。
上長とかリーダーとか顧客とかに、"依存"しない。自身に問う。自分の考えを持ち、議論する。
"こうしたらどうだろう?" という仮説が非常識なものだったとしても、先ずは小さく試してみる。
・(その他諸々...)
 
色々な書籍やネット上の情報、セミナーやワークに参加してきた内容とかが、現実的に "ああ、こう活かせば良いのか" と
腑に落ちた感がありました
 
これは、この感覚を忘れてしまわない/時の中に埋もれさせてしまわない為に、是非とも書籍を買おう!
会社で買って、皆に紹介しよう!
折に触れて話題に出し続けて行こう!、と思い至りました。
 
と、読んで感化された本人は熱くなっている訳ですが、
要約だけを聞かされても、恐らくは余りピンと来ないだろうな...と思ってました。
 
Slide0609 作成したスライドの最初でも、
"出来ない、やらない、必要ない、の理由付けばかりを探さないで下さい" と敢えて書いておいたのですが、
話し終えた後の反応も概ね冷めた感じのものでした。
(これ↑は、大いに筆者の力不足によるところが大きいのだろうと思いますが)
 
まあ、とにかく部分的にでも、1人でも多くのメンバーに読んでみて欲しい。
筆者自身が、機会を探しながら試せることを1つづつでも試して行ければと思ってます。
 
さて、もう1冊の紹介は、IT-Tips(10分枠)の中で小障子さんが紹介してくれたモノ。
 
"多動力"
堀江貴文(著)
 
F1000143 自身のヒューマン/ビジネススキルを見直し補完する上でも、あれこれと書籍を当たっている中での1冊のようです。
 
アスペアには、"書籍買い放題"制度が有ります(社費で購入して、保管は個人が行う&書き込みもOK)。
が、この本に関しては自己投資として敢えて自腹で購入したとのこと。
 
気持ちの持ち方次第なので、要は有効に活かせれば良いと思います。
 
さて、たまたま書籍紹介的なコンテンツが2つになった今回の全社定例会。
 
"こういう事で時間枠が欲しいと要求するのはアリですか?" と問うてきたのは山内さん。
"是非!" と答えると、"それでは次回に30分欲しい!" と、次回コンテンツが1つ即決しました!
 
自発的なコンテンツは大歓迎です。
 


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

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

スパルタンレース参戦!&高尾山...

アスペアでは、顧客先での開発業務と、自社内(町田事務所)での開発業務が有ります。
 
2月半ばのある日、とある顧客先(アスペアから社員が5名、パートナーさんやフリーランス(←どちらも元・アスペア社員ですが)2名が業務中)
で、プロパーの方から"スパルタンレース"参加のお誘いを受けたとのこと。
 
"参加者を待ち受けるのは火、泥、水、有刺鉄線、さらには地獄のような障害物の数々。スパルタンレースは参加者の肉体的・精神的限界を試します。"(主催者Webサイトから抜粋
...ってことで、生半可な気持ちで参加すると、ちょっとヤバいことになりそうです。
 
弊社社員で、PM補佐的な役割をさせて頂いている(と言うか、遊撃部隊的にやるべきこと、気が付いたことは
何でも言って・調整して、プロジェクトが現場で現実に回るようするぜ!的な立ち位置のようですが...)
2名が参加了承!
顧客先のプロパーの方、他社の方、4名と一緒にチーム参加と相成りました!
 
自主的に筋トレやランニングで基礎体力作りに精を出す日々。
(業務の方も、特にロールが重い&多岐に渡るので日々の疲労も結構なものだと思うのですが...。凄い。)
 
18670884_1995891537300959_28174979718740161_1995891433967636_586335761 5月27日・土曜日。当日は快晴!
 
弊社側メンバーが2名、参加者の奥さん2名が応援&見学に現地(神奈川県内の元米軍基地の広大な敷地)入り。
 
チームとしては脱落者なしに、全員がゴール出来たようです。
 
擦り傷、打撲は数々あれども、大きなケガや故障が無くてホッとしました。
 
18813418_1995891397300973_380081859 楽々制覇!、には程遠かったようですが、事前にトレーニングをしておいたおかげで
それ程の筋肉痛でもなかった。.....とは本人たちの弁です。
 
感想としてはどうだったのかなー、と思いましたが...
"楽しかった!"、"次(10月)までにトレーニングに励む!" と、もう参加することが前提の勢い!
 
若いよなー!!
.....と言いたいところですが、ウチから参加した2名とも40歳オーバーです。
で、応援だけに行ったメンバーは30代後半.....
 
気力の問題ですね! ガッツです!
 
"楽しそうだから、やってみよう!"、これですよ!
 
Dsc_0103 で、話変わって、翌日の日曜日には"高尾山登山"イベント。 本日も快晴!
あ、こちら↑は、アスペア内の別メンバーの企画です。
 
アスペア社員:男女数名と、子供連れで参加したメンバーもいました。
で.....、昨日のスパルタンレースに参加したメンバーの内の1人が、こちらにも参戦!
 
さきほど、"それ程の筋肉痛でもなかった" と書きはしましたが、
高尾山と言えども山登りであることに変わりはなく。
さすがに、ちょっと辛かったようです。
 
アスペアでは、特に"全社員・強制参加!"、みたいな企画(風土)は一切無いのですが、
"楽しいことで羽目を外そう" 的な企画はたまにあり、参加したい・出来る人が参加して、
楽しい・嬉しい時間を共有してます。
 
と、その辺のことも社員専用Webサイト上の週報の中だったり(←他メンバーから"ステキ!"マークがカウントアップしますね)、
slack上とかに、様々な文章や写真が共有されてます(あくまで自然発生的に、です)。
 


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

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

ただいま研修中:タスクの粒度は?

4月頭に中途入社した新人さんが、絶賛・研修中です。
 
予定・進捗などは、執務室の壁(真っ白です)を"かんばんボード"として利用し、
研修内のタスクを付箋で表してます。
 
マグネットシートを任意に切り貼りして、エリアの名称を書き込んだり、エリアの境界線を作ったり。
ちなみに、朝会は町田事務所にいる全員が(関与しているプロジェクトが別でも)一緒に、立って行ってます
研修中の彼も、当然、一緒に参加します
進行役は日単位で持ち回り。忘れないように、"朝会当番"と書いた小さな立て札をその人の席に置いておき、当番の人はこの立札を持って進行をするルールです
 
で、"かんばん"の写真は、slack上の研修用チャネルに挙げてもらってます。
社員専用のWebサイトに簡易なフォームで日報をアップすると共に、上記の"かんばん"の写真へのリンクを貼ってもらってます
 
20170524 社外で作業をしているメンバーでも、slackからかんばんを確認する方が楽チンです。
コメントを入れるのも、スマートデバイスから簡単に行えます。
 
さて、ここ最近は Ruby on Rails のチュートリアルを実施中
毎日のかんばんに変化が無くなりました.....
 
うーん.......どうしたんだ?、でも日報の文章を読むと進捗はある様子。
でも、かんばんボードの方を見ても......つまらない
 
付箋を見ると、予定工数が37.5時間になってる.....sign03
 
デカ過ぎるやん sign02  1週間もかかるやんか!?
 
これは、研修を行っている本人も、1日単位での"進んだ感"(達成感)が得られなくて辛いのではないかな?
まあ、プロジェクト/プロダクトやロールによってタスクの管理上の粒度基準ってのは違うとは思います。
 
でも、"人間がチームを組んで楽しく'見える化'と共有の運用ができる"
 = 小さな達成感を積み上げることが出来て、
 + ストレスが幾分かでも緩和でき、
 + 疲労度も減り、
 + 生産性・品質の向上にも役立つ...はず。
という効果も狙うのであれば、
"毎日、最低でも1枚くらいの付箋は、'Done' に移したい!"。
 
この達成感がクセになる!というメンバーが多い(人間なら当然だと思う...)ですし、
1日の区切りにもなります(多少なりとも、気持ち良く帰宅できます)
 
なので、1タスクの時間数は最大でも7h程度、出来れば4h程度を上限基準にしたいところです。
チケット管理ソフトで言うところの、子チケットに相当するような考え・管理でOKだと思います。
 
20170525_2 本人に聞いてみると、"何か全然進んでない感じがする..."
 
これ↑、メッチャ拙いです!bomb
 
なので、チュートリアルの章毎にタスク化し、親付箋の脇に Doing 付箋をペタっと貼る感じに変更
(実務だったら、親付箋の下端に貼る感じでしょうかね...)
親付箋のタスクが全部終わると、Done のエリアに縦に幾分か長くなった付箋群が出来上がる...という具合に
 
早速、メンター担当が対処してくれました。
当日の日報に上がったかんばん写真に変化が現れてますね!
 
良かったー!


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

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

Mr.當山、研修中ですっ!

先月(4月)の頭に、同業・他分野から転職・入社してきた當山(とおやま)さん
 
アスペアで行っている、Web系(フロントからバックオフィスまで含む)開発系の技術、関連ツールやら
プロセスやら、そもそもコードのデザインとかお作法とかから社内研修を行ってます
(アスペアは基本的に必ず社内研修です。新卒の方を採用した場合に、マナー研修などを外部の合同研修などに依頼してきたことはありますが、その点だけが例外です)
 
社会人・1年経過の状態で、役割も開発の中心部にいた訳ではないので、ほぼ新卒新人と同様に研修期間は
3ヵ月間で計画を組んでます。
(主たる言語・環境は、Ruby on Rails。ある程度実戦を意識した模擬開発演習も含んでます)
 
IT系の専門学校を出ているので、基礎の基礎はOK。
 
とは言え、連日新しい学習内容の連続で、更にそれらを関連付けて理解し思考して行かないと中間課題も消化できない。
難しいです。
特に、Web系は機能を実現する上での物理層・論理層・プロトコルやら概念なども多く、言語やツール・その他周辺知識も
派生して多くなる
ので、頭の中で統合的に理解するのは、なかなかに苦労すると思います。
 
さて、そんな苦労しつつも楽しい(!?)毎日の中で、
"4/21の全社定例会で何か発表してみようか!" という、メンター役の渡辺さんからの暖かくも劇的なお言葉。
 
2017042102 自己紹介も兼ねて、早々に人前で発表するという機会を設けた方が良い!、という暖かーい親心!
素晴らしいですね!!  ステキ!
"鉄は熱いうちに打て!"とも言いますし。
 
で、全社定例会の当日での登場は、"LT(Lightning Talk) 又は IT-Tips"コーナー(質疑を含めて10分枠)
発表してくれたのは、"ATOMエディターの紹介"でした。
 
業界内の方ならご存知の方も多いかと思いますが、
オープンソースのテキストエディタで、Linux, MacOS X, Windows 上で動作する。
プラグイン拡張が容易で、多数のパッケージが公開されている。
デフォルトは英語ですが、日本語化パッケージを導入すればベタな日本人でもOKっ!です。
 
ライセンスフリーのエディタとしては、Microsoft の Visual Studio Code が存在感を増しつつありますが、
さすがの多機能・Visual Studio のノウハウを詰め込んであるだけに、ちょっと遅い...という声も有りますね...。
 
ATOMより軽量のエディタも有るようですが、オープンソースでマルチプラットフォーム対応、拡張パッケージが豊富な点などから
ATOMを選んだようです。
 
HTMLの基本構文の理解と演習の際に、構文に応じたハイライト表示や、入力時のオートコンプリート機能などが
学習効率を上げてくれる!(タグの閉じ忘れなどもある程度防止できる)、ということで、便利・便利!
 
"便利"が過ぎると学習効果が損なわれる場合も有りますが、余りに単純な部分に手こずって時間を潰すのは
勿体ないですし、"生産性が低い状態に慣れてしまう" のも絶対に避けたい点です!
 
トツトツとした當山さんの進行と語り。
緊張している様子は感じられないのですが、当然ながら慣れている訳でもなく...
 
それでも、質疑を含めて、予定時間枠の10分にジャストで収まりました!
おお!、素晴らしい! (←定例会の最後の振返りで、Keepとして他メンバーが挙げてくれました!)
 
多少の苦労をしてでも、なるべく社会人経験の少ない内に、いろいろと経験しておくのは良いことです。
 
勿論、オーバーフローで心身の調子を崩すようなことは避けるべく、メンター&周囲のバックアップを含めて
声掛けしたり、お昼時の雑談などでフォローしてくれています。
 
さてさて、入社1年後にどんな活躍を見せてくれるか?
活躍できる機会を設定できるのか?、とも言えますね
今から楽しみです。
 


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

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

2016年度:"ステキ!" 大賞は??

弊社:アスペアの期は3月始まりです。
 
さて、他社の多くがそうでしょうが、アスペアも自社社員専用のWebサイトがあります。
某CMSを利用していますが、プラグインを自社開発して、他メンバーの書込みに"ステキ!"を投票出来るようになってます
 
で、年度を通じて"ステキ!"獲得数の多い順に、金・銀・銅メダルを授与してます!
(これは2014年度から始めたので、2016年度(~2016/02末)で3回目となります)
ちなみに、賞金とかは有りませんが...(名誉こそが最大の懸賞ですよねっ!!?)
 
2016年度の金賞は忠さん
("忠さん"ってのは、社内で同じ姓の人が4人もいるので紛らわしい!ってんで、名の頭文字を呼称にしているのです)
 
獲得票数、175票。
 
投票者は社内の人間だけで20名そこそこですから、結構な数です。
 
CMSに全社員が書き込むのは、主に週報
1人・1年間に50回ちょいですね。
 
アスペアでは、週報は"上長に出す"モノではなく、"全社員に共有するモノ"なんです(ブログ機能で、即時共有されます)。
 
なので、日々の業務で得られたTipsとか、状況判断・行動・結果とか工夫とか(痛い目を見たとか)...
 
顧客の守秘義務に触れるような情報は勿論書きませんが、普遍的なこと、特定顧客やプロダクト/プロジェクトに
依存しない事などは共有します。
 
別の場所で業務をしているメンバーであっても、ある程度の情報を共有し、間接体験をすることが出来ます
興味を惹かれれば、コメント機能で質問したり、フォロー発言したりもOK
 
他にも、体調&モチベーションを数値表現します(1~5で、大きい数ほどGood!状態を表す:ニコマーク付き)、
業務とは全く関係のない事も書いてOK!(SNS的な要素とも言えますが)
 
ここに、この1週間で読んで面白かった本とか、参加したイベントとか旅行先とか、
独習・検定試験向けの学習状況を申告して自分自身を追い込んだりとか、
家族(お子さんとか)の何気ない事を書き添えたり...
 
週報としての基本の項目セットが有るのですが、書きたいことが書けるように改訂されてきました。
 
チャットツールとしてはslackを利用してます(Standardコース)し、大変に便利!なのは確かですが、
CMS、電子メール、それぞれの特性があるので、
要は使い分けだと思います。
 
で、話を戻すと、2016年度の金賞の忠さん。
2014年度は銅、2015年度は銀、そして次は金!と、着実に獲得票数を伸ばして来ました!
凄い!
 
本人の弁護の為に書いておきますが、決して業務が暇なわけじゃありません。
それどころか、ロールの数も多いし、重いロールも複数抱えている。
タスクの数たるや、半端じゃありません!!
 
稼働時間制限をかけながらの業務とは言え、定時帰宅ではないし、時間密度は恐ろしく濃いはずなのに...
 
最近では、簿記2級の受験準備、スパルタンレースの参加準備などが熱い話題です!
(プロジェクト的にも熱くなってきているようですが...←こちらは心配...)
 
さて、2017年度はどうなるのだろう?
 


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

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

帰って来た "偏愛マップ"!

4月の全社定例会は、4/21(金)。
 
通常は毎月・第2週を目途に開催しているのですが、数ヶ月間・定常的に毎月-第2週の金曜が
都合がつかない(定例会に参加できない)メンバーが発生したので、その間は開催タイミングを1週間ずらすことにしてます。
 
さて、4月に入って、中途採用者が1名パート契約のママさんエンジニアが1名入社しました。
 
「それじゃあ、久々にやってみるか!」ってことで、やってみました。
『帰って来た、偏愛マップ』ワークショップ
 
前回実施したのは2年前(2015年)の9月ですので、1年7ヵ月振りです。
http://aspire.way-nifty.com/majime/2015/09/post-a423.html
 
"偏愛マップ"は、特にアジャイルな開発プロセスなどには限定されず適用可能なアプローチで、
主にチームビルディング初期に行うと効果的、なものです。
 
が、今回のように新規参画者がいるときにも、手っ取り早くお互いのコミュニケーションを
自然で滑らかなものにしたい場合などにも良い
と思います。
 
ここ数年、IT業界関連で盛んに話題にされるようになった"心理的安全の確保"の為にも、
自社内にどんなメンバーがいるのか?
業務以外のことでも気軽に話題にすることが出来れば、余分な緊張感も減りますし、
心理的な障壁も低くなるはず
ですね。
 
前回のワークに参加したメンバーも、既に19ヵ月も経っているので内容のバージョンアップ?が可能なはずだし、
そもそも前回のワークに参加できなかったメンバーも数名います。
ちょうど良いタイミングでしょう。
 
ってことで、一応、"偏愛マップ"の実施目的・内容・進め方などを一通り説明してから、ワーク開始!
 
20170421042017042105 2017042103
2017042106"書きたくても漢字が思い浮かばない..."という職業病者が続出していたり(⇒ネット検索しまくり)、
"前回の内容から変わってないから、前回のを見ながら描く!"なんてメンバーもいれば、
"絵を描いてみたけど、サイトで確認したら全然違ってたよ"、とか、
"アレは封じる!"、とか、怪しげな発言が飛び交ったりもしてました。
 
なお、前回のワークでの問題点として、
"用紙がB3ではちょっと小さ過ぎた"、
"コピー用紙を使った為に、裏写りした(水性マーカーだったので机の汚れは残りませんでしたが)"、
...などが有ったので、今回は大き目の用紙で、材質も画用紙にしました。
 
絵を描けるように、マーカーもなるべく多色を用意しましたが、ちょっと時間が足りなかったか...
(そもそも、絵心のあるメンツが少ないってのも有るのかも知れません)
 
2017042107201704210820170421092017042110 ネット上では、このような[↓]サンプルも紹介されていますが、とてもここまでは描けないな...
http://tamkaism.com/2014/06/henai-map/
https://note.mu/tamkai/m/m719115669c6b
 
ちなみに、今回の定例会後に、中途入社・新規パート契約の方の歓迎会を行いました
ので、定例会自体が短縮バージョン
 
加えて、前年度・新年度以降の方針・計画などの話が役員から展開されたので、ワークに割り当てられる時間枠が少なかった...。
なかなか難しいです。
 
2017042111 まあ、それでも、最後の振返りで"新規採用者が入った時には必ず偏愛マップやりたい!"とのKeepの声が聞けました!
 
この後の歓迎会でも、話題の繋ぎとして有効に作用した様子だったので、実施して良かったと思います。
 
前回のワークで作成したマップは、社員用Webサイトの"社員名簿"からリンクさせてますが、
今回作成した分で更新・登録しておこうと思います。
 
これは余談ですが、同ワークの司会・進行・撮影は筆者が行ってます。
ので、自分の分の偏愛マップは未だ1回も作成されてません.....
 
"見たい!、書いて下さい!"と具体的にリクエストされてしまったので、後日・自分の分も
(ワークの時と同じ時間制限で)作成して、社内公開しようと思ってます。 あはは.....
 


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

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

Mr. 速形、ブチかます!(ラムダ式)

3/17が3月の全社定例会の日でした。
 
この日は、個人的な事情でアスペアを卒業することになった速形さんから、
事前には予定の無かった "IT-Tipsを是非やりたい!、10分枠をくれ!" との嬉しい飛び込み発言があり、
当日に急遽、枠を設けました
(ちなみに、同日の定例会終了後に彼の送別会を行う予定だったので、定例会は短縮バージョンで行ってます)。
 
2017031704 どんな内容かなー?、と思っていたら、タイトルは...
"わかる!ラムダ式"
 
技術のトレンド系・最先端と言うより現実的に身に迫って来ているけど、
実案件では意外と導入が遅れていたりする要素を積極的にフォローアップしている速形さんらしい出し物設定と言えそうです。
 
あ、ちなみに、
なぜ、急に "全社定例会の枠を設けてくれ" と自ら要求してくれたのか?に付いては、
"定例会の場で、皆の前で話すのが楽しかったし、色々と突っ込んでくれるのも面白かったので、退職する前に
是非もう一度やっておきたかった!"
と言ってくれました。
(嬉しいです! もの凄く....(涙))
 
実際のコンテンツは、Qiitaサービス上で作成し、スライドとしてデモで見せてくれました。
WebページをPDF化&圧縮したファイルを掲載させて頂きます:勿論、本人の承諾済み)
↑分り易さ優先の資料のため、技術的な問題点など余り突っ込まないで下さい;ご教示頂ける点は有り難く伺います...
 
2017031702 言語的にはJavaScriptで実例を追う形
Javaより簡単に書ける
Javaと構文が似ている(現時点のアスペア内ではJavaが最も共通知識となっているので)
すぐに動かして確かめられる
...という理由からの選択です。
 
サンプルとして、"或る処理ロジックをJavaで書いたもの" をJavaScriptのラムダ式に書き換えていく
という形で展開されました。
 
高階関数+ラムダ式を使用して、
より簡潔に短く、処理の意図が伝わる、コードが書けることを順を追って説明してくれました。
 
と、このブログ原稿を書いている筆者自身の理解が追い付かない点が情けないのですが、
出席していた技術部メンバー達には理解・納得できたようです。
確かに、"ゴチャットした制御構造を読み解かないと仕様・意図が分からない" 状態から、
"意図した仕様が箇条書き的に、一読で読み取れるようになった" ことは私にも理解できました!
 
端的な例とは言えるのでしょうが、
メンバー全員が理解して、ガイドラインなどを設けて&共有して&納得した上で活用したら、
開発者の皆が(今と比較して)幸せになれる可能性を感じ取れました。
 
資料も説明も、今までの速形さんのコンテンツの中で最も完成されたデモだったと思います!
いろいろと周りにも刺激を与えてくれてありがとう!
 
次の職場でも、きっと様々に活躍されることと確信してます。


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

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

古いツールでも光るヤツも有るんだぜ!

2月の全社定例会は、2/17でした。
 
コンテンツは、企画モノ(非レギュラー)は、
仕掛り中のプロダクト/サービスからのDevOps的視点からの実例共有&相互質疑
セキュリティ系の昨今の事例共有&相互質疑
その他、労務的なこと、社内的なスキル評価体系的な話題など...
...でしたので、
ちょっとここには書けない内容ばかりでした。
 
ただ共通して言えるのは、作業をしている場所・顧客、仕掛りプロジェクト/プロダクトに関わらず、
オンラインだけでなく対面でも実例・事象を共有して、相互に質問し合う、
お互いの間接経験となるように活かす、という視点&行動
です。
 
また、共有が比較的(かなり?)難しい "暗黙知" に関してですが、
これを共有するには、現実的な話として "一緒に作業しながら伝え合っていくしかない" 面が多分にあります...。
...と言っていても、なかなか現実は先に進めない=勿体ないので、
出来る限りハンズオンやワークショップなどの形態を採るようにしています。
 
準備・仕込みに時間・手間がかかるので、肝心の"暗黙知を持っている本人"の調整が難しいですし、
いかにワーク実施時に"持っている側から見せられるか"、"持っていない側が部分的にでも体感できるか"も
悩ましい所です。
 
とは言え、これが出来ることが"その会社に属している・仲間との間に妙な制約を設けずに済む"大きなメリットですから
活かしていかなければ!
 
さて、具体的な内容が無いと寂しいので、同日のレギュラーコンテンツの方から紹介を1つさせて頂きます。
 
毎回、"IT-Tips 又は LT(ライトニング・トーク)"を行ってます。
 
2月の回では、蓑方さんが発表してくれました。
 
ちなみに、蓑方さんは "自身の公的なロールに捉われず、なるべくプロダクト/サービスの全容を把握し、
機会があれば可能な限りの外部仕様・内部構造も把握しつつ、俯瞰的な視点で理解をして設計や製造にも
反映できる&メンバー間で共有も進めていける" 人物です。
 
多くのプロジェクトに関わって来ましたが、"いつの間にか、設計や仕様・要件の中心に関わっている" 人です。
 
2017021701 さて、そんな蓑方さんが今回お話してくれたのは、
自身がかなり以前から使っている "自分のメモを構造的に集約するツール" についてでした。
("ウェアラブル EXPO" 参加レポートを発表!...と思ったけど行けなかった、というフェイント付きでした...)
 
Nami2000
http://www.geocities.jp/my_ultraseven/mozart/_start.htm
 
既に世に出てから17年を超えるフリーソフトウェアです。
分類的には、"アウトラインプロセッサ"。
 
最近は余り耳にしない用語かも分かりませんが、
要は、情報を構造的・階層的に構築・集約していくツール、です。
 
それ自体をそのままで、多くの他者と共有・運用することには向きません。
基本はあくまで、個人の情報を、個人の基準で構造決め・メンテをして成長させていく(或いは適宜で掃除する)ものです。
 
今なら、例えばGoogleDriveやDropBox、SkyDriveなどに置いておけば、物理PCに限定されずに利用できますね。
 
2017021702 自分でカテゴリー分けをしながら、大体3階層くらいまでで済んでいるとのこと。
検索機能も当然有りますが、"何処にどんなモノを入れているかは大体頭に入っているので、検索は余り使わない"そうです。
 
このツールに、
自身で得たTips的な知識、ちょっとした(しかし重要な)スクリプトとか、
日々のToDoリスト的なメモの保存とかから週報を起して効率的に進められるとか、振返りに使ったりとか...
 
で、今回の蓑方さんからのツール紹介を受けて、
"早速インストして利用します!" という反応もありました
 
新しいばかりが良い、と限った話ではありませんよね。


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

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

Mr. 三文字、踏ん張る!

1月の全社定例会にて、アーキテクトでもある三文字さんから、プロジェクト/サービスの事例発表がありました。
 
Web上で展開されている各種サービスを実現するために、それらを支えている様々な要素があります。
 
2017011301 サービスが大きく成長し(ユーザー数を増やし、継続的な収益と成長を持続させる)、機能拡充と共に、
ユーザビリティの改善や、顧客内の他のサービスとの連携・API化の流れ(マイクロサービス・アーキテクチャ)、
様々な側面からメンテナンスの必要性が生じて来ます。
 
特に、大規模なサービスで、かつ運用期間が長くなるほど、
顧客にとってのビジネス的な価値も大きくなるでしょうが、同時に、徐々に技術的な負の資産を膨らませてしまうことは
避けられません。
 
負債はどこかのタイミングで返済しなければならない。
負の資産は、どんどん保守・運用コストの増加という形で顧客のビジネスを圧迫していきます。
 
2017011302 三文字さんが、この"負の資産の返済"の実例実務上の中心人物として稼働してきた経験から、様々なことを共有してくれました。
 
サービスは、長期間運用して来れば(=長期間、必要とされ続けて来た)、必要とされ方・利用の仕方・求められる
サービス内容も大なり小なり変化していきます。
 
その度に "どんな課題に対し、どんな目的を持って、どう変化させるのか?" 、"結果として何がどう変わることを期待するのか"
が、事前に明確にされなければならないはず...
 
...ですが、
"どう変えれば、ビジネスの成果にどう反映されるか?"、は、やってみなければ分からない面も多分にあります。
 
開発途中で、関係者(ステークホルダ)からの要望が出たり、他のサービスから得られた分析結果を元に
施策を変えたりといったことも頻繁に発生します。
 
そんな状態の中で、これらの要求・外部仕様・対応する内部仕様が資料として確実に残されるか?
と言うと...残念ながら、不完全な場合の方が圧倒的に多いのではないでしょうか?
 
三文字さんの苦闘の中でも、
"彼自身が頑張れば何とかなる" 範囲と、
サービスの外部仕様・運用を最も知っている人達の協力を得なければどうしようもない
(現実的な時間制約やコストの範囲で収まらない)こともあります。
 
それらの判断を行い、切り分けつつ、顧客側の上位職の方々と提案・交渉などを行うことも、三文字さんの
重要な仕事の1つでした。
 
膨大な量のプログラム・コード。
品質を担保しながら、負の資産を返済する手段とステップを考え・調整する。
テストケースの設定自体も、以前に関与したメンバー達の協力を得られるように各種の調整を行い、
テスト・コストも現実的なレベルに抑えつつも、必要な品質担保の点で手抜かりは許されない。
ユーザー数の多い大きなサービスですから、フロント/バック共に性能的な低下が無いことも十分に検証しなければならない。
 
具体的なことは書けないのですが、様々な問題が発生し、1つ1つへの対処法を工夫しつつ、
クリアしながら(多くの人達と協働しながら、ですが)リリースに向けて進んで来たのですね。
 
ほぼ完了している時点で話をしてもらっているので、淡々と話すことが出来ていますが、
「これは....苦労しました」という、微妙な言い淀みや間合いに、
「大変だったんだろうなあ...」という印象を持ちました。
 
負債返却の具体的なケースと、効率的な調査方法、対処方法(政治的なモノから技術的な詳細に至るまで)など
様々な要素を惜しみなく共有してくれた三文字さん、有難う御座いました。
 


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

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

本が欲しいだあ?、買え買えーっ!!

"書籍買い放題!" の運用をスタートしましたっ!
 
今までも業務的に、或いはトレンド技術やプロセス、マネージメント系、業務系など、必要な書籍が有れば
都度の申請(職制によっては自己裁量でOK)で社費での購入はしていました。
 
しかし.....
 
"業務で必要としないと買えないのか?"とか、
"既に社内に有ったら&誰かが持ち出してたら買えないのか?"とか、
"そもそも書き込み出来ないと、実戦的に使えないじゃないか!"とか、
"あーだこーだ承認受けないと買えないのか?"とか、
 
面倒臭い.....
 
本当は関心があるんだけど、今の業務じゃ使ってないし、申請・承認だとか面倒臭いし...
...で、そのまま流れて放置されてしまうのは、余りにも勿体ない!
 
技術系の書籍は概ね高価ですし、個人で賄うのは結構厳しいものがあります。
(中には、"◯◯文庫"、と個人名で呼ばれるような書籍群を社内に貯め込んでいる猛者もいますが...)
 
そこで、改めて "書籍買い放題!" 制度を立ち上げましたー!
 
事前承認のフローは無しです(運用ルール/ガイドラインは事前に社内共有しておく(社員専用サイトなどで))。
 
これから始めるので、
こりゃー社費で買うには余りにも違うだろー?、とか、
うわあーっ!、想定を遥かに超えて予算オーバーだあーっ!、とか、
...あるかも知れません。
 
ので、3ヵ月間は先ずは試験運用。
状況を見ながらルールを見直す。
費用の累積は、ほぼリアルタイムで共有可能にする。
...などを前提としました。
 
あ、ちなみに、購入報告・支払い申請は、slackの専用チャネルから行うようにしてます。
 
1年の長期貸出しの場合、"書込みOK!"
以降も1年単位で延長更新可能にしてます。
 
フロントサイド・エンジニアの場合などは、欲しい書籍は単に技術や業務という括りに収まらないはずです。
"良いものに触れる"という点から、過去のグラフィカルな作品や意匠が掲載された書籍なども社費の対象に想定しています。
(こういう本[↑]って、特に高いんですよね...。手が出にくいです)
 
さてさて、どうなるだろう?
 
運用していく中から、面白い事例とか波及効果などありましたら、
改めてこのブログで紹介させて頂きたいと思います!


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

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

Mr.山下、暴れる!

2017年の最初の全社定例会(1/13)で、顧客先プロジェクトにアーキテクト・兼・要件定義者、
兼・実質的にリーダーとして参加している山下さんから、
顧客のビジネス概要と、特に技術面を中心に共有可能な範囲でのお話をしてもらいました。
 
2017011303 大きな開発規模ではありませんが、顧客要求がぼんやりした状態から要求定義・開発スコープの明確化と、
スケジュール立て(希望納期の提示は有ります)、適用する技術要素の選定やリスクヘッジ方針決め、
開発プロセスの方針決め・実行と、参画早々に大忙し!
 
結構短期でフルスクラッチのリリース。 如何にも今時のプロジェクトです。
 
顧客の要求を具体化していく為に、プロトタイピングを適用。
ドキュメントは、山下さん自身のメモを含めて、基本的には MarkDown 形式での記述を選択。
整形表示されて見栄えも良く&見易いですし、そのまま顧客に見せても良い。
ビューワーはWebブラウザでOK。 参照デバイスを限定されない点も便利ですね。
 
WordやPowerPointで作成するのではなく、MarkDown記法を使うという選択は、結構トレンドのような気がします(妥当性が有る、という事だと思います)。
 
業務・ビジネスに関してはここには書けませんが、技術要素だけ記載します。
 
React.js、MaterialUI、webpack
ES6(動かないWebブラウザもあるので、babel でコンパイルしてJSに変換)
(Redux(検討中))、CSS3
某・クラウド分析用DB。
開発言語としては kotlin を選択(Javaにコンパイルできる言語(=JavaVM上で動くコードを吐く))。
 つまりは、同じくJavaVM上で動く言語で書かれた資産ならば何でも利用できる!、ということです。
 当初は scala も選択肢に含めていたのですが、メンバーの経験・意見を元に切り替えたとのこと。
 アーキテクトだからと言って、好き放題に技術選択できる・すべきという訳じゃありませんよね。
 現実に関わるメンバー、メンテナンス性、コード寿命(システムの想定寿命)、その他諸々の要素を考慮して
  結論を出さなければなりません。

SpringBoot(フレームワーク)、MySQL。
ビルドツール:gradle
リポジトリ管理:gitbucket
チケット管理:Redmine
コミュニケーション:Slack
WBS管理: asana(タスク管理)、instgantt(ガントチャート(5名まで無料)。asanaと連動してくれる)
 
...などなど。
 
2017011304 聞いていたメンバー内からの質問、
「どうしてVue.jsじゃなくて、React.jsを選んだのか?」に対しては、
「トレンドだし良いものだと思うし、自分が経験したかった!」と、何とも率直なお答えでした。

顧客要求として、"リッチUI"、"SPA(Single Page App.)" を希望されている、という点が大前提です。
(他にも理由が述べられましたが、ここではちょっと割愛...)
 
以前のプロジェクトや普段からの継続的な情報収集などから、各要素を判断したとのこと。
未経験要素も多分にあるのですが、リスク・コントロールの方向性も具体的な候補を想定して決定している
という点に、(当然と言えば当然なのでしょうが)感心。
 
会議の最後の振返りの際にも、
知らないキーワードが満載だった。勉強しないといけないといかん!、と思った。
...などが挙がりました。
 
自社内相互で刺激し合うことが出来るのは良いことだし、有り難いなあとしみじみ思います。
 
また、そういった情報を惜しみなく出してくれる山下さんの人柄と姿勢にも感謝・感謝です!
 


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

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

Amazon Dash Button を手に入れてみた!

12月の定例会にて、(ほぼ)レギュラーコンテンツである"IT-Tips or LT(Lightning Talk)"で、前田さん
2016120906_ 最近のホットな話題になりつつある "Amazon Dash Button" を実際に使ってみた!、の紹介をしてくれました(実物持参)。
 
改めて紹介するまでも無いかも知れませんが、一応、
同製品の要約を書くと...
・Amazonの特定商品(ボタン毎に事前に決まっている)をボタンを押すだけで注文できるボタン型端末
・Wi-Fi圏内でボタンを押して、商品到着を待つだけ
・アメリカでは2015年4月1日に発表

・日本では12/5から購入可能になった
 
利用における前提条件は...
・Amazonプライム会員であること
・「Amazonショッピングアプリ」が使えるスマートフォンなどがあること
・自宅(ボタンを使う場所)にWi-Fi環境があること
 
使い方は...
・アマゾンダッシュボタンの初期設定をする
  スマフォアプリから、接続先のWi-Fiや、商品内のバリエーションを選択するなどの初期設定。
  スマフォとの連携は、スマフォのスピーカーとDash Button内蔵のマイクで、超音波を使って情報をやりとりする
  とのことです。 へー、面白い!
・ボタンを押すだけで注文!
  但し、注文品が届くまでの間にうっかり押して重複注文になってしまうのを避けることも出来ます(設定次第)。
 
電源は、乾電池のグローバルな老舗メーカーである energizer社の単4リチウム乾電池で、"アルカリ電池の9倍長持ちする"という触れ込みだそうです。
 
ユーザーにとっては"ボタンを押すだけ!"ですが、その際に
ボタン内で行われる処理(概略)としては、
・(当然ながら)電源が入る。
・初期設定されたWi-Fiネットワークに接続する。
・IP重複検知のためにARPプローブ送信を行う。
・Amazonに向けてHTTPリクエストを飛ばす。
・自動的に電源を切る。
 
で、"あくまで注文できるだけの単純なボタン"ではない!、ところが面白い!!
 
ハック可能な物理ボタンとして活用することが出来、ライブラリも公開されているとのこと。
実際に応用されている例として、下記のようなものがある。
・ピザ注文
・タクシーの呼び出し
・車のエンジンを掛けて適温になったらクラクションを鳴らさせる!?
・病気の娘がトイレに行った回数の記録(Googleスプレッドシートに記録)
.....
 
で、IoTに関心のある前田さんもトライしてみた!
先ずは調査から!
.......残念ながら、様々な要因で一旦は断念...
 
・ハック例が大体Mac(前田さんはまだMacを入手していない...)
・Windows上でのドキュメントが全然見当たらない...
・環境要素として、Node.js、npm、Scapy...多くの要素の知識と習得が必要...
 
なので、当面は普通に使ってみることに。
 
ただ、今後もいろいろな可能性を考えつつ、環境構築の機会を探っていくようです。
 
社内の業務でも、Google App Script を使って"ひと手間を省く"ところから効率化を実践している前田さん
(↑ 自主的な判断・行動&成果はチーム内に共有してくれました!)。
 
slack社とGoogle社の結び付きも強くなりましたから、連携処理もし易くなりましたし、
更なる"プチ時短"を実現出来るかも知れません("出勤ボタン"で、月報(Googleスプレッドシートで社内運用してます)に自動記載するとか)。
 
"何かを作り出したい"という衝動・欲求と、"こんなものが欲しい!"(自分、或いは周囲からの呟き)と、
加えて"実現(先ずは試作)できる技術を持っている"ことは素晴らしいことですからね!
 
あ、ちなみに、Amazonからは"AWS IoT ボタン"なる、公式にプログラミング可能なDash Buttonも発売されています(20$)。
但し、発売とほぼ同時に即完売だったそうです。
残念でした.....
 
でも、恐らくは次の機会が有るでしょう!
 
"Amazon Dash Button"。
存在は知っていても、実物を見たのは初めてでした!
定例会の最後の振返りでも、"結果的に成功しなかった話でも、実例を発表してくれたのは良かった!"とのKeepが有りました
 
前田さん、有難う御座いましたー。


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

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

LT:昨今の小学生事情について

全社定例会の中に、"IT-Tips or LT(Lightning Talk)"というレギュラーコンテンツ枠を設けています。
 
"LT"を敢えて"or"で繋いでいるのは、言うまでもなく"何の話題でもいいよ!"ってことです。
 
要は、"制限時間を設けて人前で話をする"機会を設けることでの訓練的な効果を狙うのと、
"誰が、どんなことに興味を持っているのか?"の相互理解・共有する、という2点が元々の目的です。
 
2016111104 11月の定例会では、"母"でもあり"エンジニア"でもある中里さんからのLTが有りました。
 
お題は、"昨今の小学生事情について"。
 
お子さんが今年の春に小学生になった、とのこと。
世代毎に環境や教育システムは変わっていくわけですが、中里さんが驚いたこと・感じたこと。
・宿題が多い!
  1年生なのに結構宿題が多くて、中には"音読"を親が聞いて採点する、などという課題も。
・パソコンで日記をつける
  当然、キーボードから入力しなければなりません!
  パソコンが家に無い家庭はどうするんだろう?
  スマートデバイスに外付けキーボードとか買って繋げたりするんだろうか?

・食事事情
  食関連のイベントとかでも、国産原料にこだわったり、衛生面から"塩にまで熱を通す"とか...
・文章を読み取る力を伸ばしている
  国際的な学力比較・能力比較の点から、日本の弱い部分を強化しようってことでしょうか。
・土曜日も学校
  これは、"土曜は休み"(ゆとり)方針と、"授業時間が足りないので土曜も登校"方針との間で揺れてますよね。
・"さくらんぼ計算"なる教え方
  算数の解き方を教える段階での、考える手順の説明が不可思議??
  "答えを出す"よりも、"考える力"の育成を重視ってことらしいのですが...。

・いつまで勉強を見てやれるのだろう?"、と不安も感じる(追付かない?)
  "答えは分るけど、解き方が昔と違う"ので、下手に説明できないってケースが出て来ますね。
  子供の教科書を読んで、改めて悩まないといけなくなるかも知れません...。
 
定例会当日は、同じくママさんエンジニアであるJさんは、2人目のお子さんの育児休暇中でお休み
他の女性エンジニアは独身ですが、
男性陣の中には子持ちの連中もいます(筆者も)ので、共感できる部分も多かったろうと思います。
 
さて、"母"であり"妻"であり、"エンジニア"でもある(勿論"一個人"でもある)中里さん、
普段の業務では"町田ラボ"(顧客先に詰める・或いは半常駐する自社メンバーと主に連携しつつ、町田で開発業務をこなす)
のリーダーを務めてくれています。
 
自身では、「やるべき事に追われていっぱいいっぱい」みたいなことを言っているのですが、
はた目にはいつも落ち着いて、成すべきこと、改善すべきことなど、生産性を意識しつつも柔軟に、
かつ根気よく対応してくれているように見えます。
 
とは言え、お子さんの生活時間を考慮した勤務時間帯で稼働しなければならないので、バランスが難しい。
自身の仕事の切れ目は勿論のこと、メンバーの今日・明日・当面のタスク配分・その他も考えないといけない。
 
加えて、顧客先にスポットで出向くことも有りますから、家庭生活のタスク・ピースとの組合せにも工夫が要ると思います。
 
多くの要素の間を頭と体でスイッチし続けると、疲弊も激しくなるので要注意!
(これは業務に限った話ではなく、人間、というか生物の基本じゃないかと思います)
体の調子も崩し易くなります。
 
この辺は、逆にメンバーの方で旨く支えてあげて欲しいのですが、
手に余る部分が出て来てもおかしくはないので、その辺は会社としてのマネジメント(サポート)が何処まで
出来るか?、に掛かってくると思っています。
 


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

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

なぜ人と組織は変われないのか!(え?)

ワークショップ実施の記載が有ったので、
「よし、11月の全社定例会で、思い切ってやってみるか!」という事でやってみました!
 
「変わりたいんだけど、変われない」・「必要なのは理解してるし困ってもいるんだけど、実行できない」など、
業種とか、私生活上のことも含めて、こういう事(↑)って有りますよね!?
 
上記の書籍は、発達心理学と教育学の権威にしてコンサルタントでもある著者達が、30年をかけて開発したアプローチだそうで。
2013年の出版物ですが、既に多くの(IT業界に全く限定されず)採用されているとのこと。
 
自己啓発本というのは、ともすると禁欲的・継続的で強い自己制御を前提とする内容が多い気がします。
 
その点、ここで紹介されている内容は、
「変わりたいけど、変われない」のは、「変わることを拒む、無意識の目的や前提認識があるから」であって、
それを知らずして理性だけで目標を達成しようとしても(大抵は)無理、ということ(←かなり乱暴な省略ですが...)。
 
人は理性だけで動くわけではなく、むしろ心理や既成観念を重視しながら、自己分析(信頼できる何名かの仲間の協力があると、
格段に良い!
)し、改善のための実験行動と結果分析を繰り返しながら改善していこう
、というもの。
 
実行段階での各ステップに対して、標準としてのチェックシートが用意されてます。
洋書に多く見られる傾向ですが、具体例が多数掲載されています(ちょっとウンザリする位に...)
 
それらの中から、"2時間に満たない時間枠内でのワークショップとして実行可能なシナリオ"を探ってみました。
 
この手法では、最初の具体的なステップである、"免疫マップの作製"の後に、
"改善のための実験の設計"、
"実験結果の分析(視点のチェックリストが掲載されている)"、
"実験結果の評価"、
"次の実験の設計".....
...と続きます。
 
が、さすがにこれ全部を2時間程度の定例会の枠内に押し込むのは無理が有ります。
(特別に時間延長するとか、土日に設定しろよって話になるのでしょうが、現実的にコストの問題もあります...)
(正直のところ、ワークショップ自体を上手く回せるのか?、皆が必要と判断・認知できるか?、も企画段階では不明です...)
 
なので、最初の大きなステップであり、割とこの手法の効果を実感(!)しやすい部分として、
"免疫マップの作製"(グループ内での相互コメント有り)までを実施してみることにしました
 
201611141 事前に想定した時間枠は80分、実施結果は90分。
 
各人が作成した"免疫マップ"に対して、チームメンバー相互に共有し、コメントし合うのに(予感はしてましたが)
想定以上の時間を要しました。

(これ↑を緩和するために、チーム人数は3名にしたかったのですが、4名チームができてしまった...)
 
が、言い換えれば、"自身では気が付かった点や方向性でのコメントが展開された" 結果でした。
メンバー間の信頼や理解があってこその結果だと思うので、これは率直に嬉しいことです。
 
201611142201611143 今までに、
開発プロセス系(LEGOブロックによるスクラム疑似体験、インセプションデッキ作成、その他)、
チームビルディング時の相互理解ワーク(偏愛マップ、他)、
その他カテゴリー(デザインワーク)、
...いろいろとやって来ましたが、
今回のワークは各人の個人的な課題を吐き出した上に、チーム内にさらけ出し、
コメントし合うという、ある意味では負担(ストレス)の強さではトップ級の企画だったと思います。
 
実はそんな理由から、このワークは同日の定例会の最後の方に配置しました。
 
皆、予想以上に熱心に参加してくれた分、相当に消耗した様子でした(企画者としてはホッとする反面、参加メンバー達には申し訳なかったのですが)。
 
定例会の最後の振返りで、「今まで知らなかった手法を知ることが出来て良かった」という Keep 発言を聞けて良かった。
 
今回のワークのような形態に囚われず、"何かしらの問題にじっくりと取り組む" 場合のアプローチの1つとして
実生活・実務のどこかで部分的にでも活かしてもらえたら良いなあ、と思います。


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

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

元 モーニング娘。初代メンバーの石黒彩さん

今回のブログ記事は、株式会社アスペアの代表加藤が担当致します。
 
子育てしながら書籍出版やテレビ出演などで活躍中です
 
株式会社アスペアが、子育てしながら働く「ママさんエンジニア」を積極的に募集していることから、
子育て繋がりでインタビューを受ける機会がありました!
 
 
 
町田相模原周辺に住むママさんエンジニア採用に積極的なことには背景があります。
 
弊社に新卒で入社した女性社員が結婚し子供が生まれ、産休・育休をとりました(写真とはまた別のメンバーです)。
会社にとっては大変痛手ではありますが、結婚してお子さんが生まれることは大変めでたいことです。
 
それまでの働き方である月間残業~(10)~30時間の勤務を100として、
辞める(
100の稼働が出来ないので復職できない)ことを0(ゼロ)とすると、
0になることは会社にとってもったいない。
 
80とか60の働き方であっても戻ってきてくれることは嬉しい。
 
以前からそう思っていたので、本人の望む時期に復帰して、望む働き方で働いてもらう。
そのためには「制度・仕組み」を作るだけでななく、普段から戻ってきやすくなる「社風」づくりを醸成してきました。
 
おかげさまで育休後、すぐに会社に復帰し子育てしながら頑張ってくれました。(いまは2人目のお子さんの産休に入っています
 
それをいいことに、、すでに子育て中の方を新たに中途採用して、現在活躍していただいています(写真・左の女性)。
 
本人は最初パート勤務を覚悟していたようですが、面接で会話をしているうちに正社員として働けると思っていただけたようです。
 
弊社は(出勤義務のある)コアタイム有りのフレックスタイム制ですが、子供が熱を出して保育所から連絡があった場合など、
コアタイム中でも皆で快く送り出しています。
 
会社としても、即戦力となる経験豊富なエンジニアが仲間になってくれて、ありがたい!
それどころか、チームリーダーとして若手の育成も担ってくれています。
 
本人も豊富な経験を活かせる職場が自宅近くにあって、安心して働けて喜んでくれているようです。
 
経験を活かせて働きやすい会社が増えれば、世の中がもっと明るく、もっと活性化すると本気で思っています!


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

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

«社外セミナー等への参加は...