無料ブログはココログ

« 2014年9月 | トップページ | 2014年11月 »

軽量、自立、手帳型 iPhone 6 plus ケース(701円)購入記

auのクーポンと買い取りを利用して、iPhone 5からiPhone 6 plus(以下plus)に機種変更しました。

クーポンには何種類かある様ですがauからiPhone 5が発売された際の購入者に送られたファストクーポンだったので、64G->128Gの機種変更にも関わらず割賦の残額程度でした。買い取り金額はau WALLETのポイントになると聞いていたのですが、大手量販店だったからか現金で引いてくれました(ラッキー!)。

plusにしたのはiPhone 6でもGパンの前ポケットに入らないこと、スーツのスラックスの前ポケットならどちらでも入ることから、より見やすく、おじさんにやさしいplusにしました。

ケースの検討

スマホを買ってすぐに必要になるのがケースです。とりあえずはソフトケースで凌いで、自立できる手帳型のケースを探しました。

Amazonで探してみると、多くが3,000円前後するもののデザインが良いので、買いかけました。しかし、よく考えると

  • ケースは消耗品
  • 2年ほどで使わなくなるかも
  • 自立できるものは少ない(最近は増えている様です)
  • 手帳型は意外と重い(plus は172gなのに高級感のあるものは100gを超えるものが多い)

ということで、人柱のつもりで最も安いものを探しました。そして見つけたのがiPhone 6(5.5インチ) アイフォン6(5.5インチ)対応ケース ウェアラブル ファスナーケース ブラウン カード収納ポケット付き スマホケース PUレザー保護 手帳型ケース 横置きスタンド機能 というもの。本体599円、送料込みでも701円でした。

届くまで2週間

「在庫あり」なので、すぐに届くと思っていたのですが、2週間かかりました。社名にJPはついているものの、在庫・発送は中国の様です。

週末に購入するとすぐに発送済みになりました。しかし週明けになると、祝日なので2日ほど出荷が遅れる。いやならキャンセルして欲しい、とたぶん言いたいと思われる変な日本語のメールが来ました。

気になってAmazonの感想を見ると、発送が遅いだの、変な日本語のメールが来ただの、気になる内容が書かれていました。人柱としては興味深いので、そのまま購入することにしました。

2週間ほどたって日本郵便の不在連絡が入っていました。そんなに大きくないのにと思いながら再配達を申し込むと、小さいのに国際小包なのかハンコが必要なようです(102円なのにありがとうございました)。

Ip6case_2

滑りにくく良い感じ

さて実際につかってみると、クッション材が入っているようで指にフィットして良い感じです。電車の中でも、小指で下端を支え、親指で操作、残りの指で裏から支える、という感じで、電車が大きく揺れたりしなければ片手でも代替操作できます。

軽く2度タッチすれば、画面の上半分が下がって操作できますので、ニュースやtwitterを見ている分には、左手をあまり使いません。

Ip6key

横置きスタンド機能

横置きに自立させたると留め具が下になりますので、画面が隠れません。キーボーを上に置くと、スタイリッシュです。iOSの問題でスペースが余分に入ったりしますが、便利に使っています。

Ip6weit

軽い

購入ページに主さが書かれていなかったのですが、計ってみるとplus込みで244.5gでした。ケースだけなら73グラム、軽い方だと思います。

おわりに

以前に買ったiPhone5のケースの様に、接着剤のはみ出しがありましたが、それ以外は気になるところもなく、便利に使っています。

届くまでは色々ありましたが、滑りにくく自立できますので多いに満足しています。柔らかい素材ですので、こすれに弱いかもしれませんが、安価ですので傷つけば買い直すつもりです。

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


[#agileto2014] コーディネートは全体で - Agile Tour Osaka 2014「パタン特集」 -

Agile Tour Osaka 2014「パタン特集」に参加しました。

パタン探し

午前中は「@haradakiroと行くパタン探し」というオプション企画で、伊丹の町を歩きながらクリストファー・アレグザンダーのパタンを探しました。

クリストファー・アレグザンダーは建築家で、心地よいと感じるパタンを、町、建物、施行の3レベルにまとめました。たとえば、小さな広場、南向きの屋外、いっぱいに開く窓、というパタンの組み合わせを聞くと、素人の私でもなんとなく良いイメージがわきます。

このようにパタンを体系化したものをパタン・ランゲージと呼びます。クリストファー・アレグザンダーの書籍名についている冠詞は「a」で、本に書かれたものはアレグザンダーが見つけたものであり、他にもパタン・ランゲージは存在するという意味だそうです。

ワークショップ&ディスカッション

懸田さんのワークショップでは、謎のAさんが健康的な生活が取り戻せるように、

  • 力の衝突(フォース)を 明らかにする
  • 解決策とパタンの名前を考える
  • スケールで分類する
  • スケールの異なるパターンを組み合わせて素敵な未来を 描く

といった作業をしました。ここでスケールという概念が出てきて、アレグザンダーが3つのレベルにまとめていた事が思い出されました。

Posauneさんの講演は「テスト自動化のパタンランゲージ」でした。以前聞いた内容でしたが、ワークショップのあとで聞くと、パタンを間連付ける事の重要性を感じると共に、「スケール」のない事が気になりました。

ディスカッションでは小林サンからの午前中の報告のあと、原田サンが登場。

  • パタンとは対立のフォースをそらすもの
  • 良いパタンはあたり前のもの
  • パタンはソリューションカタログではない

というお話がありました。

おわりに

対立するフォースをそらせるパタンを関係付け体系化したものがパタンランゲージです。パタンにはレベルがあり、それらを組み合わせて、何を、なぜ、どのように、作るかを考えます(このように物事の対立を前提に解決する点は、TOCfEに似ていると思いました)。

ソフトウェアでパタンというと、最初に思い出すのはデザインパターンです。でもこれは、実現したいものの一部に過ぎません。実現する際に立ちはだかるフォースを避けてより良いものを実現するには、アーキテクチャや組織のパタンなども組み合わせる必要があります。

ソフトウェアを開発する技術者は「プログラマ」と呼ばれる事が多いですが、ソフトウェアを実現する行為は、プログラミングのレベルを超えたコーディネートだと思います。開発に関わる体制、プロセス、アーキテクチャ、もちろんプログラム、に存在するフォースを利害関係者と調整し、進行し、実践するからです。

それは、対立する課題からよりよい解決策を求める作業です。 パタン・ランゲージの視点で見ると、我々の仕事のゴールは色々なレベルのパタンを組み合わせて、より良いシステムを作り上げる事だと思います。

そこで技術者に求められるのは、より良いソフトウェアを実現できるように、会社間、組織、モチベーション、技術、など複数のレベルのパタンを常に洗練し、パタン・ランゲージとして用意することです。複数のレベルのパタンをコーディネートして、より良いシステムを実現することが必要だからです。

Agile Tour Osaka 2014に参加して、特定のレベルを最適化するだけでは不十分だと考えるようになりました。全体をうまく構成できるように、広い視点を持って、パタン・ランゲージを用意できるように心がけたいと思います。

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


契約から「納品のない受託開発」の仕組みを考える

先日のSEA関西のパネルは多くの質疑応答をこなして、「納品のない受託開発」が何であるかは理解できました。しかし、2時間では時間が足りず、あまり深い議論ができませんでした(司会の私の責任です。すみません)。

人の話を理解するだけでなく、そこにある原理が自分の知識体系に組み込まれなければ、応用ができません。ワークショップの様に実践することでわかることもあると思いますが、それは体感にすぎません。いわば言われた通りのコーディングで、本格的に動かすまで正しいかどうかもわかりません。

やっぱり、あーでもない、こうでもない、と色々考えないとわかりません。そこで役に立つのはコードリーディングです。様々なスタイルや似て非なる色々なコードを読むうちに、どんなコードがわかり易いとか、保守性が高いとか、どうしてこう考えたのだろうとか、考えることができます。

そこで「納品のない受託開発」の仕組みを契約の側面から考えてみます。

請負開発

コトバンクによれば「依頼を受けた者(請負人)がある仕事を完成することを約束し、その注文者がその仕事に対して報酬を支払う契約を「請負契約」といいます。」とされていて、完成物を引き渡す、いわゆる納品までが開発期間になります。

あらかじめゴールを決めて契約するのですから、ゴールの解釈が広くなると発注側(顧客)が得に、ゴールの解釈が狭くなると開発側が得になり、利害が対立します。そこで、受注側(開発)は新たな提案はもちろんのこと、なるべく仕様変更を受け入れず、より簡単な実装にして利益を増やそうとする「ディフェンシブな開発」(kuranukiの日記)が行われがちになります。

もちろん、継続案件があれば開発側は目先の利益だけを考えることができずに、良心的な対応をするでしょう。とはいえ、予想外の問題が発生すると利益を確保しないといけないので、責任の所在について顧客と開発側が対立してしまうことになります。

準委任契約と時間精算

そこで、リスクの高いプロジェクトや、見積もりが困難なプロジェクトの上流では、準委任契約によるシステムエンジニアリングサービス(SES)が行われます。

この場合も、発注側は同じ金額なら多くの時間を作業してもらった方が得ですし、受注側は作業時間が少ない方が得になり、やはり利害が対立してしまいます。

そこで、標準的な作業時間を幅を持たせて決めておき、その幅を超えれば時間単位で精算する方法がとられます。

請負契約の場合は瑕疵担保責任があるので、一定期間は開発側の責による障害を解決しないといけません。しかし、準委任契約では瑕疵担保責任はなく、リスクは発注側が持つことになります。

その点は開発側が有利なのですが、準委任契約は多くの場合は期間契約ですので、顧客の要望が満たされなければ契約を中断することができます。

納品のない受託開発

納品のない受託開発は月額固定の費用で、顧客との合意を取りながら開発を行います。納品のない受託開発を既存の契約に近い表現を探すと、時間精算のない準委任契約、常駐のない準委任契約といえるでしょう。

時間精算のない準委任契約をソフトウェア開発で探すとコンサルタント契約が挙げられます。時間でなく訪問回数に応じて費用を精算するもので、時間精算を緩くしたものと考えて良いものです。しかし、常駐こそしていないものの拘束されることで費用が発生していますので、費用の合理性があるものの成果に応じた報酬とは言い切れません(成功報酬契約も可能ですが、顧客が成功をコントロールできるので、うまくいかない場合もあるそうです)。

一方の常駐のない準委任契約をさがすと、リモートでの運用契約があります。運用にはこれまで常駐するものが多く、時間や日、あるは常駐人数などで契約していました。しかし最近は、クラウド上の監視対象のサーバ数によって契約する形態があります。

ここで納品のない受託開発と比較すると、一定の成果を期待して定額を払うところは似ていますが、リモートの運用では成果が明確であるのに対して、納品のない受託開発では決まっておらず、常に合意を得ながら進めていく点が異なります。

ここで、時間精算のある準委任契約を思い出してください。時間精算によって機能を詰め込もうとする顧客に制限を加えていたのですが、納品のない受託開発では抑えが利きません。これを解決する秘密は、以下の3点だと思います。

  • 顧客のビジネスに入り込んでいるので、本当に求めているものや必要なものを知っている
  • 力技に頼らない代替手段を提案できる技術力がある
  • 対等の関係になれるような仕事を選んでいる

これらを実現することで、顧客との約束を時間ではなく成果とでるのでしょう。そして技術力によって時間を生み出して、技術者が技術者として勉強し、より高度な技術を提供できるような環境を整えるられるのだと思います。

価値創造契約

ここで、同じように月額定額のアジャイル開発でありながら、苦戦しているらしい 永和システムマネジメント さんの価値創造契約と比べてみます。

顧客の価値という点を考えると、価値創造契約はソフトウェアおよびその利用(サービス)を価値としていて、契約終了と共に利用ができなくなります。一方の納品のない受託開発はより顧客のビジネスに関わっていて、戦略的なソフトウェアの実現(開発作業)を価値としている点が大きく違います(開発作業を請け負うのでソフトウェアは顧客のものです)。

ソフトウェアの利用ができなくなる点は大きいと思いますが、ソフトウェアは長期に使うものですので、それだけで苦戦の説明になりません。それ以外に、なにかボタンの掛け違えの様なものがあるのではないでしょうか。それぞれのビジネスモデルがどのように構築されたか、そのプロセスが大きく関わっているように思います。

ビジネス構築のプロセス

納品のない受託開発のはじまりは顧客からの要望だったそうです。手探りですすめながら「いける」という感触を得て、始められた様です。リーンスタートアップのようにコアなモデルからボトムアップに発展させることで、確実な仕組みを手に入れられたのでしょう。

これに対して価値創造契約は社内コンテストのアイデアを元に、すすめられたそうです。アイデアからビジネスに持っていったので、トップダウン的な明確さがある反面、顧客のニーズにあわせて方向転換がやりにくいという弊害があるのかもしれません。

これは、営業のpushとpullにも繋がります。倉貫さんの知名度と人脈をベースに、要望を受けて仕事を選びながらビジネスをする納品のない受託開発に対し、物量的なアウトバウンドな営業を必要とする価値創造契約が苦戦するのは無理もないと思います。pullを上回るような強力な価値の提供が必要だと思います。

おわりに

「納品のない受託開発」は少し難しいビジネスモデルです。倉貫さんにとっては納品は大きなキーワードだったかもしれませんが、契約の視点では大きなポイントではなく、開発の考え方や組織づくりに効果があるからです。

また、書籍を読んで一通りのお話を聞くとなるほどと思うのですが、それを前提が異なる普通の職場に活かすことは難しいでしょう。

そこで、実践されてきたプロセスに注目すると、それがリーンスタートアップの実践であることが見えてきます。最もコアな価値を提供できるMVPの実践から、必要に応じてピボット(方向転換)して、ビジネスを組み立てられているのです。

日々の仕事の中で気付くビジネスの問題、それをどう組み立てて実践するか、参加者のそれぞれに宿題をいただいたように思います。

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


[#Redmine #TiDD] 日経SYSTEMSにRedmineの紹介記事を寄稿しました

Photo_2

現在発売中の日経SYSTEMS 2014年10月号11月号に寄稿しました。

「現場でホントに役立つツール PM・運用編」のRedmineの回です。10月号は障害管理を中心にRedmineの基本的な使い方を、11月号はタスク管理とチケット駆動開発、プラグイン、REST APIとスマホクライアント、メール連携を説明しました。

紙面の都合で全体にかなり端折って説明しましたがページが足りなくなり、用意したまとめが入らなくなってしまいました。せっかく書いたものですし、謝辞もなくなってしまって申し訳ないので、11月号のまとめを一部修正して公開します。興味を持たれましたら、大手書店等でお買い求めください。


Redmineのより進んだ使い方として、タスク管理ではガントチャートでRedmineの構造を、チケット駆動開発ではプロジェクトの状況に合わせた4つの方法を説明しました。また、プラグインやAPIなどRedmineの機能拡張や外部連携についても説明しました。


Redmineを導入する場合、全体の効率化と組織文化を育てることのバランスがポイントになります。Redmineはプロジェクトの情報を一元管理するリポジトリです。障害情報やバージョン管理ツールの情報など、開発に関連する様々なデータをチケットやWikiに紐付けることで、情報共有が効率化されます。

しかし、それが旗ふり役の独りよがりであったり、Redmine導入の負担でモチベーションが下がって、開発効率が下がるようでは意味がありません。プロジェクトの関係者全員が、自分の問題として検討して、プロジェクトの状況を改善していく文化を醸成できれば、より多くの効果が得られるでしょう。


今回紹介したRedmineの使い方はごく一部です。ソフトウェア開発以外にも、メール対応やIT全般統制(赤羽根さんの論文スライド)、受発注管理、創薬、結婚準備にいたるまで、様々な使い方があります。独立行政法人IPAが開発した定量的プロジェクト管理ツールEPM-Xのメトリクスの収集に利用されていて、ソフトウェア工学分野も期待できます。


Redmineはオープンソースソフトウェア(OSS)です。OSSを選択する場合に大切なことは継続性です。そのOSSが継続的にバージョンアップされていることはもちろんですが、中心的な開発者・支援者やユーザ、コミュニティ、周辺のソフトウェアやサービスが存在しているかも重要です。


Redmineは開発言語のRubyやフレームワークのRuby on Railsの大きなバージョンアップを乗り越えて、継続的に開発されています。また、SaaS、プラグイン、クライアントなど、有料のサービスやソフトウェアも増えています。

もちろん、ユーザも増え続けていてコミュニティも活発です。東京にはredmine.tokyo(旧品川Redmine、facebookTwitter)、大阪にはRxTstudy(Redmineやタスク管理を考える勉強会@大阪、facebookTwitter)というコミュニティがあります。


この記事でもこれらのコミュニティで教えていただいた内容も多く、 末筆ながら感謝の意を表します。


なお、今回の寄稿のねらいについて、2014年11月15日(土)開催のredmine.tokyo 第7回勉強会でLTさせていただきます。ご興味のある方はご参加ください。

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


« 2014年9月 | トップページ | 2014年11月 »