Innovation in Software Development Process by Introducing Toyota Production System

Transcription

1 Innovtion in Softwre Development Proess y Introduing Toyot Prodution System V Koihi Furugki V Tooru Tkgi V Akinori Skt V Disuke Okym (Mnusript reeived June 1, 2006) Fujitsu Softwre Tehnologies (formerly Fujitsu Prime Softwre Tehnologies [PST]) hs een onduting tivities sine 2003 to improve produtivity using the Toyot Prodution System (TPS). An gile development proess nd store mngement method were introdued to implement the si onepts of TPS in the IT softwre field. We inluded the si onepts of TPS (elimintion of mud [wste], heijunk [leveled prodution], nd jidok [utomti detetion of norml onditions]) nd visul mngement in the gile development proess nd store mngement method s prtil tehniques. PST introdued this gile development proess to its softwre development proess nd the store mngement method to support its mintenne proess. As result, PST hieved signifint improvements in oth proesses nd in its orgniztionl limte. This pper introdues the TPS onepts employed in the gile development proess, desries how heijunk is used in the store mngement method, nd exmines the effets of implementing gile development nd store mngement t PST. 1. Introdution Fujitsu Softwre Tehnologies (formerly Fujitsu Prime Softwre Tehnologies [PST]), following the urst of the IT ule in 2000, introdued the Unified Modeling Lnguge (UML) nd intensified its projet mngement to improve the produtivity of softwre development. These efforts improved produtivity, ut not enough to overome IT defltion. To rek through this sitution, the Toyot Prodution System (TPS), 1) whih hs lredy proven its effetiveness in hrdwre mnufturing, ws introdued experimentlly to the softwre development proesses. This mens tht the onepts of TPS suh s the elimintion of mud (wste), heijunk (leveled prodution), jidok (utomti detetion of norml onditions), nd visul mngement re prtied in the softwre development proesses. To implement these onepts, the gile development proess (herefter lled gile development) nd the store mngement method, whih employ TPS, hve oth een introdued. This pper desries gile development nd store mngement nd the effets of their introdution. 2. Agile development nd proess improvement In generl, gile development is regrded s the extreme opposite of wterfll development. In wterfll development, eh proess (e.g., plnning, nlysis, design, implementtion, nd testing) is performed only one nd in sequene. In gile development, series of these proesses is repeted in wht is known s repetition development (Figure 1). Compred to the repetition style of gile development, wterfll development hs the following drwks. 1) Wterfll development ssumes tht no hnges will e mde hlfwy through FUJITSU Si. Teh. J., 43,1,p (Jnury 2007) 139

2 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System Time Plnning Anlysis Design Implementtion Test Sope () Wterfll development Time Plnning Anlysis Design Implementtion Sope () Agile development Figure 1 Comprison of wterfll nd gile development. the plnning; therefore, the dditionl person-hours required for trk k will e signifint if ny hnges re mde. 2) Bugs re deteted t the review of eh proess end nd during the test of lower proesses. If ny ugs re deteted, the dditionl person-hours required for trk k will e sustntil. 3) If the qulity of design nd implementtion re not good, the person-hours needed for testing (deugging) will inrese. 4) Operle softwre nnot e otined until the finl proess is ompleted. Agile development hs the following dvntges to offset the issues inherent in wterfll development. 1) Anlysis, design, implementtion, nd testing re repetedly performed in smller units; therefore, it is more tolernt of hnges nd dditions to the plnning (requirements). 2) To omplete the required implementtion nd testing requirements, operle softwre n lwys e otined, even if the sope of the implemented fetures is smll. 3) By repeting the regression tests every time smll unit is implemented, filures n e Test deteted t n erly stge. Unlike other industril produts, softwre produt is not ontinuously mnuftured. Also, in wterfll development, the series of proesses is performed only one during the development period. Therefore, in mny ses, lessons tht were lerned from the suesses nd filures tht ourred during development will not e pplied to the next projet. Consequently, it is hrd to exeute the pln-do-hek-t (PDCA) yle. On the other hnd, with gile development, series of softwre elements re developed repetedly y lmost the sme people using the sme mteril nd in the sme environment. Therefore, the lessons lerned from the development proesses will likely e used in the following development proesses. As result, there re opportunities for the PDCA yle to e exeuted. This is the true dvntge of gile development. 3. Agile development nd onept of TPS Agile development inludes mny of the TPS onepts. The following re some exmples. 1) Pull system The onept of the pull system is emodied in the eptne test of gile development. The eptne test tests whether the softwre meets the ustomer s requirements. This test drives the implementtion, whih is very different from the sitution in trditionl development, in whih the inoming speifitions from the upper proesses drive the implementtion. 2) Just-In-Time The Just-In-Time onept prioritizes the ustomer s needs nd implements the prioritized funtions sequentilly. Also, this is desried s You Aren t Going to Need It (YAGNI). 3) Visul mngement In gile development, mirroring, whih is prtie of Extreme Progrmming (XP), emodies the visul mngement tehnique, whih mkes projet s sttus self-explntory using nlog 140 FUJITSU Si. Teh. J., 43,1,(Jnury 2007)

3 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System medi nd enourges muh fster feedk in the tion level. 4) Heijunk/multi-skill development Multi-skill development, whih gives eh worker multiple work skills, nd heijunk, whih redues eh worker s working hours, re the priniples of gile development. 4. Agile development In gile development, the development period is divided into units lled itertions. An itertion is period in whih proesses re exeuted to develop the sope of funtion. The first itertion strts t the eginning of development. At this point, the prioritized ustomer requirements re lerly indited to the development tem, whih implements them ording to their priority. Also, the end dte is deided when the itertion strts. The time period is typilly from one week to month. Even if the requirements hve not ll een implemented, the end dte is given priority. Any requirements tht hve not een implemented (lower priority) re postponed. If ll the requirements hve een implemented efore the end dte, new ustomer requirements n e worked on. Therefore, lthough ll of the funtions might not e implemented s originlly estimted, the provision of outome will not e delyed. Therefore, the delivery dte is given priority over the funtion sope. One the itertion is terminted, even if ll of the ustomer requirements hve not een implemented, the high-priority funtions will hve een implemented, nd operle softwre n e output. As soon s the first itertion is terminted, the seond itertion egins. At this time, s with the initil itertion, the prioritized ustomer requirements nd the operle softwre from the initil itertion will e entered. This itertion is often set to the sme length s the initil itertion. Repeting the sme time period is n effetive wy for the tem to lern the development rhythm within the time frme. When the seond itertion is terminted, the operle softwre is output in the sme wy s in the first itertion. This softwre hs the funtions tht were implemented during the seond itertion s well s the initil funtion sope. As eh itertion is exeuted, the softwre is developed nd the implemented sope is extended. Also, the softwre n e relesed to the ustomer whenever n itertion is omplete. Figure 2 shows the development proedure within n itertion. The ustomer requirements entered when the itertion strts re sorted in simple, single funtion lled story. It is preferle if the ustomer retes story on their own; however, in mny ses, role lled the okykusm (ustomer) proxy is set within the development tem. The ustomer proxy onsists of one or more tem memers who represent the ustomer s interests. The memers who est understnd the ustomer s position undertke this role, nd the requirements of stories lwys hve top priority. The reted stories re divided into units lled tsks t stff meeting lled plnning meeting (or plnning gme). A story is funtion unit from the ustomer s viewpoint, nd tsk is n implementtion unit from the developer s viewpoint. In other words, the plnning meeting n e desried s the design tsk. This plnning meeting is held when the itertion strts. Tsks tht hve een divided t the plnning meeting re ssigned to the developers t the stnd-up meetings (rief ll-stff meetings) tht re held every morning. The tsks re often ssigned ording to the developers own hoies rther thn s instruted y the mnger or supervisor. The developers re required to understnd the entire development piture nd determine wht should e done nd tke tion on their own inititive. Also, when the pir progrmming phse is exeuted, the pirs will e deided t the stnd-up meeting on tht dy. Idelly, the pirs re FUJITSU Si. Teh. J., 43,1,(Jnury 2007) 141

4 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System Itertion (out 2 weeks) Feedk to proesses Okykusm (ustomer) proxy Story Plnning meeting Tsk Tsk Tsk Tsk Stnd-up meeting Pir progrmming Pir progrmming Pir progrmming Pir progrmming Code Test Code Test Code Test Code Test Aeptne test Retrospet Completion of story Story mster All developers All developers All developers Dily repetition Dily heking t stnd-up meeting Figure 2 Agile development proedure. swithed every dy. Pir swithing enourges the spred of knowledge nd therefore n provide higher lerning effet within the development tem. Also, y mking the progrm ode nd omponents ville to the whole tem insted of lloting it to speifi persons, unlned intelligene out the softwre development n e prevented. The test progrm is reted t the sme time s the ode is developed y the pirs. The developed progrm is tested y this test progrm, nd the tsks re ompleted. When ll of the tsks tht ompose story re ompleted, the ompletion of the story is tested y the eptne test, whih is test progrm reted y the ustomer or ustomer proxy. From nother viewpoint, this is test proedure in whih the riteri for ompletion re ler. The story is ompleted y pssing the eptne test. Within n itertion, proedures from the implementtion of the tsks to the ompletion of the story y the eptne test re repeted dily. At the end of n itertion, meeting lled the kiko (retrospet) is held, in whih ll the developers prtiipte. In the kiko, ll of the detils relevnt to the itertion re reviewed, for exmple, the oding, testing, nd meetings nd even the ir ventiltion, lighting, nd telephone mnners of tem memers re reviewed. Then, the stff do the following. 1) Review the tivities tht will ontinue in the next itertion 2) Disuss ny prolems tht ourred, find their solutions, nd onfirm their implementtion in the next itertion 3) Reh n greement out new efforts tht must e mde in the next itertion. Bringing the resulting feedk from this kiko meeting into the development proess drives future improvement. 142 FUJITSU Si. Teh. J., 43,1,(Jnury 2007)

5 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System 5. Implementtion of gile development The following is n exmple implementtion 2) of gile development. In this exmple, prototype system ws developed for the mnufturing industry with development period of out two months. The system is n infrstruture We pplition tht uses server-side Jv (servlets). There were nine memers in the development tem. The following lists the mount of softwre-development experiene nd ojet-oriented development experiene (in tht order) in yers for eh memer. Memer X: Trker nd ustomer proxy: 9 nd 8 Memer Y: Mnger nd oh: 5 nd 3 Memer Z: Coh: 3 nd 2 Memer A: Developer: 3 nd 1 Memer B: Developer: 3 nd 1 Memer C: Developer: 0 nd 0 (new employee) Memer D: Developer: 2 nd 1 Memer E: Developer: 4 nd 1 Memer F: Developer: 14 nd 7 Memers E nd F joined the projet t the end of July. Also, none of the stff hd previous experiene of gile development. The introdued prties of XP were s follows. 1) Itertion (itertive development) At the eginning, five-dy itertion ws used s tril nd then two-week itertion ws set three times. 2) Kiko (retrospet) 3) Visul mngement (mirroring) Story rds, tsk rds, nd urndown hrt (grph of numer of klogs) were posted on wll so the developers ould hek the progress in rel-time. 4) Pir progrmming 5) Co-ownership of soure ode 6) Coding riteri 7) Stnd-up meetings 8) Continuous onsolidtion 9) Unit testing 10) Aeptne testing 11) Customer proxy 12) Reftoring Test-driven developments were not performed euse, sine this ws the first gile development for the stff memers, ertin tehnil risks hd to e voided. 6. Evlution of gile development The evlution of the gile development onduted in the exmple implementtion desried in the previous setion is detiled elow. The viewpoints of this evlution re produtivity, qulity, ost, delivery dte, nd the opinions from developers. 6.1 Produtivity The produtivity in eh itertion nd the produtivity in the entire development re indited elow using produtivity index. note) Itertion 0: Itertion 1: Itertion 2: Itertion 3: Averge throughout: The produtivity t the eginning of the development ws 24% lower thn PST s stndrd produtivity; however, it ws improved t the lst stge nd indited 26.8% inrese throughout the gile development. The resons for this produtivity improvement re exmined elow. 1) The funtions were implemented ording to their priority so tht unneessry funtions were not implemented. Also, stories were divided into tsks nd then developed one y one (single-flow prodution) so tht wste (i.e., untested progrms) ws eliminted. In ddition, euse of the existene of the ustomer proxy, no intermedite output suh s unrequested douments ws reted. note) A omprison of the numer of soure ode lines written y eh memer per month ginst stndrd PST vlue FUJITSU Si. Teh. J., 43,1,(Jnury 2007) 143

6 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System 2) Beuse of the pir progrmming, the neessry informtion ws lwys ville for the developers. Also, y o-owning the soure ode, ny developer ould modify ny progrm. This prevented lgs due to modifitions y other developers, whih tends to our during trditionl development. 3) The dily progress ws heked in the stnd-up meeting every morning, whih enled the tem to provide timely response to lteny nd optimize the tsk shedule. 4) The kiko meeting held for eh itertion implemented the PDCA yle within the development proess. This meeting enled the development tem to shre their prolems nd give feedk for the next itertion. The ove prties re onsidered to improve produtivity. 6.2 Qulity Agile development is not like wterfll development, whih is divided into proesses suh s plnning, nlysis, designing, implementtion, nd testing, nd therefore the qulity nnot e verified y trking down the ourrene of ugs t eh proess. However, developers re finding tht gile development promotes high qulity. 1) With the pir progrmming, developers n sk questions or disuss their onerns t ny time. Also, the progrm n e reviewed t ny time, whih drmtilly suppresses the retion of ugs ompred to the trditionl method. 2) The utomted regression tests revel ugs within dy. Also, the progrm ode is immeditely tested with the test progrm tht is reted t the sme time nd then deugged. 6.3 Cost Figure 3 shows the overtime hours of the developers in eh itertion. As the itertion preedes, the differene in overtime hours etween developers dereses, whih mens heijunk is tking ple. The heijunk of the working hours is ffeted y the degree of multi-skill development of the developers. If ny developer n work on ny jo, the work hours n lso e leveled. Figure 4 shows the ommitments of eh developer to the progrms s mesured using the ommitment log of the Conurrent Versions System (CVS), whih is onfigurtion mngement tool. As n e seen, eh developer hd multiple ommitments, whih indites tht multi-skill development ws ourring. In the trditionl method, eh developer is in hrge of omponent or progrm, whih, 4 Itertion 0 Itertion 1 Itertion 2 Itertion Averge overtime (hours) A B C D E F CVS ommitment rtio (%) A B C D E F 0 E nd F joined t the end of July 0 Developed progrms Figure 3 Developer s overtime hours in eh itertion. Figure 4 CVS ommitment rtios of developers. 144 FUJITSU Si. Teh. J., 43,1,(Jnury 2007)

7 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System onsequently, hs the idiosynrsies of the developer. Co-ownership of the soure ode nd pir progrmming help implement multi-skill development. No one is ppointed to work on speifi progrm: eh dy, the developers work on different progrm nd with different prtner so tht the experiened developers pss on their knowledge. This mehnism filittes multi-skill development. In this gile development, ompred to the previous wterfll development of similr system, the ost rte ws redued y 16% (ost redution). 6.4 Delivery dte Figure 5 shows the trnsition of the numer of ustomer requirements nd implemented requirements in this gile development. Fifty perent of the ustomer requirements were ler sine the eginning of the development, nd the reminder were reeived spordilly during the development. Also, mny requirements disppered from the list. New requirements from the ustomer were implemented in the order they were reeived, nd ll the requirements were implemented y the relese dte. The verge time etween the rrivl of requirement nd its implementtion ws one week. In ft, on verge it took s little s one week to implement requirement fter it ws reeived. This rpid rte of implementtion ws hieved due to the prties of ustomer proxy, itertion, nd stories. The requirements were prioritized, the implementtion of single-flow prodution shortened the delivery dte, nd the regression tests were performed in n environment of ontinuous integrtion. Inluding reftoring, we think we hve formed development proess tht ensures qulity nd lso llows dditionl Ourred stories Extint stories Digestion point Cumulted stories Burndown hrt Point Itertion 0 Itertion 1 Itertion 2 Itertion 3 Ourrene of requirements Cumulted requirements Digested requirements (Bk log) Implemented requirements Delivery dte Relese dte 7/5 7/12 7/26 8/9 8/23 8/27 Extintion of requirement Month/Dte Figure 5 Trnsition of ustomer requirements nd implemented requirements. FUJITSU Si. Teh. J., 43,1,(Jnury 2007) 145

8 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System requirements to e implemented. 6.5 Opinions from the development memers The following re some of the opinions of the development memers in the gile development projet. 1) In the pst, when I eme overloded, I ws under pressure nd did not wnt to ome to work. However, this time, even if I ws overloded, I did not feel under pressure. 2) It ws esy to see the quntity of work per dy t the tsk llotions in the stnd-up meetings. 3) It ws good to hve oh. We ould sk the oh questions t ny time. 4) The tmosphere of the entire tem hs een good, nd the memers motivtion remined high until the end of the development. 5) The pir progrmming system prevented the work from eoming stuk. 6) During the pir progrmming, we worked while tlking out things we knew or did not know. So eventully we lerned new things. 7) Due to the pir progrmming, the skills of the tem quikly improved. 8) The pir progrmming redued mistkes nd filitted effiient work. These quotes show tht the developers kept their motivtion high nd were le to work with stle mentl stte during the entire development period. 7. Expnsion of gile development This exmple of gile development desried in the previous setion ws reltively smll development for prototype system. It ws performed on n XP sis nd ws suitle for wht is generlly onsidered the proper rnge of XP (i.e., for softwre tht is not life-ritil nd with tem of less thn 20 people). There re mny issues to e solved, for exmple, the implementtion method nd the verifition of qulity, efore gile development n e pplied to lrge-sle projets involving more thn out 20 people nd the development of mission-ritil systems. However, there seems to e mny proedures in gile development tht n lso e effetive in wterfll development, for exmple, visul mngement; the itertion/retrospetion meeting (kiko), whih implements the PDCA yle within the development proess; nd the use of pir progrmming, whih levels the lods nd ilities of the developers. In the future, the implementtion of gile development prties will e expnded step-y-step into trditionl development proesses suh s wterfll development. 8. Proess improvement y store mngement method Agile development is intended for softwre development proesses; however, the store mngement method is intended for muh lrger proesses. The store mngement method improves proess y implementing the TPS onept of leveled prodution. In this setion, we desrie this method using the work model shown in Figure 6 s n exmple. This work model hs three types of opertion works tht require rndomly generted work hours nd ilities (,, nd ) nd person in hrge of eh opertion to proess the work sequentilly. Generlly speking, regrding the work generted in the opertion proesses, workers re ssigned to eh opertion nd perform the work. However, when work is done in this style, the work pility nd the worklod depend on the opertions, whih redues the overll performne. The store mngement method improves the overll performne y gthering the instrution mngement for the work nd minimizing/ heijunk the worklod differenes nd work pilities etween workers. Figure 7 shows 146 FUJITSU Si. Teh. J., 43,1,(Jnury 2007)

9 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System <Genertion of work> : Opertion work A : Opertion work B : Opertion work C In hrge of opertion A In hrge of opertion B In hrge of opertion C Figure 6 Work model for store mngement. <Completion of work> the heijunk improvement tht ws hieved in this exmple. The following heijunk prties were implemented. 1) Work exeution using the store pull system 2) Single-queue worklod mngement 3) Visul mngement of worklod nd utonomi heijunk ontrol These prties re desried elow. 1) Work exeution using the store pull system As shown in Figure 8, the work generted in the opertions were mnged in work instrution oxes lled Store-IN oxes. The workers hose one work item nd then strted working on it. It is importnt tht the workers fous on one work item t time (single-flow prodution). Otherwise, they will wste time swithing etween work items nd might, s result, e unle to omplete them within the lloted mount of time, leding to redution in overll led-time. 2) Single-queuing worklod mngement As shown in Figure 9, when work items were generted, insted of ssigning them in equl mounts to eh worker, they were mnged using single queue of Store-IN oxes nd proessed in sequentil order. When rndomly generted work ws proessed, this method gretly Closing time Work hours Differene Heijunk Poor distriution of work pilities nd worklods etween workers is eliminted. Person in hrge of A Person in hrge of B Person in hrge of C Person in hrge of A Person in hrge of B Person in hrge of C Figure 7 Heijunk improvement y store mngement. FUJITSU Si. Teh. J., 43,1,(Jnury 2007) 147

10 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System Store-IN Store-IN Closing time Opertion A Opertion B Opertion C In hrge of opertion A Store-OUT In hrge of opertion B In hrge of opertion C In hrge of opertion A Store-OUT In hrge of opertion B In hrge of opertion C Figure 8 Work exeution using store pull system. Eqully ssigned work Work instrution Single-queue work Work instrution Person 1 Person 2 Person 1 Person 2 Work led time Figure 9 Shortened led time y single-queue worklod mngement. Shortened redued the work led-time ompred to the eqully-ssigned work method. 3) Visul mngement of worklod nd utonomi heijunk ontrol As shown in Figure 10, the Store-IN sttus ws displyed in n esy-to-visulize wy on ords nd other medi (visul mngement) so workers ould see wht work ws pending for eh opertion. By heking the lod sttus of the queued work on the ords, workers ould determine whether ny dditionl workers were required or whether ertin workers should e swithed to different workers. Heijunk ws implemented y the workers ting independently Figure 10 Visul mngement of worklod nd utonomi heijunk ontrol. to mintin the lne etween the worklod nd work pility. By solving the issues generted in the ourse of implementing these prties one-y-one, the opertion proess ws improved. 9. Effets of introduing store mngement method PST s softwre mintenne support usiness is not suited to gile development. However, PST improved the opertion of this usiness y introduing the store mngement method. The prolems ffeting the trditionl opertion of this usiness nd the dvntges of the store mngement method re desried elow. The prolems were s follows. 1) The worklod tended to e onentrted t the end of the week nd in the lte fternoon. Therefore, workers frequently hd to work overtime nd on holidys. 2) Beuse of the workers differing ilities, some workers hd n espeilly high worklod. Implementing the store mngement method hd the following effets. 1) Visul mngement of the worklod sttus enled the tem memers to lwys understnd the distriution sttus of the worklod nd to level the worklod independently. Sine the store 148 FUJITSU Si. Teh. J., 43,1,(Jnury 2007)

11 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System mngement method ws introdued, none of the urrent tem of workers hs hd to work during holidy. 2) The differene in overtime hours ws redued to out 30% y leveling the worklod etween workers. 3) The temwork pility ws enhned y out 20%. Before the store mngement method ws introdued, there were no methods to mesure the quntity of work in the softwre mintenne support opertion; therefore, it ws not possile to understnd the work pility quntittively. However, fter the introdution of the store mngement method, ll of the work hs een reorded on work rds so the work pility n e understood nd evluted y nlyzing nd ggregting these work rds. This is nother ig dvntge of the store mngement method. Figure 11 shows the numer of work rds tht were written during five-month period fter the store mngement method ws implemented in the opertion mngement division of PST. The figure gives quntittive indition of how the work pility improved. By introduing the store mngement method, produtivity ws improved y out 80% in 4 months. 10. Conlusion When implementing the TPS onept using gile development nd the store mngement method, we found it is useful to return to the fundmentl priniple of mnufturing in the softwre field nd to improve our softwre development proess. The onept of TPS ws introdued to some of the divisions experimentlly in 2003, nd y the end of 2004, it hd een introdued to every PST division. PST s profits stopped delining in Septemer 2004, nd the ompny hs een on grdul reovery sine then. Aknowledgement We re very grteful to Mr. Junihi Mtsui of Consultsouring Co., Ltd. for his help in introduing the store mngement method to PST s softwre development proess. Referenes 1) T. Ohno: Toyot Prodution System: Beyond Lrge-sle Prodution. (in Jpnese), Dimond, ) A. Skt: Agile Prtie. Is gile mngement the Toyot Prodution System? Attempt of Softwre Multi-Skill Development. (in Jpnese), Developers Summit 2005 (presenttion mteril), Numer of rds/persons per dy Mrh April My June July Month Figure 11 Quntifition of improvement sed on numer of work rds. FUJITSU Si. Teh. J., 43,1,(Jnury 2007) 149

12 K. Furugki et l.: Innovtion in Softwre Development Proess y Introduing Toyot Prodution System Tooru Tkgi, Fujitsu Softwre Tehnologies Ltd. Mr. Tkgi reeived the B.S. degree in Engineering from Ritsumeikn University, Kyoto, Jpn in He joined Fujitsu Aihi Engineering Ltd. (urrently Fujitsu Softwre Tehnologies Ltd.), Aihi, Jpn in 1985, where he hs een engged in reserh nd development of OS susystems. He ws lso engged in development of We systems from 2000 to 2003 s n SE. He promotes softwre development sed on the Toyot Prodution System. E-mil: tkgi.tooru@jp.fujitsu.om Koihi Furugki, Fujitsu Ltd. Mr. Furugki reeived the B.S. nd M.S. degrees in Chemil Engineering from Tokyo Institute of Tehnology, Tokyo, Jpn in 1974 nd 1976, respetively. He joined Fujitsu Ltd., Kngw, Jpn in 1976, where he hs een engged in development of minfrme operting systems. E-mil: furugki.kouih@jp.fujitsu.om Akinori Skt, Fujitsu Softwre Tehnologies Ltd. Mr. Skt reeived the B.S. degree in Engineering from Ymnshi University, Ymnshi, Jpn in He joined Fujitsu Aihi Engineering Ltd. (urrently Fujitsu Softwre Tehnologies Ltd.), Aihi, Jpn in 1989, where he hs een engged in reserh nd development of minfrme operting systems. He ws lso engged in development of We systems s developer from 2000 to He promotes softwre development sed on the Toyot Prodution System. E-mil: skt.kinori@jp.fujitsu.om Disuke Okym, Fujitsu Softwre Tehnologies Ltd. Mr. Okym reeived the B.S. degree in Engineering from Ymnshi University, Ymnshi, Jpn in He joined Fujitsu Prime Softwre Tehnology Ltd. (urrently Fujitsu Softwre Tehnologies Ltd.), Aihi, Jpn in 2002, where he ws engged in development of We systems s developer from 2002 to He ws then engged in development of finnil ounting system until He promotes softwre development sed on the Toyot Prodution System. E-mil: okym.disuke@jp.fujitsu.om 150 FUJITSU Si. Teh. J., 43,1,(Jnury 2007)