家のPCを漁ってたら、2年前に前社で社内の開発の仕様決定、部品再利用、ディレクションをきちんとするようにしましょう、チームで仕事をするようにしましょう、という主旨の提案をした時の資料が出てきました。 特に社秘に触れるような内容もなく、読み返してみると割とよかったので、会社名やプロジェクト名等わからない形に変更した上で公開します。 前社は研究機関の延長で研究者が会社組織化されたような会社だったので、基本研究者マインドで組織されない一人仕事、案件毎に作りっぱのシステム、メンテナンス性や再利用性、コスト感覚がなかったため、このような資料を作ってそういった意識を紹介する必要がありました。 そういったものが普通にある会社では、レベルが低過ぎて失笑ものの資料だと思いますが、同じように研究機関が出自であるとか、非技術者が主導権を握っていて開発コスト意識がない会社等の抱える内部問題に対してでしたら、それなりに問題に対処資料を作る上でのたたき台になるのではないかと思いました。

1. Kick off meeting of Dev team

2.  Study is an individual match (maybe).
 Business is a team match.
 Make better performance and cost-down by…
 Sharing information and results
 Standardization and Componentization
 Direction

4. Solution A fortress App B castle Web C base
 Battle in many front without sharing…
 Fighting power
 Equipment
 Strategy
 Information

5. Solution A fortress App B castle Web C base
Conquer Solution A
first, then App B!
 Battle with team power, with same
strategy, equipment, and information.

6.  No.
 Good standardization and
componentization breed creativity.
 Tell two examples.

7.  One of biggest internet portal in Japan
 Well known by having many famous geek members.
 Guru of perl, Wizard of Javascript, Lord of ruby…
 Geeks can use many computer languages, but they cannot be a
coding poet without their best native computer language.
 Best way to make “best creativity” by them is allowing to use
their native computer language.
 Problem is…livedoor ID
 Every livedoor service must implement livedoor ID, and it’s
specification changes sometime by changing of marketing
strategy.
 Making and maintaining livedoor ID libraries for many languages
are severe cost.
 Many tests, tests, tests for each change, each languages.

8. Making and maintaining
User
two libraries for same function
are severe cost!
Perl livedoor ID library Ruby livedoor ID library
Login /
Logout
Perl application Ruby application
ID Database
Perl team. Ruby team.
Livedoor Inc.

9.  Solution is: livedoor ID module for Apache
 All of livedoor ID procedure is handled not by
application but by Web server layer (Apache
module).
 Application developer must not care about ID
procedure (like login, logout, cookie handling),
and make effort and creativity only for their
own product.
 Power of componentization!

10. Only one component to be
User
maintained -> cost down!
Apache module for livedoor ID
Login /
Logout
Perl application Ruby application
ID Database
Perl team. Ruby team.
Livedoor Inc.

11.  Making mobile phone web site
 Mobile phone web sites have many local specification.
 i-mode, EZWeb, SoftBank…specification is all different.
 Procedure of getting GPS location
 Procedure of getting subscriber’s ID
 Emoticons
 Character encoding (UTF-8, SJIS)
 Image format (GIF, PNG, JPG)
 Problem is…
 All developers and designers must know all specification
different between each platform.
 Resources (like html templates, images, etc.) are must be
prepared for each platform.

12. SoftBank
DoCoMo KDDI
Each application must consider about
every carrier’s specification
An application Another application
DoCoMo KDDI SoftBank DoCoMo KDDI SoftBank
logic logic logic logic logic logic
Templates must be
prepared for every
platform
Mapion Inc.

13.  Solution is: mobile site contents translator
module for Apache.
 All procedures and translations different between
carriers are handled not by application but by
Web server layer (Apache module).
 Developer must not care of specification differences
between carriers.
 Designer must not care of specification differences, and
not to prepare multiple templates.
 They can care only for their creativity.
 Power of componentization!

14. SoftBank
DoCoMo KDDI
DoCoMo KDDI SoftBank
Apache module for mobile site logic logic a
logic
Developer and designer must not know about each carrier’s specification.
An application Another application
Each page needs
only one template.
Mapion Inc.

15.  Good standardization and componentization
never kill creativity, but give power to
creativity!
 So, we don’t make products not by individual
but by team, and found many points of “same,
and bored functions”, then make them as
component.
 It makes us free from “bored technology”, and
we can aim only core of our creativity.

16.  Laziness (怠惰)
 The quality that makes you go to great effort to reduce overall energy expenditure. It makes you
write labor-saving programs that other people will find useful, and document what you wrote so you
don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also
hence, this book. See also impatience and hubris.
 全体として使うエネルギーを節約するために骨を折るような気性。 怠惰な人は、労力を省くため
にプログラムを書いて、他の人の助けにもなる。 また、同じ質問に何度も答えなくていいように
とドキュメントを整備する。 だからこそ、これが三大美徳の1番目であり、だからこそこの本があ
る。
 Impatience (短気)
 The anger you feel when the computer is being lazy. This makes you write programs that don't just
react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great
virtue of a programmer. See also laziness and hubris.
 コンピューターがのろのろしているときに感じる怒り。 短気な人は、必要に応じて動くだけでは
なく、 先を見越して処理を行うプログラムを書く。 もしくは少なくとも先を見越しているふりは
する。 だからこそ、これが三大美徳の2番目である。
 Hubris (傲慢)
 Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and
maintain) programs that other people won't want to say bad things about. Hence, the third great
virtue of a programmer. See also laziness and impatience.
 神の雷に焼かれるようなたぐいの過剰な自尊心。 人に悪く言われないようなプログラムを書き 人
に悪く言われないようにその整備をするような気性とも言える。 だからこそ、これが三大美徳の3
番目である。
 I think these are some kind of irony.

18. Let’s make I see.
Special
building!
Pipe size
is 30mm
 Everyone share only concept by words
 There are no total design specifications.
 Concept is shared by word, but everyone’s real concept in mind
is quite different.
 Specifications are shared and decided only at interface, so no
one knows total specification of what is building now.
 Sometimes concept is changed, but no one knows what is happened in total
specification by that change.

19. Let’s make OK, then I make
Special total specification
building! from concept.
Work in
harmony
 Concept must be interpreted as specification before developing = direction.
 According to specification, it is guaranteed that every parts of working are worked
together well, without contradiction.
 Even if concept is changed, director reconsider specification to make less impacts and
contradictions.
 Sometimes, direction tasks divided into some parts, and are charged by sub directors.
Total director give “at least” specification to sub director, and details are decided by
sub director.

20.  An army of sheep, led by a lion, is better
than an army of lions, led by a sheep.
 This tells the importance of conducting,
directing in works.
 …This not means “OHTSUKA is lion”, for
confirmation.

22.  Sorry.
 I have experiences of planning componentization
and directing, but no experience to organize a
system from scratch.
 But, I’ll try it. If members share goal of team’s
reconstruction and considering together, it can be
done, I think.
 I will start from considering total direction of some
projects (Solution A, App B), so everyone also
consider about how to make new team and what
to do yourself.

23.  Share, share, share
 Share codes
 Every codies must be put into version control system
(Assembla, Subversion).
 Sometimes see other members code (even if product is
different), and give a comment to it.
 Share discussions
 Every discussion result, decided specification should be
documentation and put into Wiki or so.
 Share schedules
 Don’t make your schedule only on your brain, but make
clear milestones and schedules.
 Then, write them to task control system (Assembla).

24.  Share tasks
 After making milestone, you must divide it to more small tasks,
and record and control it as Assembla’s tickets.
 Knowing every one’s schedules and tasks make us to work in
harmony.
 And, if you don’t have enough power to do your all tasks, then
you can ask someone to do it.
 Share what’s going on
 Make a lunch meeting or so, and share everyone’s what’s going
well now and what makes you trouble now.
 Sending mail not to person but to ML to share conditions of all
projects by every member.
 Share component
 If the code coding now can be a component? Thinking about it
every times.