受託開発と自社開発のあいだ
Developing for Clients
vs
In-House Development
@neotag 2015/09/10
Who am I ?
Naotaka Harada 原田 直貴
- HTML coder
- Markup Engineer
- Frontend Engineer （ちょっとだけ）
- Gaji-Labo inc. Co-Founder
Who am I ?
Worked at
- Mitsue-Links 2006 - 2009
- Naver Japan 2009 - 2011
- Gaji-Labo (Co-founder and CEO)
2011 - present
At Mitsue-Links
What did I do?
At Mitsue-Links
What did I do?
- Built HTML over 10,000 pages
- Developed UI with HTML/CSS for online banking
- Made guidelines
- A lot of pages
- Many domestic clients
At Naver Japan
What did I do?
At Naver Japan
What did I do?
- Naver Search
- "Total search", "Image search",
"Video search", "Theme search"
- "Total search", "Image search",
- Website promotion
- Making Coding Rules and Guidelines
- Many Services
- Many Products
About Gaji-Labo
- Developing for clients
- Supporting Startups
受託開発と自社開発のあいだ
Developing for Clients
vs
In-House Development
Summary
- Only do the important things
- What's important:
Trust, Speed and Quality that's "good enough"
Case: EduTech Service at 2013
- Six months prototyping and running user test
- Measuring effect on learning from giving children tablets
- UI tuning
- Content tuning
- Tuning the "gamification"
Client situation
- Excellent business development
- Great engineer team
- Design is outsourced (only PSDs)
- Didn't hire coders
Client situation
Great engineers have their time taken up doing HTML/CSS
(and it doesn't raise the quality)
Issues with working with a client
- So cutting-edge that they don't trust
an HTML coder - No spec sheet
- Communicating is difficult
Too cutting-edge
- Ruby on Rails
- Backbone.js
- Chapline.js
- Handlebars
- Sass (SASS Style)
* 2013
Too cutting-edge
Standard of technology options - when working with a client
- Difficult to use things that change while you're using them
- Important to use something that can be used continually
- Important to have lots of engineers that can use the tool
- Best to use something relatively old and stable
Too cutting-edge
Standard of technology options- when working
with a product company
- Having short-term goals to achieve
- Using the team's existing skills
- Motivation of the team is very important
Too cutting-edge
Strategies
- Always trying to use wide range of technology (broad but shallow)
- The company does not try to be responsible for everything
- Important to try to do 80 percent and leave 20 percent up to an expert in the team
No spec sheet
- Only working in applications with PSDs
- If you have a problem you talk about it in GitHub
- People who come in later or after the process don’t know who to ask about things
No spec sheet
Using a spec sheet when working for a client
- You have to clearly define what your responsibilities are
- You have to clearly assign responsibility/fault when there is a problem
- The spec sheet is the centre of everything
No spec sheet
Using a spec sheet when working with a product company
- Things you decided yesterday will have already changed today
- If you have time to update the spec sheet you want to improve the service
- The service you’re working on is the centre of everything
No spec sheet
Strategies
- Decide on a “Product Guy”
- Decide on the most knowledgeable person on the team even if you don’t have a spec sheet
- Make a decision log
Tips: KPT
Do Keep/Problem/Try (KPT) as much as possible
- Do a KPT meeting with the team every week
- Able to talk about things before the situation gets bad
- Able to reduce unseen risk by sharing uncertainties and fears
- KPT is a weekly health checkup for the team
Only one example of this
- Build relationships of trust
- Loosely link the process together
- A company working with client services cancontribute to a Product companies.
- Product companies can make good use of clients
Last thoughts:
Next things We are thinking about:
Workshop on how to cooperate between teams
I’m currently looking into whether I can do a workshop on the subject of team cooperation
