無料ブログはココログ

« 2014年5月 | トップページ | 2014年7月 »

【告知】Redmineを自分たちのツール仕立てよう:7月12日RxTstudy「Redmine Plugin 活用最前線」

Redmineと聞くと障害管理ツールだと思われる方が多いかもしれません。
しかし、「チケット駆動開発 」が広く行われているように、いまやプロジェクトの中央リポジトリとして協調作業基盤になっています。

標準でも多機能なRedmineですが、プラグイン機構も用意されています。プラグインを作れば、自分たちのツールに仕立てることができ、すでに多くのプラグインが開発されています(r-labs Redmineプラグインリスト)。

日本人のプラグイン開発者も多く、今回講演される飯田さんはコードレビュープラグイン等の多くのプラグインを開発されていますし、野田さんもWikiフォーマットの切り替えなどプラグインの開発をされています。

飯田さんは静岡からお越しいただくので、プラグイン開発を実践されているこのお二人の講演を関西で聞く機会は滅多にありません。

ご興味のある方はお忘れのなきよう、ぜひご参加ください。

タイトル:第11回 RxTstudy(Redmineやタスク管理を考える勉強会@大阪)
     「Redmine Plugin 活用最前線」
日  時:  2014年07月12日 13:30〜18:00
会 場 :  JAC Recruitment 大阪支店
     大阪府大阪市北区梅田2-2-2 第二吉本ビルディング
     (ヒルトンプラザウエスト オフィスタワー) 12階 )
参加費:1,000円(講演者の交通費等運営費として)
案内ページ: http://atnd.org/events/51786


iPad mini Retina に Bluetoothキーボードをつなげてみた - 日本語入力の苦悩 -

Bluetooth(以下BT)キーボードを購入して、iPad mini Retineで使っています。いくつかの問題と対策をまとめておきます。

予測変換が邪魔をする

(2015/7/26 追記:新しいiOSでこの問題は改善されました)

日本語を確定した後に予測変換の候補が表示されます。続けて文章を有力する時は良いのですが、誤字など文章の一部を変えようと単語を入力・変換すると続きの予測が出てきて、エスケープキーを押しても消えません。

次に入力する文字が

  • ワードの区切り(スペース、句読点、改行)
  • キーボード(日本語/英語)切り替え

でないと予測し続けます。仕方がないので、表示速度の速いスペースとバックスペースを入力しています。

全角が入力できない

ローマ字変換中にスペースキーを押しても半角スペースしか押せません。ソフトウェアキーボードをかなキーにすると入力できる様ですが、BTキーボード接続中はソフトウェアキーボードは表示されませんので、使えません。

そこで、回避法は以下の3つです。

  • ATOK Pad(ATOK付きのメモソフト)を使う
  • 辞書に登録する
  • コピー&ペーストする

ATOK Padは便利そうですが1,000円以上しますので、辞書で我慢しています。設定->一般->キーボード->ユーザ辞書の下の新規単語を追加...で、カーソルキーのすぐ横にある「‘’」(全角2文字)を「 _」にしています。

変換する際は全角入力時なので読みは全角で2文字以上です。返還後の文字は読みと同じにすると候補の中から選ぶ際にわかりにくいので、わざと読みと異なる文字にしています。

その他

私の使っているMacのOSが古いので、iPadからMacにPagesのファイルを持っていくと、バージョンが低い旨のメッセージが出て読めません。ワードやテキストでやり取りしています。

なお、キーボードは最近出たLOGICOOL ウルトラスリムマグネットクリップキーボードカバーfor iPad mini/Retinaシルバー iK0760SVを狙っていたのですが、利用形態等を考えてチープなものにしました。その件は、またいずれ書こうと思います。


言葉と技術とビジネス、そしてスーパーニッチ

ソフトを他人に作らせる日本、 自分で作る米国」の続編とも言うべき谷島さんの記事「記者の眼 - 150年経っても解決できない大問題に向けた極めてささやかな対策:ITpro」が公開されました。今回はささやかな対策が示されているところが興味深いです。これは、

IT勉強宴会では拙著を出版した意図を話し、出席者の感想を聞いた後、質問に答えた。出席者から「なぜ日本人はグランドデザインを描くことが苦手なのか」と質問が出たが、東京に戻る新幹線の最終発車時刻が迫っていたこともあって「宗教の違いです」と乱暴に答えてしまった。

とされていたことに対して、今回は

「言葉を大切に扱う。」

とされています。大賛成ですが前回と同じように最後の判断は読者に任されているので、言葉について考えました。

技術には論理的思考が必要

技術を積み上げるには論理的思考が欠かせません。論文はもちろんのこと、仕様書においても言葉は重要です。言葉の定義は必要ですし、論理的な矛盾は赦されません。欧米と技術で戦うには言葉を大切にしないと行けません。

しかし、言葉が大切に扱われてもビジネス指向とは限りません。大手企業や国に近いところでは論文や技報が書かれますし、組織内のコミュニケーションも論理的に矛盾のない説明が求められます。しかし、言葉を大切にされているのですが、欧米に比べると新しいビジネスは少ないように思います。

道具としての言葉

では、ビジネスに必要な言葉とは何でしょう。欧米と言うと思い出すのは、ディベート(リンク先はWikipedia)が教育されていることです。言葉を道具として、論理的思考を身につけ、問題を整理し、自分の意見をアピールし、主体性や協調性を身につけます。

そのように書くと教育の違いだと思われるかもしれませんが、それは結果だと思います。本質的な減員は、多様な民族ではないでしょうか?色々な価値観を持つ民族間で、自分が生き残るには、 正確に意見を交換し、主張すべきところは主張しないとi
けないからです(宗教もそのような背景から結果として選ばれたと思います)。

大切なのは、長所と短所を見極めて、それぞれの戦力(戦略、戦術)からゴールを決めることだと思います。ビジネスモデルキャンバスやリーンキャンバスのように、自らの強みを認識することが大切だと思います。

ビジネスの拡大はスーパーニッチを狙え

ここで日本の企業を考えると、論理的な思考はできているし、個人では少ないかもしれませんが、企業の強みと弱みは見極めているはずです。すると、単に言葉を大切にするだけではなく、自身の強みを見極めるだけでもない、何かが必要なのだと思います。

それは、スーパーニッチの市場を作るという戦略ではないでしょうか?かつて論理回路(TTL)の74シリーズなど汎用チップで有名だったTI社が、あるときカスタムチップに舵を切りました。その時の説明では、汎用品では競争になって未来がないのでスーパーニッッチを目指すという説明でした。

同じような話は、世の中が流通在庫を減らそうとする中、豊富な在庫で買う楽しみを実現した100円ショップ、ロングテールをねらったアマゾンなどもあります。当時はニッチと思われたこれらも、その後の発展を見るとスーパーニッチと言えるでしょう。

(個性を生かす発想は、タレントの語源になった聖書のタラントンのたとえに見る事ができます。しかし、上述の100円ショップのほか日本初の企業も多数あり、多様性を認めてアイデアをつぶさなければ、宗教は関係ないと思います。)

このようにピンポイントで顧客ニーズをつかみ、戦略的にビジネス市場を作り出すことが必要だと思います。それは「スーパーニッチ」「買う楽しみ」「ロングテール」といったシンプルな言葉で伝えられます。

おわりに

他国のマネをするなら、前提が異なるのでおかしくなるでしょう。しかし、国民性や地域性を考慮して、ピンポイントで勝てるところで勝負すれば良いと思います。その際には再発明するのではなく、外国で整理された技術から使えるものを活用する。といった発想が必要なのではないでしょうか?

その際に何が我々の強みで何が弱みか?何が使えて何が使えないのか?言葉で説明できないといけません。他所がやっているからうちもやる、うまくいきそうだからやってみる、ではなく、きちんと言葉にして勝てる戦略を立てることが、うまくいく秘訣だと思います。

米国と日本の比較からこの議論は始まりました。しかし、比較して追いつこうとするだけではいつまでたっても同じです。違うことが問題ではなく、違うことを活かス戦略がないのが問題ではないでしょうか。

最後にスクラムでは米国に勝てなくても、チケット駆動によるアダプタブルウォーターフォール開発でなら勝てる分野もあるはず。と言っておきます。


「納品」の意味と「納品をなくす」メリット

倉貫さんの「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル が発売されました。Kindle版が出たか購入する予定ですが、待ちきれないので先に意見を書いておきます。

まず、「納品」の意味を考えてみます。この本の目指す文脈で納品するということは

  • 顧客のビジネスではなく、契約がゴールである
  • 変化に対応しなくても契約を満たせば良い
  • 納品が完了するとソフトウェア開発が終了する

となりがちで、これを無くせば

  • 顧客のビジネスに責任を持つ
  • 社会の変化にあわせてより良いソフトウェアを開発できる
  • ソフトウェアの継続的な改善ができ、満足度を向上できる

となる可能性が高まる。と理解しています。

もちろん、納品のある開発でも提案力があり、柔軟な対応をする、運用を含めてサポートしてくれる、というスタンスは実現可能ですし、顧客からも求められていると思います。

倉貫さんの提案の興味深いところは、

  • リーンスタートアップ
  • アジャイル開発
  • DevOps

といった技術的基盤を背景にしている点だと思います。

また、個人的には

  • 世の中のソフトウェアが一部の極端な大規模システムを除くと、徐々に小規模化している

ことに対して

  • 人月単位ではなく、リソースを細かく調整しうる

という点だと思っています。

以上が、私の勝手な思い込みの意見です。Kindle版が出たらきちんと読んで、感想を書きたいと思います。


[#TiDD] 目指すべき組織文化にあわせたチケット駆動開発

チケット駆動開発ではチケットファーストという考え方があります。チケット駆動開発はRedmineやTracなどITSのチケットでタスクを管理する方法ですので、何かを始める前には必ずチケットを発行しましょうという考え方です。

チケットファーストが実現できていると、チケットによって、予定の共有、タスク管理、経験の蓄積が可能になります。

予定の共有では、チケットは未来を示します。それは上司が立てた計画を示すことや、メンバーが忘れそうな作業や課題を備忘録的に記録してリスクを見える化していることがあります。

タスク管理では、チケットは現在の状況を示します。障害、課題、タスクの作業指示や、自主的なコミットメントの状況を共有します。自動化ツールの実行結果をチケットにしている場合は、チケットを元に担当者を割り当てたり、各自が自主的に管理するでしょう。

経験の蓄積では、チケットは過去を示します。実施した作業の管理者に対するエビデンス(証拠)の場合や、 蓄積された履歴による経緯の確認や過去のノウハウの利用といった現場での利用の場合があります。

これらのチケットの利用方法を、規律を重視するトップダウンと、自律・協調を重視するボトムアップに分類すると以下のようになります。

トップダウン
ボトムアップ
予定の共有
WBS、ガントチャート
備忘録
タスク管理
作業指示
コミットメント
経験の蓄積
エビデンス
履歴

トップダウンによる指示や確認の場合は、内容が明確でメンバー間の競合が起きにくい反面、管理的です。組織の規模が大きい場合や、高信頼性が要求されるなど、規律ある組織活動を目指す場合に有効でしょう。

ボトムアップによる自律的な活動は、内容が整理されていない反面、議論が容易で、協調的です。組織の規模が小さい場合や、新しいアイデアが必要な場合など、自律的な組織を目指す場合に有効でしょう。

この表は検討が容易になるように分類したものですから、いずれかだけを選ばないなくても構いません。管理を重視しながらも起票を自由にすることで、現場の自律的な活動を容易にできます。また、現場の自律性を重視しながらも、時々はチケットの棚卸しをすることで作業漏れを管理することもできます。

まず、現状の問題を見極めて、どのような組織文化を目指すべきかを検討してください。そうすれば、どのようなチケット駆動開発を実施すべきかがわかるでしょう。


[#TiDD] チケットの属性とデータ収集

先日のつぶやきが予想外に評判が良くて驚きました。

前半は1990年代後半のCMMブームのときにプロセス改善について語られていたことですし、後半は開発リポジトリからメトリクスを収集するEPM(Empirical Project Monitor)という環境の説明会でお話ししていた内容です。

これらの背景にあるのは、チケットの属性に限らず、データを収集する際に大切なことで、見える化、改善、成長の視点です。

問題の見える化であること

データを集めようとすると、ついついアレもコレもと思いがちです。しかし、闇雲に集めても意味がありません。見える化はただの可視化でなく、問題の見える化であるべきです。

無駄のないデータ収集には、GQMが有効です。ターゲットとなる問題に必要なメトリクスだけを収集すれば、効率的なデータ収集が可能でしょう。

参考:[#TiDD] ツール・技法の導入法

改善活動であること

問題を見える化している場合でも、それが管理を目的としていたのでは、その効果は限定的です。得られたデータに基づいて、QCD(品質、コスト、デリバリー)を改善しないと意味がありません。

良くない兆候を早期に発見し、早めに対策を打つことが効果的です。後になって大きな手戻りがない様に、フロントローディングしましょう。どのような時に問題が生じ易いかを予め開発者と共有しておけば、手戻りが小さくなるようにプロセスが改善されるでしょう。

参考:[#TiDD] チケット駆動開発をプロジェクト管理の視点だけで考えてはいけない

成長を支援すること

データを収集したなら、その結果だけでなく、分析結果をフィードバックして、組織の成長につなげましょう。技術の導入を優先する場合も(ライトウィング)、より良い社内文化を優先する場合も(レフトウィング)、最適な状態に向けて成長しないといけません。データを分析することでより本質的な解決策を見つけ出し、プロジェクトの成長を支援します。

たとえば、試験項目数が一定の比率以下だとうまくいかないことがわかった場合、単に試験項目数が少ないと指摘するのでは、無駄な試験が増えるだけです。もし、うまくいったプロジェクトを調査すれば、テスト設計に向けて必要な観点を整理していることや、試験項目レビューのチェックリストがあることがわかり、より良い開発の方法がわかるかもしれません。

収集したデータを分析して組織全体が成長できるように活かすことができたなら、無駄なデータを強制することによって形骸化することなく、ごまかしのないデータが収集でき、組織全体で良い方向に向くことができるでしょう。

参考:[#TiDD] チケット駆動開発の「ライトウィング」と「レフトウィング」


« 2014年5月 | トップページ | 2014年7月 »