« 2016年12月 | トップページ | 2017年2月 »

2017年1月の記事

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

"書籍買い放題!" の運用をスタートしましたっ!
 
今までも業務的に、或いはトレンド技術やプロセス、マネージメント系、業務系など、必要な書籍が有れば
都度の申請(職制によっては自己裁量で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)

« 2016年12月 | トップページ | 2017年2月 »