| Bottom | Home | Article | Bookshelf | Keyword | Author | Oxymoron |

 

Five customs for software development
Cat: ICT
Pub: 2007
#: 0711a

Kazutoshi Ono (小野和俊)

07407u/18301r
Index
  1. Introduction:
  2. <Custom-1> Visualization of Inspiration:
  3. <Custom-2> Pursuit of usability:
  4. <Custom-3> Adherence to a programmer:
  5. <Custom-4> Avoidance of all-night jobs:
  6. <Custom-5> Work your way instead of blaming:
  7. Fracterization of market:
  8. Innovation Map:
  1. 序文:
  2. <習慣1>閃きの可視化:
  3. <習慣2>ユーザビリティの追求:
  4. <習慣3>現役プログラマーへの固執:
  5. <習慣4>徹夜作業の回避:
  6. 5<習慣5> 責めないで、攻める:
  7. 市場のフラクタル化:
  8. イノベーションマップ:
Why?
  • Mr. Kanzutoshi Ono, who had involved software development using XML & Java at Sun Microsystems in Silicon Valley, then established Appresso Corp in 2000 and became EVP.
  • He was awarded SOFTIC Software Product of the Year in 2002 by 'DataSpider,' a data linkage middleware. connection .
  • He belonged to joint developers of Galapagos project, a tool aiming efficient agenda-driven meeting, which is nominated by IPA as the first uncharted software innovation project. This
  • His unique idea for innovation test and five customs for software development sounds fresh and impressive, which made presentation at Glocom, Int'l Univ. of Japan on Mar. 15, 2007.
  • 小野和俊氏は、シリコンバレーのSun Microsystems 社でXML/Javaを活用してソフトウェア開発に従事し、その後2000年に株式会社アプレッソを設立し、副社長に就任。
  • また2002年にデータ連携ミドルウェアのDataSpiderが2002年のSOFTICソフトウェア・プロダクト・オブザイヤーを受賞。
  • また、2004年にはIPAの第１回未踏ソフトウェア創造事業Galapagosプロジェクトの共同開発者となる。
  • 彼のイノベーション・テストとソフトウェア開発のための５つの週間というユニークなアイデアは新鮮で印象的である。2007年3月15日に国際大学Glocomで講演が行われた。
Key Phrase
キーフレーズ

>Top 0. Introduction:

  • Mr. Taguchi, Chief Editor of Nikkei Computer mentions:
    • Strength of US software development: dynamic idea
    • Strength of Japanese software development: Quality and usability
    • But Japan became a huge importer of software, though there are so many excellent engineers in Japan; why?
    • Probably it is due to a custom of Japanese software industry.
  • There are three major points relating to such custom:
    1. A custom which produces an idea.
    2. A custom to enhance manufacturing ability.
    3. A custom to make favorable workplace environment to realize these.

0. 序:

  • 日経コンピュータの田口編集長曰く。
    • 米国のソフト開発の強み：ダイナミックな発想
    • 日本のソフト開発の強み：品質とユーザビリティ
    • 日本は優秀な技術者が沢山いるが、でも日本はソフト輸入大国である。なぜか？
  • ポイントは３つ：
    1. アイデアを生み出すための習慣
    2. もの作り能力を高めるための習慣
    3. これらを実現するための職場環境を作る習慣

>Top 1. <Custom-1> Visualization of Inspiration:

  • When we get an inspiration, there are background possibilities of new products or services.
    • But usually similar products or services could be found.
    • Value sells in the details.
    • The strength should be instantly visualized before the inspiration vanishes.
  • Visualization of peaks and troughs:
    • Visualize as strength=peak and weakness=trough.
    • Watch peak rather than trough.
    • If there is a peak, consider to take advantage of it.
    • If there is no peak, review from the beginning.
  • Idea of revision:
    • One point specialization type:
      • Focus and specialize a certain peak.
      • Infill troughs at minimum.
    • Plug-in type:
      • Focus only peak.
      • Use other features in the existing product.

1. <習慣１> 閃きの可視化:

  • インスピレーションが湧き上がる時、その背景に新たな製品やサービスの可能性が隠れている。
    • しかし、ほぼ必ず類似するものが見つかる。
    • 価値は細部にこそ宿る
    • 閃きが消える前に、すぐに強みを可視化する。
  • アイデアの山と谷の可視化
    • 強み＝山、弱み＝谷として可視化する。
    • 谷よりも山に注目する。
    • 山があるなら、その活用を考える。
    • 山がないなら、見直す。
  • 修正案の例
    • 一点特化型:
      • 一つの山に集中・特化する。
      • 谷は最低限埋める。
    • プラグイン型:
      • 山だけに注目
      • 他は既存製品を利用

>Top 2. <Custom-2> Pursuit of usability:

  • Advent of the age of rich client:
    • Various modes of expression become available.
    • Coexistence of easy-to-use software and cumbersome software.
  • Maturity of software industry:
    • Not only function but also pleasant feeling is required.
  • Program design and operation design:
    • Needs for implementation tends to come first.
    • Difference between products of the industrial age and those of the information age. The former is easy to be understood, but the latter is useless without manuals.
  • Conjecture of operation:
    • Users understand tools by way of rules which was acquired from past experiences.
  • Persona and scenario method:
    • Persona:
      Hypothetical users who are assumed during the process of designing
    • Everyday scenario:
      Ordinary and frequent actions like keeping diary
    • Essential scenario:
      Not frequent but inevitable actions
    • Edge-case scenario:
      Neither necessary nor frequent actions
  • It is essential to design software for empathic personae, not for faceless actors.

2. <習慣２> ユーザビリティの追求:

  • リッチクライアント時代の到来:
    • 様々な表現方法が実現できるようになった。
    • 使いやすいソフトウェアと使いにくいソフトウェアとが共存する時代
  • ソフトウェア業界の成熟:
    • これからは機能だけでない手触りが重要
  • プログラムデザインと操作デザイン:
    • 実装上の都合を優先しがち
    • 工業時代のツールは使いやすいが、情報時代のツールはマニュアルがないと使えない。
  • ペルソナ／シナリオ法：
    • ペルソナ：
      デザインのプロセスの過程で想定された仮説的なユーザ
    • 日常利用シナリオ:
      通常頻繁に実施される行動
    • 必須利用シナリオ:
      頻繁ではないが必ず実施される行動
    • エッジケースシナリオ:
      必要でもなく頻繁でもない行動
  • 顔の見えないアクターではなく、感情移入のできるペルソナのためにソフトウェアをデザインする。

>Top 3. <Custom-3> Adherence to a programmer:

  • Too early retirement as a programmer:
    • Because of marketing reason, or carrier path?
    • Early retirement of programmers are crisis of manufacturing.
Classification
Ability

Programmer like wind

 A wind-swift programmer who can develop rapidly.
Programmer like woods A team-based programmer who can cope with troubles in a calm manner.
Programmer like fire A passionate programmer like fire who can actively challenge new technology & tools.
Programmer like a mountain An accurate programmer who can pursue stable programming.
  • Note: Sun-Tzu's phrase of ancient China: Swift as wind, calm as woods, moving away as fire, and stationary as a mountain.
  • Each corporation, team, or person should consider such characters of programmers and their posts and carrier path in order to make stronger organization for software development.

3. <習慣３> 現役プログラマーへの固執:

  • 早く卒業しすぎるプログラマー
    • 営業的理由かキャリアパスか
    • プログラマーの早い卒業はもの作りの危機である。
分類
能力
風のプログラマー 風のように迅速なプログラマーで迅速に開発できる
林のプログラマー 林のように冷静でチームに徹し、冷静にトラブルに対処できる
火のプログラマー 火のような情熱的なプログラマーで新技術やツールに挑戦する
山のプログラマー 正確なプログラマーで算定したプログラミングを追求する
  • 風林火山は春秋時代の孫子の句
  • 各企業、チーム、個人はこれらのプログラマーの性格、そしてポストやキャリアパスを検討し、ソフトウェア開発のためのより強固な組織を作るべきである。
  • Cf: Herrman model - 風林火山

>Top 4. <Custom-4> Avoidance of all-night jobs:

  • Reasons to avoid all-night jobs:
    • Symptom-I:
      Eyes become stinging. Sense of exhaustion. Body scent of overnight. Patronizing attitude. Reserved about complaining from outside.
    • Symptom-II:
      Eyelids become spastic. Body turns pale. Gets angry with people who thinks the future. Negative spiral
    • Symptom-III:
      Become twilight state. Feel betrayed, Feel like in a tunnel with no way out.
  • Change the tendency of software industry toward usual all-night working.
    • Battered mind and body hinder creativity.
    • All-night jobs have an long-term adverse effect on person and organization, though they bring short-term effect in efficiency.

4. <習慣４> 徹夜作業の回避:

  • 徹夜をしてはいけない理由:
    • 症状 I 度:
      目がしばしばする。脱力感、徹夜による体臭、恩着せがましい態度、外部からは文句を言えない雰囲気。
    • 症状 II 度:
      まぶたが痙攣、身体が土気色、先のことを考える人に対する怒り、ネガティブスパイラルに陥る。
    • 症状 III 度:
      意識が飛ぶ、被害者意識を感じる、出口の見えないトンネルのような感じ。
  • 徹夜が当たり前という業界体質を変える必要あり。
    • 疲弊した心身は創造力を阻害する。
    • 徹夜作業は、短期の効果をもたらしても中期的には個人・組織に悪影響をもたらす。

>Top 5. <Custom-5> Work your way instead of blaming:

  • It is easier to blame others, but inspiration tends to be erased.
  • Even you are pelted a mudball, you should find out something glittering in it.
    • It is more important to find out possibility than to point out the problem.
  • The basic of work is enjoying.
    • 'Fun place to work'

5. <習慣５> 責めないで、攻める:

  • 他人を責めることは簡単だが、閃きがつみ取られやすい。
  • 泥の塊を投げつけられても、その中に光るものを探せ。
    • 問題の指摘より可能性の発見
  • 仕事の基本は楽しむこと。
    • 楽しみながらの仕事

>Top 6. Fracterization of market:

  • market_fractal
  • Upper part:
    Triangles show growth of the market. If the triangle becomes bigger than the boundary, it means a situation of excessive R&D.
  • Lower part:
    Growth of the market could not be expected any more, filling niche markets just like fractal development.
    On the other hand, the market begins to show some cavity, which means a kind of product obsolescence.

6. 市場のフラクタル化:

  • <左図>
    • 上段：成長市場
      三角形は市場の拡大を示す。
      • 市場そのものの拡大
      • 但しR&D過多も問題
    • 下段：成熟市場
      市場の拡大は望めず、フラクタル的にニッチを埋めていく。
      一方で市場の空洞化（陳腐化など）が始まる。
      • 小さなイノベーションの積み重ね
      • 成熟市場の空洞化

>Top 7. Innovation Map:

  • innovation_map
  • A: Premise for innovation:
    • Which is more evaluated, results or innovations?
    • Which is more evaluation, sucess-failure, or did-didn't?
  • B ->D: Reproduction of innovation
    • Can organizational innovation be produced sustainably?
    • Is the business process regularly reviewed?
    • Are success and unsuccess stories stored?
  • C ->D: Paradigm shift
    • Usually most thick wall for many corporations
    • Are resources for making innovations secured?
    • Is there written policy how to use such resources/
  • A/B/C/D: Communication is indispensable platform.
    • Are there places for flat communications both in office and online?
    • Kneipe and blog

7. イノべーションマップ:

  • <左図>
    • A: ビジネス創生
    • B: 組織力型成長
    • C: 組織力型安定持続
    • D: リーダーシップ型成長
  • A: イノベーションの前提：
    • 仕事の成果が革新的であることが評価基準となっているか？
    • 成否よりも実行したか否かが評価されるか？
  • B→D: イノベーションを再現
    • 組織的なイノベーションを持続的に生み出せるか？
    • 仕事のやり方を定期的に見直しているか？
    • 過去の成功・失敗例が蓄積されているか？
  • C→D: パラダイムシフト
    • 最も厚い壁（ここに悩む企業多い）
    • イノベーションを生み出すためのリソースが確保されているか？
    • リソースの使い方が明文化されているか？
  • A/B/C/D: コミュニケーションは不可欠なプラットフォーム
    • フラットなコミュニケーションをとれる場所がオフィスとオンラインの両方にあるか？
    • 飲み会とブログ
  • 代表例：
  • innovation_test_example

 
Comment
  • The issue of 'Innovation' is always difficult, because a person who talks about innovation is not necessarily innovative, and one who is innovative rarely talks about innovation.
  • イノベーションの問題はいつも難しい。それはイノベーションを語る人は必ずしもイノベーティブでなく、イノベーディブな人はほとんどイノベーションについて語らないからである。

| Top | Home | Article | Bookshelf | Keyword | Author | Oxymoron |