開発プロジェクトなどでは作業内容をタスク化することが多いです。最初は数多くのタスクがありつつも、徐々に減っていってなくなったタイミングがプロジェクトの完了となります（多くの場合はタスクが追加されていくのですが）。
個人的にお勧めしているタスク管理法が1タスクの見積もりを最大16時間で考えるというものです。今回はそのメリットを紹介します。
1日8時間、マックス2日間で考える
16時間は何かというと、1日8時間労働とした場合にマックス2日ということです。単純に2人日とした場合、朝9時から夜23時まで（1日14時間！）で考えたりしないでしょうか。そういった無理は総じてすぐに破綻しますので注意が必要です。
なぜ16時間をマックスにするかというと、3日間になると途端に読みづらくなるからです。だいたい1人月でできるとは思っても、22日なのか18日なのかは曖昧になりがちです。なるべく読める範囲で積んでいくことでプロジェクト管理しやすくなっていきます。
溢れたらタスクを分割する
もし16時間では間に合わないと思われるタスクの場合、まず分割を考えましょう。何の作業を行うかを考えて、それぞれに分割してしまえばOKです。分割した上で、それぞれ16時間以内で見積もりを作っていきます。
　

ここ数年、定期的にアジャイルは死んだというエントリーが出ます。それに合わせて注目されてるようになっているのがDevOpsです。
これらは本当に言葉遊びでしかなく、名称や形から入ったところで組織の生産性が大きく変わったり、劇的に開発スピードがアップするわけではありません。むしろ形から入ったところは失敗することでしょう。
そこで、なぜ皆さんの組織でアジャイルやDevOpsが失敗するのか考えてみたいと思います。
振り返りをしない
アジャイルではスプリントの最後に振り返りを行います。もちろん、皆さんの組織でも振り返りをしている！というところはあるでしょう。しかし、それが次にどう活かされるのかが重要です。ただ振り返るだけでは意味がありません。
良いところをがあれば明文化した上で次のスプリントから取り入れたり、悪いところは改善して同じ轍を踏まないようにチーム全体で共有しなければなりません。特にユースケースの軽重を見誤っていた場合は今後続くタスクに対して再見積もりが必要になることでしょう。多くの場合、何ができたか、何ができなかったという結果の確認だけで、次に活かされることが少ないようです。
タスクが疎結合になっていない
DevOpsは開発者と運営者がスモールチームになって進めるなどと言います。しかしタスクに関わる人員がスモールチーム外であったり、タスク自体がスモールチームの中で密結合になっていて、誰が状況を把握できているのか分からなくなることがあります。特にスモールチームであれば細かい管理は不要だと考え、ステータスや責任者がいないなどということもあります。
各タスクは明確に属人化し、他のタスクと明確に切り分けるようにしましょう。
　

今回はWebサイトやアプリなど、利用者に対してサービスを提供する中でユーザがストレスを感じる項目について考えてみたいと思います。コンサルティングなどで依頼されるのですが、多くの場合答えは決まっていたりするものです。
なお、Webとアプリで共通するような動きを求める傾向がありますが（Webでぬるぬるした動きなど）、多くの場合Webサイトにおける訪問者は動きよりも適切、かつ高速な表示の方がストレスが少ないという傾向があったりします。
表示が遅い
最もやってはいけない問題です。表示に7秒以上かかると離脱するとよく言われますが、今はデスクトップであれば3秒程度でもストレスを感じるでしょう。モバイルでユーザ自身が襲い回線だと感じている場合でも10秒かかるとストレスを感じます。
Ajaxの場合、転送中はローディングが出せるのでストレスが低いと思われがちですが、実際にはローディングアイコンが長い間表示されている方がストレスが強く感じたりしますので注意が必要です。
画像でコンテンツの高さがずれる
特に広告バナーでDOMの高さが変わるのは問題です。予め画像の高さを決めておけば済む問題なのですが、それを省くと読み込まれる度にコンテンツの高さがガクガクと動きます。これは特にスマートフォンでは強いストレスを感じます。
防ぐ方法としては画像の高さを定めておく他、data-URIでデータを渡してしまうと言う方法もあります。画像は非同期で読み込まれるため、ユーザのネットワーク環境によって表示状態が変わるのを把握しておかなければいけません。
　

システムの負債化というのが度々話題になります。自社サービスはもちろん、クライアント向けのシステムであっても数年経った後のメンテナンス作業というのはとても大変です。最初はそんなことないのですが、一年も経つと劣化が激しくなります。
そこで今回はメンテナンスしやすいシステムを維持するために考えておきたいことをリストアップします。
常に手を入れ続ける
負債化はメンテナンスしなくなった瞬間から発生します。一番簡単に防ぐ方法は常に更新し続けることです。常に新しい状態を保ち続けることで記憶の劣化を防ぎ、システムメンテナンスの勘所を保てるようになります。
ドキュメントで解決すると考えない
ドキュメントさえ書いておけば何年経ってもいきなりメンテナンスできるなどと考えない方が良いでしょう。大抵ドキュメントは読み込まれませんし、それですべてが理解できるなら苦労はしません。
多くのエンジニアがドキュメントを理解しないにも関わらず、他人にはドキュメントで理解するように強要します。100のドキュメントより、分かりやすいコードと十分なテストコード、そしてコマンド一つのデプロイスクリプトの方が良いでしょう。
　

日々の業務でちゃんとメモを取っていますか。その場では覚えられても、1ヶ月もすれば大抵のことは忘れてしまうものです。人の脳はストレージとして考えると性能が悪いので、なるべくメモをとって形に残るようにしておかなければなりません。
そこで今回は主なメモ環境と関連オープンソース・ソフトウェアについて紹介します。
ノート
オフラインで使えるノートをメモ環境としている人は多いでしょう。利点は電気を消費しないので、いつでもどこでも使えるという点です。また、テキストやイラスト、ドローなど様々なオブジェクトを記述できます。
難点は検索性と、蓄積されていった時の一覧性です。古くなったノートを常にとっておくのは不便ですし、情報を探すのも時間がかかります。個人的にはスクラップブックにメモを取ることがありますが、その場の思いつきであったり、アイディアをまとめるなど後々使わないものを記録するのに用いています。
　

今回のテーマはWebGLです。HTML5が普及し、その中でWebGLも使いやすくなってきました。iOS9でもWebGLがサポートされたこともあって、スマートフォンでもWebGLコンテンツが普及しはじめています。
今回はそんなWebGLの使われ方と、関連オープンソース・ソフトウェアを紹介します。
ゲーム
WebGLと聞いて最初に思いつくのがゲームではないでしょうか。元々OpenGLから派生していることもあり、ゲーム分野でのWebGLは期待されています。しかしコンテンツの作成ノウハウが少ないことや、Webブラウザ上で動くゲームに対して高度なものが求められていない状態とあってなかなか広まっていません。
　

ここ最近、海外のカンファレンスに足繁く通うようにしているのですが、今回はパリで開催されたReact Europe 2016に参加してきました。Reactは言わずと知れたFacebook製のUIライブラリですが、React Nativeによってアプリ開発まで対応できるようになったことで一気に利用者が増えている感があります。
　

先月のまとめです。過去分は以下の通りです。

01月


02月


03月


04月

今月はHTML5をはじめとして、Web系のソフトウェアが多かったようです。スマートフォン周りはライブラリが充実してきたこと、iOS/AndroidともにOSの機能が安定したことで進化が若干緩やかになってきた感があります。
Hain - Electron製のランチャー
最近のランチャーは事前にアプリケーションを登録するものではなく、アプリケーションが自動で情報を収集してくれるタイプのものが主流になっています。今回紹介するHainも同じく自動収集型のランチャーです。特徴的なのはElectron製ということです。ElectronということはWeb技術で作られているということです。Windows向けに作られていますが、Electronであれば他のプラットフォーム向けにも提供できそうですね。
Spec.js - スマートフォン/タブレットのスペックを判定
Webサイトへモバイルやデスクトップ、タブレットなどが入り乱れてアクセスするようになると、それぞれに分けて情報配信を行いたいと思うようになります。さらにスマートフォンの中でも使える機能が異なったりして、そのための処理分けが複雑なものになっているかも知れません。そこで使ってみたいのがSpec.jsです。より細かく端末の情報が絞り込めるライブラリになります。Spec.jsのデモです。ユーザエージェントを使って各種機能やスペックを知ることができます。例えばiPhone 6の場合は次のようになります。
長雨 - 日本向けの縦書きTumblrテーマ
Tumblrはコンテンツを簡単にシェアしたり、公開できるとあってとても人気のあるサービスとなっています。さらにテーマがカスタマイズできるとあって、自由度が高さも売りとなっています。今回はそんなTumblrテーマの一つ、長雨を紹介します。特に和なコンテンツを公開していくのに最適なテーマとなっています。長雨はまさに和のコンテンツにぴったりなTumblrテーマで、落ち着いた雰囲気が印象的です。日本語はやはり縦書きが似合うなと思わされるテーマではないでしょうか。
　

今回のテーマは静的CMSです。15年くらい前のCMSというと、PHP+MySQLが基本となっていました。しかしデータベースやスクリプトがボトルネックになったり、システム全体の複雑性を増してしまっていたという問題がありました。
そこで最近では静的なCMSに注目が集まっています。幾つかのパターンがあり、

データベースレス


管理画面だけスクリプト


生成されたHTMLファイルをデプロイ

となります。データベースレスの場合も、テンプレートは簡易的なものでスクリプトはアセットやちょっとした操作を行うだけに留まっています。その結果、テンプレートやコンテンツ側の自由度は高い傾向があります。
今回は静的CMSのメリットと関連オープンソースソフトウェアについて紹介します。
アクセス負荷に強い
静的CMSはボトルネックになる部分が殆ど存在しません。ApacheやnginxといったHTTPサーバやファイルの読み込み、書き込み速度やネットワーク自体の速度くらいでしょう。大量のアクセスが来たとしても、ほぼ問題なくレスポンスを返せるはずです。