• このエントリーをはてなブックマークに追加

2016年6月の記事 9件

16時間タスクのススメ

開発プロジェクトなどでは作業内容をタスク化することが多いです。最初は数多くのタスクがありつつも、徐々に減っていってなくなったタイミングがプロジェクトの完了となります(多くの場合はタスクが追加されていくのですが)。 個人的にお勧めしているタスク管理法が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が失敗するのか考えてみたいと思います。 振り返りをしない アジャイルではスプリントの最後に振り返りを行います。もちろん、皆さんの組織でも振り返りをしている!というところはあるでしょう。しかし、それが次にどう活かされるのかが重要です。ただ振り返るだけでは意味がありません。 良いところをがあれば明文化した上で次のスプリントから取り入れたり、悪いところは改善して同じ轍を踏まないようにチーム全体で共有しなければなりません。特にユースケースの軽重を見誤っていた場合は今後続くタスクに対して再見積もりが必要になることでしょう。多くの場合、何ができたか、何ができなかったという結果の確認だけで、次に活かされることが少ないようです。 タスクが疎結合になっていない DevOpsは開発者と運営者がスモールチームになって進めるなどと言います。しかしタスクに関わる人員がスモールチーム外であったり、タスク自体がスモールチームの中で密結合になっていて、誰が状況を把握できているのか分からなくなることがあります。特にスモールチームであれば細かい管理は不要だと考え、ステータスや責任者がいないなどということもあります。 各タスクは明確に属人化し、他のタスクと明確に切り分けるようにしましょう。  

注意したい、ユーザをイラつかせる10の要素

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

メンテナンス性の高いサービスを維持する

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

2016年05月の人気ソフトウェアまとめ

先月のまとめです。過去分は以下の通りです。 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テーマで、落ち着いた雰囲気が印象的です。日本語はやはり縦書きが似合うなと思わされるテーマではないでしょうか。  

MOONGIFTニコニコ出張所

MOONGIFTのニコニコ動画向け出張所です。

著者イメージ

MOONGIFT中津川篤司

1978年生まれ。オープンソース紹介サイト「MOONGIFT」管理人。プログラマ、SE、ITマネージャを経て、オープンソースのビジネス活用を推進する。現在は独立し、Webサービスのコンサルティング、プロデュースを行う。

http://www.moongift.jp/
メール配信:ありサンプル記事更新頻度:毎日※メール配信はチャンネルの月額会員限定です

月別アーカイブ