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

前回の定例会の中で、山内さん自ら立候補した上でのコンテンツ。

"書籍紹介" ということだけは、事前に分かっていました、が．．．．．
果たして何を、どんな理由で取り上げるのだろう？？

フタを開けてみると．．．．．
対象書籍はリーダブルコード。

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

業界内では著名な書籍で、多くの方に読まれていることと察しますが、
"より良いコードを書くためのシンプルで実践的なテクニック" を集めたものです。

Amazonのサイト上で見ても、とても高評価！（低い評価がごく僅かの割合しかない！、というのも珍しいです）

お勧めなのは分かる！

分かるけど、敢えて定例会で取り上げたいってのはどうして？？．．．と思ってましたが．．．

何と、"解説"を紹介するという！

「実際にやるとぶつかること」の部分が必読だよ！
是非、先に解説（ココ↑）を読んでから本文を読んだ方が良いよ！、というのが趣旨でした。

"読んだだけでは綺麗なコードを書けるようにはならない"
　"そもそも、どこが直すべき箇所かわからない"
．．．という当たり前の事が書かれている。

"まずは何をすればいいの？" ⇒ "実際にやる！"
具体的には、何をどうすれば良いのか？、に関しても、解説に書いてあるよ！、と。

それを先に読んでから、本文を、各人の関心のある部分から（考えながら）読む方が良い、ということでした。

（その方が、時間の有効活用度が高くなる：同書籍をより深く活用したことになる）

小説などの創作物の場合だったら、解説から読んでしまったらつまらない。
（でも、そういう方もいるのでしょうね。解説内に敢えて"先ずは本文を先にお読み下さい"と書かれている場合もありますね）

技術書の場合なら、
"こういう視点で考えながら読むといいよ"的なことは、出来れば"まえがき"とかに書いてあると有難いですが、

そうとも限りません。

増してや、ネット上で高評価の書籍だったりすると、普通に先頭から読んでしまうのが人情です。
普段なら目次の構成やまえがき、解説などから慎重に読み進め（品定め）してから入手する人でも、です。

なるほど、こういう書籍紹介のパターンもアリなんだなあ．．．とも感じさせられました。
面白いです。

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

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

今年4月の頭から、第二新卒的に転職・入社して来た新人君の社内研修が、7月初旬で一旦終了しました。

新人研修と知っても、言うまでも無く、その人の知識・経験値に応じて研修の実施内容やペースが必然的に違ってきます。

漏れなく、無駄なく、が原則ですが、
そもそも入社時点での練度によって、研修期間終了時の目標到達状態・レベルなどの設定も違ってきます。

今回の場合は、1年間の社会人経験は有りますので、マナー研修など個別には設定せず。
専門学校を出て来ているので、"コンピューターが動く仕組み"やら、"プログラムを書いてコンピューターを動かすこととは？"、"処理の手順を組み上げる"、etc.の基礎は不要です。

が、"アプリケーションやシステムの開発は初めて"、なので、"DBもWebも知識が無い"状態。
前職で、ツールとしてPythonは少し触ったことがある。

ということなので、研修の要素群と到達レベルの設定からして、模擬開発を含めて3ヵ月間を想定しました。

少し実戦向けの補完カリキュラムなどを足しながら、7月上旬には入社時研修は完了しています。

その後の最初の定例会が7月度（7/21）になりましたので、そこで研修レポートを発表して貰いました。

研修レポートは、研修者本人と研修内容・メンターによってレポート内容や方向性が違ってきます。
"必ずこの形！"というのは決めていませんし、決め打ちできるもの・すべきものでもありません。

今回の研修では、言語・フレームワーク的には Ruby on Rails だったのですが、諸事情があって、メンターが途中で入替ってしまいました。
特に、最後の模擬開発のメンターは RoR 未経験だったので、研修者本人にはちょっと申し訳ない対応になってしまいました．．．。

窮余の一策として、RoR実務経験のあるメンターがオンライン（slack）でサポートするという一幕も有りましたが、やはり効率は良いとは言えないですね...。
（ソースレビューもオンラインで行ってくれた）
まあ、全く無いよりは格段に良かったと思いますし、オンラインでサポートしてくれた側にも負担が掛かったので、
申し訳ない＆とっても感謝していることに変わりはないのですが．．．

レポート当日は、パワポを元に報告してくれました。
模擬開発で作成した小さなアプリの動きも披露しつつ、です。

この記事に、本人が作ったパワポのページを画像化して貼ります（自己紹介ページだけは省きました）。

最終段階でのメンターが、何度もレポートの練習・指導をしていたのが印象的でしたが、
結構良い形・内容になってるんじゃないかと思います。

模擬開発に関しては、方針的に悩ましいところも有るのですが、
実務の一部：実際に顧客に納品されるコードを書く方がモチベーションが上がるのではないか？、とか。

しかし、メンターが張り付いていたとしても、慣れない人間が納品用コードを書くことに対しての不安感は
相当のものだと思います。

それに、実際のシステムの一部で研修を行う場合、全体仕様が見え辛いと思います。
仮にも"実際に使われるアプリやシステムの一部分"なので、結局、自分がどんなプロダクトに対して、
何処でどう動く何を作ったのか？、どう貢献しているのか？、見え辛いのでは意味が乏しかろう？、と。

それよりは、顧客に使われることは無いとは言え、仕様は事前に決まっている、機能も構成もモジュール構成まで全体が見えるし、自分で作る。
機能追加や改修課題、リファクタリングなども、自分でこなす経験をさせる方がベターだと考えています。

色々と悩む機会・要素が増える面もありますが、"どうしてこうなんだろう？"、"もっと良くならないんだろうか？"、いろいろと悩んで欲しいと思います。

当面はメンターは継続担当しますし、先に担当したメンターもオンラインや定例会の時などに対面でフォロー
してくれています。
と言うか、熱い質問を投げ続ける新人君を見ていると、"ああ、嬉しいなあ"と思いますね。

"自律的に考える"⇒"疑問・質問が生じる" のは、とっても良いことですから！

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

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

筆者がtwitter上でフォローしている方の中に、吉羽龍太郎氏がいます。

氏のtwitter上での呟きで、スクラムマスターロールプレイなるスライドが公開されていました。

内容を拝見してみると、まあ表題の通り、開発スタイルとしてスクラムを適用していることが前提にはなっている
のですが、必ずしも限定しなくても実務ケースでのシミュレーションとして使えるのでは？

．．．．．と考えて、6月の定例会の中で60分ほど枠を取って実施してみました。
（これまでにスクラム／アジャイル関係の勉強会やワークショップなど、幾つかやって来てましたし...）

ちなみに、同日の出席者の中で、スクラムを実務で適用していた経験者は１人のみでした。

研修中の新人（第二新卒的な人）もいるので、
同じく吉羽氏の作成されたスクラム概説図を使わせて戴き、用語などの要点のみ"おさらい"を最初に行いました。

60分の枠の中で、最初の数分を上記のおさらいに充て、残りをディスカッション形式にしてみました。

保険として？、反応が悪い場合に備えて、自分でもどんな回答が考えられるか？、を
可能な限り挙げておいてみました。
場が余りにも展開しないようなら、"例えば"という形で小出しにしてみようかな？、というつもりで.....

結果、話題に挙げられたのは最初のスライドから3つ。

スライドの p.5："常態的にスプリントバックログが消化し切れない、何故か？、どうする？" に対しては、
おおよそ下記のような発言がありました。

・スプリントの振返りの場で、全員で考える。
・"完了"としているストーリーの精度も疑問がある。完成の判定基準に問題が有るのでは？
・各ストーリー／タスクに対しての見積が甘く、しかも学習＆改善がなされていない。
・他プロジェクト等からの頻繁な割込みが有るのかも？
　⇒割込みを抑えられえるなら抑える
　⇒割込み対応要員を分けてしまう。←の人数は、チームメンバー数としてカウントしない。
　　⇒残業対応で賄うことはしない！
　　　⇒プロダクトバックログの全数消化は無理になる、或いはプロジェクト終了日の延期の了承をもらう。
・スプリントバックログの各々の単位が大き過ぎるのでは？、見積精度が下がるのを避けられない
　⇒粒度を小さく、分割する
・メンバー間の繋がりが弱いのでは？
　⇒"個人の集まり"ではなく、"チーム"としてスプリントの完遂を担保する意識を共有できるように
・勤怠が悪いのでは？

上記に出なかったもので、筆者の方で想定していたのは下記のようなものでした。

・ストーリーの仕様が不明確(確認に時間が掛かる・矛盾が見付かる等)、プロダクトのinputとして不適切？
・メンバー構成が拙い(スキル問題)？
・スクラムの各種プラクティスの理解不足？、或いは手段が目的化している？
・メンバー中の何名かが？プロジェクトを掛け持ちしている？
・タスクへの分解の仕方、タスクの取り方が拙い？
　⇒複数タスクが同時にDoing(仕掛り中)になると、生産性・品質は低下する。

これら↑に関しても、軽く触れてみました。

で、3つの課題に関してディスカッションした後に、今回のセッションに関しての振返りを行ってみました。

Problem：
・スクラムに関して(自分達が)実戦的な理解が無さ過ぎてイメージが湧かない。分からない。
・やっぱり回答例（スクラム的に望ましい現実的な例）が欲しい！

Try：
・出題されたPOが余りに無能過ぎるので、そのPOのペルソナを作ってみたい。(恐らく半分以上は怒りか？)
・スクラム経験者のワークを見学してみたい。
・POとしての社内的な教育機会が有るべきでは？！

Keepに分類できそうな発言は残念ながら無かったのですが、
スクラムの実務経験が無いメンバーが殆どだった割には、ある程度のディスカッションにはなったように
思うのだけれど．．．手前みそでしょうかね．．．。

なお、当"ロールプレイ"を実施してみよう！、と判断した筆者の反省としては、
・案の定ではあったが、実戦経験が圧倒的に足りない．．．
　⇒機会が有れば、請負・自社内で作業がほぼ完結する案件で実践してみたい．．．
・せめて事前にお題を公開しておくべきだった、かも．．．（タイトルしか事前告知していなかった）

最後に、これは言い訳がましくなるのですが、
今回の定例会には、技術メンバーの半数未満しか出席していませんでした。
（繁忙期の大所帯プロジェクトが複数、ピーク状態だったため）

先月も同様の状態で、5月度は定例会自体を開催中止にしたんです。

さすがに2ヵ月連続で中止はしたくなかったので、コンテンツを少人数でも展開できそうなモノに入れ替えて実施しました。
（"実プロジェクトで利用した技術ベースでのUI･UXデモ"も予定していたのですが、勿体ないので次月に繰り越してもらいました...）

7月度の出席者は改善されるはず。
．．．と言うより、改善すべく、"定例会自体の開催時間帯を見直すべき！"、との案が出されました。

小さなお子さんの子育て中のお母さんエンジニアが何名かいて、常態的に出席出来ていないという問題点への改善も必要という事です。

現在、Googleフォームベースでのアンケートを配信し終わり、回答待ちの状態です。

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

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

6月の全社定例会議では、たまたま書籍紹介的なコンテンツが2つ重なりました。

1つ目は、

"Joy, Inc. 役職も部署もない全員主役のマネジメント"
リチャード・シェリダン(著)

これは、筆者からの紹介。簡単にスライドに要約してデモりました。

当初は個人的に図書館で借りて読んだのですが、予想に反して余りにも面白い！
と言うか、いろいろと刺激的！

そのまま、あれやこれやを真似することは出来ませんが、
・自社や、顧客との関係など、今のままで問題無いとは到底思えない。
・小さなことから実験して、早く間違えて、早く学習することを積み上げる。共有する。
・上長とかリーダーとか顧客とかに、"依存"しない。自身に問う。自分の考えを持ち、議論する。
・"こうしたらどうだろう？" という仮説が非常識なものだったとしても、先ずは小さく試してみる。
・(その他諸々...)

色々な書籍やネット上の情報、セミナーやワークに参加してきた内容とかが、現実的に "ああ、こう活かせば良いのか" と
腑に落ちた感がありました。

これは、この感覚を忘れてしまわない／時の中に埋もれさせてしまわない為に、是非とも書籍を買おう！
会社で買って、皆に紹介しよう！
折に触れて話題に出し続けて行こう！、と思い至りました。

と、読んで感化された本人は熱くなっている訳ですが、
要約だけを聞かされても、恐らくは余りピンと来ないだろうな．．．と思ってました。

作成したスライドの最初でも、
"出来ない、やらない、必要ない、の理由付けばかりを探さないで下さい" と敢えて書いておいたのですが、
話し終えた後の反応も概ね冷めた感じのものでした。
（これ↑は、大いに筆者の力不足によるところが大きいのだろうと思いますが）

まあ、とにかく部分的にでも、1人でも多くのメンバーに読んでみて欲しい。
筆者自身が、機会を探しながら試せることを1つづつでも試して行ければと思ってます。

さて、もう1冊の紹介は、IT-Tips（10分枠）の中で小障子さんが紹介してくれたモノ。

"多動力"
堀江貴文(著)

自身のヒューマン／ビジネススキルを見直し補完する上でも、あれこれと書籍を当たっている中での1冊のようです。

アスペアには、"書籍買い放題"制度が有ります（社費で購入して、保管は個人が行う＆書き込みもOK）。
が、この本に関しては自己投資として敢えて自腹で購入したとのこと。

気持ちの持ち方次第なので、要は有効に活かせれば良いと思います。

さて、たまたま書籍紹介的なコンテンツが2つになった今回の全社定例会。

"こういう事で時間枠が欲しいと要求するのはアリですか？" と問うてきたのは山内さん。
"是非！" と答えると、"それでは次回に30分欲しい！" と、次回コンテンツが1つ即決しました！

自発的なコンテンツは大歓迎です。

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

スパルタンレース参戦！＆高尾山...

アスペアでは、顧客先での開発業務と、自社内（町田事務所）での開発業務が有ります。

2月半ばのある日、とある顧客先（アスペアから社員が5名、パートナーさんやフリーランス（←どちらも元・アスペア社員ですが）2名が業務中）
で、プロパーの方から"スパルタンレース"参加のお誘いを受けたとのこと。

"参加者を待ち受けるのは火、泥、水、有刺鉄線、さらには地獄のような障害物の数々。スパルタンレースは参加者の肉体的・精神的限界を試します。"（主催者Webサイトから抜粋）
．．．ってことで、生半可な気持ちで参加すると、ちょっとヤバいことになりそうです。

弊社社員で、PM補佐的な役割をさせて頂いている（と言うか、遊撃部隊的にやるべきこと、気が付いたことは
何でも言って・調整して、プロジェクトが現場で現実に回るようするぜ！的な立ち位置のようですが...）
2名が参加了承！
顧客先のプロパーの方、他社の方、4名と一緒にチーム参加と相成りました！

自主的に筋トレやランニングで基礎体力作りに精を出す日々。
（業務の方も、特にロールが重い＆多岐に渡るので日々の疲労も結構なものだと思うのですが...。凄い。）

5月27日・土曜日。当日は快晴！

弊社側メンバーが2名、参加者の奥さん2名が応援＆見学に現地（神奈川県内の元米軍基地の広大な敷地）入り。

チームとしては脱落者なしに、全員がゴール出来たようです。

擦り傷、打撲は数々あれども、大きなケガや故障が無くてホッとしました。

楽々制覇！、には程遠かったようですが、事前にトレーニングをしておいたおかげで
それ程の筋肉痛でもなかった。．．．．．とは本人たちの弁です。

感想としてはどうだったのかなー、と思いましたが．．．
"楽しかった！"、"次（10月）までにトレーニングに励む！" と、もう参加することが前提の勢い！

若いよなー！！
．．．．．と言いたいところですが、ウチから参加した2名とも40歳オーバーです。
で、応援だけに行ったメンバーは30代後半．．．．．

気力の問題ですね！　ガッツです！

"楽しそうだから、やってみよう！"、これですよ！

で、話変わって、翌日の日曜日には"高尾山登山"イベント。　本日も快晴！
あ、こちら↑は、アスペア内の別メンバーの企画です。

アスペア社員：男女数名と、子供連れで参加したメンバーもいました。
で．．．．．、昨日のスパルタンレースに参加したメンバーの内の１人が、こちらにも参戦！

さきほど、"それ程の筋肉痛でもなかった" と書きはしましたが、
高尾山と言えども山登りであることに変わりはなく。
さすがに、ちょっと辛かったようです。

アスペアでは、特に"全社員・強制参加！"、みたいな企画（風土）は一切無いのですが、
"楽しいことで羽目を外そう" 的な企画はたまにあり、参加したい・出来る人が参加して、
楽しい・嬉しい時間を共有してます。

と、その辺のことも社員専用Webサイト上の週報の中だったり（←他メンバーから"ステキ！"マークがカウントアップしますね）、
slack上とかに、様々な文章や写真が共有されてます（あくまで自然発生的に、です）。

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

ただいま研修中：タスクの粒度は？

4月頭に中途入社した新人さんが、絶賛・研修中です。

予定・進捗などは、執務室の壁（真っ白です）を"かんばんボード"として利用し、
研修内のタスクを付箋で表してます。

マグネットシートを任意に切り貼りして、エリアの名称を書き込んだり、エリアの境界線を作ったり。
（ちなみに、朝会は町田事務所にいる全員が（関与しているプロジェクトが別でも）一緒に、立って行ってます）
（研修中の彼も、当然、一緒に参加します）
（進行役は日単位で持ち回り。忘れないように、"朝会当番"と書いた小さな立て札をその人の席に置いておき、当番の人はこの立札を持って進行をするルールです）

で、"かんばん"の写真は、slack上の研修用チャネルに挙げてもらってます。
社員専用のWebサイトに簡易なフォームで日報をアップすると共に、上記の"かんばん"の写真へのリンクを貼ってもらってます。

社外で作業をしているメンバーでも、slackからかんばんを確認する方が楽チンです。
コメントを入れるのも、スマートデバイスから簡単に行えます。

さて、ここ最近は Ruby on Rails のチュートリアルを実施中。
毎日のかんばんに変化が無くなりました．．．．．

うーん．．．．．．．どうしたんだ？、でも日報の文章を読むと進捗はある様子。

でも、かんばんボードの方を見ても．．．．．．つまらない。

付箋を見ると、予定工数が37.5時間になってる．．．．．

デカ過ぎるやん 　　1週間もかかるやんか！？

これは、研修を行っている本人も、1日単位での"進んだ感"（達成感）が得られなくて辛いのではないかな？

まあ、プロジェクト／プロダクトやロールによってタスクの管理上の粒度基準ってのは違うとは思います。

でも、"人間がチームを組んで楽しく'見える化'と共有の運用ができる"
　＝ 小さな達成感を積み上げることが出来て、
　＋ ストレスが幾分かでも緩和でき、
　＋ 疲労度も減り、
　＋ 生産性・品質の向上にも役立つ...はず。
という効果も狙うのであれば、
"毎日、最低でも1枚くらいの付箋は、'Done' に移したい！"。

この達成感がクセになる！というメンバーが多い（人間なら当然だと思う...）ですし、
1日の区切りにもなります（多少なりとも、気持ち良く帰宅できます）。

なので、1タスクの時間数は最大でも7h程度、出来れば4h程度を上限基準にしたいところです。
チケット管理ソフトで言うところの、子チケットに相当するような考え・管理でOKだと思います。

本人に聞いてみると、"何か全然進んでない感じがする..."。

これ↑、メッチャ拙いです！

なので、チュートリアルの章毎にタスク化し、親付箋の脇に Doing 付箋をペタっと貼る感じに変更。

（実務だったら、親付箋の下端に貼る感じでしょうかね．．．）
親付箋のタスクが全部終わると、Done のエリアに縦に幾分か長くなった付箋群が出来上がる．．．という具合に。

早速、メンター担当が対処してくれました。
当日の日報に上がったかんばん写真に変化が現れてますね！

良かったー！

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

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

先月（4月）の頭に、同業・他分野から転職・入社してきた當山（とおやま）さん。

アスペアで行っている、Web系（フロントからバックオフィスまで含む）開発系の技術、関連ツールやら
プロセスやら、そもそもコードのデザインとかお作法とかから社内研修を行ってます。
（アスペアは基本的に必ず社内研修です。新卒の方を採用した場合に、マナー研修などを外部の合同研修などに依頼してきたことはありますが、その点だけが例外です）

社会人・１年経過の状態で、役割も開発の中心部にいた訳ではないので、ほぼ新卒新人と同様に研修期間は
3ヵ月間で計画を組んでます。
（主たる言語・環境は、Ruby on Rails。ある程度実戦を意識した模擬開発演習も含んでます）

IT系の専門学校を出ているので、基礎の基礎はOK。

とは言え、連日新しい学習内容の連続で、更にそれらを関連付けて理解し思考して行かないと中間課題も消化できない。

難しいです。

特に、Web系は機能を実現する上での物理層・論理層・プロトコルやら概念なども多く、言語やツール・その他周辺知識も
派生して多くなるので、頭の中で統合的に理解するのは、なかなかに苦労すると思います。

さて、そんな苦労しつつも楽しい（！？）毎日の中で、
"4/21の全社定例会で何か発表してみようか！" という、メンター役の渡辺さんからの暖かくも劇的なお言葉。

自己紹介も兼ねて、早々に人前で発表するという機会を設けた方が良い！、という暖かーい親心！
素晴らしいですね！！　　ステキ！
"鉄は熱いうちに打て！"とも言いますし。

で、全社定例会の当日での登場は、"LT(Lightning Talk) 又は IT-Tips"コーナー（質疑を含めて10分枠）。
発表してくれたのは、"ATOMエディターの紹介"でした。

業界内の方ならご存知の方も多いかと思いますが、
・オープンソースのテキストエディタで、Linux, MacOS X, Windows 上で動作する。
・プラグイン拡張が容易で、多数のパッケージが公開されている。
・デフォルトは英語ですが、日本語化パッケージを導入すればベタな日本人でもOKっ！です。

ライセンスフリーのエディタとしては、Microsoft の Visual Studio Code が存在感を増しつつありますが、
さすがの多機能・Visual Studio のノウハウを詰め込んであるだけに、ちょっと遅い...という声も有りますね...。

ATOMより軽量のエディタも有るようですが、オープンソースでマルチプラットフォーム対応、拡張パッケージが豊富な点などから
ATOMを選んだようです。

HTMLの基本構文の理解と演習の際に、構文に応じたハイライト表示や、入力時のオートコンプリート機能などが

学習効率を上げてくれる！（タグの閉じ忘れなどもある程度防止できる）、ということで、便利・便利！

"便利"が過ぎると学習効果が損なわれる場合も有りますが、余りに単純な部分に手こずって時間を潰すのは
勿体ないですし、"生産性が低い状態に慣れてしまう" のも絶対に避けたい点です！

トツトツとした當山さんの進行と語り。
緊張している様子は感じられないのですが、当然ながら慣れている訳でもなく．．．

それでも、質疑を含めて、予定時間枠の10分にジャストで収まりました！
おお！、素晴らしい！　（←定例会の最後の振返りで、Keepとして他メンバーが挙げてくれました！）

多少の苦労をしてでも、なるべく社会人経験の少ない内に、いろいろと経験しておくのは良いことです。

勿論、オーバーフローで心身の調子を崩すようなことは避けるべく、メンター＆周囲のバックアップを含めて
声掛けしたり、お昼時の雑談などでフォローしてくれています。

さてさて、入社1年後にどんな活躍を見せてくれるか？
（活躍できる機会を設定できるのか？、とも言えますね）
今から楽しみです。

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

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年度はどうなるのだろう？

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

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

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ヵ月も経っているので内容のバージョンアップ？が可能なはずだし、
そもそも前回のワークに参加できなかったメンバーも数名います。
ちょうど良いタイミングでしょう。

ってことで、一応、"偏愛マップ"の実施目的・内容・進め方などを一通り説明してから、ワーク開始！

・"書きたくても漢字が思い浮かばない..."という職業病者が続出していたり（⇒ネット検索しまくり）、
・"前回の内容から変わってないから、前回のを見ながら描く！"なんてメンバーもいれば、
・"絵を描いてみたけど、サイトで確認したら全然違ってたよ"、とか、
・"アレは封じる！"、とか、怪しげな発言が飛び交ったりもしてました。

なお、前回のワークでの問題点として、
・"用紙がB3ではちょっと小さ過ぎた"、
・"コピー用紙を使った為に、裏写りした(水性マーカーだったので机の汚れは残りませんでしたが)"、
．．．などが有ったので、今回は大き目の用紙で、材質も画用紙にしました。

絵を描けるように、マーカーもなるべく多色を用意しましたが、ちょっと時間が足りなかったか...
（そもそも、絵心のあるメンツが少ないってのも有るのかも知れません）

ネット上では、このような[↓]サンプルも紹介されていますが、とてもここまでは描けないな．．．
※ http://tamkaism.com/2014/06/henai-map/
※ https://note.mu/tamkai/m/m719115669c6b

ちなみに、今回の定例会後に、中途入社・新規パート契約の方の歓迎会を行いました。
ので、定例会自体が短縮バージョン。

加えて、前年度・新年度以降の方針・計画などの話が役員から展開されたので、ワークに割り当てられる時間枠が少なかった...。
なかなか難しいです。

まあ、それでも、最後の振返りで､"新規採用者が入った時には必ず偏愛マップやりたい！"とのKeepの声が聞けました！

この後の歓迎会でも、話題の繋ぎとして有効に作用した様子だったので、実施して良かったと思います。

前回のワークで作成したマップは、社員用Webサイトの"社員名簿"からリンクさせてますが、
今回作成した分で更新・登録しておこうと思います。

これは余談ですが、同ワークの司会・進行・撮影は筆者が行ってます。
ので、自分の分の偏愛マップは未だ1回も作成されてません．．．．．

"見たい！、書いて下さい！"と具体的にリクエストされてしまったので、後日・自分の分も
（ワークの時と同じ時間制限で）作成して、社内公開しようと思ってます。　あはは.....

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

Mr. 速形、ブチかます！（ラムダ式）

3/17が3月の全社定例会の日でした。

この日は、個人的な事情でアスペアを卒業することになった速形さんから、
事前には予定の無かった "IT-Tipsを是非やりたい！、10分枠をくれ！" との嬉しい飛び込み発言があり、
当日に急遽、枠を設けました

（ちなみに、同日の定例会終了後に彼の送別会を行う予定だったので、定例会は短縮バージョンで行ってます）。

どんな内容かなー？、と思っていたら、タイトルは．．．
"わかる！ラムダ式"

技術のトレンド系・最先端と言うより現実的に身に迫って来ているけど、

実案件では意外と導入が遅れていたりする要素を積極的にフォローアップしている速形さんらしい出し物設定と言えそうです。

あ、ちなみに、
なぜ、急に "全社定例会の枠を設けてくれ" と自ら要求してくれたのか？に付いては、
"定例会の場で、皆の前で話すのが楽しかったし、色々と突っ込んでくれるのも面白かったので、退職する前に
是非もう一度やっておきたかった！" と言ってくれました。
（嬉しいです！　もの凄く．．．．(涙)）

実際のコンテンツは、Qiitaサービス上で作成し、スライドとしてデモで見せてくれました。
（WebページをPDF化＆圧縮したファイルを掲載させて頂きます：勿論、本人の承諾済み）
（↑分り易さ優先の資料のため、技術的な問題点など余り突っ込まないで下さい；ご教示頂ける点は有り難く伺います...）

「lambda_expressions.zip」をダウンロード

言語的にはJavaScriptで実例を追う形。
・Javaより簡単に書ける
・Javaと構文が似ている（現時点のアスペア内ではJavaが最も共通知識となっているので）
・すぐに動かして確かめられる
．．．という理由からの選択です。

サンプルとして、"或る処理ロジックをJavaで書いたもの" をJavaScriptのラムダ式に書き換えていく、
という形で展開されました。

高階関数＋ラムダ式を使用して、
より簡潔に短く、処理の意図が伝わる、コードが書けることを順を追って説明してくれました。

と、このブログ原稿を書いている筆者自身の理解が追い付かない点が情けないのですが、
出席していた技術部メンバー達には理解・納得できたようです。

確かに、"ゴチャットした制御構造を読み解かないと仕様・意図が分からない" 状態から、
"意図した仕様が箇条書き的に、一読で読み取れるようになった" ことは私にも理解できました！

端的な例とは言えるのでしょうが、
メンバー全員が理解して、ガイドラインなどを設けて＆共有して＆納得した上で活用したら、
開発者の皆が（今と比較して）幸せになれる可能性を感じ取れました。

資料も説明も、今までの速形さんのコンテンツの中で最も完成されたデモだったと思います！
いろいろと周りにも刺激を与えてくれてありがとう！

次の職場でも、きっと様々に活躍されることと確信してます。

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

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

2月の全社定例会は、2/17でした。

コンテンツは、企画モノ（非レギュラー）は、
・仕掛り中のプロダクト／サービスからのDevOps的視点からの実例共有＆相互質疑
・セキュリティ系の昨今の事例共有＆相互質疑
・その他、労務的なこと、社内的なスキル評価体系的な話題など．．．
．．．でしたので、
ちょっとここには書けない内容ばかりでした。

ただ共通して言えるのは、作業をしている場所・顧客、仕掛りプロジェクト／プロダクトに関わらず、
オンラインだけでなく対面でも実例・事象を共有して、相互に質問し合う、
お互いの間接経験となるように活かす、という視点＆行動です。

また、共有が比較的（かなり？）難しい "暗黙知" に関してですが、
これを共有するには、現実的な話として "一緒に作業しながら伝え合っていくしかない" 面が多分にあります...。
．．．と言っていても、なかなか現実は先に進めない＝勿体ないので、
出来る限りハンズオンやワークショップなどの形態を採るようにしています。

準備・仕込みに時間・手間がかかるので、肝心の"暗黙知を持っている本人"の調整が難しいですし、
いかにワーク実施時に"持っている側から見せられるか"、"持っていない側が部分的にでも体感できるか"も
悩ましい所です。

とは言え、これが出来ることが"その会社に属している・仲間との間に妙な制約を設けずに済む"大きなメリットですから
活かしていかなければ！

さて、具体的な内容が無いと寂しいので、同日のレギュラーコンテンツの方から紹介を１つさせて頂きます。

毎回、"IT-Tips 又は LT(ライトニング・トーク)"を行ってます。

2月の回では、蓑方さんが発表してくれました。

ちなみに、蓑方さんは "自身の公的なロールに捉われず、なるべくプロダクト／サービスの全容を把握し、
機会があれば可能な限りの外部仕様・内部構造も把握しつつ、俯瞰的な視点で理解をして設計や製造にも
反映できる＆メンバー間で共有も進めていける" 人物です。

多くのプロジェクトに関わって来ましたが、"いつの間にか、設計や仕様・要件の中心に関わっている" 人です。

さて、そんな蓑方さんが今回お話してくれたのは、
自身がかなり以前から使っている "自分のメモを構造的に集約するツール" についてでした。
（"ウェアラブル EXPO" 参加レポートを発表！．．．と思ったけど行けなかった、というフェイント付きでした...）

Nami2000
http://www.geocities.jp/my_ultraseven/mozart/_start.htm

既に世に出てから17年を超えるフリーソフトウェアです。
分類的には、"アウトラインプロセッサ"。

最近は余り耳にしない用語かも分かりませんが、
要は、情報を構造的・階層的に構築・集約していくツール、です。

それ自体をそのままで、多くの他者と共有・運用することには向きません。
基本はあくまで、個人の情報を、個人の基準で構造決め・メンテをして成長させていく（或いは適宜で掃除する）ものです。

今なら、例えばGoogleDriveやDropBox、SkyDriveなどに置いておけば、物理PCに限定されずに利用できますね。

自分でカテゴリー分けをしながら、大体3階層くらいまでで済んでいるとのこと。
検索機能も当然有りますが、"何処にどんなモノを入れているかは大体頭に入っているので、検索は余り使わない"そうです。

このツールに、
自身で得たTips的な知識、ちょっとした（しかし重要な）スクリプトとか、
日々のToDoリスト的なメモの保存とかから週報を起して効率的に進められるとか、振返りに使ったりとか．．．

で、今回の蓑方さんからのツール紹介を受けて、
"早速インストして利用します！" という反応もありました。

新しいばかりが良い、と限った話ではありませんよね。

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

Mr. 三文字、踏ん張る！

1月の全社定例会にて、アーキテクトでもある三文字さんから、プロジェクト／サービスの事例発表がありました。

Web上で展開されている各種サービスを実現するために、それらを支えている様々な要素があります。

サービスが大きく成長し（ユーザー数を増やし、継続的な収益と成長を持続させる）、機能拡充と共に、
ユーザビリティの改善や、顧客内の他のサービスとの連携・API化の流れ（マイクロサービス・アーキテクチャ）、
様々な側面からメンテナンスの必要性が生じて来ます。

特に、大規模なサービスで、かつ運用期間が長くなるほど、
顧客にとってのビジネス的な価値も大きくなるでしょうが、同時に、徐々に技術的な負の資産を膨らませてしまうことは
避けられません。

負債はどこかのタイミングで返済しなければならない。

負の資産は、どんどん保守・運用コストの増加という形で顧客のビジネスを圧迫していきます。

三文字さんが、この"負の資産の返済"の実例実務上の中心人物として稼働してきた経験から、様々なことを共有してくれました。

サービスは、長期間運用して来れば（＝長期間、必要とされ続けて来た）、必要とされ方・利用の仕方・求められる
サービス内容も大なり小なり変化していきます。

その度に "どんな課題に対し、どんな目的を持って、どう変化させるのか？" 、"結果として何がどう変わることを期待するのか"
が、事前に明確にされなければならないはず．．．

．．．ですが、
"どう変えれば、ビジネスの成果にどう反映されるか？"、は、やってみなければ分からない面も多分にあります。

開発途中で、関係者（ステークホルダ）からの要望が出たり、他のサービスから得られた分析結果を元に
施策を変えたりといったことも頻繁に発生します。

そんな状態の中で、これらの要求・外部仕様・対応する内部仕様が資料として確実に残されるか？
と言うと．．．残念ながら、不完全な場合の方が圧倒的に多いのではないでしょうか？

三文字さんの苦闘の中でも、
"彼自身が頑張れば何とかなる" 範囲と、
サービスの外部仕様・運用を最も知っている人達の協力を得なければどうしようもない
（現実的な時間制約やコストの範囲で収まらない）こともあります。

それらの判断を行い、切り分けつつ、顧客側の上位職の方々と提案・交渉などを行うことも、三文字さんの
重要な仕事の１つでした。

膨大な量のプログラム・コード。
品質を担保しながら、負の資産を返済する手段とステップを考え・調整する。
テストケースの設定自体も、以前に関与したメンバー達の協力を得られるように各種の調整を行い、
テスト・コストも現実的なレベルに抑えつつも、必要な品質担保の点で手抜かりは許されない。
ユーザー数の多い大きなサービスですから、フロント／バック共に性能的な低下が無いことも十分に検証しなければならない。

具体的なことは書けないのですが、様々な問題が発生し、１つ１つへの対処法を工夫しつつ、
クリアしながら（多くの人達と協働しながら、ですが）リリースに向けて進んで来たのですね。

ほぼ完了している時点で話をしてもらっているので、淡々と話すことが出来ていますが、
「これは．．．．苦労しました」という、微妙な言い淀みや間合いに、
「大変だったんだろうなあ．．．」という印象を持ちました。

負債返却の具体的なケースと、効率的な調査方法、対処方法（政治的なモノから技術的な詳細に至るまで）など
様々な要素を惜しみなく共有してくれた三文字さん、有難う御座いました。

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

本が欲しいだあ？、買え買えーっ！！

"書籍買い放題！" の運用をスタートしましたっ！

今までも業務的に、或いはトレンド技術やプロセス、マネージメント系、業務系など、必要な書籍が有れば
都度の申請（職制によっては自己裁量でOK）で社費での購入はしていました。

しかし．．．．．

"業務で必要としないと買えないのか？"とか、
"既に社内に有ったら＆誰かが持ち出してたら買えないのか？"とか、
"そもそも書き込み出来ないと、実戦的に使えないじゃないか！"とか、
"あーだこーだ承認受けないと買えないのか？"とか、

面倒臭い.....

本当は関心があるんだけど、今の業務じゃ使ってないし、申請・承認だとか面倒臭いし...
...で、そのまま流れて放置されてしまうのは、余りにも勿体ない！

技術系の書籍は概ね高価ですし、個人で賄うのは結構厳しいものがあります。
（中には、"◯◯文庫"、と個人名で呼ばれるような書籍群を社内に貯め込んでいる猛者もいますが...）

そこで、改めて "書籍買い放題！" 制度を立ち上げましたー！

事前承認のフローは無しです（運用ルール／ガイドラインは事前に社内共有しておく（社員専用サイトなどで））。

これから始めるので、
こりゃー社費で買うには余りにも違うだろー？、とか、
うわあーっ！、想定を遥かに超えて予算オーバーだあーっ！、とか、
...あるかも知れません。

ので、3ヵ月間は先ずは試験運用。
状況を見ながらルールを見直す。
費用の累積は、ほぼリアルタイムで共有可能にする。
．．．などを前提としました。

あ、ちなみに、購入報告・支払い申請は、slackの専用チャネルから行うようにしてます。

１年の長期貸出しの場合、"書込みOK！"。
以降も１年単位で延長更新可能にしてます。

フロントサイド・エンジニアの場合などは、欲しい書籍は単に技術や業務という括りに収まらないはずです。
"良いものに触れる"という点から、過去のグラフィカルな作品や意匠が掲載された書籍なども社費の対象に想定しています。
（こういう本[↑]って、特に高いんですよね．．．。手が出にくいです）

さてさて、どうなるだろう？

運用していく中から、面白い事例とか波及効果などありましたら、
改めてこのブログで紹介させて頂きたいと思います！

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

Mr.山下、暴れる！

2017年の最初の全社定例会（1/13）で、顧客先プロジェクトにアーキテクト・兼・要件定義者、
兼・実質的にリーダーとして参加している山下さんから、
顧客のビジネス概要と、特に技術面を中心に共有可能な範囲でのお話をしてもらいました。

大きな開発規模ではありませんが、顧客要求がぼんやりした状態から要求定義・開発スコープの明確化と、
スケジュール立て（希望納期の提示は有ります）、適用する技術要素の選定やリスクヘッジ方針決め、

開発プロセスの方針決め・実行と、参画早々に大忙し！

結構短期でフルスクラッチのリリース。　如何にも今時のプロジェクトです。

顧客の要求を具体化していく為に、プロトタイピングを適用。
ドキュメントは、山下さん自身のメモを含めて、基本的には 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と連動してくれる）

．．．などなど。

聞いていたメンバー内からの質問、
「どうしてVue.jsじゃなくて、React.jsを選んだのか？」に対しては、
「トレンドだし良いものだと思うし、自分が経験したかった！」と、何とも率直なお答えでした。

顧客要求として、"リッチUI"、"SPA（Single Page App.）" を希望されている、という点が大前提です。
（他にも理由が述べられましたが、ここではちょっと割愛...）

以前のプロジェクトや普段からの継続的な情報収集などから、各要素を判断したとのこと。
未経験要素も多分にあるのですが、リスク・コントロールの方向性も具体的な候補を想定して決定している、
という点に、（当然と言えば当然なのでしょうが）感心。

会議の最後の振返りの際にも、
知らないキーワードが満載だった。勉強しないといけないといかん！、と思った。
．．．などが挙がりました。

自社内相互で刺激し合うことが出来るのは良いことだし、有り難いなあとしみじみ思います。

また、そういった情報を惜しみなく出してくれる山下さんの人柄と姿勢にも感謝・感謝です！

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

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

12月の定例会にて、(ほぼ)レギュラーコンテンツである"IT-Tips or LT(Lightning Talk)"で、前田さんが
最近のホットな話題になりつつある "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が有りました。

前田さん、有難う御座いましたー。

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

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

全社定例会の中に、"IT-Tips or LT(Lightning Talk)"というレギュラーコンテンツ枠を設けています。

"LT"を敢えて"or"で繋いでいるのは、言うまでもなく"何の話題でもいいよ！"ってことです。

要は、"制限時間を設けて人前で話をする"機会を設けることでの訓練的な効果を狙うのと、
"誰が、どんなことに興味を持っているのか？"の相互理解・共有する、という2点が元々の目的です。

11月の定例会では、"母"でもあり"エンジニア"でもある中里さんからのLTが有りました。

お題は、"昨今の小学生事情について"。

お子さんが今年の春に小学生になった、とのこと。

世代毎に環境や教育システムは変わっていくわけですが、中里さんが驚いたこと・感じたこと。

・宿題が多い！
　　１年生なのに結構宿題が多くて、中には"音読"を親が聞いて採点する、などという課題も。
・パソコンで日記をつける
　　当然、キーボードから入力しなければなりません！
　　パソコンが家に無い家庭はどうするんだろう？
　　スマートデバイスに外付けキーボードとか買って繋げたりするんだろうか？
・食事事情
　　食関連のイベントとかでも、国産原料にこだわったり、衛生面から"塩にまで熱を通す"とか...
・文章を読み取る力を伸ばしている
　　国際的な学力比較・能力比較の点から、日本の弱い部分を強化しようってことでしょうか。
・土曜日も学校
　　これは、"土曜は休み"（ゆとり）方針と、"授業時間が足りないので土曜も登校"方針との間で揺れてますよね。
・"さくらんぼ計算"なる教え方
　　算数の解き方を教える段階での、考える手順の説明が不可思議？？
　　"答えを出す"よりも、"考える力"の育成を重視ってことらしいのですが...。
・いつまで勉強を見てやれるのだろう？"、と不安も感じる（追付かない？）
　　"答えは分るけど、解き方が昔と違う"ので、下手に説明できないってケースが出て来ますね。
　　子供の教科書を読んで、改めて悩まないといけなくなるかも知れません...。

定例会当日は、同じくママさんエンジニアであるJさんは、2人目のお子さんの育児休暇中でお休み。

他の女性エンジニアは独身ですが、
男性陣の中には子持ちの連中もいます（筆者も）ので、共感できる部分も多かったろうと思います。

さて、"母"であり"妻"であり、"エンジニア"でもある（勿論"一個人"でもある）中里さん、
普段の業務では"町田ラボ"（顧客先に詰める・或いは半常駐する自社メンバーと主に連携しつつ、町田で開発業務をこなす）
のリーダーを務めてくれています。

自身では、「やるべき事に追われていっぱいいっぱい」みたいなことを言っているのですが、
はた目にはいつも落ち着いて、成すべきこと、改善すべきことなど、生産性を意識しつつも柔軟に、
かつ根気よく対応してくれているように見えます。

とは言え、お子さんの生活時間を考慮した勤務時間帯で稼働しなければならないので、バランスが難しい。

自身の仕事の切れ目は勿論のこと、メンバーの今日・明日・当面のタスク配分・その他も考えないといけない。

加えて、顧客先にスポットで出向くことも有りますから、家庭生活のタスク・ピースとの組合せにも工夫が要ると思います。

多くの要素の間を頭と体でスイッチし続けると、疲弊も激しくなるので要注意！

（これは業務に限った話ではなく、人間、というか生物の基本じゃないかと思います）

体の調子も崩し易くなります。

この辺は、逆にメンバーの方で旨く支えてあげて欲しいのですが、
手に余る部分が出て来てもおかしくはないので、その辺は会社としてのマネジメント（サポート）が何処まで
出来るか？、に掛かってくると思っています。

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

なぜ人と組織は変われないのか！（え？）

書籍ネタ："なぜ人と組織は変われないのか"（ロバート・キーガン (著), リサ・ラスコウ・レイヒー (著), 池村千秋 (翻訳)）

にワークショップ実施の記載が有ったので、
「よし、11月の全社定例会で、思い切ってやってみるか！」という事でやってみました！

「変わりたいんだけど、変われない」・「必要なのは理解してるし困ってもいるんだけど、実行できない」など、
業種とか、私生活上のことも含めて、こういう事（↑）って有りますよね！？

上記の書籍は、発達心理学と教育学の権威にしてコンサルタントでもある著者達が、30年をかけて開発したアプローチだそうで。

2013年の出版物ですが、既に多くの（IT業界に全く限定されず）採用されているとのこと。

自己啓発本というのは、ともすると禁欲的・継続的で強い自己制御を前提とする内容が多い気がします。

その点、ここで紹介されている内容は、
「変わりたいけど、変われない」のは、「変わることを拒む、無意識の目的や前提認識があるから」であって、
それを知らずして理性だけで目標を達成しようとしても（大抵は）無理、ということ（←かなり乱暴な省略ですが...）。

人は理性だけで動くわけではなく、むしろ心理や既成観念を重視しながら、自己分析（信頼できる何名かの仲間の協力があると、
格段に良い！）し、改善のための実験行動と結果分析を繰り返しながら改善していこう、というもの。

実行段階での各ステップに対して、標準としてのチェックシートが用意されてます。

洋書に多く見られる傾向ですが、具体例が多数掲載されています（ちょっとウンザリする位に．．．）。

それらの中から、"2時間に満たない時間枠内でのワークショップとして実行可能なシナリオ"を探ってみました。

この手法では、最初の具体的なステップである、"免疫マップの作製"の後に、
"改善のための実験の設計"、
"実験結果の分析（視点のチェックリストが掲載されている）"、
"実験結果の評価"、
"次の実験の設計"．．．．．
．．．と続きます。

が、さすがにこれ全部を2時間程度の定例会の枠内に押し込むのは無理が有ります。
（特別に時間延長するとか、土日に設定しろよって話になるのでしょうが、現実的にコストの問題もあります...）
（正直のところ、ワークショップ自体を上手く回せるのか？、皆が必要と判断・認知できるか？、も企画段階では不明です...）

なので、最初の大きなステップであり、割とこの手法の効果を実感（！）しやすい部分として、
"免疫マップの作製"（グループ内での相互コメント有り）までを実施してみることにしました。

事前に想定した時間枠は80分、実施結果は90分。

各人が作成した"免疫マップ"に対して、チームメンバー相互に共有し、コメントし合うのに（予感はしてましたが）
想定以上の時間を要しました。
（これ↑を緩和するために、チーム人数は3名にしたかったのですが、4名チームができてしまった...）

が、言い換えれば、"自身では気が付かった点や方向性でのコメントが展開された" 結果でした。

メンバー間の信頼や理解があってこその結果だと思うので、これは率直に嬉しいことです。

今までに、

開発プロセス系（LEGOブロックによるスクラム疑似体験、インセプションデッキ作成、その他）、
チームビルディング時の相互理解ワーク（偏愛マップ、他）、
その他カテゴリー（デザインワーク）、
．．．いろいろとやって来ましたが、

今回のワークは各人の個人的な課題を吐き出した上に、チーム内にさらけ出し、
コメントし合うという、ある意味では負担（ストレス）の強さではトップ級の企画だったと思います。

実はそんな理由から、このワークは同日の定例会の最後の方に配置しました。

皆、予想以上に熱心に参加してくれた分、相当に消耗した様子でした（企画者としてはホッとする反面、参加メンバー達には申し訳なかったのですが）。

定例会の最後の振返りで、「今まで知らなかった手法を知ることが出来て良かった」という Keep 発言を聞けて良かった。

今回のワークのような形態に囚われず、"何かしらの問題にじっくりと取り組む" 場合のアプローチの１つとして
実生活・実務のどこかで部分的にでも活かしてもらえたら良いなあ、と思います。

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

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

今回のブログ記事は、株式会社アスペアの代表：加藤が担当致します。

子育てしながら書籍出版やテレビ出演などで活躍中です。

株式会社アスペアが、子育てしながら働く「ママさんエンジニア」を積極的に募集していることから、
子育て繋がりでインタビューを受ける機会がありました！

⇒ 今回のインタビュー掲載記事はこちら

⇒ アスペア社内技術者のインタビュー記事はこちら

町田相模原周辺に住むママさんエンジニア採用に積極的なことには背景があります。

弊社に新卒で入社した女性社員が結婚し子供が生まれ、産休・育休をとりました（写真とはまた別のメンバーです）。

会社にとっては大変痛手ではありますが、結婚してお子さんが生まれることは大変めでたいことです。

それまでの働き方である月間残業～（10）～30時間の勤務を100として、
辞める（100の稼働が出来ないので復職できない）ことを０（ゼロ）とすると、
0になることは会社にとってもったいない。

80とか60の働き方であっても戻ってきてくれることは嬉しい。

以前からそう思っていたので、本人の望む時期に復帰して、望む働き方で働いてもらう。
そのためには「制度・仕組み」を作るだけでななく、普段から戻ってきやすくなる「社風」づくりを醸成してきました。

おかげさまで育休後、すぐに会社に復帰し子育てしながら頑張ってくれました。（いまは2人目のお子さんの産休に入っています）

それをいいことに、、すでに子育て中の方を新たに中途採用して、現在活躍していただいています（写真・左の女性）。

本人は最初パート勤務を覚悟していたようですが、面接で会話をしているうちに正社員として働けると思っていただけたようです。

弊社は（出勤義務のある）コアタイム有りのフレックスタイム制ですが、子供が熱を出して保育所から連絡があった場合など、

コアタイム中でも皆で快く送り出しています。

会社としても、即戦力となる経験豊富なエンジニアが仲間になってくれて、ありがたい！
それどころか、チームリーダーとして若手の育成も担ってくれています。

本人も豊富な経験を活かせる職場が自宅近くにあって、安心して働けて喜んでくれているようです。

経験を活かせて働きやすい会社が増えれば、世の中がもっと明るく、もっと活性化すると本気で思っています！

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

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

10月の全社定例会で、"参加者が少なかったのでミーティング形式にしてみた" コンテンツを1枠設けました（前回の記事でも触れました）。

事前の "定例会開催の確認通知メール" でも、「何か会話してみたいネタが有ったら持って来てねー」と振っておきましたが。

当日、持込みネタは１つ、あと２つほど私の方から話題を出しました。

１つは "社外セミナー" に関して。

平日の夜（19時辺りから開始されるモノ）とか、土日に行われるものも有ります。

日常がどうしても目の前の業務で忙殺されがちなので、
私の方で「これは、あの人が関心を持ちそうだ」とか、「これは関心持って参加して欲しいなー」なセミナーやワークショップ、ハンズオンなどを社内slackのチャネルに案内するようにしてます。
（いかにも個人向けでお勧めのものは、slackのDMで流します）

しかし、実際にセミナーに参加するメンバーが限定されている．．．

必ずしも業務稼働的に高稼働ではないにも関わらず、参加者が少ないなーとか．．．
（単純に "作業時間数" だけでは "疲労具合" は測れないことは承知していますが）

なので、この際に話題にしてみました。

以下、話題に挙がった意見の幾つかを紹介します。

・手持ちの軽量NotePCがない（ハンズオン出来ない）
　　⇒ これは、会社から空きNotePCを貸し出せるかも知れないので、是非問合せて欲しい。

・人見知りなので、正直に言うと恥ずかしい
　　⇒ あー、これは．．．．．．。分かります、理解できます。　私も同じです。
　　　　「そのひと山を超えると、新しい自分が開けていくかも」と考えてみても、心理的なブレーキは確かにあるでしょうね。
　　　　率直な意見、有難う御座います。って感じです。
　　⇒ これに関しては、slackで紹介したイベントに "興味あるよマーク" を付けて、２人以上になったら誘い合って行ってみる、
　　　　という対策を挙げてくれました。

・既にコミュニティが出来ていると輪に入りにくい
　　⇒ ああー、これも分かります。主催側とかメンター側でこれをやられたりすると、結構辛いですね。
　　　　「俺、完全に部外者じゃね？」ってなります。

・技術系のセミナーの場合、さわりの部分だけで終わりそう
　　⇒ これはセミナー自体の選択の問題と、講師・メンターへの質問・会話を重視するか？
　　　　そもそも講師と知り合うこと（人脈？）を目的とするか？、という気もします．．．

・過去に参加したセミナーがあまり良くなく、セミナー自体に対する印象が悪い
　　⇒ これは負の学習結果で、仕方ない一面も有り。
　　　　ですが、全てのセミナーやワークショップを否定する理由にはならないと思います。

これは私見ですが、"下手に参加して恥をかきたくない、下手な質問や発言をしてボコられたくない"ってのも
有るんじゃないか？、と思います。

と言うか、私はそう感じてました（開発で現役の頃）。

"自分が、いけてない技術者であることを自覚させられたくない"、って気持ち、正直言ってありました。

それでも、少なくともプロセス系のワークショップは刺激的です！

人見知りとか遠慮とか、言ってられません。
かと言って、無難に黙っているとか有り得ないです。
と言うより、"俺の（或いは仲間との）経験・知見からも言わせろ！"、って気持ちになって来ます。否が応でも！

参加した事の無い人は、是非一度ワークショップには参加してみて欲しい！

未体験の楽しさ・興奮・充実感（＆疲労感とか焦りとかも含まれるけど）を味わえるので是非！

．．．．．と幾ら目を輝かせて熱く語っても、行かない人は行かないんですよね．．．

たまたま最近読んだ本ですが、「なぜ人と組織は変われないのか」。

要は、自分のホンネ（直感的なモノ）が、理性的な意思や行動を必然的にゆがめてしまうってことで。

これは自己分析の段階を経て、対処の考え方と行動まで自身の頭と心で導き出せば、変われるよ。
ってことのようです。

同書にはワークショップの行い方なども記載が有ります。
ちょっと荷が勝ちすぎる感じはしますが、社内でやってみようかな．．．．．

行動無ければ変化も無し、ですし。

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

"アジャイルコーチの道具箱"を開けてみる！

10/14に10月の全社定例会議が有りました。

．．．．．が、客先で構成しているアスペア・チームの内で最大の体制で参画しているサービス／プロダクトの開発が、
ここ２～３ヵ月の間・佳境に入っており、そのほぼ全員が帰社することが出来ません。
（１人だけ帰社出来た！、と言うか帰社できるように頑張ってくれた！）

たまたま同時期に業務負荷的にピークの顧客先：サービスがあり、帰社不可のメンバーが悪いタイミングで重なってしまいました。

通常なら、基本的に役員を除いて半数を超えるのメンバーが参加出来ないときは、全社定例会を中止する原則としています。
この原則に倣って9月の定例会が中止になったのですが、2ヵ月連続での"開催無し"は避けたい．．．。

参加者数が少なめなのであれば、それに応じた、
否、返って望ましいコンテンツと言うか、進め方があるのでは？
．．．ということで、10月定例会は予定通りに実施しました。

参加者数が少なめなので、"共有・発表、ハンズオン"系のコンテンツはほぼ中止。

替わって、"じっくり資料を覗く系"、"ディスカッションと言うより、ミーティング感覚で気軽にやりとり出来る系"の内容に急遽変更。

その１つとして、「"アジャイルコーチの道具箱"をひっくり返してみよう！」（"資料を覗く系"）を実施しました。

オリジナルの資料は、電子書籍、"アジャイルコーチの道具箱" です。

「これは良さそうだ！」と思い、上記のサイトから購入して社員用Webサイトで共有してあるのですが．．．．．
．．．．．放置しておいても（全員に告知はしましたが）見る者は少なく．．．

この際、本の頭の方から順繰りに覗いてみて（プロジェクターで投影）、
面白そうなツール（基本的には全てアナログ）、気になった点、今までに類似した例を見たとか、
こんな工夫をして良かったとか、こういう点に留意すると良いとか、
そんな話がワラワラと出てくれば会話が進むに任せるし、
無ければ次々とページをめくってみて、気が付いた点などに（筆者が）コメントしたり。

"読書する書籍" ではなく、"ヒント／サンプル集" といった趣なので、
退屈はせず、肩ひじも張らず、次のページや展開の予測もつかず（コンテンツによっては、勘の良い人間は先読みして退屈したりしますから...）、

まったりと、（ほんの数分の一しか覗けませんでしたが）見ながら、参加者の何気ない経験・知見で雑談的に話せたのは良かったのではないかな、と思いました。

定例会の最後の振返りで、「"道具箱"を参考に、プロジェクト内での見える化する！」、というTryが出て来たので、それだけでもやって良かったなあ、と思った次第です。

そのプロジェクト的に、課題感が有るタイミングだったようです。
問題点を "問題" と明確に意識できること、"課題化"できる事は重要ですからね！
それを、「じゃあ見える化しよう！」と方向付けの判断をして、発言できたことも嬉しく思いました。

変えたい！、変えるべきだ！、と意識出来て＆変えたいと感じなければ、永久に変えることは出来ませんから。

折角、購入した電子書籍なので、折に触れてちょびちょびと話題に出していこうと思ってます。

幸い、この書籍は "１ページに１ツール（アイデア）" が原則構成になっているので、散発的に話題に出しても全く問題無いんです。

言い換えれば、筆者が一通りのツールを取りあえず頭に入れておき（ぼんやりとでも良いから）、
現場からの声（週報とか、定例会での発言とか）をトリガーにして、
「あ！、そう言えばこんなツール有るんだよ。面白いよ！、やってみない？」と言えるようにしておかねば。

勿論、各メンバーが自由にパラパラめくって（具体的な目的が無くても）見ておいてもらう方が良いのは
言うまでもないことですね。

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

scalaのライブコーディング。

8月の定例会："LT or IT-Tips"の枠の中で、若手の速形さんがscalaの概説＆ライブコーディングを行ってくれました。

（速形さんと言えば、去年の忘年会の時にゲーム用のWebサイトを急ごしらえしてくれた中心人物です）

（詳細記事はこちら）

レギュラーコンテンツである"LT or IT-Tips"は、デフォルトでは10分の枠を取っていますが、
事前の速形さんからのリクエストで「15分の枠が欲しい」と連絡を受けており、タイムテーブル上でもそのように設定しました。
（全員持ち回りのコンテンツなのですが、時間枠の拡張要望が有れば事前に連絡を貰うことにしています）

先ず、ネタとしてなぜ、scalaを選んだのか？

社外勉強会に3つ参加して、全ての中で話題に挙げられていた（熱く語る人達を目にした）こと。

全て有志の人達ですから、たった3セミナーとは言え、全てで熱い話題として語られていたことは無視できない、
というのは分ります。

ここ1年以内くらいで、「既存のWebサイト／サービスの開発に利用していたPHPやJavaから、scalaに移行した」
という話を、結構著名なところで聞いたりもします。

発表してくれた概要：
　・ドメイン設計するならScala！（DDD勉強会に参加した時などに繰り返し耳にしたこと）
　・業界の利用例：アフィリエイト、ツイッター
　・マルチパラダイム言語である：オブジェクト指向＋関数型言語
　・JVM上で実行される：Write Once, Run Anywhare.
　・メリット：
　　　・静的型付けが利用できる。
　　　・JVM上で実行される（Javaの資産が使える）。
　　　・Javaに似ているので学習コストが低い。　←（社内的なお話ですが）
　・デメリット：コンパイルにかなりCPUを食う、省略記号が多いため慣れるのに時間がかかる。
　・記号を多用するのでググラビリティ（Googlability：Google検索で適切な情報をヒットさせるのにコツが要る）が低い。

ここで、ライブコーディングをしてくれました！

と言っても、実際に動作しているのは彼の自宅にあるMacBook。

リモートデスクトップで、町田事務所にあるNotePC（Windows10）から操作しました。

Java7ベースで書いた＆Webページとして動作するソースコードを、scalaに書き換えていく、というものでした。

分り易くて面白いです！

拘りのあるメンバー達からは、コーディング途中で「えー！？」とか「ああー...」とか声が漏れて来て、
それも面白かったですね。
無言、無反応じゃあ、お互いに面白くないということですから．．．。

※使ってみての感想
　　・関数型を勉強できてよかった。
　　・再代入しない副作用のないコードメソッドは必ず何らかの実行結果を返す、という大原則の元で動く。
　　・ちょっといいJavaを書きたいという人はいいのでは？

[質問] 広告、ゲームでscala適用の例が有るとのことだが、その採用理由は？
　　⇒元々PHPを使っていたが、規模が大きくなって何かと運用コストが膨れるし、負の遺産と化していた。
　　　scalaを選んだ理由は、並列処理が簡単に書けること。
　　　スレッドが別になるのでバグっても全体が止まることが少ない。

[側面から補足] アーキテクトでもある山下さんが補足説明を入れてくれました。
　　　ランキング等はもの凄いアクセス・ユーザ数があるからマルチスレッドで処理する必要がある。
　　　Javaではスレッドを立てるだけでそこそこのコードを書くことになるが、Scalaは簡単に書ける。

やはり、動くモノをリアルタイムで見られるのは面白いです！

それと、現行技術（言語）から新技術への移行プロセスを、超簡単な実例ではありますが体験共有してくれたのは
素晴らしいと思いました。

実際にプロダクト／プロジェクトで採用するか否かは多くの要因を考慮しつつ決定しなければなりませんが．．．．．。

ただ、こういった新しいものへの取り組みを、若手が実践して共有してくれるってのも非常に嬉しいことです。

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

あなたのモデルになる人、傍にいますか？

あなたの近くに、自分の数年後・或いは5年、10年後として「こんな風になっていたい！」と感じる
スキルモデルの先輩（或いは同僚・後輩、他社の人でも構わない）って、いますか？

さて、どうでしょう？．．．．．

話は、もう20数年も前のことになりますが、
当時のアスペアは "クライアント・サーバーシステム"（以降、"クラサバ"と記載します） の開発が中心でした。

当然のように世間で使われていた最もポピュラーなRDBMSと言えば、Oracle製品。

OSは、通常業務用（デザイン用とかではなく）としては Microsoft Windows 3.1 から、
本物のマルチタスク（プリエンプティブな）OS、メモリ保護なども掛かるOSとして Windows 95 が台頭し始めたころ。
（古い話ですよねー！。今回はIT石器時代のお話しが絡みます）

実装言語は主にVB（VisualBasic。.NETじゃありません）でした。

当時のアスペア内に、この"クラサバ系開発のエース"が1人いました。
若手でしたが、グイグイとプロジェクトを引っ張ってくれていた。

新規で数名体制を組んで受注・開発を行う上で、必然的に中心人物となっていました。
当然ながら、多忙を極めます。

一方、筆者自身も未だ開発の現場にいましたが、私の出自は元々が "組み込み系"。
"クラサバ"、RDBMS、ネットワークなどは弱い弱い。
受注業務も、全く畑違いの方向からの案件（組み込みではないが制御系方面）をこなしていました。

で、ある日、"クラサバ系開発のエース" が社長に、退職届を提出しました。

「この会社にいても、自分が目標にできる人がいない！」と。

筆者の方が年齢的には上でしたが、未だ30代で大差はない。
当時、筆者はアスペアの役員でしたから会社的に非常に痛いという認識も有りましたけれど、個人的に、とにかく情けないったら無い！

（ちなみに、筆者自身が直前のIT系会社を退職する際に言った言葉も同様の内容でした）

『歳は上でも、こんな奴しかいない！』と、口に出して言われたわけではありませんが、客観的に見れば、そう断言されたような気がしました。
悲しいやら、悔しいやら、恥ずかしいやら．．．

しかし事実でしたし、立場が逆だったら、私も同様の理由で退職したかも知れない。

身近に、出来ればやはり自社内に、自分がモデルとしたい先輩・同僚がいた方が良いです。
或いは、自身のモデルとしなくても、"こいつはここが凄い！"という人が何人もいる方が楽しいです。

一緒に仕事をしたり、話をしたり、食べたり呑んだり、いろいろと面白い。勉強になる！

「じゃあ自分が凄いと思われる技術者になろう！、キャリアモデルになろう！」とは考えませんでした。
と言うか、考えられませんでした。
自分の気質・性質・能力や指向は自覚してましたから．．．。

さて、どうしたものか．．．．．。

ややあって、「会社的にWeb系に専門特化して行こう！」という方向が定まりました。

どんな要素が必要になって来るんだろう？

・オブジェクト指向、言語的にはJavaが中心（当時）、表記的にはUMLを全社員が共通語として使えること。
・Strutsなるものを知っていないと・使えないと、Web系でメシが食えなくなりそうだ。
・って言うか、フレームワークという概念を理解して活用できないとダメそうだ。
・デザインパターンってのも一種の共通語として、品質や生産性確保の為にも必要らしい．．．。

モデルになるような人物は、採用時点でも可能性のある人を選別するという事も行っていきましたが、
「より良いものを、カッコ良く・スマートに（今風に言えばクールに）作りたい！」という共通意識を持っていたい。

ちょっと拘っていたい。

・スキマ時間でも見付けたら、逃さずにその辺のキャッチアップを行って欲しい（全員に）。

・そして、頑張って勉強して伸びてくれる人は、どんどん高く評価する（給料も上がる）。
・Web方向でのスキルを伸ばせるプロジェクトに優先的に配置する。
・お客様からの高い評価を、社内でも全員の前で発表する。
・スキルアップに必要な要素の話は、定例会などの機会に繰り返し話題に出す、勉強会を開く。
・メンバーが実務で活かした例は、皆の前で優先的に発表してもらい、「これから全員に必要になるよねー」って話を繰り返す。

等々、試行錯誤している内に（結果的に？）、「凄い！」メンバーが段々と育ってくれました。

「凄い！」人は、「頑張ろう！」を誘発します。
次の「凄い！」人になってくれます。

今では、様々な方向・役割で（重複部分は当然ありますが）、それぞれの個性を持ちつつ、
「凄い！」メンバー達が揃ってくれました。

スキルモデル、キャリアモデルとして各メンバーが想定できそうな人物が何名も揃ってくれていると思います。

自社内にそういったメンバー達が、1人、2人とかではなく何名も揃ってくれた点は、本当に！、本当に嬉しいですっ！！

「この会社にいても、自分が目標にできる人がいない」

20数年前に言われたこの言葉を再び聞く可能性は、かなり減ったんじゃないかと思います。

また、先陣を走るメンバー達にしても、
「結局は正解を他所から持って来るのは不可能。より良い結果を出したければ、現状に応じて自分（達）で考えて、工夫して進んでいくしかない」、
という点は、は分ってくれているのではないか、とも思います。

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

お仕事場所の物理的分離・共有とWantedly！

アスペアのメンバーは、自社事務所で殆どの開発・保守作業を行っている「町田ラボグループ」と、
顧客先にて要求の内容確定・補完、交通整理から仕様確定・デザイン＆UI設計・設計・製造・各種テスト・リリース・保守・運用・障害対応など
様々なことを行うメンバーに大別されます。

また、顧客先も複数に分かれています。

基本的には、余りメンバーを拡散させない方針なのですが、
メンバー各人の指向スキル・キャリア方向に応じたプロダクト／サービス開発のプロジェクトを営業的に
探っていくと、少人数に分散されてしまうタイミングが生じます。
（敢えて統一的に習得できるスキル要素を重視して、多くのメンバーを同一個所に集約する期間もあります）

この2年ほどで見ると、2社の顧客＋顧客との共同企画サービス（1つ）で構成されていましたが、
顧客の1社が町田ラボとセットで拡大が進み、
他のメンバーは指向キャリア別に顧客先の拡散が進んできました（両極端ですね；今は一段落してます）。

とは言え、アスペアとして共通的に持っていたいマインドや知識・技術も有りますので、
毎月1回の定例会で、ワークショップやハンズオンなども行いながら、可能な限りの共有はしています。

しかし、"毎月一回" というのでは、当然ながら限界も有ります。

メンバー達から "考えていること・関心の高いこと、悩んでいることや、情報など" を聞き取る為に
顧客先の近くで会ってローカルミーティングをすることもありますが、
やっぱり基本は、"自分で吐き出したいことを、吐き出したい時に、やり易い方法で" 出してもらうのが最良だと思います。

現状のアスペア内で最も有効に機能しているのは、恐らくslackです。

（スマートデバイス用にアプリも有り！、って所が大きなポイントですね！）

slack上では、FacebookやTwitterのように「いいね」を付けることも出来ます。
（と言うか、多数の"リアクション"マークを幾つでも付けられます！）

あとは、リアルタイム性は遥かに下がってしまうのですが、構造的に整然と情報を集約できるという点では
CMSを使った社員専用Webサイトも運用しています。

アスペアでは、各人からの週報はこのサイトにアップしてもらってます。

つまり、週報はアップ時点で社内の誰からでも閲覧可能になる訳です。
（この週報、というかブログ機能に対しても、アスペア独自でプラグインを開発して「ｽﾃｷ!」が投稿できるようになってます。）

週報には"健康"という項目が有り、"体調"と、"モチベーション" を5段階で記載するようにしてます。
（"5"が最高！、"1"は最低...、です）

で、この数値の横に、数値に対応したニコマーク（顔マーク）を張るようにしてます（CMSの標準機能です）。

これで、文章では表し切れないようなニュアンスとかも表現してもらってます。

物理的には離れているメンバー間でも、こんな↑顔マーク１つでさえも、何となく、ほんの少しは距離が縮まっているような気がしないでもない．．．

slackで "出勤しました" って報告（オンランかどうかだけでは判断が付かない場合があるので）するときも、
表情マーク付けたら良いかも知れないですねー。

あ、１つだけお知らせです。

Wantedly（SNS型リクルーティングサービス）に登録しましたー！

宜しければ、ちょっと覗いてみて下さい。

★町田で働きたいんだよ！・働きたいのよ！、の小さなお子さん持ちのママさん・パパさん★

こちらへ！⇒

★或いは、共に成長していこう！、開発の現場をお客様込みで一緒により良くしていこう！、という方★

こちらへどうぞ！⇒

絶賛募集中です！！

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

Mr.徳田の「最近の自身の成功事例」

7月の定例会では、2人に「LT(Lightning Talk) or IT-Tips」を担当してもらいました。

１人は徳田さん。

某大手サイトの開発・保守を行ってくれています。
要件定義の補完的な部分から（モヤット要求から具体化？）基本設計以降を担当しています。

で、今回の出し物は「自分なりに良く出来た（出来ている）２つのこと」と題して近況の話題から。

1つ目は、応用技術者試験に合格したこと。

アスペアに限らないでしょうが、ことWeb系開発を生業としている会社は、「資格・認定」には余り重きを置きません。
まあ、資格も様々なので、特定業務系の大量・豊富な前提知識が必須になるような（法務関係とか）業務に強い
会社さんなどでは、特定の資格を重視・或いは殆ど前提になるのかも知れませんが．．．。

とは言え、やはり実務だけでは、体系的に広い視点・視野で要素を押さえていくのは難しいです。

資格・認定自体に意味は乏しくても、勉強により実務知識を整理・適宜で補完する機会を設けるのは良い事だと思います。

アスペアでは、受験費用（２回のトライまで）と、報奨金が出ます（金額はモノに拠り様々です）。

丁度、報奨金制度の対象資格・認定内容と、各々の報奨金額を見直したところでした。

徳田さんの受験日は、改訂内容の公開前。
実は、応用技術者試験に関しては、5万⇒4万に下がったのですが、移行期の特別措置として5万（旧規約）で報奨金支給となりました。

まあ、普通に考えたら（と言うか、報奨金の本来の目的を考えれば）当然の判断だとは思いますが。

ところで、試験に合格する為には、「試験用の勉強」が必要です。
実務が出来るから大丈夫！、ってことは有りません。
（この辺は、受験経験者ならばお分かり頂けると思います）

徳田さんは２回目のトライで合格。
１回目の受験時の敗因は、ちょっと勉強時間数が計画より足りなかったことと、「過去問」をちゃんと解いていなかったこと。
後者が決定的に効いてると思いますね。

この間の工夫した点として、"slackの個人チャネルに、勉強の実績時間を記録することにした" こと。

"確かにやったぞ！、という実感が得られて嬉しい" （プチ達成感が有る）のだそうです。

これが継続の為の励みになるわけですねー。

う～ん、分かるような気がしますね。

で、もう１つの「出来ていること」はダイエット。

食べることが大好きな徳田さん、同じ客先・同じサービスに関わっているメンバー（アーキテクト）が似たような属性なので、
定期的にダイエット勝負をしているのだそうで。

で、勝った方が食事をおごる！

これが結構なカロリーの食事だったりして、君らは結局、何をしたいんだ？！って感じもするのですが．．．
（お互いに、痩せて、戻ってを繰り返しており、「ダイエットが得意：何回でも痩せられる」状態ですね．．．）

で、ここに「シリコンバレー式　自分を変える最強の食事」（アスペア社内でプチ流行中！）を加えて実行中です。

こちらに関しても、やはりslackの個人チャネルに書いておくと（誰に読まれることが無くても）モチベーションが上がって
持続できるんだそうです。　　ほほ～～．．．．．

で、更にslack書込み効果をアップさせるべく、"ダイエット時間割" を作ってみて、実施結果を書き込んでいこうと。

なるほどねー。

これにより、自分自身がどう変化するものなのか？
自分を対象にした実験ですね。

その結果を次回の定例会で発表するから、時間枠をくれ！、とのこと。

うん、了解・了解。　早速、社員専用Webサイト上の定例会予定のページに時間枠を確保しましたよ。

色々と、結果が楽しみですね。　いや、ローカルな話で真に恐縮ではあるのですが。

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

DevOpsを視点に据えよう！

現在のアスペアメンバーの約3/4は、Web：EC系のサービス・顧客のWebサイト（バックオフィスやバッチ処理などを含む）の開発・保守に関わっています。

"Web系"という点では100%なのですが、"EC"とは違う分野でそれぞれが活躍してくれています。

で、恐らくは今後とも"EC"関連の業務比率が高いことは間違いない。

何が言いたいかというと、"リードタイムの短縮が必須である"点が、ECに特に顕著な特徴なんですね。

勿論、別にECに限定された話ではないのですが、通年でリードタイムを意識し続けなければならない、という点で
ECはちょっと特別かな、と思うわけです。

そこで、DevOps。　（"デブオプス"と読みます）

起源は2008年の Patrick Debois 氏による Agile 2008 Conference での発表、
2009年の Flickrのエンジニア John Allspaw氏、Paul Hammond氏による O'Reilly Velocity Conference での発表に端を発しているようです。

詳しくは、吉羽 龍太郎 氏のスライドをご覧下さい。

http://www.ryuzee.com/contents/blog/7068

残念ながら、アスペア社内では概要だけでも話せる人はいませんでした。

実は、DevOpsというのは非常に広範な意味を含んでいるのですが、敢えて短く表現すると、
「開発（Development）と運用（Operations）が協力し、ビジネス要求に対して、より柔軟に、スピーディに対応できるシステムを作り上げるためのプラクティス」（出典：@IT）。

これ(↑)で、何だか分りますか？

各人なりの想像は出来るかも知れませんが、具体的に何なのかはさっぱり分らないはずです。

それもそうかも知れません。

とっくにDevOpsの考え方（中身はとても広範に渡るのですが...）を取り入れていても良さそうなお客様たちの中にあっても、
このキーワードを耳にする、その視点から総合的に改善や変更を行っている顧客というのは、どうやら希少なようなのですね。

一部の元気の良いベンチャー企業や、DevOpsをソフトウェアツールの面からサポート（＝ツール販売＆コンサルティング）しよう
というメーカーだけが元気！？、な状態のようです。

しかし、アメリカでは既に当たり前のように浸透しつつある。

アジャイル開発に関してもそうですが、日本は数年（以上の？）単位で遅れています．．．。
（一部には、「アジア圏全体的に、アジャイルは浸透しにくい」とも言われているようです）

「周りがやってないんだったら、自分らもやらなくていいやー」
．．．．．などと考えていたのでは、つまらない！

実際、現場から、お客様からの声・情報を耳にするにつけ、DevOpsの視点から様々な提案や改善を推進できる人材が
求められていると強く感じます。

ので、先ずは社内で勉強会を行いました。

先に挙げた、吉羽氏のスライドを元に筆者が説明（←身の程知らずも甚だしいのですが、誰かがやらんと始まりませんから！）。

現時点でお世話になっているお客様の事例を具体例として引き合いに出しながら、どうにか進めました。

冷や汗をかきつつですが、どうにか60分少しオーバーで終了。

本当は、個別顧客の実態の話を、定例会に参加しているメンバー達の口から事例として話して欲しかったのですが、
それをすると軽く2時間を超えそう．．．。

と言うか、先ずは"DevOps"なるものを一通り説明して、
次回以降の定例会で、実態と関連付けしつつ、場合によってはディスカッション（どうすべきなのか？、こうしたら良いのでは？、とか）
など展開しつつ、2回、3回と続けて行けたら良いのではないか？、と思ってます。

実際には、お客様のサービス、プロダクト、そしてビジネスに応じたDevOpsが必要になります。

1つの絶対解は存在しません。

言い換えれば、お客様のビジネス：サービスに応じて、望ましいDevOpsの形を提案し実現・そして改善し続けていけるメンバー達が集まっている会社。

アスペアはそんな社風：文化を持って行きたいと考えています。

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