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

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)

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

10月の全社定例会で、"参加者が少なかったのでミーティング形式にしてみた" コンテンツを1枠設けました(前回の記事でも触れました)。
 
事前の "定例会開催の確認通知メール" でも、「何か会話してみたいネタが有ったら持って来てねー」と振っておきましたが。
当日、持込みネタは1つ、あと2つほど私の方から話題を出しました。
 
1つは "社外セミナー" に関して
平日の夜(19時辺りから開始されるモノ)とか、土日に行われるものも有ります。
日常がどうしても目の前の業務で忙殺されがちなので、
私の方で「これは、あの人が関心を持ちそうだ」とか、「これは関心持って参加して欲しいなー」なセミナーやワークショップ、ハンズオンなどを社内slackのチャネルに案内するようにしてます。
いかにも個人向けでお勧めのものは、slackのDMで流します)
 
しかし、実際にセミナーに参加するメンバーが限定されている...
必ずしも業務稼働的に高稼働ではないにも関わらず、参加者が少ないなーとか...
(単純に "作業時間数" だけでは "疲労具合" は測れないことは承知していますが)
なので、この際に話題にしてみました
 
以下、話題に挙がった意見の幾つかを紹介します。
 
・手持ちの軽量NotePCがない(ハンズオン出来ない)
  ⇒ これは、会社から空きNotePCを貸し出せるかも知れないので、是非問合せて欲しい。
・人見知りなので、正直に言うと恥ずかしい
  ⇒ あー、これは......。分かります、理解できます。 私も同じです。
    「そのひと山を超えると、新しい自分が開けていくかも」と考えてみても、心理的なブレーキは確かにあるでしょうね。
    率直な意見、有難う御座います。って感じです。
  ⇒ これに関しては、slackで紹介したイベントに "興味あるよマーク" を付けて、2人以上になったら誘い合って行ってみる、
    という対策を挙げてくれました。
・既にコミュニティが出来ていると輪に入りにくい
  ⇒ ああー、これも分かります。主催側とかメンター側でこれをやられたりすると、結構辛いですね。
    「俺、完全に部外者じゃね?」ってなります。
・技術系のセミナーの場合、さわりの部分だけで終わりそう
  ⇒ これはセミナー自体の選択の問題と、講師・メンターへの質問・会話を重視するか?
    そもそも講師と知り合うこと(人脈?)を目的とするか?、という気もします...
・過去に参加したセミナーがあまり良くなく、セミナー自体に対する印象が悪い
  ⇒ これは負の学習結果で、仕方ない一面も有り。
    ですが、全てのセミナーやワークショップを否定する理由にはならないと思います。
 
これは私見ですが、"下手に参加して恥をかきたくない、下手な質問や発言をしてボコられたくない"ってのも
有るんじゃないか?
、と思います。
と言うか、私はそう感じてました(開発で現役の頃)
 
"自分が、いけてない技術者であることを自覚させられたくない"、って気持ち、正直言ってありました
 
それでも、少なくともプロセス系のワークショップは刺激的です!
 
人見知りとか遠慮とか、言ってられません。
かと言って、無難に黙っているとか有り得ないです。
と言うより、"俺の(或いは仲間との)経験・知見からも言わせろ!"、って気持ちになって来ます。否が応でも!
参加した事の無い人は、是非一度ワークショップには参加してみて欲しい!
未体験の楽しさ・興奮・充実感(&疲労感とか焦りとかも含まれるけど)を味わえるので是非!
 
.....と幾ら目を輝かせて熱く語っても、行かない人は行かないんですよね...
 
たまたま最近読んだ本ですが、「なぜ人と組織は変われないのか」
要は、自分のホンネ(直感的なモノ)が、理性的な意思や行動を必然的にゆがめてしまうってことで。
 
これは自己分析の段階を経て、対処の考え方と行動まで自身の頭と心で導き出せば、変われるよ。
ってことのようです。
 
同書にはワークショップの行い方なども記載が有ります。
ちょっと荷が勝ちすぎる感じはしますが、社内でやってみようかな.....
行動無ければ変化も無し、ですし。


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

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

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

10/14に10月の全社定例会議が有りました。
 
.....が、客先で構成しているアスペア・チームの内で最大の体制で参画しているサービス/プロダクトの開発が、
ここ2~3ヵ月の間・佳境に入っており、そのほぼ全員が帰社することが出来ません。
(1人だけ帰社出来た!、と言うか帰社できるように頑張ってくれた!)
 
たまたま同時期に業務負荷的にピークの顧客先:サービスがあり、帰社不可のメンバーが悪いタイミングで重なってしまいました。
 
通常なら、基本的に役員を除いて半数を超えるのメンバーが参加出来ないときは、全社定例会を中止する原則としています。
この原則に倣って9月の定例会が中止になったのですが、2ヵ月連続での"開催無し"は避けたい...。
 
参加者数が少なめなのであれば、それに応じた、
否、返って望ましいコンテンツと言うか、進め方があるのでは?

...ということで、10月定例会は予定通りに実施しました。
 
参加者数が少なめなので、"共有・発表、ハンズオン"系のコンテンツはほぼ中止。
替わって、"じっくり資料を覗く系"、"ディスカッションと言うより、ミーティング感覚で気軽にやりとり出来る系"の内容に急遽変更。
 
その1つとして、「"アジャイルコーチの道具箱"をひっくり返してみよう!」("資料を覗く系")を実施しました。
 
オリジナルの資料は、電子書籍、"アジャイルコーチの道具箱" です。
 
「これは良さそうだ!」と思い、上記のサイトから購入して社員用Webサイトで共有してあるのですが.....
.....放置しておいても(全員に告知はしましたが)見る者は少なく...
 
この際、本の頭の方から順繰りに覗いてみて(プロジェクターで投影)、
面白そうなツール(基本的には全てアナログ)、気になった点、今までに類似した例を見たとか、
こんな工夫をして良かったとか、こういう点に留意すると良いとか、
そんな話がワラワラと出てくれば会話が進むに任せるし、
無ければ次々とページをめくってみて、気が付いた点などに(筆者が)コメントしたり。
 
"読書する書籍" ではなく、"ヒント/サンプル集" といった趣なので、
退屈はせず、肩ひじも張らず、次のページや展開の予測もつかず(コンテンツによっては、勘の良い人間は先読みして退屈したりしますから...)、
まったりと、(ほんの数分の一しか覗けませんでしたが)見ながら、参加者の何気ない経験・知見で雑談的に話せたのは良かったのではないかな、と思いました。
 
定例会の最後の振返りで、「"道具箱"を参考に、プロジェクト内での見える化する!」、というTryが出て来たので、それだけでもやって良かったなあ、と思った次第です。
そのプロジェクト的に、課題感が有るタイミングだったようです。
問題点を "問題" と明確に意識できること、"課題化"できる事は重要ですからね!
それを、「じゃあ見える化しよう!」と方向付けの判断をして、発言できたことも嬉しく思いました。
 
変えたい!、変えるべきだ!、と意識出来て&変えたいと感じなければ、永久に変えることは出来ませんから。
 
折角、購入した電子書籍なので、折に触れてちょびちょびと話題に出していこうと思ってます。
幸い、この書籍は "1ページに1ツール(アイデア)" が原則構成になっているので、散発的に話題に出しても全く問題無いんです。
 
言い換えれば、筆者が一通りのツールを取りあえず頭に入れておき(ぼんやりとでも良いから)、
現場からの声(週報とか、定例会での発言とか)をトリガーにして、
「あ!、そう言えばこんなツール有るんだよ。面白いよ!、やってみない?」と言えるようにしておかねば。
 
勿論、各メンバーが自由にパラパラめくって(具体的な目的が無くても)見ておいてもらう方が良いのは
言うまでもないことですね。


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

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

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検索で適切な情報をヒットさせるのにコツが要る)が低い。
 
20160819190215 ここで、ライブコーディングをしてくれました!
と言っても、実際に動作しているのは彼の自宅にあるMacBook。

リモートデスクトップで、町田事務所にあるNotePC(Windows10)から操作しました。
 
Java7ベースで書いた&Webページとして動作するソースコードを、scalaに書き換えていく、というものでした。
分り易くて面白いです!
 
拘りのあるメンバー達からは、コーディング途中で「えー!?」とか「ああー...」とか声が漏れて来て、
それも面白かったですね。
無言、無反応じゃあ、お互いに面白くないということですから...。
 
※使ってみての感想
  ・関数型を勉強できてよかった。
  ・再代入しない副作用のないコードメソッドは必ず何らかの実行結果を返す、という大原則の元で動く。
  ・ちょっといいJavaを書きたいという人はいいのでは?
 
[質問] 広告、ゲームでscala適用の例が有るとのことだが、その採用理由は?
  ⇒元々PHPを使っていたが、規模が大きくなって何かと運用コストが膨れるし、負の遺産と化していた。
   scalaを選んだ理由は、並列処理が簡単に書けること。
   スレッドが別になるのでバグっても全体が止まることが少ない。

[側面から補足] アーキテクトでもある山下さんが補足説明を入れてくれました。
   ランキング等はもの凄いアクセス・ユーザ数があるからマルチスレッドで処理する必要がある。
   Javaではスレッドを立てるだけでそこそこのコードを書くことになるが、Scalaは簡単に書ける。
やはり、動くモノをリアルタイムで見られるのは面白いです!
 
それと、現行技術(言語)から新技術への移行プロセスを、超簡単な実例ではありますが体験共有してくれたのは
素晴らしいと思いました。
 
実際にプロダクト/プロジェクトで採用するか否かは多くの要因を考慮しつつ決定しなければなりませんが.....。
 
ただ、こういった新しいものへの取り組みを、若手が実践して共有してくれるってのも非常に嬉しいことです。


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

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

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

あなたの近くに、自分の数年後・或いは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数年前に言われたこの言葉を再び聞く可能性は、かなり減ったんじゃないかと思います。
また、先陣を走るメンバー達にしても、
「結局は正解を他所から持って来るのは不可能。より良い結果を出したければ、現状に応じて自分(達)で考えて、工夫して進んでいくしかない」、
という点は、は分ってくれているのではないか、とも思います。


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

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

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

アスペアのメンバーは、自社事務所で殆どの開発・保守作業を行っている「町田ラボグループ」と、
顧客先にて要求の内容確定・補完、交通整理から仕様確定・デザイン&UI設計・設計・製造・各種テスト・リリース・保守・運用・障害対応など
様々なことを行うメンバーに大別されます。
 
また、顧客先も複数に分かれています。
基本的には、余りメンバーを拡散させない方針なのですが、
メンバー各人の指向スキル・キャリア方向に応じたプロダクト/サービス開発のプロジェクトを営業的に
探っていくと、少人数に分散されてしまうタイミングが生じます

(敢えて統一的に習得できるスキル要素を重視して、多くのメンバーを同一個所に集約する期間もあります)
この2年ほどで見ると、2社の顧客+顧客との共同企画サービス(1つ)で構成されていましたが、
顧客の1社が町田ラボとセットで拡大が進み、
他のメンバーは指向キャリア別に顧客先の拡散が進んできました(両極端ですね;今は一段落してます)。
 
とは言え、アスペアとして共通的に持っていたいマインドや知識・技術も有りますので、
毎月1回の定例会で、ワークショップやハンズオンなども行いながら、可能な限りの共有はしています
 
しかし、"毎月一回" というのでは、当然ながら限界も有ります
 
メンバー達から "考えていること・関心の高いこと、悩んでいることや、情報など" を聞き取る為に
顧客先の近くで会ってローカルミーティングをすることもありますが、
やっぱり基本は、"自分で吐き出したいことを、吐き出したい時に、やり易い方法で" 出してもらうのが最良だと思います
 
現状のアスペア内で最も有効に機能しているのは、恐らくslackです
(スマートデバイス用にアプリも有り!、って所が大きなポイントですね!)
 
slack上では、FacebookやTwitterのように「いいね」を付けることも出来ます
と言うか、多数の"リアクション"マークを幾つでも付けられます!
 
あとは、リアルタイム性は遥かに下がってしまうのですが構造的に整然と情報を集約できるという点では
CMSを使った社員専用Webサイトも運用しています
 
20160802_ アスペアでは、各人からの週報はこのサイトにアップしてもらってます。
 
つまり、週報はアップ時点で社内の誰からでも閲覧可能になる訳です。
この週報、というかブログ機能に対しても、アスペア独自でプラグインを開発して「ステキ!」が投稿できるようになってます。
 
週報には"健康"という項目が有り、"体調"と、"モチベーション" を5段階で記載するようにしてます。
("5"が最高!、"1"は最低...、です)
 
で、この数値の横に、数値に対応したニコマーク(顔マーク)を張るようにしてます(CMSの標準機能です)。
 
これで、文章では表し切れないようなニュアンスとかも表現してもらってます
物理的には離れているメンバー間でも、こんな↑顔マーク1つでさえも、何となく、ほんの少しは距離が縮まっているような気がしないでもない...
slackで "出勤しました" って報告(オンランかどうかだけでは判断が付かない場合があるので)するときも、
表情マーク付けたら良いかも知れないですねー
 
あ、1つだけお知らせです。
 
Wantedly(SNS型リクルーティングサービス)に登録しましたー!
 
宜しければ、ちょっと覗いてみて下さい。
 
★町田で働きたいんだよ!・働きたいのよ!、の小さなお子さん持ちのママさん・パパさん★

こちらへ!⇒

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

こちらへどうぞ!⇒

 
絶賛募集中です!!


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

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

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

7月の定例会では、2人に「LT(Lightning Talk) or IT-Tips」を担当してもらいました。
 
1人は徳田さん
20160708181258 某大手サイトの開発・保守を行ってくれています。
要件定義の補完的な部分から(モヤット要求から具体化?)基本設計以降を担当しています。
 
で、今回の出し物は「自分なりに良く出来た(出来ている)2つのこと」と題して近況の話題から。
 
1つ目は、応用技術者試験に合格したこと。
 
アスペアに限らないでしょうが、ことWeb系開発を生業としている会社は、「資格・認定」には余り重きを置きません。
まあ、資格も様々なので、特定業務系の大量・豊富な前提知識が必須になるような(法務関係とか)業務に強い
会社さんなどでは、特定の資格を重視・或いは殆ど前提になるのかも知れませんが...。
 
とは言え、やはり実務だけでは、体系的に広い視点・視野で要素を押さえていくのは難しいです
 
資格・認定自体に意味は乏しくても、勉強により実務知識を整理・適宜で補完する機会を設けるのは良い事だと思います
 
アスペアでは、受験費用(2回のトライまで)と、報奨金が出ます(金額はモノに拠り様々です)
 
丁度、報奨金制度の対象資格・認定内容と、各々の報奨金額を見直したところでした。
徳田さんの受験日は、改訂内容の公開前。
実は、応用技術者試験に関しては、5万⇒4万に下がったのですが、移行期の特別措置として5万(旧規約)で報奨金支給となりました。
 
まあ、普通に考えたら(と言うか、報奨金の本来の目的を考えれば)当然の判断だとは思いますが。
 
ところで、試験に合格する為には、「試験用の勉強」が必要です。
実務が出来るから大丈夫!、ってことは有りません
(この辺は、受験経験者ならばお分かり頂けると思います)
 
徳田さんは2回目のトライで合格。
1回目の受験時の敗因は、ちょっと勉強時間数が計画より足りなかったことと、「過去問」をちゃんと解いていなかったこと。
後者が決定的に効いてると思いますね。
 
この間の工夫した点として"slackの個人チャネルに、勉強の実績時間を記録することにした" こと
 
"確かにやったぞ!、という実感が得られて嬉しい" (プチ達成感が有る)のだそうです。
これが継続の為の励みになるわけですねー。
う~ん、分かるような気がしますね。
 
で、もう1つの「出来ていること」はダイエット
 
食べることが大好きな徳田さん、同じ客先・同じサービスに関わっているメンバー(アーキテクト)が似たような属性なので、
定期的にダイエット勝負をしているのだそうで。
 
で、勝った方が食事をおごる!
これが結構なカロリーの食事だったりして、君らは結局、何をしたいんだ?!って感じもするのですが...
(お互いに、痩せて、戻ってを繰り返しており、「ダイエットが得意:何回でも痩せられる」状態ですね...)
 
で、ここに「シリコンバレー式 自分を変える最強の食事」(アスペア社内でプチ流行中!)を加えて実行中です。
 
こちらに関しても、やはりslackの個人チャネルに書いておくと(誰に読まれることが無くても)モチベーションが上がって
持続できるんだそうです
。  ほほ~~.....
で、更にslack書込み効果をアップさせるべく、"ダイエット時間割" を作ってみて、実施結果を書き込んでいこうと。
なるほどねー。
 
これにより、自分自身がどう変化するものなのか?
自分を対象にした実験ですね
その結果を次回の定例会で発表するから、時間枠をくれ!、とのこと。
 
うん、了解・了解。 早速、社員専用Webサイト上の定例会予定のページに時間枠を確保しましたよ。
 
色々と、結果が楽しみですね。 いや、ローカルな話で真に恐縮ではあるのですが。


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

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

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の形を提案し実現・そして改善し続けていけるメンバー達が集まっている会社
 
アスペアはそんな社風:文化を持って行きたいと考えています


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

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

シリコンバレー式・最強の食事!?

個人的に、書籍「シリコンバレー式 自分を変える最強の食事」を読んでみました。
 
正直、「キワモノ」だろうと眉唾で読み始めたんですが、これがまあ意外と面白い。
 
ダイエットを起点に書かれていますが、それは "自分を変える" 内の1要素でしかない。
 
心身共に健康にし、快適で、日々最高のパフォーマンス(頭脳も体も)を出せるように自己改造しよう!、って内容です。
 
"西洋人目線で、かなり偏向して書かれている" んじゃないか?、と考えられる部分もあります。
例えば、「味噌・醤油は、敢えて摂取する必要が考えられない」とか...
 
ですが、日本の食養や養生訓に通じる部分もあったりして、一概に否定もできない。
何より、筆者自身が「各個人により体質も異なるので、自分の最強の食事を自分で発見してみてくれ」、みたいなことまで
書いてあります
から、"万人に通用する絶対解" ではないことは承知の上なのも分かります。
 
で、話は変わってアスペア社内の話題。
 
アスペアは1991年創設ですので、初期から参画してくれたメンバーの中には、50代に乗ってくる者もいます。
 
現役エンジニアですが、やはり年齢的な様々な変化(マイナス面)は無視できないようです
 
現代科学の範囲で対処しようもないものは仕方がないとして、
対処可能(かも知れない)な手段があるのなら、せめて試してみたい
 
で、ある日、或るベテランメンバーと個別のミーティングをしていた際に、その辺りの話題になりました。
集中力・記憶力、睡眠の不安定化などで、総合的に見てもパフォーマンスの低下が無視できない。
健康診断で中性脂肪を下げるよう指導も受けている
 
ことに、アスペアはWebサービス/WebアプリやAPIの開発を生業にしています。
どうしたって作業速度が要求される。
 
臨機応変な判断・協調&調整・アクションが必要です
 
そこで、上記した「シリコンバレー式...」って書籍があるよ、って紹介をしてみました
 
「それでは早速」ってことで、
同書のKindle版(彼はiPad miniを愛用してます)を購入し(!)、一番分かり易く、試し始め易い「完全無欠コーヒー」から始めました...。
効果は.......
 
※少なくとも、午前中は頭がスッキリ!
※記憶力も頭の回転も良くなる。
※お昼ごろまでお腹が空かない。
 
このレポートが週報として社員専用Webサイトに載ると.....
「シリコンバレー式...」入門者がジワジワと増えて、総勢4人に達しました(30代~)。
(筆者自身は50代ですが、事情により入門できないのが残念です)
 
成人していれば「シリコンバレー式...」の入門は(生理学的には)問題無し。
 
今のところ20代のメンバーに入門者はいないのですが、今後、検証者が増えて効果が確実・顕著なものは、
アスペア標準として "強く推奨っ!" ってこともあるかも!!?
 
.....いや、無いですね。 失礼しました。


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

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

Mr.山下のFirebaseデモ & DevOps予告

アスペア内でアーキテクトとして成長&実績積上げの著しい山下さん
 
定例会内の1レギュラーコンテンツとしての "IT-Tips(or Lightning Talk)" の中で、
"Firebase" の紹介説明&デモを行ってくれました。
(基本は5分で説明とかデモ、5分で質疑、計10分的な枠です)
 
この辺りの記事↓を読んで頂ければ、Firebase の概要は掴んで頂けると思います。
http://gihyo.jp/dev/serial/01/firebase/0001
 
Firebase は、当初は BaaS(Backend as a Service)という分類名称になっていましたが、
現在では(2012年にGoogleに買収されて以来)、"MBaaS"(Mobile Backend as a Service)と呼ばれるべく
大幅な機能拡張が成されてきました。
 
20160610191321 当の山下さんも、ネタの仕込みとしては数年前に行ったそうなのですが、
暫く振りに見てビックリ! どえらく機能豊富になっとる!
...と驚いたそうです。
 
さて、Firebaseの機能・特徴は様々ですが、僅かな時間枠の中でデモまでして頂くには対象機能を限定しないと。
特に、Firebaseの売り・特徴となる部分で"動くところが見られる"のが、やっぱり最高です!
 
という事で、Googleに買収される以前から存在していた機能である、
"リアルタイム同期型データベース" の機能紹介&デモ(社内の各員からどんどん随時書き込んでもらうと、
デモ中PCである山下さんのPC画面(プロジェクターで投影中)に、リアルタイムでどんどん書き込まれていく)

を行ってくれました。
この間、デモPCの操作は何も行っていません(画面のリフレッシュとか、再検索とか、何も行っていない)。
 
"リアルタイム同期型データベース" と言うのは、ローカルにデータベースを持ち、オンメモリで高速な更新処理を行いつつも
リアルタイムでサーバ間でも並行して同期を行う
、という代物です。
 
この場合だと、デモ用PCには、他者から書き込まれた内容がpull型で画面更新されていく、ということです。
 
20160610191650 まあ、これだけを見る限りでは、GoogleDocs等の操作で見慣れているかも知れませんが、
ここでは "自分で書いたコードで、この機能を活用できる" 点が大きく違います。
(Gooogleのアプリとか、何かしらのローカルアプリを起動している訳ではありません)
 
コードも見せてもらいながらの動作確認、ライブで体感できるのは、やっぱり楽しいし刺激的ですね。
 
あ、これまでの話と全然関係ないんですが...(関係なくもない、か...)
このデモ&質疑が長引いて、(&他のコンテンツもかなり長引いて)予定していた "DevOps" の確認学習会&実顧客での実例の共有会は
たったの5分しか枠が無くなってしまいましたーーーっ!
 
あはははははははは..........
 
写真に写っている白板に、何からゴチャッと絵が描いてあるのが、予告の落書きです。
(急いで5分以内に収めようと、コンテンツの趣旨を話そうとしたんですが、抜けだらけでした)
 
これから、アスペアではDevOpsの切り口で、定例会コンテンツや、場合によってはキャリア形成・スキル構築に、
更には考課にも適用していこうかと目論んでいるところです。
ふっふっふっふっふ.....


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

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

Ms. Tommyの新たな一歩!

6月の定例会は10日(金曜日)でした。
 
この日は、アスペア内で唯一のフロントエンジニである Tommy=あだ名:純粋な日本人です!)が、
新規顧客:プロジェクト(サービス)に新たに加わったということで、
 
アスペア内での参画初期時点(概ね1ヵ月程度)で、
どのようなお客様か?(現状ビジネスとか、今後のビジネス的な方向性とか、社風・雰囲気とか...)
どんなサービス(プロジェクト)で?
どんな役割で?(ロール、役割分担のポリシー、権限と責任所在...)
どんな事を、どんなやり方で行っているのか?(開発・運用・保守、チーム体制、プロセス...)
その他諸々(技術的な要素:言語、OS、ミドルウェア、フレームワーク、クラウド活用...)
.....などを、見えた範囲で社内共有します

(勿論、例え社内と言えども守秘義務が伴う場合もあります)
 
20160610172512 今回のTommyの役回りは、デザイン系の部署に配属はされるけれども、
今後はコンテンツの動的化を進めたい(クライアントサイドだけでなく、サーバー連携も含めて)、
サーバーの機能を伴って動的化するには、サーバー機能をAPI化し、JavaScriptで制御しなければならない。
 ・その際の、API化の方針や粒度の調整に、今後段々と関わっていったりとか、
 ・JavaScript側の実装の標準化や勉強会?なども考えなくちゃいけないかな?、とか、
現状のサイトが結構な数があり、担当部署も複数存在するが、これらを効率化する為にできるだけ集約したい、
その為に、共通化なども必要だろうが既存サービスは既に走っている最中なので、
先ずは出来るところから、ということで版数(リポジトリ)管理から入りたい、とか、
じゃあ版数管理に何を(どんなツールを)使いますか?とか、
そもそも、現状部署でもデザイナーさん達がたくさんいるけれども、ツールや書き方、ファイル構成などの取り決めも無くて混沌状態だね、とか、
出来るところから機会・様子を見て少しづつの改善を積み重ねていくしか無いかな、とか、
契約の切れるデザイナーさんから引継ぎして、保守・運用が止まらないようにしないとね、とか、
 
.....ちょっと、いや、かなり色々と大変なようです
 
とは言っても、部署の雰囲気はとても良く、
Tommyの人柄も相まって、仲良く楽しみつつ、お仕事をさせて頂いているようです
 
課題が多いとはいえ、短期間に無理くり進めようとか、ケツだけは決まっててスケジュールは押し込め!、とか
そういったことは無いので(少なくとも今のところは)安心です。
 
同プロジェクトで人員募集が掛かっていたのが、たまたまデザイナー系で、動的デザインやディレクションも
出来るといいなー的な要求でしたので、アスペアからはTommy1人での配属になりました。
 
日頃の業務に支障はありませんが、アスペアとしてのメンバーフォローは別に行います
 
月に1回、業務的に無理が無い限りはアスペアの町田事務所に戻り、全社定例会で互いのナレッジを交換したり、
ワークショップやハンズオンしたり、誕生日を祝ったり、
その後に有志でお食事や飲みに繰り出したり...と様々。
 
これとは別に、ローカルなミーティングとして、顧客先別のメンバー達とフォローミーティングを行います
 
ミーティング内容は、その時々の状況や課題に応じて違ってきますが、
メンバーの指向キャリアと実業務との妥当性チェック
  ・現場でメンバーから行って欲しいアクションとか、意識の持ち方とか、チャンスの捕まえ方とか、
  ・営業的に動いた方が良さそうなら、その辺の作戦会議、
↑に紐づいて、1年分に落とし込んだ目標事項(MBO:Management By Objectives)の達成状況とか確認、
  ・達成に向けたアプローチに困っている場合、障害がある場合は対処法を一緒に考える、
心身の状態チェック
  ・特に、週報で体調やメンタルにアラートやWARNINGが出ているメンバーには慎重・継続的に対応します。
  ・食事・睡眠は快適な生活の前提事項なので、本人から特にアラートが出ていなくても、時々は確認するようにしてます。
その他:顧客やプロジェクト、サービス、人間関係などに依存した固有の問題があれば適宜で対応していきます。
  ・内容によっては同行するメンバー構成・人数も変えます。
と、メンバーの成長とリスクヘッジを兼ねて
まあ多少でも(月1回の定例会以外でも)個人と会話する機会ってのは有った方が良いと思ってます
 
さてさて、Tommyもいつのまにやらアスペア入社後に丸5年が経ちました。
 
WebやWebサービス開発専門のアスペアですが、正直のところ、フロントにはそれほど強くはありませんでした。
そんな中にあって、Tommyは初のパターンとも言えます。
 
幸いに?、ソーシャルゲーム・サービスに1年半以上関わり、デザインのみならず自ら開発側との調整・交通整理なども経験してます(非常に大変な現場でしたが...)。
多くの関係者間での調整作業の難しさを知ると共に、勘所なども身に付いてきている様子。
 
逆に少人数で(フロント面という意味では、実質1人で!)某顧客のサイト・リニューアルを果たした実績もあります。
(並行して、他案件からフロントの相談を受けること多々...)
少なくとも、もうアスペア社内では最高のフロント側のスペシャリストと呼べるようになりました。
 
とは言え、業界的なレベルで言えば、課題もまだまだたくさんあります。
焦らず、着実に成果を残していってくれればと願ってやみません。


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

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

4月生まれのハッピーバースデイ!

4月生まれは徳田さん
 
なのですが、4月の定例会は余りにも参加者・帰社できるメンバーの数が少な過ぎで休止となりました。
 
ので、5月の定例会でハッピーバースデイ♪のお祝いをしました。
 
実は、4月生まれはもう1人、三文字さんがいるのですが、5月も業務多忙で帰社できず
残念です.....。
 
この辺は、自社内開発でないことのマイナス点ですね。
 
逆に、顧客の業務や、生の要求(必ずしも他の要求と論理的に統一されていなかったり、ステークホルダーが複数いる為に
要求間に重複や矛盾があったり、その他諸々)にリアルタイムで触れられる点などはメリットだと思います(他にも少なからずメリット有ります!)
 
_0002_0012 さてさて、小さいとはいえホールケーキを独占することとなった徳田さん。
 
仕事も遊びも、本を読むことも食べることも大好きで真剣にのめりこんでいく徳田さん
 
仕事面でお客様からも、社内の仕事仲間からも信頼が厚い点は素晴らしいのですが、
食べることにも真剣過ぎで体調壊し気味なのが玉にキズ。
 
とは言え、まあ、誕生日祝いのケーキくらいは良いでしょう!
 
さて、いつも通りに、消灯・♪ハッピバースデイ、トゥーユー♪を歌ってから、ロウソクの火を吹き消してもらいました。
それでは、ケーキを切り分けて、徳田さん、どうぞ!...
.....と思ったら、今回はレア・チーズケーキ
 
_004_006 何と、徳田さん、レア・チーズケーキは苦手なんですと! 何と!?
 
う~む、確かにチーズケーキは、より好みが分かれ易いかもですね。
 
いつもケーキの調達は業務推進部の人にお願いしてるんですが、その度に季節やバリエーション等を考えてくれてます。
 
で、たまにはチーズケーキも良いんじゃないか!?、と選んでくれたんでしょうが、残念なことに裏目に出てしまいました...。
 
でもまあ、周りの皆で美味しく戴きましたから! 良かったんじゃないでしょうか!!(←酷い...)
 
次回はケーキ選択に気を付けたいと思います。


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

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

slackにBOT仕込んでGoogleDocs連携。

以前に、"slackからGoogleDocs連携でラク~" という記事を書きました。
http://aspire.way-nifty.com/majime/2016/03/slackgoogledocs.html
 
これは、slackの特定のチャネルから特定の簡単な書式でつぶやけば、のGoogleDocsのスプレッドシート形式の"休暇申請"が
業務推進部に届くよ!
20160513181934 というもので、アーキテクトでもある山下さんがプロジェクトの移行期間中にパパッと作ってくれたものです。
 
折角なので、その仕組みを概説してもらおうじゃないか!、ってことになり、5月の定例会の1つのコンテンツとなりました。
 
題して、「休暇申請BOTを支える技術」
 
最近、LINEを含めて、何となくBOT流行りですね
 
あ?!、写真が、前回使ったモノの方が、今回コンテンツの物でした...
こりゃいかん。  まあ、 いいか。
それじゃ、本題に入りましょうか。
 
現在、休暇申請は GoogleDocs のスプレッドシートを作成&URLを業務推進部にメール送信する流れです。
ネット閲覧に関してセキュリティの厳しい顧客先などで作業を行う場合に、この提出作業は面倒なものでした。
さてここで、アスペアではチャットツールとして、slackを利用しています。
Slackは特定の発言があった場合に、その内容をPOSTに乗せて指定URLに飛ばす仕組みです(Outgoing WebHook)。
受信は GoogleAppScript で制御します。
最終的には、PC、スマートデバイスの区別なく、slackからつぶやけば上記の申請書が業務推進部に届くようにしたい。
(slackに関しては、iOS、Androidの別なく、アプリが提供されている)
 
.....といった点を踏まえて、
実際のslackのHook設定画面や、今回作成したスクリプト(Google Apps Script)のソースと概説などを
行ってくれました。
 
※良かった点:
  ・環境が全てクラウド上にあるため、自宅でも作業ができて便利!
   (丁度、作業期間中にウィルス性腸炎に罹り、自覚症状的に復活できても出社を控えなければならなかった)
 
※困った点:
  ・Slackのアップデートが頻繁にある為、日本語の記事を追っているだけでは把握できない&誤情報となる場合も。
  ・サーバー上でをログを見ることができない。
    → Wordファイル(Googleドキュメント)に吐き出すなどすれば良かったかも。
  ・Javascriptのライブラリを利用することが出来ないため、単純な文字列処理なども自作しなければならない。
    → 独立性の高いオープンソースからコピペ利用することは可能かも...
 
※気を付けた点:
  ・既存の「休暇申請」(スプレッドシート)は、いじらないようにした(フォームもスクリプトも)。
  ・ので、従来の休暇申請方法でも提出が可能です。
 
着想的には、PCが無くても簡単に休暇申請が出せると良いねー、って話だったんですが、
気が付いてみれば slack で呟く方が圧倒的に手数が少ない!
 
もう、PCで作業中であっても、このBOTを利用して申請提出をした方が時間効率が良いです!
 
...ということで、山下さんの予想以上に使い勝手が良く、多用されまくっている slack BOT さんなのでした。
(非常に残念ながら、特にBOTさんに固有名詞は付けられてません)
 
1回1回の短縮時間は1分程度かも知れませんが、1年間で全員分の時間短縮時間としてみると、結構・対投資効果の高い
開発だった
と思います。
 
改めて、山下さん、仕様面からいろいろと配慮したものを作ってくれて有難う御座いましたー!


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

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

ビジネス要求とサービス開発(DevOps)

今回は長部さんベテランの域だが若く見えてカッコいい!;技術者としての実力も凄いぞ!)が、
比較的最近・新たに参画した顧客:プロダクト(サービス)に関して、現時点で見えている範囲の情報を共有してくれました!

起業の最初っからインターネット上のビジネスをスタートされたお客様とは違い、
元々はアナログ媒体でのビジネスも活発にされていたお客様です。

あまり詳細は書けないのですが、上記の前提がビジネスフローの特徴に必然的に結びつき、
恐らくはシステムや運用にも大きく反映されているんだろうな...、
という事を感じさせてくれる内容でした。

直前まで対応していた別顧客:サービスでは、最初っからネットビジネスだったこともあり、
また、負荷対応に関しても、ちょうど長部さん本人が、案の提示に関わったり、チューニング作業自体・及び検証・測定を行ったりの経験がありましたから、
この辺は経験値の積重ね=厚みを増す=メタ知識・技術の習得にも役に立つのではないかな?!
と思いながら、興味深く話しを聞きました。

こうした、メンバーが関わっているプロダクトやサービスに関しては、社内限定で共有しますが、
質疑を行うことで、より共有度・理解度を上げます
と共に、質問を受ける側も、「回答しきれない」シーンが出て来ます

これを基点にして、更に現場での知識の深堀を行うことが出来ますね。

20160513173750ちなみに、今回の長部さんからの発表内容は(前述した通り)ビジネス・フロー的に特殊な面がありますが、
こういった話題になると、技術者からではなく、会長や社長から非技術の視点からの質問も出て来るので
コンテンツとしての厚みが増すのが面白い
ですね。

余談ですが、"技術者だからビジネスに関する理解は、それほど必要ない"という考え・認識は間違っていますよね!?

特に、我々アスペアもそうですが、ネット・ビジネスを支えるシステム(サービス)を具現化しようというときに、
要求の仕様"=吟味されてブレない、正しいモノ"として対処すれば、手戻りや混迷が深まるばかりです。

エンジニアもビジネス的な要求と、システムという形を取る目的・意義・効果を、ある程度理解していなければなりません。

IT業界で言うところの"DevOps"ってヤツですね。

けれども、"ビジネス要求を正しく把握"と言葉にするだけなら簡単なのですが、これをしっかり意識して
実践し続ける/顧客の投資に対して最大限の価値を提供する、ってのはなかなか難しいです。

要求や手段がかなり限定された場合であっても、「だったら絶対にこうすればOK!、大儲け間違いなしですよー!」
なんて仕様・設計や実装はあり得ません。

なので"DevOps"。

想定を膨らまし過ぎて大きな失敗(=大きなコスト損失)を招くより、小さく作って小さい失敗から学びを得る。
その為には、"調査・想定"⇒"仕様決め"⇒"試験的実装"⇒"部分的な公開"⇒"反応を分析"⇒(元に戻る)を、
迅速に確実に回していく必要があります
よね。

今回の長部さんのお話によると、既にビジネス的には結構な成功状態で軌道に乗っており、
今後は更なるブッチギリ方向に向けた施策と、
ビジネスをしっかり支えるバックヤードの仕組みを、より堅牢にする必要がありそうでした。
(まさにその一部のステップに、長部さんが加わったようです)

生きたビジネスとシステムの話しを聞けるのは、本当に面白いです!


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

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

Mr.山下の「入って早々大暴れ!」?(大活躍)

5月の定例会では、山下さんアーキテクトであり、要件定義フェーズの支援や顧客間の各種調整、リーダー業務、
更にはメンバーの教育などもこなすスーパーマン!
)から、
20160513170854 新たに参画した顧客先プロジェクトのビジネス的特徴や、開発の体制とか進行上の特徴、技術的な基本特性などに関して
お話をしてもらいました。
 
山下さんとしては未経験の技術要素として、
RoR、Rubyそのもの、AngularJS、CoffeeScript、RedShift(その他Amazon系の各種サービスと連携)と盛りだくさん。
 
これだけのものが有るのに加えて、
山下さんが顧客先で作業を開始するに当たって
「山下さん、作業用のPC、Windowsがいいですか?、Macにしますか?」と聞かれて、
思わず馴染みのない(でも機会があれば使ってみたかった)「Macでお願いします!」と答えてしまったのだそうな。
 
さすがにMacには直ぐに慣れた(?!)と言ってました。
「基本的にはUnixだし、コマンドラインでサクサク使えるのは快適ですねー」って、うーん、そうですか。
 
既存のソースコードもあり、品質改善や不具合改修から入るという、有りがちなパターンの導入だったのですが、
「さすがに、これだけ未経験の要素が幾つも入り込むと、全然ソースが読めなくて困った」
とのこと。
 
...とか言いつつも、入場してから1.5か月。
「今回の不具合に関してですが、フレームワークの側にまで踏み込んで改修した方が今後の為にも良さそうなので、
手を入れても良いでしょうか?」
とサブリーダーに進言
 
問われたサブリーダーも判断に窮してリーダーに相談。
結局、3者で検討した結果、山下さんの提案通りに踏み込んだ改修をする方向になりました
 
20160513173030 所属しているチーム内では最も新しいメンバーであるはずなのですが、既にソースコードのレビュワーになったり
レビュー自体の習慣が無かったところに、「品質改善が課題にもなってますし、やりましょう!」と提案して、
チームとしてレビューを行うようになった
)、
 
色々とワケありで全体仕様を正確に把握している人がいない中にあって、既に仕様の問い合わせとか相談を受ける側に
回ってるとか
普通じゃないでしょ??
 
上記のリーダーさんからも、「山下さんって、ヤバイよ!、ヤバイ!」との反応(評価?)だそうです。
 
しかし、本人が言うには、
「だいたい何処に行っても、ソース位は読めるだろう。という自信があったのだが、今回はさすがにダメだった」
「やっぱり、主要キーワードの概念やポイントを押さえるだけでなく、ある程度手を動かしてキャッチアップしていかないと、追従ができない」と。
 
そりゃ普通そうだろう?!
...と思いますが、これまでのお客様評価を含め、社内開発も含めて、その成果を目にして来ている他のメンバー達から
見ると、「あー、山下さんでも、やっぱりそうなんだあ」となってしまいます。
 
上記した以外にも、技術要素は多く存在し、
システムの構成も「よくメモとか資料見ないで白板に描けるなあ...」と思うほど複雑。
このシステムのオリジナルをデザインしたアーキテクトは、相当の頭脳とやる気の塊だったのだろうと思わずにいられません。
 
とは言え、「採用されている技術要素群は、最新のトレンドと言うよりは、その1つ前」(by 山下さん)とのこと。
 
.....難しいですね。
 
20160513173137 AngularJSも、やっとバージョン2に上がろうとしているところ。
React.JSがメインストリームになろうかという勢いで、この辺は学習も、プロジェクトへの適用も、判断の難しいところ
なんじゃないでしょうか。
 
何れにしても、顧客先のプロジェクトに入っていく、俗に言うSESという形態ですが、
能動的に新しい/トレンドの技術を追っていかないと対応ができません
 
メタなスキルがあれば、実務経験のない技術要素を含む案件であっても参画のチャンスは掴めますし、活躍もできます
(少し会話をすれば、分かる相手には通じるようです)
 
逆に、経験の範囲に収まってメタスキルが育っていない人。
吸収力の弱い・遅い・無駄が多い人は、Web系で(特にフロント側は)生き残っていくのは難しいかも知れません。
 
フルスクラッチを選ばず、既存サービスのカスタマイズや拡張・組合せを主として行き、
顧客のビジネスや業務を知る・理解する・価値のあるシステムへと方向付けることを自らのミッションとすれば、
技術を追い続けるのは他の誰か(サービス提供者)に任せる、という選択肢もあるでしょう。
 
アスペアは基本的に技術志向が強いメンバーが多いです
 
ある程度は意図的にそうしてきた面もあるのですが、「技術だけ」ではダメ。
チームとして、プロダクトを、或いは顧客のビジネスの為のシステムを、価値の高いものにすること。
 
その為の必要要素の1つに「技術」が含まれているということですよね。
ちなみに、今回の話をしてくれた山下さんも、その辺はとても理解してくれている
 
だからこそ、チームが良い方向に変わっていけるように、お客様側の上長(結構上の階層だったり...)の方が相手であっても
忌憚なく様々な提案・相談をしてくれることが非常に多い
んですね。
 
有り難いことです。


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

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

gitbucketに移行した。

リポジトリ管理(成果物・版数管理)、と言うと、以前は Subversionが一般的だったかと思います。
それ以前はCVS、ずっと大昔(?)には、VSS(Microsoft Visual Source Safe)とか、SCCSRCSとか(ここまで来ると知らない世代が多そうですね)...。

現時点でのトレンドは、やっぱり Git/GiuHub でしょう

アスペアでも、社内的に利用しているクラウド環境上に持っていたリポジトリ管理環境は、つい最近までは Subvesionで構築していました。
環境を立ち上げたタイミングが数年前でしたから...

が、2016年・現在時点でのメンバー達のツール利用経験的には、Git/GiuHub経験者が殆ど。

社内的な可用性の点でも、ツール自体のメリット的にも Git の方が良いよね。
出来れば GitHub の方が良いかな?

でも、占有して使うには有料の Enterprise 契約しないといかんなあ...

じゃあ、GitHub close(少なくとも現在時点では)である、gitbucket を導入しちゃおう!
...という事になり、旧版のSubversion上のモノで、今後もメンテナンスを頻繁に行う予定のリポジトリは gitbucket に
移行しよう!
、ってことになりました。

各種調査&方針決め、環境構築は、アーキでもある山下さん
請負案件での開発(要求元との物理的な環境条件、セキュリティ的な要件などから、顧客先での開発が前提となった)が完了して、
次期案件が決まるまでの狭間の期間で、サクサクッと対応してくれました
中身の移行作業自体は、速形さんが実行してくれましたー)

かくして、社内的な保有リソースの管理も Git 相当のツールに統一した状態に移行しました。

ただ、今後の gitbucket の開発方向的に、「GitHub clone 路線から離れる」(GitHub管理側から、「Cloneとして開発を続けることは版権違反である」
旨で警告が有り、今後は gitbucket 独自での開発方向を目指す)...だそうで

この辺は、まあ様子見ですね。

要はメリット/デメリットを判断しつつ、柔軟に対応していければ良かろうと思います。
言い方を変えれば、柔軟な対応が出来なくなるほどの、組織の総合力としての学習・習得能力が下がるような事は避け続けて
行ければと思います。


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

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

«「ステキ!」大会・2015年度のメダリストは?