システム開発の際、デザインとHTMLコーディングは別会社で!
受け取ったHTMLの組み込みはお願いします!
ということが結構あるのですが、その時もらったHTMLを見て、ここはやめてほしいという点をまとめて書いていこうと思います。

インデントがバラバラ

プログラム書くときもそうですが、インデントがバラバラだと見づらいです。
※弊社ではHTML/CSSともにインデントはスペース2つです。

タブ/スペースが混じっている

インデントが崩れているときは大体、タブ/スペースが混じってますね。見づらいです。
※弊社ではタブは使わないようにしています。

JSが意図した動作になっていない/動かない

JSまで対応となっているにもかかわらず、動かないというのは論外ですね。
「JSが意図した動作になっていない」これも結構ありました。
ex. 全選択/全解除というところをチェックすると、下にある項目が全部選択されるところが選択されていた箇所はチェックがはずれ、選択されていなかったところがチェックされるという謎挙動

Firefoxでは動かないというJSも埋め込まれたとこがありました。

↓これよくある
Ajaxでコンテンツを切り替える個所で、切替後にJSが動かなくなる。

スペースやbrタグで余白の調整をする

これは、HTML組み込み云々以前の話だと思うのですが、
スペースやbrタグが連続して書いてあると見づらいし、そもそも、CSSにmarginというものがあるので、そちらを使ってください。

個数が変動する可能性があるところを個数固定前提にしている

個数が変動するかどうかという判断は難しいのかもしれないですが、少しでも疑問に思ったのであれば、確認してほしいです。

td:nth-child(1){}
td:nth-child(2){}
td:nth-child(3){}

↑こういうのとか3個前提なんですが、4つになったり2つになったりすることあったりします。

実際に、個数が変わって、個数を増やしたり減らしたりしたらデザインが崩れたということがありました。

クリックして画面遷移するようなパーツがaタグで作られていない

仕様とかあまり気にされない感じなのでしょうか。
本来クリックして画面遷移するような箇所がaタグ以外のタグで書かれていることが結構あります。
onClickで無理やりやることもできますが、やはりよろしくないので、aタグでお願いします。

valueにPlaceholderの値が入っている

HTML5にplaceholder属性があるので、それで問題なければ、それを使ってくれればよいのですが、
何やら頑張ってくれたようで、valueにPlaceholderの値が入っています。
submitボタンを押したときにvalueの値を消してくれればまだいいのですが、
その処理が入っていなくてPlaceholderの値が送信されるということがしばしば。。。

formタグが入っていない

テキストボックスや送信ボタンをinputで作っているのにformタグがない。
formタグがないだけであれば、追加すればいいだけの話なのですが、
追加したらデザイン崩れるとかになるとさすがに困ります。

活性/非活性のコーディングができていない

特定の条件下でボタンが無効になる場合や有効になる場合でデザインが違っていたりするのですが、
大体どちらかができていないということが多いです。
たぶん、もらったPSDをそのままHTMLにしているので、表示されていない部分に関しては気がまわらない感じでしょうか。

特にページャの部分が多いです。
↓こんなの
前へ 1 2 3 4 5 … 次へ

1ページ目では、「前へ」は押せない状態で、2ページ目以降で押せるようなデザインにするところがそのデザインがないとか。

活性/非活性のON/OFFについてはclass付で切り替えられるようになっていると大変便利です
↓こんな感じ

<span class="prev">無効</span>
<span class="prev on">有効</span>

見た目よければ良しという考え

嫌な書きかたしましたが、要するに
「コードの中身や仕様も気にしてください」
ということです。
デザイナーがHTMLコーディングを担当することが多いのか見た目はできてるってのが多い印象です。

おわりに

私もHTMLコーディングをするのですが、PSDだけ渡されて後はよろしくお願いします。
みたいな頼まれ方をされることも少なくはありません。
そういうこともあるので、HTMLコーダーさんが悪いということではないのですが、
やはり、仕様の把握漏れや文化の違い等でやりづらいと感じることはあります。
一度、開発始める前にちゃんとこの辺りが話し合えればもう少しうまくいくのかなとか思いつつ、いろいろ模索しています。

現在、弊社では、上記のようにHTML作成者とHTML組み込む側が困らないように新人の研修を行っています。

どうも、Genkiです。

4月1日に2015年度の新入社員が入社してくれました。
今日は、先週の金曜日に行った入社式の様子と、新入社員二人の紹介を簡単に記事にします。

入社式の様子

入社式、とは言っても、どこかのホールや会議室を借りてみたり、全員スーツ着用にしておごそかな雰囲気で実施したりはしてません。
BPSは知っての通り開発会社で服装も自由なスタイルなので、入社式もかなりフランクに行われました。

お寿司やケバブのデリバリーに、社長セレクトのドリンク群、これらで入社式に色を添えます。

もうすでに2週間弱は共に働いてくれている仲間なので、実際働いてみた感想や今後の抱負などを語ってもらいました。
その後、社長から歓迎の言葉と、新入社員が読んでおくべき本の紹介がありました。

仲間入りの証、イラストをプレゼント

その後、会社の仲間入り、ということで社員用のイラストをプレゼントしました。

これは、既存メンバのイラストです。
ご存知の方も多いかもしれませんが、BPSのメンバは全員このイラストが割り当てられています。
新メンバの2人のイラストは後述します。

実は、そのイラストを入れたマグカップを準備してプレゼントする予定だったのですが、スケジュールがタイトだったのもあって、式までに到着が出来ませんでした。
結果的には翌営業日に届いたのですが、スケジュール管理はしっかりしなきゃなーと反省しています。
そもそも当日到着っていう計画が危険ですよね。笑

美味しい食事と食事で盛り上がる

12～3月はBPSはかなり忙しく、こうやって皆で食事をする機会がほとんどありませんでした。
アプリとWebのメンバが交わるいい機会になったのではないかと思います。

普段は19時頃スタートだと20時半くらいには撤収の雰囲気が漂う社内ケータリングですが、今回は新メンバの加入でテンション上がっちゃったのか、お酒やつまみを買い足しをしつつ23時過ぎまで盛り上がっちゃいました。
翌日が土曜日だったのが幸いですね。

2015年度採用を振り返って

2015年度の新卒採用は、説明会の開催や学生の受け入れなど諸々の部分を任せてくれました。
前職が人材業界だったのもあり、そのノウハウを活かしつつ運も味方して、結果的に2人の入社にたどり着けました。

全部で30名以上の学生に出会ったと思います。
その中で、インターン選考にも参加してくれたり、入社したい！とアツい思いを伝えてくれる人もいました。

エントリーしてくれて、説明会にも来てくれて、すごくうれしかったですし、可能なら全員に内定を出して、みんなと一緒に働きたかったです。
今はまだ20名そこそこの会社なので、その企業体力もないのが悔やまれますが、いつかそれができるように、
どんどん会社の受け入れ態勢を寛大にしていきます。頑張ります。
じゃ、次からは早速新入社員を簡単に紹介します。
本人たちからの自己紹介記事もあるかと思うので、僕からは簡単に・・・

Webエンジニア加藤さん

キミスカというスカウト型の媒体でBPSに来てくれました。

イラストはこちら。

BPS待望の女性エンジニアです。

和服が似合いそうなのと、大学時代はラジオ番組をやっていたとかでそこら辺をデザインに利用しています。

見た目は大人しそうですが、負けん気が強そうなので粘り強く開発してくれそうです。

現在は、お客さまのLPをひたすらにコーディングしてもらってます。
冗談抜きで200枚くらいはやってもらう予定です。

アプリエンジニア川島くん

パッションナビという媒体から来てくれました。
パッションナビという名前からエンジニアの採用は難しいかと思いましたが、
「開発」という部分に対して情熱的な学生が来てくれました。

イラストはこちら。

ボーカロイドが好きなのでそのカラーリングと、入社直前まで長髪だったのでその戒め（僕も大学時代は超ロンゲでした）と、群馬出身だというので材木（勝手なイメージです）をデザインに利用しました。

開発はかなり好きみたいで、学生の頃からサービスを運営してたみたいです。

現在は、リリース直前のアプリのテストを社内メンバやアルバイトを巻き込んで進めてもらっています。

遅れて到着したマグカップ

後日、こんな感じでプリントされたものが到着しました。

新社会人なので、名刺入れとかも考えたのですが、エンジニアという職種ってあまり名刺入れを多用しないかなーってことで、普段から使うマグカップにしました。

一緒に働いてるメンバだと、何が好きかとかどういう特徴があるかとかなんとなく分かりますが、新入社員は情報源が少なく、得意のFacebookストーキングで情報集めて↑のデザインに仕上げました。

そういえば、今回のデザイナさん紹介できますので、似たようなイラスト欲しいなーて方いれば声かけてください。
写真と好きなものを羅列したものを渡せばよしなにデザインしてくれるので非常に助かりました。
本人たち想像以上に喜んでいるみたいなので良かったです。
BPSに入社した方にはもれなくプレゼント（イラストもマグカップも）するような文化もアリだなーって思いました。

2016年度の採用について

2016年度も新卒で2名ほど採れればいいな、と思っています。
新卒だけじゃなく中途の方も大募集です。

とにかく開発が好き、という方は是非一度ご連絡ください。（宣伝）

読んで頂きありがとうございました。

西新宿を拠点とするシステム開発会社の雑用係長、渡辺です。外で営業チックなことをしている時間と社内で開発ディレクションしている時間が丁度半々くらいです。上記の画像は本物です。青が請求、緑が入金、橙が支出です。具体的な数字がなくて恐縮なのですが、上半期に比べて下半期の収­­­益は例年約2倍です。上半期はところどころ売上を支出が超えてドキドキです。とても光栄なことに年末に近づくにつれ取引先各社が次年度への投資するために弊社にもお声がけくださいます。そのため3月が数字として突出していて、年度末投資の延長で＋α依頼されることがあると4月に持ち越されます。期の初めに売上がたっているのはこれですね。

受託開発と、商材開発の共通するところ

収益には周期があります

参考までに弊社の事業を紹介させていただくと、Ruby on Rails によるWEBシステムの受託開発と、電子書籍関連商材の開発と販売があります。商材があるとはいえ、流行とは裏腹にありのままで受け入れられることは少なく、導入の際にカスタマイズと既存システムとのつなぎ込みが必要です。つまり、どちらの事業も受託開発があり、収益には周期あり、やはり年度末にはスタッフへの負荷と会社の収益が増加します。WEBシステムの受託開発だと平均して1~3ヶ月、電子書籍商材の販売だと3~6ヶ月の周期といったところでしょうか。投資がでかい分、リターンが大きいこともあるのは事実です。

導入後もちゃんと仕事がある

僕にもソフトを開発していた時期があり、ソフトを1度作ったら後はばらまいて放置してチャリンチャリンさせたい！と思っていた時期がありました。たしかに製品開発は投資が長い分、成功した時のリターンも大きい。でもうまく導入が完了しても、当然お客様が使い続けてくださるうちには保守対応があります。当然クレームもまれにあります。製品に求められる機能やUIが時代の流れとともにかわります。投資は永遠です。これは受託開発したシステムの保守と同じですね。何も問題がない状態を維持し続けるためにはコストと労力を要します。

特色があれば引き合いもたえず収益も安定する

受託開発は比較的短い周期で、実力さえあれば一定の収益も確保でき、幸い仕事の引き合いも採用応募者も絶えません。Railsというキーワードで実績を押し出しているのでそれに関連したお仕事をいただけます。これは受託開発だけかなと当初思っていましたが、製品開発もあまりかわらないように感じます。高い表現力や自由な販売モデル、圧倒的なコスト差などがあれば、お話は絶えません。まあClosedな業界なため、プッシュ営業の難易度と頻度は受託開発のそれよりも高いように感じます。

受託開発と比較して、製品開発が異なるところ

そんなWEB受託開発事業と比較して、電子書籍の商材開発事業はどこが違うのか？まだまだどちらもの事業も会社自体も未熟で成長過程ですが現時点までの気付きをまとめます。僕自身のなかの整理のためと、今後いろんな方からアドバイスいただけければと願い、書いています。よろしくお願いいたします。

先行投資期間が長い

まず、必要なものが揃ってないし、必要なものを理解していない。のりこむ業界ともちいる技術の業務知識と先見性の両方が客観的に業界最高峰レベルであり、かつ目的達成のために計画段階から必要なあらゆるリソース（適切な開発人員、市場へのリーチ、システム以外の要件をみたすところとのパートナーシップ）が揃っていて、収益がでるまで耐えられる経営基盤事前にあれば別ですが、弊社はいずれも不足していたため、初月から単月黒字を記録した受託開発とは異なり、黒字化まで2年かかっています。

人は集まりやすい

SIerとして業界や業務を絞っていくのと、事業目的に合わせて業界や業務を絞っていくのと、実はさほど違いがあるとは思えません。その仕事を好きになるかと続けられるかどうかは、会社の文化がまず自分の肌にあうかというのもありますが、その後は自分の役割、成長している分野、役割に対する対価や成長曲線のほうに意識がシフトするように見えます。でも、応募や転職のきっかけになるのは、事業目的が自分にあうかどうかを重視されている方が多いと感じます。当然といえば当然ですね。事業目的があると、人が集まってくれます。

始まりと終わりをつくるのが難しい

製品開発が事業としてうまく軌道に乗っていればのっているほど、製品開発に終わりがないです。導入先が増えてくると、時間とともに変化するニーズに加え、使ってくれているユーザの属性自体も増えていくため、どんどんやることが無限に溜まっていきます。受託開発のように、お客様都合で始まりと終わりが綺麗に区切れないため、期限はデッドラインではなく目標ラインなため、なんとなく目的意識が合わせづらいように感じます。導入後も100%面倒見続けることを考慮すると、導入が完了しても完全に稼働があくわけではないので、上手く行けば行くほど慢性的に仕事が溢れかえっている状態になります。

以上、ここまで私の拙い文章や弊社の事業について見てくださり本当にありがとうございます。興味をもってくださったかたはぜひご連絡ください。また、ここから先の文章はもう本当に自分のためのログです。記事タイトルをみて訪れてくださった方々にとってあまり興味を引かない内容かもしれませんので、ここで一旦区切らせていただきます。

それらを踏まえて弊社が来年度から意識してやっていくこと

まだまだ貧乏暇なしな日々が続いておりますが事業のあり方が見えてきたところで来年度から意識してやってこうと思うことを洗い出してみました。

キャッシュフロー

収益の平均的な周期がいままでより大きくなり、また事業拡大のための外注費がとても多くなっています。集金は導入完了後1-2ヶ月後に対して、発注は着手時付近になるため、内部留保でやりくりしていて外部資本をうける予定がない以上、数ヶ月先まで何にいくら投資できるのかを把握することの重要性が増してきました。何となく数十万単位ではいつも頭にあったのですが、すべて1円単位で把握できる仕組みを用意しておかないといけないですね。同時に、支払いサイトはある程度統一していかないと、ですね。発注と集金の間に6ヶ月あくことが多く、さすがに辛い。

単発の収支

取引先も社内人員もそのチームも増え、外注先との提携のための権限も委譲し始めていることを考えると、問題点の多くが細部に集まりだすので、全体の数字だけみて大きな課題を潰していくのは効果が薄くなってきています。案件ごとの予想と実績値の比較と、製品別・顧客別・案件別の収支があれば、客観的な指標をもって意見だしができるようになるので、まずはそれを用意します。問題が浮き彫りになれば自主的な動きが加速するし改善するはず。

横の繋がり強化

去年度半ば頃は、例年6月～11月は仕事がないため、この期間の収益性をどう確保しようか悩んでいました。ただ現状は全く新規の仕事のヒアリングを受けられない状態になっていることを考えると、開発会社同士の横のつながりを、現場レベルで強めていくことが大事になってきます。個人的に前から繋がりがあったり、たまたま会社同士の信頼関係が芽生えたところしか頼れるところがないと、第一線で価値を生産してくれているメンバの脚を引っ張るし、そもそもいろんな機会損失が起きてしまっているように感じます。接点作っていきます。

ブランディング

横のつながりを強化していくためにはどうしても仕事や勉強会といった共通の目的がないといけませんね。ただ闇雲に仕事を増やすために営業力を強化したり、仕事する時間を勉強会開催のために使って勉強会を開いていくのは非効率ですし旨味が少ない。僕らが求める知見を蓄積できるプロジェクトや仕事へのお声がけを増やすのが良いですね。そのために、そろそろ会社としてのブランディングをより一層力をいれてしていかなければですね。

ドーモ、shibusoです。原作読まずにアニメ見たら何を見ているのかよく分からないことになりました、忍殺。

前置き

たまにHTMLのテーブルでヘッダーを固定して欲しいという要望が出ます。ExcelとかGoogleスプレッドシートとかでテーブルのヘッダーを固定出来るのだから、きっとそんなのすぐに出来るだろうという考えなのでしょう。

しかしフロントエンドエンジニアからしたら「うわ、出た」という感じではないでしょうか。最近ではJSのライブラリがあったりして無理難題というレベルではなくなりましたが、それでも基本的にはあまりやりたくないところ。しかも行の固定はあっても列の固定は無かったりするものが多いです。

今回私が担当した案件では行と列の固定に加えて、範囲選択を出来るようにして欲しい、という注文がきました。行と列の固定はそれでも探せばいくつかライブラリが見つかりましたが、範囲選択というところがネックでした。加えて対応ブラウザはIE8以上。そんな中出会ったのがFixedMidashiです。日本人しか分からなそうなお名前です。

FixedMidashiのメリット

FixedMidashiが他のヘッダー固定ライブラリと一番違うと感じたのは、表示範囲に応じて見出しの出し分けをしている点です。見出しが見える範囲にある場合は通常のテーブルを表示し、範囲が見えない場所までスクロールすると予め作成された見出しだけを切り出したテーブルを表示するようにしています。

この実装のおかげでスクロールしていない状態では通常のテーブルと変わりなく範囲選択することが可能となりました（通常のテーブルを表示しているのだから当たり前といえば当たり前ですが）。使用できる状況は限定されているとはいえ、要望を満たすことが出来たため大変助かりました。

その他にも色々属性を指定するでカスタマイズすることが可能です。今回私は固定する列を2つに指定したり、borderを指定したりして利用しました。

なお今回はdivモードを利用した場合のお話です。bodyモードは試していないためbodyモードをご利用の場合は少し勝手が違う可能性があります。またバージョン1.8から混合モードが追加された模様ですが、こちらもまだ試していません（スマホに適しているみたいです）。

FixedMidashiの使い方

基本的な使い方はFixedMidashiのホームページでご確認ください。この手のJSライブラリをVectorからダウンロードするというのが個人的には斬新でした（Vectorには90年代、2000年代前半に大変お世話になった記憶が）。

使い勝手については下の方にデモを置いていますが、FixedMidashiのホームページにも各モードでのデモページが用意されているのでそちらでもご覧いただけます。

一箇所このライブラリ自体をカスタマイズした方が良いと個人的に感じたのは、使用する時に指定する「_fixedhead属性」です。これをこのまま使用するとHTML5のvalidatorに怒られます。代わりにdata-fixedheadで指定できるようにカスタマイズすると怒られないで済みます。

単純に”_fixedhead”を見ているところを”data-fixedhead”に置換するだけで動きました。修正版の配布は禁止されているのでここには置けません、あしからず。

FixedMidashiのデモ

GitHub Pagesに簡単な紹介用のテーブルを作ってみました。

まとめ

FixedMidashiはシンプルにテーブルの見出しを固定させたい場合、非常に楽に導入できます。ここでは紹介しませんでしたが、他にも色々な関数が用意されていて、それらを用いればより便利に使用することが可能となります。特にsyncValueとsyncStyleはフォームを含んでいたり、途中で表示に変更が生じる場合にはありがたい機能です。

もし行と列を共に固定する必要が出た場合に利用してみてはいかがでしょうか。

いつも弊社サイトをご覧いただきありがとうございます。昨年度は例年を上回る利益を残すことができ、4月には新卒が2名参加してくれ、また5月にはもう１名中途の方が加わってくれるようになりました。まだまだではございますが、応援してくださる皆さまのご期待に添えるような進捗を少しずつだしていけるのではないかと思います。今回は7月1日～4日に東京ビッグサイトで開催される電子出版EXPOへの出展が決まりましたので、そのご報告です。

電子出版EXPOとは

東京国際ブックフェア実行委員会とリード エグジビション ジャパン株式会社が主催されている、電子出版ビジネスに関連した企業が集まる展示会です。僕らは3年前から毎年参加していますが出展されている企業はだいたい同じなのですこし同窓会のような雰囲気になりつつあります。同じ期間中に近くの別の会場で、コンテンツマーケティングEXPOや先端技術EXPOなども同時開催されているので、合わせてみてみるのもいいかもしれませんね。僕も当日はいろんな企業さんのブースや会場を回っているので、もし予定を組んでくださる方がいましたら事前にご連絡ください。

第19回電子出版EXPOの会期、会場、主催

だいたいのターゲットと出展者

去年までの様子

そこで何をしているか

主に業務システムや決済を要するECサイトなどのシステム開発力を評価して取引してくださっている企業様が多いかとは思いますが、弊社では電子書籍を配信するソリューションを自社内で開発し、3年ほど提供してきました。漫画をスマホやWin/Macで閲覧するための「超画像」や縦書き文字者に最適化された「超縦書」など、電子書籍配信のための製品ラインアップの詳細はこちらです。

毎年の成果や今後の方向性を同じ業界内の方にアピールするために参加します。今年はお披露目したい新機能や新規対応したプラットフォームのデモがあります。ついでに主力商材のマスコットキャラを創ってみました。以下ラフ案です。

ここからの成長に乞うご期待。

弊社への応募を検討してくれている学生さんや、弊社との取引を検討くださっているや企業様へ

もしよかったら他社の出展を見つつで構いませんので、弊社のブースにもお立ち寄りください。お待ちしています。

今年の一般新卒採用はアイ・パッション社のパッションナビを軸に展開します

4月に自慢の新卒さんたちが入社してくれてからまだ2ヶ月しかたってませんが、2016年度の新卒採用に向けて動き出す時が来ました。中途採用のほうが圧倒的に多い弊社ではありますが、それでも新卒の定着率とその後の安定した成長曲線はやはり魅力的です。去年はいろんな採用エージェンとやら採用メディアやらインターンメディアを利用させていただきましたが、今年の一般からの新卒採用はアイ・パッション社のパッションナビを主軸に展開していきます。中途ではもちろんエージェントさんの力添えはお願いしていきますし、新卒採用媒体も型が決まり始めてから順番に契約していくと思います。

動画が2個ついてくる

比較的安価な年額で動画2個までついてきます。動画もプランから外せば更に安くなるみたいですが絶対に作ったほうが良いと思います。再利用しまくれる。今年は去年の新卒採用からのメッセージと、夏に公開する予定の新商品動画作成を編集していただきます。去年は漫画までついてきましたが今年はオプションになったようですね。そのかわり集客力は増えたそうで期待しています。

こちらが会社案内と事業部長からの事業案内です。去年とった動画の1つです。

こちらが去年採用させていただいた方と、教育担当、採用担当からのメッセージです。

応募者が絶えない

もちろんリクナビのような大型採用メディアと比較すると少ないかもしれませんが、弊社のように20人規模の会社にとっては十分すぎる程度にはちゃんと応募者からの連絡が継続的にあります。来週の説明会予約は既に10名を超えています。20名くらいまで増えて、ドタキャンとかもでてきて、15名くらいに落ち着く気がします。説明会当日が雨だと10人に戻るかな。まあそれでも6名を超えたら恥ずかしながら会議室に入りきらないので社内勉強会の広いスペースで今年は説明会を開催します。

正直な気持ちを伝えてくれる応募者が多い

新卒なので能力には当然ばらつきがあります。でも、他の採用メディアからはなんとなく開発力を伸ばしたくて企業のインターンをして転々と回っている方や開発したことがないけれど身につけたいって方も一定割合いるなかで、パッションナビ経由の学生さんは目的が割とハッキリしている方が多かった記憶があります。ベンチャー志望だからかな。まあ正直すぎる方も目標があれ？と感じる方もいましたが、考えていることは伝わります。というわけで弊社にマッチしているかどうかがわかります。だから弊社から提供できるメリットも明確に伝えられます。会社側に育てる意欲があれば相性は良いはず。過去2年でお会いしたどの担当者さんもとてもいい感じでした。ただまあ今後ハズレもでてくる可能性もなきにしもあらずなのでもし慎重になりたいようでしたら良かった方をご紹介しますので遠慮なくご連絡ください。僕の連絡先を知っている方はLINEでもメールでもFacebookでもTwitter経由でも。その他記事コメントやShareとかでコメントいれておいてくれたら反応するようにします。：D

他社のステマみたいになってきたので自社のことに話しを戻すと、これらの動画をみて弊社に興味を持ってくださった方はぜひ弊社採用ページからもご応募ください。事業として行っていることは以前こちらにまとめましたのでご興味を持ってくださった方はこちらも合わせてどうぞご覧ください。もちろん中途の方も歓迎です。心よりお待ちしています。

ども、BPSの採用担当Genkiです。

前回、2015年度入社の2人について触れましたが、世間ではもうすでに2016年度の新卒採用は渦中ですね。
僕らも、2016年度の新卒採用について今月から動き始めました。

採用手法や、告知などをまとめましたので企業の採用担当の皆さまには是非見て頂けると嬉しいです。
学生の皆さまは、・合同説明会を開催する企業さまの紹介　まですっ飛んでいただければと思います。

目次
・2015年度新卒採用の反省点

・2016年度新卒採用の目標や手法

・合同説明会のメリット

・合同説明会を開催する企業さまの紹介

・第一回合同説明会の告知

・ご予約や各種連絡先など

2015年度新卒採用の反省点

前に書いたメディア比較の記事を読んで頂いても分かる通り、2015年度の採用では新卒中途問わず様々なメディアを利用してみました。
と、いうのも、前職では売る側だったので各メディアの特徴はつかんでいるつもりだったのですが、実際採用担当になった時の使い勝手というものを把握しておきたかったからです。
テレアポやメールなどで営業していただいた企業さまの話は、ほぼお伺いし、その中で吟味しました。

インターンのメディアも含めると、エンジニアインターン・インターンシップガイド・Wantedly・PASSIONナビ・朝日学情ナビ・キミスカ・OfferBoxなどなど・・・
そういえばリクルートキャリアさん経由でもご紹介頂きましたね。

色んなメディアを使ってみた率直な感想は、「複数のメディア利用は大変！」でした。
どのメディアに掲載したとしても欲しい人材のターゲット像は変わらないので、基本的に原稿の方向性は同じになります。
しかし、各メディアによって項目の種類や、各項目の文字数制限、掲載用の画像サイズフォーマットなどバラつきがあるので、1つベースの掲載原稿があったとしても多展開は結構大変です。
そして機能も様々なので、予約機能を使ったり、社内でスクリプト書いてもらって上手に処理したとしても、
毎日各メディアにログインし、応募者対応や情報更新をしているとそれだけで1日が終わってしまうことも珍しくありませんでした。

つまり、ターゲットの親和性、信頼できるメディアか否か、機能やサポートの充実度、価格などを考慮した上で、出来れば1つ、多くても2つのメディアを使って採用をしていくのがいいのではと思います。
採用に時間を割くことが勿体ない事だとは微塵も思いませんが、それでも圧縮できる時間は圧縮すべきです。
ちなみに、これはあくまで採用担当の人数が少ないベンチャー・中小企業によく言えることで、採用事業部として何人も採用に携わっているメンバーがいる会社では、各担当にメディアを割り振って複数メディア展開はアリだと思います。
BPSも早くそんな体制になるといいなーと思いながら、エンジニアの採用がやっぱり最優先でまだまだ先の話になりそうです。

2016年度新卒採用の目標や手法

2015年度の新卒採用では2名の未来のエンジニアと出会うことが出来ました。
2016年度新卒採用では、採用目標を“5名”にしています。

これは、2015年度の2名が思ったよりも成長のスピードが速いのと、会社としてもそろそろ仕掛けていきたい時期だからです。
「去年よりもいい子が欲しいな」と、新卒採用は年々ハードルが上がるのが常ですが、BPSでは2015卒の2名と同等であれば十分内定出しは出来ると思います。もちろん、個人の考え方や会社との相性もありますが。

2016年度新卒採用ではメディアにPASSIONナビを選定しました。

やはり、比較的安価な掲載料金の中で動画制作が出来るのが大きいのと、昨年このメディアからの採用実績があるからです。
PASSIONナビについては渡辺の記事でも触れています。

説明会を開催して、ESを記入してもらって、技術力を見てみて、技術を好きか否かを見てみて・・・という採用の基本フローは昨年と変わりません。
そして、今年は初めての試みとして、他の会社さまとの合同説明会を実施しようと思っています。

合同説明会のメリット

ご存知の方も多いかと思いますが、合同説明会とは複数の企業が集まって会社説明会を開催することを意味します。
合同説明会には、企業側にも学生側にもメリットがあります。

企業側のメリット

・自社の原稿やメディアではリーチ出来ない層の学生に出会える。
・一度に多くの学生に出会うことができる。
・他社の自社紹介を聞くことで、自社の差別化のポイントを把握できる。
・企業同士でフィードバックを行い、お互いの採用力を高めることができる。

学生側のメリット

・一度に複数の企業の説明を聞くことができる。
・普段の自分のサーチではヒットしない会社に出会いきっかけになる。
・同じ業種、募集職種の会社でも全然違うのだという事を知り、企業研究に深みが増す。

ざっとこんな感じでしょうか。
また、デメリット、というか合同説明会開催にあたっていくつか気を付けておくべき点もあります。

■募集職種が同じであること
営業なら営業、エンジニアならエンジニアと募集職種が同じ企業同士で開催する方が良いです。
大学1～2年次の職種が決まっていない時期であれば、色々な職種で集まって選択肢を増やすのは有効です。
しかし、この時期にエンジニアになるか営業になるか迷っている学生は少ないと思われます。
自分の希望職種と異なる企業の説明は、おそらく耳に入ってこないので双方にとって時間の無駄になります。

■参加企業数が多くなり過ぎないこと
企業側のメリットは社数が多くなればなるほど倍増していくように見えますが、これは間違いです。
多くなり過ぎる＝自社のアピールできる時間が少なくなってしまうので、学生に魅力を伝えるのが難しくなります。
せっかく参加したのに、名前すら憶えてもらえないケースだって往々にしてあるわけです。個人的には合同説明会は2～4社が適切だと思います。

■採用ターゲットが被っていないこと
同じ開発会社と言えども、欲しい人材は異なるはずなので、あまり意識するべき項目ではないかもしれません。
これはどっちかと言うと、各社欲しい人材像を明確にしておく、という感じですね。
単に「開発経験があって、優秀な学生！」とかではなくて、具体的な開発経験や、将来なりたい方向性、今の会社に足りないポジションなどと相談して予め決めておくべきです。
ターゲットが曖昧だと、説明会でも欲しい人物像が明確に伝えられず、学生の印象に残らないことも多いです。

ちなみに、万が一採用ターゲットが被ってしまった場合に、お互いの悪口を言って辞退を促すような会社とは合同説明会を開催しない方がいいですね。
その点では、「■信頼できる会社と開催すること」も項目に入れておいてもいいかもしれませんね。

このブログを読んでくださっている企業の採用担当の方で、一緒に合同説明会を開催したい企業さまは是非、ご連絡ください。

合同説明会を開催する企業さまの紹介

さて、BPS設立以来初の合同説明会を共に開催する企業「株式会社enFactory」さまの紹介を簡単にさせて頂きます。
BPSの会社紹介は、自社ホームページか、PASSIONナビの採用情報をご覧ください。

株式会社enFactoryは、「専業禁止!!」というユニークな人材理念を掲げる企業で、
ローカルプレナーと呼ばれる、専門家やフリーランス、つくり手、パラレルワーカーといった人々に、ユーザへのブランディングや露出、マッチングやECなどの様々なマーケティングサービスを中心に展開しています。

社内メンバの半数以上が副業を行っており、会社としてもそれを推奨しているという珍しい企業です。
1つの会社に属し、その会社に捧げることも勿論大切です。
しかし、そうではなくてもっと自分を軸に考え、「生きる力」を身に付けられる、それらを推奨している会社があってもいいのでは、という思いからこの理念を掲げているようです。
会社を辞めて起業する人、学生のうちから起業する人も目に見えて増えてきていますが、社会人になって会社に属しながらも起業をする選択肢を与えてくれる素敵な会社です。

今年初めて新卒採用を実施する、ということで（新卒採用においては）1年先輩であるBPSと一緒に合同説明会を開催します。
enFactoryさまも、BPSも募集職種はエンジニアです。今回はこの2社で開催する予定です。

第一回合同説明会の告知

さて、ここからは具体的な説明会の告知になります。

タイトル

せっかくなのでタイトルつけてみました。
【未来のエンジニア集まれ！】あなたの目指す開発スタイルはどっち！？enFactory×BPS、初の2社合同説明会【限定20名】

日程

6月29日（月）14時～16時
（受付は15分前から開始します）
※6月に1回、7月に1回実施する予定です。7月の日程はまた告知します。まずは上記の日程をご確認ください。

場所

東京都渋谷区代官山町20-23 TENOHA代官山施設内キッチンスペース

アクセス

東急東横線「代官山駅」より徒歩3分、各線「恵比寿駅」より徒歩12分、渋谷からタクシーで1メーターほど

持ち物

筆記用具

服装

雰囲気の良い場所ですので、是非スーツではなく私服でお越しください。

参加資格

2016年3月卒業予定の学生の方
今回は主に2016年度新卒向けですが、既卒の方や1～3年生でインターンを希望する学生の方も予約可能です。

席数

最大20名
定員になり次第予約を締め切らせていただきます。その際は7月開催分の案内をお送りします。

予約方法

こちらをご確認ください。

説明会概要

※変更があるかもしれませんが、大まかにはこのような流れを予定しています。

・挨拶と今日の流れ

・会社説明

・各社長の話（企業ストーリーや今後の話など）

・社長対談（学生さんからのツッコみも交えつつやるつもりです）

・質疑応答

・今後の選考の説明

・ES記入

・（選考希望者のみ）各社社長・社員との座談会（ドリンク＆軽食付き！）

※長くても2時間程度を予定しています。

ご予約や各種連絡先など

説明会へのご予約はPASSIONナビ経由またはBPSのフォームよりお願いします。
BPS宛に直接ご連絡頂いても構いません。

PASSIONナビのアカウントを持っている方、または登録予定の方

PASSIONナビでの予約はこちらからお願いします。
ちなみに、enFactoryさまもBPSも個別説明会随時開催中です。

enFactoryさまへのエントリーはこちらから
BPSへのエントリーはこちらから

フォームまたは直接メールを送っていただける方

フォームよりご予約の方はこちらから
直接ご連絡頂ける方は　recruit@bpsinc.jp　宛にお願いします。

その際、大学名・学科名・名前（フリガナ）・学年の記載をお願いします。

何か不明点などあれば、03-6279-4320　BPS株式会社：担当大場までご連絡ください。

皆さまのご予約心よりお待ちしております！

今回は告知中心の記事になりましたが、読んで頂きありがとうございました。
また説明会の様子などはアップしたいと思います。

どもGenkiです。

エンジニア対談、ということでこれから定期的に[BPSの誰か]×[他の会社のどなたか]の記事を投稿していきます。（いつまで続けられるか分かりませんが・・・）

対談記事って読みやすいですよね、僕も好きです。
なるべく多くの方に読んでもらえるような人気シリーズにしていきたいので、長い目で見守ってくれると嬉しいです。

もちろん、勉強会の開催や対談をしていただけるエンジニアの方も募集中です！
記事へのコメントや、お問合せからお願いします。

さて、第一回目の今回は比較的誰でも読みやすい内容になっています。株式会社エンファクトリーさまと開催した就活生向けの合同セミナーでの対談です。

就活生の皆さんはもちろん、これからエンジニアにキャリアチェンジをしようとしている方必見です！それではどうぞ。

①自己紹介＆経歴

澤田(以下S)：株式会社エンファクトリーでクリエイティブユニットという部署の統括責任者をしていて、主にWebサービスのプログラム開発の仕事をしています。ゲームが死ぬほど好きで、大学時代には当時流行っていたバーチャファイター2という格闘ゲームの筐体を買ってしまったほどです(笑)。

就職もゲーム好きが高じてSCEに入社しましたが、プログラミングに携わる時間が少なくスキルアップをもっとしたかったので、セキュリティ業界に転職しました。プログラムからデザイン、営業まであらゆることを経験しました。その後独立してWebサービスを提供する会社を設立しましたが、自分でやってみて初めて経営の大変さが分かりましたね。エンファクトリーの前身である、オールアバウトで代表の加藤と出会い、今のポジションに至ります。今日はよろしくお願いします。

森(以下M)：BPSの森です。BPSは電子書籍事業をメインに、ホームページ制作などのWeb開発事業もしており、僕はその中のWeb開発事業を統括しています。コンピューターとの出会いは澤田さんと同じくやっぱりゲームからで、本格的に触るようになったのは高校生になってからですね。プログラミングを仕事にするようになったのは大学に入ってからです。同じ高校の卒業生がやっていた会社で、化粧品会社のECサイトのコードを書いていました。そのまま大学院に進学し、フリーランスとして仕事をしていた時にBPSからお仕事を頂くようになって、そのままズルズルと今に至る感じです(笑)。こちらこそどうぞよろしくお願いします。

②今からエンジニアになりたい人が身につけておくべきスキルって何だと思いますか？

S：最近では立場上、あまり自分でコードを書くことは少なくなりましたが、昔はC++や現在はJavaScriptなどのフロント系技術言語を得意としています。ただ、最初からこれらの言語に興味があったというわけではなくて、「こんなゲーム、サービスを作ってみたいな」という思いがあって、それらの言語がたまたま必要だったというだけのことです。よくWebニュースなどで「この言語を身につけておくと楽！」という情報がありますが、僕は、それよりも何を作りたいかをまずしっかりと決めて、それに沿ってスキルを伸ばしていくのが良いと思います。やはり興味を持てないと伸びしろって限界がありますからね。

M：じゃ、僕はちょっと斜めっぽいアドバイスを。実は、プログラミングを書き始めた頃、エンジニアってとっても儲かったんですよ（笑）。当時は大学生で、「興味あることでこんなにお金貰えるんだ！」ってビックリしたのをよく覚えています。好きなこと、興味あることでお金を貰えるなんて世の中に一握りしかいない、と思ってましたからね。それからプログラミングにどっぷりとハマってしまい、ありとあらゆる言語、仕様を勉強していきましたね。私の場合たまたま人より早い段階でお金を得られていたので、のめり込むきっかけはお金でしたが（笑）、学ぶきっかけは澤田さんの言っているようにゲームを作りたいとか楽をしたいとか、何でも良いと思います。ただ、「作った物がお金に変わる」という感覚を得られるとより良いと思います。やっぱりエンジニアって知識を身につけるだけではダメだと思うんです。修得した知識を基に実際に作ってみて、周りの人に利用してもらってこそ「開発」の仕事だと思います。書いたコードの価値は、同じエンジニアにしか分からないことが多いですが、実際サービスやアプリになって価値を生み出す感覚、それを味わい続けるのが良い物を作れるようになる一番の近道だと思いますね。

③良い開発会社の見分け方って何かありますか？

M：SES（システムエンジニアリングサービス）は知っておいた方が良いかもしれませんね。エンジニアを他社へ出向させる、要は「エンジニアの派遣」みたいなものです。エンジニアは不足していて、採用コストを減らすため、忙しい時だけ他社のエンジニアを借りて回している企業もたくさんあります。SESがダメ！とは言い切りませんが、大体しっかりした開発会社であれば自社でいいエンジニアがいますし、逆に自社にエンジニアがいない会社はエンジニアを育てて伸ばす土壌がしっかりしていないと言えます。エンジニアとして深く学びたい、スキルを伸ばしたいと考えているのであればそういった企業を見極めることも大切なのではないでしょうか。

S：そうですね。ありがちなのが面接時にスキルレベルだけを聞いてくるような所はあまりお勧めしません。面接でどこまで熱い会話ができるかみたいなところがあって、やっぱり仕事って人と人が行うものですし、良い仲間と作ればより良い物が出来上がりますからね。SESの話が出ましたけど、使い捨てのエンジニアで終わることのないように就職先は慎重に選んだ方が良いと思います。人間性まで含めて見てくれているのかどうかってやっぱり大事だと思いますよ。

④エンジニアやってて辛い時ってどんな時ですか？

S：納期を死守しなければいけない一方で、他の仕事も同時に進めなければいけない点でしょうか。開発の際、細かい点を気にするとどうしても時間がかかります。それでも新しい仕事や、他の業務も進めなければいけない・・・となると時間が足りなくなってしまうことも多々あります。ただ、エンジニアは技術職ですから、ある程度細かくこだわることも必要だと思うんです。当然そこから自身のスキルアップにも繋がっていくわけですしね。大事なのはそれらの時間配分とバランスの取り方でしょうか。

M：仰るとおりです。弊社のようなあまり規模の大きくない会社ほど、エンジニアといえども開発だけやっていれば良いというものではないんですよね。同じ仕事を100人で回すのと20人で回すのでは当然ですが一人ひとりの負担の大きさは全く違います。中小、ベンチャー企業ほど一人でカバーしなければいけない守備範囲が広がっていくものなのです。100パーセント開発だけをしたいという人は大企業かSESとして働く方をお勧めしますね。中小、ベンチャー企業は守備範囲が広がる分大変だと思いますが、やりがいは確実に増すと思います。自身もそうなんですけど、エンジニアという肩書きではありますが、営業もしますし、時には大学で教壇に立って学生相手に話すこともしています。僕はそんな状況が楽しいですし、やりがいも感じていますので、これからも必要であれば色んなことに挑戦していきたいですね。

⑤本日はありがとうございました。

S：あまり対談とかしたことなかったので緊張しましたね、次はもっと開発の中身について対談したいですね、ありがとうございました。

M：新卒で入社した会社は良くも悪くも自分の社会人生活の基盤になります。しっかり悩んで後悔しない就活をしてくださいね。ありがとうございました。

終わりに

いかがでしたでしょうか？これからエンジニアを目指す方にとって何かしらのヒントになれば嬉しいです。
ちなみに対談の後は、みんなで軽食を堪能しました。僕も学生の時にこんな説明会行きたかったなぁ～！

今回は学生さんからの質問を元に対談形式での記事になりましたが、こんなテーマで対談してほしい、対談したい、などあればお気軽にご連絡ください。
読んで頂きありがとうございました。

皆さまこんにちは。先日お知らせさせていただいたように国際電子出版EXPOに今年も参加して参りました。

Vivliostyle（ビブリオスタイル）社と一緒に出展させていただきました。

Vivliostyleとは

Vivliostyle社はワンソース・マルチユースで電子書籍もWebも紙の本の出版をWebブラウザベースの自動組版システムで実現しようとしている企業です。そして僕らはEPUBベースの漫画や雑誌向けの軽量高速ビューアを提供している企業です。今回はご縁があって光栄にもご一緒させていただくことができました。

BPS x Vivliostyle ポスター

MediaDo（メディアドゥ）社ブース内で専門書領域への挑戦について講演させていただきました。

講演内容も文字でご覧になりたい方はこちらになります。

始めまして。ビヨンド・パースペクティブ・ソリューションズ株式会社（以下BPS）の榊原と申します。最初に我々がどのようなことをやっている会社なのかと私榊原の簡単な自己紹介を交えましてお話させていただきたいと思います。

我々BPSは2007年に設立しまして、当初はECサイトやコーポレートサイトの開発事業をしておりました。電子書籍事業に携わるようになったのは5年程前からで、主に読むためのソフト、ビューアソリューションの提供をしております。その他にも珍しい事業で言えば大学などの各教育関係各所との提携、サポートなどを行う研究開発事業も行っています。

私榊原ですが、弊社が電子書籍事業に参入し始めた2010年まで大学でネットワーク関係の研究を行っておりました。その後BPSとご縁があり、働き始めるようになってからも助成金の獲得を始め、大学での非常勤講師も行うなど、今でもIT分野の研究を続けております。

さて、いよいよ本日の議題である、「専門書系配信ソリューションに必要な技術とビジネスの可能性」について話を進めていきたいと思います。まず電子書籍の市場規模については現在約3000億円だと言われています。以前はご存知のように紙の媒体が主流でしたが、スマートフォン、タブレット端末の普及に伴ってこれからはますますペーパーレス化が進むものと予想されています。皆さんが接する電子書籍のほとんどは漫画や小説だと思いますが、これらは物語を楽しんで思いを馳せるもの、つまりコンテンツを消費していくタイプだと言えます。一方、教科書や専門書はと言うとこれらには「知識」が書いてあります。漫画や小説との読み方として大きな違いは重要な箇所にマーカーを引いたり、知識を書き込んでいく、知識を反映できる点にあると思います。つまり教科書、専門書の役割としては「知識を得る」ことと「吸収した知識をアウトプットするのに役立つ」、読み方、求められているものに漫画、小説と大きな違いがあると思われます。

それでは次に具体的にどんな機能が必要か具体的に考えていきましょう。まず表示の仕方ですが、コマ割されている漫画を電子書籍化する場合には大きさを等倍率で表示する方が見やすいでしょうし、小説などはリフローで画面のサイズに合わせた表示の仕方をした方が読みやすいですよね。論文などは文字が羅列して書いてあることが多いので、リフローによる表示で問題ないかと思いますが、日本の教科書はレイアウトまで凝って見やすくしてあるものが多いんです。そこで漫画と同じく固定で表示する方法をとっていたりします。同じ専門書でも教科書と論文などの違いによっても表示方法を変えているのです。
次に専門書に求められる要件としては「ユーザーのインタラクション」が挙げられます。漫画ではそうそう無いかと思いますが、小説を読んでいると分からない単語や言葉を見かけることが多々あります。そのままその箇所を選択して検索エンジンで検索出来る点が紙には無い便利な点です。ただ、教科書、専門書に求められるインタラクションはもっと多岐に渡っていきます。受験勉強などの際に分からない箇所にマーカーを引いて色の異なるシートを被せて文字を消して暗記した…という懐かしい記憶をお持ちの方もいるでしょう。これ要は分からない箇所をリストアップして列挙しているということですよね。専門書などでは当然一般には使わない専門用語がたくさん出てきます。小説を読むより調べる回数は確実に多くなるでしょう。また、先生に言われて重要な箇所にグルグルと印をつけることもあったと思いますが、電子書籍では先生と生徒が同じ画面を見られるのであれば、より理解度が高まると思います。これらの専門書を読む際にソフトウェアに求められるポイントというのは、単に表示する方法だけでなく、分からない言葉をすぐに調べられる「ウェブ検索機能」だったり、覚えるのに役立つ「マーカー文字列リストアップ機能」、先生と生徒が共有出来る「アノテーション機能」など、理解の補助も求められているという点がポイントだと思います。

冒頭でBPSではビューアーと呼ばれる「読むためのソフト」を提供していると言いましたが、主に電子書籍のフォーマットの一つであるEPUBのビューアーを主に作っています。それが漫画などを読む際に役立つ画像に特化したビューア「超画像」や、日本独特の縦書きを見やすくした「超縦書」などの「超」EPUBシリーズです。縦書きに特化したビューアを提供している会社は国内でも数少ないので、BPSでは1，2を争うと自負しています。
その辺りを踏まえて、今回メディアドゥさんにお力を貸せる部分が大きく3つあると思いましたので順次説明させていただきます。まず1つ目の強みは、出版・組版に対する知識が高いこと。縦書きのレイアウトに特化した「超縦書」は国内でも数少ないとお話しましたが、日本の縦書きは色んな表示の技術を要しています。読み仮名（ルビ）のふり方や、圏点の表示、また数字やアルファベットなどを読みやすくする縦中横と呼ばれる表示技術、禁則処理など例を挙げていくとキリがないほどです。紙印刷であればDTPツールやアドビのインデザインなど、表現豊富なソフトウェアはあるのですが、HTMLやCSSだけではこれら全ての組版を表現するにはどうしても用件が足りない、紙印刷されたものにレイアウトをより忠実に近づけようと表示するには力不足になってしまうのです。弊社の「超縦書」では実際に出版社からの意見を取り入れることで、より正確で自然な形に表現出来るように改善していますので、読みやすい、見やすい表現の提供が可能になっているんです。

2つ目の強みは高いソフトウェア実装力です。再度「超縦書」を例に出して説明しますが、超縦書を作る際にはGoogleのブラウザ、Google Chromeの一番の核となる「Blinkコアエンジン」を基本ベースに、色々な組版要素を追加してソフトウェアの作成をしております。
ただ、このBlinkエンジンだけでもソースコードが200万行くらいになってしまい、縦中横などの縦書き独特な表示がうまく表示されない場合、どこを修正したら良いのか探すだけでも開発する者たちにとっては厄介なことなんです。そこに加えてページを高速でめくるには欠かせない、GPUに適切な処理を加えてあげる必要が出てきます。さらに、最近では「超縦書」のWindows版をリリースしたのですが、ユーザーの方から「フォントが汚い」というご意見をいただきました。もともとWindowsというのはそこまでフォントレンダリングが綺麗ではありませんでしたが、BPSではフォントを書き出す部分ごと交換してしまいました。するとMacほどではないにしろ「見やすくなった」「綺麗だ」と満足してもらえることが出来ました。これらのことを行うだけでも相当な実装力を要します。「こうしたいな」「こうなったら便利だな」という思いがあっても実際にそのソフトウェアを作れる技術がないと話になりません。BPSではそれが可能であるという点が大きな強みとして言えると思います。

3つ目の強みは最新技術への追従です。昨年BPSは「W3C（ワールドワイド・ウェブ・コンソシアム）」という団体へ加盟しました。このW3Cは世界標準となるHTMLやCSSを制定している団体です。簡単に済ませてしまいますが、EPUBとはHTMLやCSSをZIPでまとめたもの。W3CではHTMLやCSSなどの表示に関わる部分を制定しているのですが、表示に関わる部分以外のZIPなどを管理しているのがアメリカの「idpf」という団体もあります。我々としてはどちらに加盟しても良かったですし、本当であれば両方に加盟したかったところですが、ひとまず表示に関わるW3Cの方に加盟させていただきました。このW3Cという団体、取り組みとして非常に面白いことをやっていて、組版仕様について考察するCSS WG（ワーキンググループ）や、次世代のEPUBについて考えるDPUB IG（インタレストグループ）などがあります。特にこのDPUB IGの取り組みが興味深くて、例えばZIPはストリーミング配信に不向きなEPUBの圧縮技術になってしまうのですが、これらを撤廃して新しくもっと優れた圧縮技術を開発しようと動いていたりします。他には、専門書の所で話が出ましたが、アノテーション（共有）をもっと当たり前に提供出来ないかと考えるWEB Annotationという取り組みだったり、新しい世界に関する技術が日々話し合われているという団体です。私たちとしても加盟したばかりなので、まだそれほど強い発言権を持ててはいませんが、今後もっと積極的に参加していくことで最新技術をいち早く取り入れられますし、またユーザーからのフィードバックを生かして逆にBPSの方から提案するといった可能性も十分に考えられることです。電子書籍の分野はまだまだ改善する余地もありますし、表示技術だけじゃなく、ネットワークで共有するWEB Annotationなど新しいサービスも登場してきますので、そういった最新情報を素早く仕入れられるというのが最後の強みだと言えますね。これら3つの強みを生かして、専門書領域に強いメディアドゥ様と組むことで、お互いの良い所を合致させて新しい電子書籍領域を開拓していけるのではないか、そんな風に考えております。

EPUBの話ばかりしてきてしまいましたが、ここでPDFの話も少し絡めて、今後専門書のフォーマットに関するお話をしておきましょう。現在EPUBとPDFが2大電子書籍フォーマットです。先述した通り、EPUBがHTMLやCSSをZIPでまとめたものに対し、PDFは印刷用のPostScriptをベースに発展させたフォーマットなので、表示能力が固定的であるというのが大きな特徴です。そしてもう一つ決定的な違いというのが、DTPソフトなどを使った際にPDFの方がはきだしやすいということが挙げられると思います。EPUBの場合ですと、そのままはきだせないため、余計なコストがかかってしまうという部分があります。現状まだまだPDFに推されている部分ですね。しかし、当然EPUBにしか出来ない強みもあります。教育業界や専門業界において注目されているのが「edu PUB」です。先述したWEB Annotationの機能やQ&A機能をEPUBの中に組み入れることで、先生と生徒、教える側と教えられる側の共有がより一層深いものとなるのが利点です。アメリカにあるIMSという団体ではこのQ&Aシステムを既に多用しているという実例もあります。こういったインタラクションの部分がもっと組み込まれて活用されるようになると、EPUBももっと多くのユーザーに使われるフォーマットになる可能性を十分に持っていると思います。また、今後専門書領域に求められる機能としては次世代EPUBであるDPUBに興味関心があります。特にWEB Annotation機能に関してはどうやってネットワーク化するかやフィードバックはどうするかなど、問題は山積してますが、これらを解決していけばきっと有用なフォーマットとなるでしょう。まだまだ可能性、拡張性があると信じています。

更新期間がだいぶあいてしまいましたが、弊社のCSS研究部のWebページを更新しました。更新内容は、昨年10月に開催された第二回部会の概要部分で、CSS3 Writing Modesモジュールについて扱っています。

• CSS研究部 第二回部会 – part 1

このモジュールでは書字方向の仕様を収めており、日本語の縦書きコンテンツについて興味のある場合にぜひとも押えておきたい内容となっています。

本日更新分はWriting Modesの概要で、仕様の背景、書字方向の考え方の基本、行の方向、文字が進む方向などを余談を交えながら進めています。文字の回転、縦横混在の仕方やその場合のサイズ計算などもこのモジュールで扱っており、本日更新のpart 1に続いてpart 2、part 3で詳細にお送りいたします。part 2、part 3は8月中を目処に公開する予定で執筆中です。いましばらくお待ちください。

この部会はCSS仕様の先端に切り込もうとしている分、記事に不備が残っているかもしれません。お気付きの点がありましたら、記事の末尾にコメントをいただけると助かります(Disqusを使用しています)。

だいぶ出遅れた感がありますが、弊社で開発しているAndroidプロジェクトをようやくEclipseからAndroid Studio環境へ移行したのでその手順を書いてみたいと思います。

移行時のビルド環境は以下の通りです。

• Android Studio 1.2
• Gradle 2.2.1
• Android Plugin 1.2.3

※Android Studio 1.3、Gradle 2.4、Android Plugin 1.3.0に更新後も問題なく動きました

EclipseからAndroid Studioへの移行に関する記事は既に色々と出回っていると思いますので、Android Studioへ移行しないといけない理由やHello World的な説明は省きます。

今回は移行対象のプロジェクトがサブモジュールの多い結構大きめのもの、かつ、リリースビルドは顧客環境で行う、など色々と考慮しないといけないことが多かったのでその辺りを中心に書いていきたいと思います。

Android Studioを始める上で知っておいた方が良いこと

まず初めに、基本的な部分なのですが、既存のブログなどの紹介記事にはあまり記載が無かったため、Android Studio(主にGradle)の勉強に必要なURLをまとめて紹介します。

Android Studio Overview
Configuring Gradle Builds
Android Plug-in for Gradle
上記の3つは基本的な部分なのでひとまず読んでおきましょう。
分量もさほど多くありません。

Gradle Plugin User Guide
ここは超重要です。
build.gradleのandroid {} 内に出てくる名称やビルドタスク名称の意味が分からなかったら上記サイト内で検索してみましょう。

例えば以下のような単語などです。
assemble、clean、signingConfigs、productFlavors、buildTypes、applicationId、versionNameSuffix、zipAlignEnabledなど。

Gradle Documentation
※上記の日本語訳サイト
Gradle Build Language Reference
ここはbuild.gradleのandroid {} 外のことで分からないことがあったら見る感じですかね。
allprojects、dependenciesなどの単語は上記サイトで調べてみてください。

Groovy Documentation
Groovy Language Documentation
ここも重要。
当初、Groovyのことを調べずに始めたら色々つまづきました。build.gradleの記法で疑問に思うことがあったらひとまずGroovyを調べてみましょう。(文字列のシングルクォートとダブルクォートの違いとか！)

Groovyの入門としては以下の記事が分かりやすかったです。
Groovyを知らない人のためのbuild.gradle読み書き入門

EclipseからAndroid Studioへの移行

今回のプロジェクトは以下の様な構成となっていて、ソース管理にはGitを使用しています。

• メインのアプリケーションモジュール
• Gitの別プロジェクトで管理しているサブモジュール
• オープンソース等のサブモジュール等が複数

また、今回はEclipseプロジェクトからのimport機能的なのは使っていません。
最初はひとまずという感じでimportしてみようとしたのですが、盛大にエラーが出まくるし、ディレクトリ構成なども色々と変える必要があるため、地道に1モジュールずつ追加していく方法を取ることにしました。

移行前のEclipseのディレクトリ構成は以下のようになっています。
※Eclipseの設定ファイルその他諸々端折っています＋実際にはもっとモジュールいっぱいあります

     / (Gitプロジェクトのルート)
     + MyApplication/ (アプリケーションのメインプロジェクト)
        + assets/
        + libs/
        + res/
        + src/
           + jp/
     + module1/ (サブモジュール)
        + libs/
        + res/
        + src/
           + jp/
     + module2/ (サブモジュール)
        + libs/
        + res/
        + src/
           + jp/
     + submodule/ (gitの別プロジェクトに登録されているサブモジュール)
        + libs/
        + res/
        + src/
           + jp/

それでは以下に移行手順を記載していきます。

Android Studioで空アプリが起動するようにする

いきなり元の大きなアプリを丸々移行して動くようにするのは大変です。
エラーが大量に出た際に原因が分かりにくくなってしまい、どのエラーから解消していけば良いのか分からなくなってしまうためです。

今回は地道に行きます。急がば回れです。

1. Android Studioを起動し、Start a new Android Studio projectを選択します。
2. Application name、Company Domain、Package nameなどを元のアプリケーションのメインモジュールに沿って入力し、Project locationやSDKも同様に設定して次へ進む。
3. Add an activity to Mobileの項目はBlank Activityを選択し、Finishを押下します。

この時点でプロジェクトの構成は上記のようになっており、
Runを実行するとアプリが起動するはずです。

ひとまずここがスタートとなり、この「起動する」状態を維持しつつ、だんだんと元のアプリに近づけていきます。

サブモジュールを追加する

先ほど作成したメインのアプリケーションモジュール(上記の例だとapp)は一旦放置し、ひとまずはサブモジュールのビルドが通るようにします。

settings.gradleを見ると現時点では以下の内容しか記載されていません。
サブモジュールを追加していくとここの記述が増えていきます。

include ':app'

1. File > New > New Moduleを選択しCreate New Module画面でMore ModulesからAndroid Libraryを選択し、Nextを選択しメインプロジェクト同様に各種値を設定して次に進みます。
2. サブモジュールのAdd an activity to Mobileの項目は余計なファイルが生成されないようにAdd No ActivityにしてFinishを押下します。

これでプロジェクトの構成が上記のようになり、settings.gradleを見ると以下のように変更されています。

include ':app', ':mylibrary'

ただし、このままでは追加したmylibraryにエラーがあったとしても起動できてしまったりします。
build.gradle (Module: app)のdependenciesに以下の文を追記すれば、mylibraryがビルドに失敗する状態だと起動ができなくなります。

compile project(':mylibrary')

この状態まで行ったら、いよいよ元アプリのサブモジュールファイルを移行していきましょう。

現時点だと以下のディレクトリ構成となっています。
※Projectの表示をAndroid→Projectに変更した表示になっています

ファイルの移行

Eclipseからファイルを移行するには以下のことをします。

• mylibraryのsrc/main/res配下のファイルを削除する
• Eclipse側のsrc/jpをmylibraryのsrc/main/java/jpに移動する
• Eclipse側のresをmylibraryのsrc/main/resに移動する
• Eclipse側のlibs内にあるjarをmylibraryのlibsに移動する
• Eclipse側のlibs/armeabiなどのsoが入ったディレクトリをmylibraryのsrc/main/jniLibsに移動する

こんな感じになります。

設定ファイルの修正など

New Moduleで追加した直後のbuild.gradle (Module: mylibrary)を開くと、dependenciesが以下のように記述されています。

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:22.2.0'
}

以下の記述があれば、libsに置いたtest.jarは勝手に読み込まれます。libsにjarが存在しないなら消してしまって問題ありません。

compile fileTree(dir: 'libs', include: ['*.jar'])

以下の記述も、v7のサポートライブラリを使用していないなら消してしまいましょう。

compile 'com.android.support:appcompat-v7:22.2.0'

逆に、今まではEclipseのlibsディレクトリにandroid-support-v4などの Android Support Repositoryから取得出来るjarや、volleyのようなMaven Central(build.gradle (Project: MyApplication)に初期設定されているjcenterはMaven Centralのスーパセットとのこと)などから取得出来るjarが入っていたとします。

その場合は該当するjarは全て消し、build.gradle (Module: mylibrary)のdependenciesを以下のように書き換えます。
※バージョン番号は適宜読み替えて下さい

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:support-v4:22.2.0'
    compile 'com.mcxiaoke.volley:library:1.0.17'
}

Google Play ServiceのAPIなどもGoogle Repositoryをインストールしていれば同様の設定で使用出来るようになります。
それ以外のライブラリに関しては、今まで通りlibsにjarを入れるようにします。

アプリの起動

Sync Project with Gradle Files(以後Sync)の実行をしてからアプリを起動してみましょう。
エラーが出ずに起動に成功したら、このサブモジュールの追加に関しては成功です。

ちなみに、サブモジュールのAndroidManifest.xmlに関しては基本的に初期状態のままで問題無いはずです。

もしもエラーが出た場合は、表示されたメッセージに従って修正を行いましょう。
そして、全てのサブモジュールを追加し終わるまで上記手順を繰り返します。

サブモジュールの各種管理に関して

サブモジュールの追加作業をしていると、サブモジュールを管理する上でいくつか気になる点が出てきたので、その時にした対処方法について記載していきます。

サブモジュールのディレクトリをもっと深くしたい

特にGitサブモジュールなどを使った場合に、リポジトリのルートにサブモジュールプロジェクトのルートが存在すれば良いですが、そうなっていない場合も多いかと思います。

例えばここに記載のようにlibrariesの下にサブモジュールを置くことにしてみます。

作成したサブモジュール(mylibrary2)をこのlibrariesの下に配置したら、settings.gradleを以下のように記載します。

include ':app', ':mylibrary', ':libraries:mylibrary2'

Syncすると以下のような状態になりました。

うまく行ったように見えます。
が、librariesというただのディレクトリがProjectに表示されていたり、実際にディレクトリを見るとappやlibrariesと同じ階層にmylibrary2のディレクトリが作成されていたり(もちろん、javaファイルなどはlibraries/mylibrary2の下にあります)、ちょっと気持ち悪い状態になってしまいました。

この辺り、あまり詳しく調べていないので他に良い方法があるかも知れませんが、ひとまずsettings.gradleを以下のようにすることでこの現象は解消できました。

include ':app', ':mylibrary', ':mylibrary2'
project(':mylibrary2').projectDir = new File('libraries/mylibrary2')

2行目の意味とかはこの辺りを参照して下さい。

再度Syncをすると、Projectからlibrariesが消えていると思います。
librariesや無駄に作成されていた方のmylibrary2ディレクトリに作成されていた.imlファイルも消えています。

サブモジュール単体でAndroid Studioのプロジェクト作れないんだけどどうすんの？

できないようです。(たぶん)

Gitでサブモジュールごとにプロジェクトを管理したい場合、一旦何かのアプリのサブモジュールとして作成し、そのサブモジュール部分だけを登録する、という形になるかと思います。

以後はそのアプリ、または別のアプリにサブモジュールとしてimportして開発を行う、と。

volleyなどはGitのプロジェクトルート＝Android Studio(Gradle)のサブモジュールのルートな構成となっていました。

アプリのメインモジュールをAndroid Studioに移行する

長かったですが、遂にここまで来ました。

ひとまず、メインモジュールのソースなどを移行する前に、build.gradle (Module: app)のdependenciesに全サブモジュールと依存するライブラリが設定されており、かつ、アプリが起動出来る状態であることを確認して下さい。

これが問題なければおそらく期待通りに移行が完了するでしょう。

まずはサブモジュールの時と同じで、Eclipse側のsrc、res、libsなどをAndroid Studio側の該当のディレクトリにコピーしていきます。

次にメインモジュールのAndroidManifest.xmlもコピーしてapp/src/main/に置きます。
この時、Eclipseの時に指定していたversionCode、versionName、minSdkVersion、targetSdkVersionなどの設定はbuild.gradleで設定するためAndroidManifest.xmlからは消します。

dependencies以外いじっていなければ、build.gradle (Module: app)は以下の様な感じになっているはずです。

apply plugin: 'com.android.application'

android {
    compileSdkVersion 22
    buildToolsVersion "22.0.1"

    defaultConfig {
        applicationId "jp.bpsinc.myapplication"
        minSdkVersion 10
        targetSdkVersion 22
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:22.2.0'
    compile project(':mylibrary')
    compile project(':mylibrary2')
}

ビルド構成など考え始めると設定を色々と追記する必要がありますが(その辺りは後述します)、ひとまずデバッグビルドでアプリを起動するだけならこれで問題ありません。

Sync後、アプリを起動できれば成功です。
エラーが出るようなら、またメッセージに従って1つずつ解消していきましょう。

アプリ起動までの移行はここまでで完了しましたが、今回は顧客環境でのリリースビルドや、各種ビルド構成なども考慮する必要がありました。

以降でそれを説明します。

その他考慮すること色々

Android Studioへ移行したソースのGitへのコミット

ファイルの変更履歴

EclipseからAndroid Studioへ移行すると、ディレクトリ構成が変わるため、mvで移動しないと今までの履歴が台無しになってしまいます。

ここも地道に頑張るしかありません。(SourceTreeとかだと、元ファイル全削除してから新ファイルを丸コピーしてもある程度は勝手にmv認識してくれたりします)

ディレクトリ構成

「EclipseからAndroid Studioへの移行」で移行した直後の状態は以下のような感じになっていると思います。(サブモジュールをlibraries配下にした場合)

     / (Gitプロジェクトのルート、かつ、Android Studioのプロジェクトルート)
     + app/ (メインモジュール)
        + libs/
        + src/
           + main/
              + assets/
              + java/
                 + jp/
              + jniLibs/
              + res/
     + libraries/ (サブモジュール)
        + mylibrary1/
           + libs/
           + src/
        + mylibrary2/
           + libs/
           + src/
        + gitsubmodule1/
           + libs/
           + src/
     - readme.txt
     - その他ファイル

で、途中で気付いたんですが、Android Studioのアプリのプロジェクト名称って親ディレクトリ名に勝手に書き換わっちゃうんですね。

なので、上記のディレクトリ構成だとGitプロジェクトのルートディレクトリ名称が違うとプロジェクト名が変わってしまいます。

開発メンバーや顧客先と用語を統一したりするためにも、以下のように変更しました。

     / (Gitプロジェクトのルート)
     + MyApplication/ (Android Studioのプロジェクトルート)
        + app/ (メインモジュール)
           + libs/
           + src/
        + libraries/ (サブモジュール)
           + mylibrary1/
           + mylibrary2/
           + gitsubmodule1/
     - readme.txt
     - その他ファイル

Gitへ登録するファイルについて

Android Studioでアプリのプロジェクト作成直後、プロジェクトルートに存在する.gitignoreは以下のような記述になっています。

.gradle
/local.properties
/.idea/workspace.xml
/.idea/libraries
.DS_Store
/build
/captures

各モジュールの.gitignoreは以下のような記述になっています。

/build

.ideaディレクトリとか、各モジュールディレクトリにある.imlはAndroid Studioの設定ファイルなどのため、gradlew assembleコマンドなどでビルドを行うだけなら必要のないものです。

また、.imlやいくつかの設定ファイルは自動で再生成されたり、各個人環境の設定を保存しているだけだったりするので、Gitでファイル共有する必要は無かったりします。

これらファイルのどれを共有するかは各プロジェクトごとに判断が異なると思います。
※デフォルトの.gitignoreのままでも、無駄なファイルが共有されるだけで大きな不都合は無いと思います

ここに勉強の労力をかける気はしなかったので、細かく調べてはいません。
が、以下のサイトの説明が参考になったので紹介だけしておきます。
バージョン管理 ─プロジェクト管理ファイルについて［中編］
バージョン管理 ─プロジェクト管理ファイルについて［後編］

アプリの署名について

デバッグビルド

開発メンバーごとに別々のdebug.keystoreを使用していると、アプリの上書きインストールや
バージョンアップ確認などがやりづらくなるため、keystoreを共有する設定にしました。

debug.keystoreって何？という方はSigning in Debug Mode辺りを参照下さい。

まず、以下のようにdebug.keystoreを配置します。
※場所はどこでも良いです

     / (Gitプロジェクトのルート)
     + MyApplication/ (Android Studioのプロジェクトルート)
        + app/ (メインモジュール)
        + libraries/ (サブモジュール)
        + keystore/ (keystore配置ディレクトリ)
           - debug.keystore

そして、build.gradle (Module: app)に以下の指定を追記しています。

android {
    signingConfigs {
        debug {
            storeFile file("../keystore/debug.keystore")
        }
    }
}

これで、各開発メンバーが同じdebug.keystoreを共有することが出来ます。
詳細はSigning Configurationsに記載があります。

顧客先でのリリースビルド対応

今まで紹介してきた設定のままだと、リリースビルドを行おうとすると署名関連の情報がないためビルドに失敗します。

もちろんリリース用のkeystore(以後release.keystore)を設定してあげれば良いわけですが、今回はリリースビルドは顧客環境で行うため、release.keystoreは弊社では保持していません。

しかし、社内でもテストなどでリリースビルドを行いたいことはあります。
この時はもちろん適当にテスト用のrelease.keystoreを作成して使うわけですが、このファイルをdebug.keystore同様に保存してしまうと、納品物に混じってしまって顧客先で混乱を招く可能性があります。

そのため、今回は社内テスト用のrelease.keystoreをGit上はプロジェクトディレクトリ外に保存し、リリースビルドを行いたい時は手動でkeystoreディレクトリにコピーすることにしました。

同様に、顧客先でもrelease.keystoreをkeystoreディレクトリにコピーしてからビルドを実行する、という手順を踏んでもらいます。

     / (Gitプロジェクトのルート)
     + MyApplication/ (Android Studioのプロジェクトルート)
        + keystore/ (keystore配置ディレクトリ)
           - debug.keystore
     + testkeystore/ (test用keystore配置ディレクトリ)
        - release.keystore
        - release.properties

この時点でGit上は上記のようなディレクトリ構成になっています。
今回はrelease.keystore用のパスワードなどをpropertiesファイルに格納するようにしました。

release.propertiesの中身は以下の様になっています。

keyAlias=testkeystore
storePassword=testkeystore
keyPassword=testkeystore

そして、build.gradle (Module: app)には以下の内容を追記します。

android {
    signingConfigs {
        release {
            File keystoreFile = file('../keystore/release.keystore')
            File keystorePropertiesFile = file('../keystore/release.properties')
            storeFile file(keystoreFile)

            Properties properties = new Properties()
            keystorePropertiesFile.withInputStream {
                properties.load(it)
            }
            keyAlias properties.getProperty('keyAlias')
            storePassword properties.getProperty('storePassword')
            keyPassword properties.getProperty('keyPassword')
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

これでMyApplication/keystore内にrelease.keystoreとrelease.propertiesを入れておけば、リリースビルドも成功するようになります。

しかし、このままだとMyApplication/keystore内にrelease.keystoreとrelease.propertiesが無い状態でSyncしようとするとファイルが見つかりません、というエラーが発生してしまいます。

開発時はできればMyApplication/keystore内は空にしておき、社内でリリースビルドをしたい時に例外的にtestkeystore内のファイルを使用する、としたいです。
常にtestkeystore内のファイルを使用する状態だと、プロジェクトディレクトリ外にtestkeystoreを配置した意味が薄くなり、納品時にも間違いが発生する可能性が高くなるからです。

そのため、以下のようにbuidl.gradle (Module: app)を書き換えます。

android {
    signingConfigs {
        release {
            File keystoreFile = file('../keystore/release.keystore')
            File keystorePropertiesFile = file('../keystore/release.properties')
            if (keystoreFile.canRead() && keystorePropertiesFile.canRead()) {
                storeFile keystoreFile

                Properties properties = new Properties()
                keystorePropertiesFile.withInputStream {
                    properties.load(it)
                }
                keyAlias properties.getProperty('keyAlias')
                storePassword properties.getProperty('storePassword')
                keyPassword properties.getProperty('keyPassword')
            }
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

これでSync時にファイルが存在しなくてもエラーにならなくなりました。デバッグビルドを行うのみであれば、MyApplication/keystore内は空のままで問題ありません。

また、今回はpropertiesファイルを使用しましたが、keystoreのパスワードなどは環境変数やコマンドラインから読み込む方法もあります。詳細はここ。

環境変数から読み込む。

storePassword System.getenv("KSTOREPWD")
keyPassword System.getenv("KEYPWD")

コマンドラインから読み込む。

storePassword System.console().readLine("\nKeystore password: ")
keyPassword System.console().readLine("\nKey password: ")

様々なビルド構成の作成

Build Variantsに記載の通り、Build Type + Product Flavorの組み合わせで様々なapkを出力することが出来ます。

Build Types

この項目では、debuggableなどのデバッグ関連の設定と、署名、proguardに加え、applicationIdSuffixやversionNameSuffixによるapplicationIdやバージョン名の変更ができます。

applicationIdSuffixでdebugの際に”.debug”などと設定しておけばデバッグ版リリース版を同時にインストールすることが出来るようになります。
※今回のプロジェクトではapplicationIdの変更が許されなかったため使えませんでしたが・・・

versionNameSuffixもバージョン名がアプリの設定画面などで見れるようになっていれば、今インストールされているapkが何なのかパッと分かるようになって便利です。

Product flavors

この項目ではapplicationId、versionNameなどの変更に加え、targetSdkVersionなども変更が可能です。

独自定数の定義

Build TypeやProduct FlavorではbuildConfigFieldを使用してBuildConfigに定数を定義出来ます。

この機能を使うと、テスト用の機能のON/OFFを切り替えたり、開発環境と本番環境でURLを切り替えたりなどが簡単に行えます。

以下のような感じで書くと

android {
    productFlavors {
        dev {
            buildConfigField "String", "TEST_STRING", "\"TEST_STRING\""
            buildConfigField "boolean", "TEST_BOOLEAN", "true"
        }
    }
}

BuildConfigに以下の内容が追記されます。

  public static final String TEST_STRING = "TEST_STRING";
  public static final boolean TEST_BOOLEAN = true;

上記内容を見ればなんとなく分かるかと思いますが、String型を指定した際の「”\”TEST_STRING\””」を「”TEST_STRING”」と記載すると、BuildConfigが以下のように出力されてしまい、ビルドエラーになってしまうので注意が必要です。

  public static final String TEST_STRING = TEST_STRING;

ソースの切替

Sourcesets and Dependenciesに記載の通り、Product Flavorごとにディレクトリを分け、ソースファイル自体を切り替えることも可能です。

ただ、ファイルが分かれていると修正漏れなどが発生する可能性が高いかな？と思い、今回のプロジェクトではこの機能は使いませんでした。

バージョン名の付け方とか

テスト中などに不具合が見つかる度にビルドを繰り返すと、市場リリースバージョンは同じでもテスト用のapkは複数作成されることになります。

この時にバージョン名の末尾にビルド番号が表示されていると、バグが発生した際などに弊社－顧客間で意思の疎通が取りやすくなります。

今回は以下の様な感じでバージョン名を付けてみました。
Product Flavorsは開発環境、ステージング環境、本番環境向けの3つを作成しています。
※必要な部分のみ記載しています

def VERSION_NAME = "1.0.0"
def BUILD_NUM = "1"

android {
    defaultConfig {
        versionName VERSION_NAME
    }
    buildTypes {
        debug {
            versionNameSuffix "." + BUILD_NUM + "-debug"
        }
    }
    productFlavors {
        dev {
            versionName "dev-" + VERSION_NAME
        }
        stg {
            versionName "stg-" + VERSION_NAME
        }
        prod {
        }
    }
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            def dir = output.outputFile.parent
            def flavorName = variant.productFlavors[0].name
            def apkNameSuffix = variant.versionName

            if (variant.buildType.name.equals("release")) {
                apkNameSuffix = apkNameSuffix + "." + BUILD_NUM
            }
            if (flavorName.equals("prod")) {
                apkNameSuffix = "prod-" + apkNameSuffix
            }
            output.outputFile = new File(dir, "MyApplication-${apkNameSuffix}.apk")
        }
    }
}

こうすると、以下のように出力されます。

BUILD_NUMはテスト期間中に再ビルドなどを行う度に1ずつ上げていきます。

本当はprodRelease以外はリリースビルドであってもバージョン名にBUILD_NUMを付与したかったのですが、applicationVariants.allの中だとversionNameの書き換えはできないためうまく行きませんでした。

この辺り、もっとうまいやり方知っている方がいましたら教えていただけると嬉しいです。

リリースビルドは本番向け以外いらないんだけど？

build.gradle (Module: app)に以下の記述を追記すればBuild Variantから開発環境(dev)とステージング環境(stg)のリリースビルド設定を消せます。

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals("release")) {
            if (variant.flavors[0].name.equals("stg")
                    || variant.flavors[0].name.equals("dev")) {
                variant.setIgnore(true);
            }
        }
    }
}

ビルド環境に関して

Gradleラッパー

Gradlewラッパーの詳細はここを見て下さい。

     + MyApplication/ (Android Studioのプロジェクトルート)
        + gradle/
           + wrapper/
              - gradle-wrapper.jar
              - gradle-wrapper.properties
        - gradlew
        - gradlew.bat

サイトに記載の通り、ラッパーにより上記ファイルが生成され、これをGitなどのバージョン管理システムに登録しておくことにより、別の環境での環境構築が非常に楽になります。

Gradleのバージョンを更新する際もgradle-wrapper.propertiesを書き換えるだけでできます。

ビルドに必要な最小環境

今回のプロジェクトで開発者以外や、顧客環境などでビルドしてもらう際に整えてもらう必要のある最小環境は以下の通りでした。(Android Studioは必要ありません)
※プロジェクトにGradleラッパーが保存されている前提となります。

• Java SE Development Kit 7のインストールと環境変数JAVA_HOMEの設定
• Android SDKのインストールと環境変数ANDROID_HOMEの設定
• Android SDK Managerで以下の項目をインストール
  • Android SDK Tools
  • Android SDK Platform-tools
  • Android SDK Build-tools (対象のバージョン)
  • SDK Platform (対象のAPI Level)
  • Android Support Repository
  • Google Repository

Google Repositoryなどは使用していなければインストールする必要はないかも知れません。

この状態でAndroid Studioのプロジェクトルートをコマンドラインで開き、「gradlew clean assembleDevDebug」などと打てばビルドが出来ます。
※ここの62.2.にあるように、Gitなどを経由すると実行権限がなくて失敗する可能性があるので注意

Android Pluginの仕様で説明が載ってない部分があるんですけど？

こういう時は仕方ないのでソースを覗きましょう。
ちらっと覗くだけでも雰囲気が掴めます。

Windows環境のデフォルト仕様でAndroid Studioを使っている場合は、build.gradle内で気になる名称(productFlavorsとか)に対してJump to Source(F4)とかCtrl+左クリックとかしてソースを覗いて見ましょう。

ソースファイルの実体は以下のディレクトリとかに入っています。
　{Android Studioインストールディレクトリ}/gradle/m2repository/com/android/tools/build/gradle-core/

まとめ

途中から大分とりとめのない内容になってしまいましたが、以上が今回の移行作業で行った(学んだ)内容となります。

正直今ではもうEclipseに戻る気が全くしません。
ビルド構成を色々いじれるのも素敵ですが、操作に慣れるとIDEとしてもEclipseより良い点が多いように思います。

ひとまず今回の件で自分が学んだ内容は全て出し切ったつもりなので、みなさんも「俺の最強Gradle設定」を是非晒してもらえると嬉しいなーと思います。

いつもTechRachoを読んで頂いているみなさん、こんにちは。
BPSの開発以外担当第二号のGenkiです。（第一号は社長です）
この度、プレスリリースを発表いたしましたのでご報告です。

こうやってプレスリリースを大々的に打つのは、実は初めてだったりします。
そして、BPSには広報専門の担当者がおりませんので、詳しい方是非色々アドバイスしていただけると嬉しいです。

プレスリリースの内容は、BPSが長年開発を続けてきた自社商材「超縦書」の導入実績発表です。

ちなみに、全文はこんな感じです。

「DMM.com」公式ビューアアプリ「DMM ブックス」が EPUB 3 準拠ビューア「超縦書」を採用
－複雑な日本語組版も忠実に再現する「超縦書」ビューアエンジンにより、小説・ビジネス書のラインナップを拡充－

ビヨンド・パースペクティブ・ソリューションズ株式会社（本社：東京都新宿区、代表取締役：渡辺正毅、http://www.bpsinc.jp/ 以下 BPS）は、同社の EPUB 3 に準拠し、複雑な日本語組版も忠実に再現できる電子書籍ビューアエンジン「超縦書（ちょうたてがき）」の Windows 版が、Web を通じて様々なコンテンツを 提供する株式会社 DMM.com（本社：東京都渋谷区、代表取締役 社長 松栄 立也、http://www.dmm.com/ 以下 DMM ）の公式アプリ「DMM ブックス」のビューアエンジンとして採用されたことを発表いたします。

「超縦書」ビューアエンジンが組み込まれ、小説・ビジネス書のラインナップを拡充した「DMM ブックス」は７月３０日より、提供開始されております。

「DMM ブックス」は、「DMM.com」で購入した電子書籍作品を スマートフォンやタブレットで閲覧できるサービスです 。「DMM ブックス」では、これまで独自の日本語組版 エンジンが採用されていましたが、この度、日
本語独自の縦書きや複雑な組版を EPUB 3 の仕様に基づき忠実 に再現する「超縦書」（Windows 対応）ビューアエンジンを導入することにより、小説やビジネス文書等の複 雑な日本語組版の再現が必要となる文書を快適に閲覧できるように機能を拡張いたしました。
なお、Mac、Android、iOS 版「超縦書」は今秋リリースを予定しております。

同時に BPS は、「DMM ブックス」に必要な書店機能および画像ビューアなど全ての新規開発と、ACCESS 社「PUBLUS」エンジンを一部組み合わせて導入を行なうことで、総合書店としての機能を充実させることに成功いたしました。

「超縦書」ビューアエンジンは、電子出版業界から組版の正確性において高く評価されており、小説だけでなく専門書など幅広いジャンルの出版物の閲覧ビューアでの採用が広がっています。この度、本ビューアエンジンの実績および充実した機能が評価され採用に至りました。

BPS は、引き続き電子書籍ビューアの普及に貢献するとともに、事業者のサービス拡充を支援し、世界のエンドユーザに向けて、より便利で豊かな電子書籍体験を提供してまいります。
※1: iOS/Android 版につきましても、この秋公開を予定しております。
「超縦書」に関する詳細は、http://www.bpsinc.jp/epub.html をご覧ください。
「DMM ブックス」の機能については、DMM.com の公開情報をご覧ください。
http://www.dmm.com/dc/info_bookviewer.html

■ビヨンド・パースペクティブ・ソリューションズ株式会社について
ビヨンド・パースペクティブ・ソリューションズ株式会社（BPS co,. Ltd.）は「電子書籍ビューアアプリ開発事業」「Ruby on Rails を使った Web 開発事業」の 2 軸を中心に据えた、2007 年設立の IT ベンチャー企業です。
「ICT を通じて日本好きを増やす」を合言葉に、ブラウザ閲覧用固定レイアウト向け EPUB ビューアや日本語縦書きビューアエンジンの開発を行っています。
近年では Web 技術の世界的標準化推進団体である W3C (World Wide Web Consortium)への加盟も果たし、Web上の日本語表現普及にも注力しています。

http://www.bpsinc.jp/

※こちらのサイトでも確認出来ます。

http://www.asahi.com/and_M/information/pressrelease/CPRT201528558.html?iref=andM_kijilist

http://prtimes.jp/main/html/rd/p/000000001.000014900.html

いかがですか？なんかそれっぽいプレスリリースになってますよね。
よくBPSって何やってる会社なの？と聞かれることが多かったのですが、このプレスをきっかけに「電子書籍の縦書きビューアはBPS！」みたいな分かりやすい企業ブランディングをしていきたいと思っております。


もちろん、Ruby on Railsを使ったWeb開発も引き続き注力していきます。
そして、DMM.comさまには引き続き満足していただけるよう開発陣一同尽力して参ります。

その他、詳しいお話を聞きたい方などは、是非BPSのスタッフに直接ご連絡頂くか、お問合せフォームよりご連絡ください。
本日も読んで頂きありがとうございました。

CSS研究部Webを更新しました。予告通り、8月中のPart2の更新です。

* CSS研究部 第二回部会 – part 2

本日更新分は、Writing Modesの本編に入り、縦横混在の仕方や、その場合のサイズ計算などを扱っています。

もう少し残りがあり、Part 3として8月末を目処に公開する予定で執筆中です。
行の方向、文字の回転、縦中横などを扱います。
8月もあと日数が限られ、焦っていますが、いましばらくお待ちください。

この部会はCSS仕様の先端に切り込もうとしている分、記事に不備が残っているかもしれません。お気付きの点がありましたら、記事の末尾にコメントをいただけると助かります(Disqusを使用しています)。

CSS研究部Webを更新しました。なんとか8月中という更新予定通り、8月最終日ですが公開にこぎつけました。
夏休みの宿題が終わった気分です。

* CSS研究部 第二回部会 Part 1 (概要)
* CSS研究部 第二回部会 Part 2
* CSS研究部 第二回部会 Part 3 – New!

本日更新分は、Writing Modesのインライン方向、文字の回転、縦中横を扱っています。インライン方向の説明をする都合上、簡単ですがBIDIの解説も行っております。
HTMLにおけるアラビア語の挙動を知っておきたい方にはおすすめの内容となっています。

これで、勉強会の内容はすべて公開となりました。
実は第三回はその後まだ開催しておらず、出せるネタは出し切った状態です。

幸い、内外からそろそろ機会を設けようということで、9月に2回ほど久々に勉強会の開催予定があります。
詳細については、最近開設したCSS研究部のWikiをご覧ください。

この部会はCSS仕様の先端に切り込もうとしている分、記事に不備が残っているかもしれません。お気付きの点がありましたら、記事の末尾にコメントをいただけると助かります(Disqusを使用しています)。

ども、Genkiです。

元々が人材出身ということもあり、BPSに入社してからは採用担当をやりつつ、たまに他社の採用を手伝ったりしています。

特にエンジニアの採用については、新卒・中途共に一筋縄ではいかないな、と前職の時から感じていたことを、最近さらに強く感じています。

以前、こんな記事を書いてみたのですが、あれから1年ほど経ちました。

前のバージョンアップ、ということで今回はエンジニアの転職について少し掘り下げて書いていきたいと思います。

・エンジニアを採用したい企業側の気持ち

・開発会社に転職したいエンジニアへのアドバイス

と主に2つの側面から書いていきたいと思います。

まずはエンジニアを採用したい企業側の気持ちです。

とはいっても、BPSは星の数ほどある開発会社の一社に過ぎないので、こんなことを思ってる会社もあるんだな、ぐらいに捉えてください。

■相変わらず転職市場では人気のエンジニア

これは、以前書いた時と変わらずですね。

もうね・・・みんな高い！（スキルもだけど採用費用が）

媒体や紹介でいい人を見つけたとしても、すぐ大きな会社に持って行かれます。笑

自社サービスで成功している会社や、誰もが知ってるような会社はやっぱりお金がありますね。

面談で魅力付けの意味も込めて、一緒にキャリアプランとかを練って、かなり前向きに検討しててくれたとしても、やはり提示年収の桁が違うと人の心はグラッと動くみたいです。

そりゃそうですよね。僕も、待遇が1桁違ったら迷わず動くと思います。笑

面談も社長、及び役員面談がまず1回、その後同じチーム（アプリorWeb）面談が1回の最高2回なのですが、時間に換算すると合わせて3時間もないのです。

その中で、他の待遇に揺らがないようなほど口説き落とすのはかなり至難の技なのでは無いかと思います。

そして、職種でぶった切っちゃうのも安易かもですが、営業に比べてエンジニアの方はそれらがより難しいです。

営業は、会社の理念や社長の人柄、社員の情熱および飲み会などの雰囲気で囲い込みが出来る事が多いですが、エンジニアの方は基本冷静です。

だからこそ、僕らもロジックをしっかり立てて説得するのですが・・・まぁ、難しいですね。

■BPSのメイン手法

そんなBPSでの中途採用ですが、メインで使っているのは紹介です。求人広告を出すことは滅多にありません。

というのも、上で書いたようにほんとに人気の職種なので、スカウト送ってもまず反応が無いです。

当社のスカウト返信率は3パーセントです！（ドヤぁ）とか言ってくるメディアさんもいらっしゃいますが、100通も送って3人しか返って来ないのはすごく労力に見合っていません。

3人に出会えるならまだしも、3人からの“返信”ですからね。

昨今自由応募ではなかなかいい人から応募が来ないという話をよく聞きます。転職系のメディアを提案してくる方は、スカウトで「攻め」の採用をしましょうと言います。

これはおそらく全企業に言っていることであって、よほど情報に疎くない採用担当者であれば、スカウト打ちまくるというのはもはや常識です。

これにより、求職者さんの動きが「登録→検索→応募」ではなく「登録→届いたスカウト見る→応募」に変わっています。

大手の求人メディアだと、登録した瞬間に100通近くのスカウトが届くことも今ではそんなに珍しい話ではありません。

もはや広告としての役割はかなり薄くなってしまっていて、どれだけ露出の高いスカウトにお金を払えるか、そしてそれを打てる社内リソースがあるか、が重要になっています。

BPSは、そのどちらもなく、また必要性を感じていないので、人材紹介、という方法を取っています。

求人広告に比べると採用単価は高いです。でも、「採れるかどうか分からないし掲載してからも社内リソース使う」よりは採れた時にしっかり支払う方がシンプルで良いですよね。

採用基準も、数百万の紹介フィーを払ったとしても、すぐにペイしてくれるような人材のみに絞れば、そんなにリスクもありませんしね。

■紹介会社のいいところ

前述した料金体系に加えて、コンサルタントがスクリーニングをしてくれるのも人材紹介の良い所です。

欲しいスキルや年齢、年収は明確なのに、肝心の採用する側の企業は求職者からみたらどんな開発会社かよく分からない。

これを間に入ったコンサルタントがうまく緩衝してくれます。

僕らがやっていることや強みを単にテキストではなく、F2Fで伝えてくれるのは非常に助かります。

もちろん、そのコンサルタントとは何度も面談をして僕らの会社をしっかりと理解してもらう必要がありますが、そのコストはスカウトを無駄打ちするコストに比べたら遥かに有意義だと考えます。

BPSのように採用担当専任がいない会社だと、しっかり時間をかけて求職者を口説いてくれるコンサルタントは第二の採用担当だと言っても過言ではありません。僕もいつも非常に助かっています。

ITエンジニアさんの紹介に自信のある企業さまは、是非ご連絡ください。

そして、ここからはエンジニアさんへのアドバイスになります。

■オススメの転職方法

まずはオススメの転職方法として、人材紹介への登録を挙げます。

これは、前の記事でも触れているのですが、自分にマッチした求人を持ってきてくれるので、特に現職の方は無駄な時間をかけずに絞り込みまで持って行けます。

あとは、僕らが人材紹介を利用しているので、出会える確率がアップするからですね。これは完全な邪です。笑

■いい紹介会社の選び方

じゃあ、どういう紹介会社がいいの、という話になると思います。

実はこれも以前記事にしているので、参考にしてもらえると嬉しいです。

せっかくなので抜粋しますね。

社会人になると学生の時みたいに暇じゃないので、転職活動に使える時間が限られています。
そこで便利なのがエージェント、つまり紹介会社ですね。
おすすめの求人持ってきてくれるのと、推薦してくれるので、スピーディにことが進みます。
ただし、当たりはずれが大きいのも事実。
そしてその当たりはずれはこんな感じで見極められると思います。

仮に今当てはまる要素があるのなら、
会社か担当の変更を検討した方がいいかもしれません。
ちなみに、悪いと考える理由はこんな感じです。
※あくまで個人的な見解です。

■エンジニアが転職するなら、IT専門の人材紹介会社が良い

餅は餅屋です。一口に人材紹介会社、と言ってもそれぞれ得意分野、不得意分野があると思います。

そんな中でエンジニアの転職に特化しています、とホームページなどで明確にしている会社に登録するのは必須だと思います。

もし、自分の担当についたコンサルタントがITに全然詳しくなくて、スキルを正しく伝えてくれない恐れがあるなら、遠慮なく変えてもらうべきだと思います。

超オススメなのが、元々エンジニアをやっててコンサルタントにキャリアチェンジしました、という人なのですが、まぁそんなに多くはないですね。

とはいえ、エンジニア特化の会社であれば、そうでない会社に比べて出会える確率は高くなると思います。

■エンジニアにオススメの人材紹介会社

色々書いてきましたが、転職はエンジニアに限らず慎重に進めていきたいもの。

人生の3分の1は働いていることを考えると、それを変えるのってかなり勇気いりますよね。僕も転職は1回していますが、3か月以上は悩んだと思います。

結局、単に求人を紹介してくれるだけでなく、自分と同じ目線で自分の新しい職場候補を探してくれるコンサルタントに出会えるか否かが転職成功のカギを握ると思います。

そんな、エンジニアにとって親身になってくれそうなコンサルタントが多い紹介会社を1社だけ紹介しておきます。

■レバテックキャリア

https://career.levtech.jp

サイトを見て頂いても分かると思いますが、ITに特化した人材紹介会社さんです。

中でもWebエンジニア、そしてデザイナーに強みがあるようです。

単に開発言語だけでなく、開発方針なども視野に入れて、自分に合った企業を紹介してくれます。

利用はもちろん無料です。

転職するかどうかすらまだ決めていない方でも大歓迎だそうです。是非、興味のある方は見てもらえると良いかと思います。

今回も読んで頂きありがとうございました。

タイトルはSlackからGoogle spreadsheetをコントロールできそうな感じがしますが、別です。すみません。活用術というほどでもない、他愛のない記事ですが、面白そうと思った方に読んでいただければと思って盛りました。

弊社では80台ほどの携帯端末を保有していて、WebサイトやiOS/Androidアプリのテストをしています。Webサイトやアプリの開発者だったり、アルバイトのテスターだったり、営業担当がデモで持っていきたかったり、様々な人がいろんな端末を使います。そういう中にいると、よく「Android 4.3の端末あったっけ」「iOS8.4のiPhone6かiPhone6+ある？」と聞かれるわけです。

私は端末管理を任されているのですが、聞かれると帳簿を開き、そういう端末があるかどうか探します。幸い、OSバージョンや画面サイズは帳簿に正確に書いているので、あとはそこで検索するだけなんですね。
条件に合う端末がなければ、404を返します。条件に合った端末を保有していれば、管理番号を引いて教えてあげます。そうするとテストコーナにある端末の、番号シールを見て、「これがAndroid 4.3の端末なのだな」とわかります。

前提が「帳簿にOSバージョンを記録してある」「端末に番号シールが貼ってある」ということで、ちょっとシビアなのですが、そういう前提のときにSlackbotを使って省力化できないかということで考えました。

検索条件をSlackbotにフィードして、botが考えて返してくれるといいな、が理想です。それは理想です。そこまでやっていません。なのでぜんぜん大したことないので期待しないでください。

手順

1. まず、Slackbotの設定を行います。

SlackのMacアプリの、チーム名のメニューにある「Customize Slack」を選びます。

この設定は、チーム内のすべてのユーザーに影響するので、編集は慎重に行いましょう。

2. すると、Webブラウザで設定画面が開くので、「Slackbot Responses」タブを選びます。

3. 「Add new response」ボタンを押し、キーワード欄(左)とメッセージ欄(右)になにか入力します。

キーワードは、Slack上で打たれるワードです。コンマ区切りで複数指定できます。「find ios」「find android」など、コマンド風のものがよいでしょう。社内のSlackに頻出する「仕様変更」「締め切り」「モンゴル語」みたいな単語を指定すると、スパムみたいにあちこちのスレにresponseが付いてしまうので、気をつけましょう。適度な長さで、頻出の発言にはかぶらず、必要なときに思い出しやすい語にしておきます。

今回は、「find ios」と打つと、端末とバージョン情報を記録した帳簿(Google Spreadsheet)へのリンクを出すようにしました。メッセージ欄に、Google Spreadsheetへのリンクを1行で書くだけです。ちなみに、メッセージ欄は改行区切りで、複数行の記述ができます。毎回同じものを返す場合は、メッセージは1行だけにします。複数行を入れると、キーワードが打たれるたびにランダムで1行返されます。

おまけとして、スペルの違う「andriod」などを入れると、正しいスペルを案内してくれるレスポンスも書いてみました。関係ないですが「遅延証明」と入れると、鉄道各社の遅延証明へのリンクもランダムにサジェストしてくれるレスポンスも作ってみました。微妙に便利じゃないけど人工無能的な知性を感じさせるbotが演出されています。

4. リンク先のGoogle spreadsheetは、検索しやすいようにちょっと細工しておきます。

端末情報をいろいろ書き溜めたシート「携帯端末・充電器」とは別に、「クエリ」シートを作っておきます。そこのA1セルに、検索するOSバージョンを書くようにします。そして、4行目あたりの空欄に、下のようなクエリを書くと、A1の内容をクエリに足して、5行目以降に検索結果をバシっとリストしてくれます。

=query('携帯端末・充電器'!A:Z, "select A, B, C, H, I, K, L, M, N, O, P, Q, R where K like '"&A1&"%' order by K")

クエリはアクティブに動作しますので、A1セルの内容を変更するたびに、すぐにクエリ結果が反映されて見ることができます。この方法だと2人以上が同時にクエリしたいときに速攻で上書きされてしまいますが、1日に1回聞かれるかどうかくらいなので、衝突確率(Collision Frequency)を計算した結果、気にしないことにします。クエリの「where K like …%」で、K列(OSバージョン名を入れた列)にA1で指定した文字列が前方一致すれば、という条件を指定します。「order by K」は、検索結果をOSバージョン名で昇順に並び替えます。

スプレッドシートは事前にGoogle Driveの共有フォルダに置いたり、個別に共有設定をしておきましょう。これで、Slack上で「find andriod」などの発言をすると、事前に設定したメッセージが表示され、端末や正しいスペリングを探すお手伝いをしてくれます。

本当は、Slack上で引数を指定して拾って、さらに社内のすべての該当端末でアラームとバイブレーションが鳴ってくれたらパーフェクトですね。「Android 4」だけ打つと10台くらい一斉に鳴ったりしてうるさいですが、どなたかそういうことを試されたらこっそり教えてください。

BPSで数少ない、開発以外その他全般担当しているイトウです。
様々なスクールによく書かれていて、お金がもらえそうだけどよく分からなかった「教育訓練給付金」というものを使って勉強をしてきてみたので、まとめてみます。

教育訓練給付制度ってなぁに？

キャリアアップのために新しい知識・技術を身に付けたい！
という熱い志を持って、労働者が自発的に学校に通ったり、通信講座を利用したりして勉強・訓練をしている人に向けて、政府がその費用の一部を負担してくれる制度です。

内容の専門性別に2種類あり、それぞれ制度を受けられる人の条件も違いますが、基本的に雇用保険に入っている（入っていた）ことが必要です。
まぁ、会社に雇われて働いている方であれば大体強制的に入っているはずです。

一般教育訓練給付

専門実践教育訓練給付

ちょっと小難しいですが、厚生労働省のサイトにしっかり書かれているので細かい条件や自分に合った講座は探してみてください:)

私は今回「一般教育訓練」の方を受けてきました。

勉強を始める前に

給付金は対象講座じゃないともらえません！

受けてみたい講座がキャリアアップに繋がれば何でも給付金がもらえるわけではありません。講座を開講する予備校や通信講座会社側であらかじめ厚生労働大臣に申請をして、認定を受けた講義でなければ給付金の対象とはなりません。
とはいえ、認定は予備校が頑張って取ってくれるので、我々としては、認定講座を選んで受ければいいだけの話ですね。

授業はちゃんと受けよう

講座を選んだら、ちゃんと受けなくてはダメです。
修了時には一定の出席率（もしくは答案提出率）と成績を収めていないといけないので、気を抜きすぎるのは禁物です。

修了試験は追試も受けられる場合がある（私は受けられました）ので、まずはちゃんと授業を受けることが大切です。

そう、実は給付金の受給のために本試験への合格は必要ないんです。
きちんと認定講座を修了すること。それが条件なのです。
修了してれば最低限の知識や技術はちゃんと身についていて、その人のスキルは確実に上がっている！はずなのです。…はずなのです。

次回は実際に私が講義を受けてみたときの手続きなどを紹介する予定ですー。

まずはご覧いただきありがとうございます。弊社では事業拡大につき募集職種・募集人数を増やしております。担当頂く予定の業務は弊社のEPUB系電子書籍商材追加開発と保守対応です。応募方法や募集職種の詳細については文末にまとめておきました。
応募はまだしないけど話しだけでも聞いてやるよ、という方はよろしければ以下イベントに参加ください。弊社および弊社の商材を説明させていただきます。参加費3000円と記載されていますがこちらよりご連絡いただければ無料となります。

10月14日＠飯田橋で会社と商材を紹介させていただきます。

来る2015年10月14日（水）に開催予定の電子出版に関する専門的な技術、販売のノウハウ、独自のコンテンツなどを有する会員社が集結する「電子出版ビューア最前線」（主催：一般社団法人日本電子出版協会、以下JEPA）セミナーにおいて、EPUB3準拠のリフロービューア「超縦書 for Mac」をはじめとする、電子出版の最新ソリューションおよび取り組みについてご紹介いたします。同セミナーではVivliostyle株式会社ともに、電子書籍における最新の縦書き技術などについて講演を行います。もろもろのプレスリリースはこちらを参照ください。

第1部「ワンソース・マルチユースで電子書籍もWebも紙の本も。Webブラウザベース自動組版システム Vivliostyle」

・講師：
　村上真雄((株)ビブリオスタイル　代表取締役社長)
・概要：
　新たな電子出版ビューアとしての Vivliostyle.js：リフローでも、自由なページレイアウトを可能に
　ワンソース・マルチユースで電子書籍もWebも紙の本も作れるCSS組版システムを紹介
　W3C CSSページ組版仕様の標準化の動向、次世代のWeb＋電子出版の標準について

第2部「EPUB3 ビューア超シリーズの紹介と，今後の電子書籍技術について」

・講師：
　榊原 寛（BPS(株)取締役 / 慶應義塾大学 SFC 研究所訪問研究員 / 同環境情報学部 非常勤講師）
・概要：
　EPUB3 ビューア 超縦書/超画像の組版・表現力に関する紹介
　EPUB/EDUPUB/DPUB/アクセシビリティ/CSS 組版など，今後登場する電子書籍関連技術に関するビジネス展開の可能性

概要

日時：10月14日(水)　15:00-17:30　(14:30受付開始)
料金：JEPA会員社：無料、非会員社：3000円(当日持参、領収書発行)
会場：飯田橋：研究社英語センター
主催：日本電子出版協会(JEPA)

BPSに応募してもいいかな、と感じた方はこちらからご応募ください。

各種マーケットへのアプリ公開実績やGitHubやブログ等での活動実績を重視します。 職務経歴や所有スキルがわかるような自己PR書類（形式自由）を作成し、以下フォームより応募ください。書類選考後、次のステップをご案内いたします。

募集職種

スマホアプリ開発マネージャー

iOS/Android アプリケーション開発のマネージメントができるメンバーを募集しています。弊社のマネージャはプログラミング技術が必須です。

スマホアプリ開発エンジニア

iOS/Android アプリケーション開発の経験者を募集しています。

募集要項

さらに詳しい情報はこちらの採用ページからご覧ください。

勤務地

本社（〒160-0023 東京都新宿区西新宿6-20-7 コンシェリア西新宿TOWER’S WEST 2F）
都営大江戸線「西新宿五丁目」駅A1出口 徒歩5分
都営大江戸線「都庁前」駅A5出口 徒歩7分
東京メトロ丸ノ内線「西新宿」駅2番出口 徒歩11分

勤務時間

10:00~19:00（休憩1h）

休日・休暇

週休２日制（土・日）、祝祭日、年末年始、その他（年次有給休暇等）
福利厚生
健康保険（関東ITソフトウェア健康保険組合）、厚生年金保険、雇用保険、労災保険
書籍購入支援、勉強会支援、情報処理技術者資格取得支援、その他資格取得支援

選考方法

経験・資格

学歴不問
応募職種経験者

給与

経験、能力を考慮の上、当社規定により優遇します。
年収の目安：300万~720万

日本電子出版協会(Japan Electronic Publishing Association, JEPA)で、弊社の榊原が、セミナー講演をしました。
「電子出版ビューア最前線 Vivliostyleと超縦書」と題して、最前線のビューアを2つ、紹介しています。

発表の前半は、Webブラウザベースの組版システム「Vivliostyle」です。
レスポンシブなページフローや、雑誌にあるような段組など、画面や文字サイズに合わせて自動的に組版が行われる様子が紹介されています。

後半で、BPSの製品「超シリーズ」の紹介と、今後の電子書籍の技術展望について熱く語っています。

「超縦書」は、最新のCSS3の仕様に従って、縦書きや改行まわりの改良を行い、日本語を美しく表示するリフローEPUBビューアです。
26分あたりから超縦書の開発秘話や、超縦書にのみ搭載の秘密機能を紹介しています。

↓動画はこちら。

・講師：
　榊原 寛（BPS(株)取締役 / 慶應義塾大学 SFC 研究所訪問研究員 / 同環境情報学部 非常勤講師)

↓発表資料と、前半・後半すべての動画はこちらです。
http://www.jepa.or.jp/sem/20151014/