|
漁師プログラマ
山崎敏 YAMAZAKI Satoshi
vol.10 |
|
|
●●ある日 |
|
|
筆者はあるパターンを発見しました．それは「納期どおりにシステムを完成させると，完成していないシステム（デスマーチ）に転送される」というパターンです．そして筆者は悪魔に魂を売ることになるのですが，そこに至るまでの話を紹介します．
上司の言葉に「また火消し？」と悪態をつきながらも，朝早く起きて，超満員の電車に長時間揺られ，携帯電話を頼りに目的の開発現場に着いてみれば，壮絶なデスマーチがすでに繰り広げられていました．「これだよ，これ」．緊迫感というか，緊張感というか，なんとも言えない雰囲気が漂っているのです．みんな殺気立っているし，疲れているし，眠いし，とても健康的とは言えない人々が集まっているわけです．
その場所で筆者を待っていたのは，テスト作業でした．テスト作業なら筆者でなくても誰でもできるだろう…と思いながら「具体的に，何をどうテストすればいいの？」と聞くと，「適当に動かしてみておかしな所を見つけてくれ」と言うのです．
一瞬，我が耳を疑ってしまいました．要するに仕様が決まっていないのです．仕様を「キレイに紙に書いて見せろ！」とまでは言いませんが，今作っているシステムはいったいどういうもので，何がどうなったら完成なのかは最低限押さえていないと，ゴールもわからずに闇雲に走り回っているマラソンと同じことになります．これには恐れ入りました．こんな仕事が存在していいのでしょうか？納期が2週間後でしたので，テストに入っていないとまずいのは当然なのですが，それ以前に，何が間違いで何が正しいのかの判断基準がないなんて…．いったい何をどうするとこんな状態になるのかまったく不可解でした．
もっと不可解だったのは，現場にプログラマがいない！ということでした．「これってどういうこと？」と聞いてみたのですが，なんでもプログラマは快適な環境でコードを書くのが最も効率的だとか…．プログラマには快適な環境が必要で，テストをする人間は現場でヒーヒー言ってもいいなんてことはないだろ！とそのとき，筆者のやる気を支えていた糸が切れる音がしました．ダメだこりゃ，とりあえず2週間，ただひたすら耐えよう．システムが完成するかどうかなんてもうどうでもいいや…．筆者は悪魔に魂を売り渡してしまったのです．
その後2週間，毎日夜の9時に出社して翌日の朝の9時までひたすらテストをするという作業を続けたのでした．当然，2週間では終わりませんでしたが…．
|
|
|
●●システム開発はサービス業 |
|
|
●顧客の求める価値を実現する作業
「転んでもタダで起きるな，何かをつかんで起き上がれ」とか，「人生につつかれたら，頭を使うときだ」（注1）とか言いますが，このデスマーチを体験して1つ学んだことがあります．それは「おまえは考えなくていい，言われたことをやれ」という言葉が，筆者の最も嫌いな言葉だということに気付かされたことです．
このときから，「システム開発とはサービス業である」と強く思うようになりました．以前は，プログラマとは技術職でありモノを作る仕事であると思っていました．しかし，多くのデスマーチを体感しているうちに，モノを作る側面よりもサービス業的な側面が強いことを思い知らされたわけです．要求定義に始まり，設計し，コードを実装し，テストし，納品するという，一連の作業は顧客を満足させるために行っているサービスだと思えてきたのです．
おそらく，プログラマの皆さんは「少なくともコードの実装やテスト作業は製造業に近い」と思われるでしょう．しかし，コードを書いてテストをするという作業は，「顧客の求めている価値は何か？それをコードに書いて，実際に動かして見せて，要求どおりか確認する」という作業だと思います．
ただし，サービス業といっても，1つ特徴があります．それは，完成品をコピーできるという点です．
パッケージ販売やネット販売をすることで，製品1つの開発コストを安く抑えることができます．ソフトウェア業界は映画業界や音楽業界，そして出版業界に近いと考えることができます．逆に言えば，システム開発のおもな発注形式である受注生産（少量生産）では，開発コストが高くならざるをえないということです．
注1）『金持ち父さん貧乏父さん』（Robert T.Kiyosaki，Sharon L.Lechter著／白根美保子訳／筑摩書房／ISBN：4480863303）という本の中の金持ち父さんのセリフ．
●99％が設計
たとえば，自動車を作るとき，まず設計をします．そしてその設計図を元に生産します．ビルを作るときも橋を作るときも，設計図を描きその設計図に従って作ります．
では，ソフトウェア開発の場合はどうでしょうか．仕様書を書いて，その仕様書どおりにコードを書きます．え？ホントにそうですか？それはタテマエではありませんか？実際には，仕様はコロコロ変わり，完成したコードは仕様書とは違うモノになっている，そんなことはないでしょうか．
ある人が言いました．「実はソースコードが設計図であって，建築でいうモノ作りに相当するのはコンパイラを動かしてる時間だけではないだろうか」と．筆者もこの言葉に同意します．ソフトウェア開発の99％は設計だと思うのです．
●システム開発には右脳的感覚も必要
右脳は，イメージや感覚を処理し，音楽，絵画，幾何学に適していて，直観的，アナログ的で図で考えるタイプと言われています．一方，左脳は，言語や理論を処理し，言語，観念構成，算術に適していて，論理的，デジタル的で三段論法で考えるタイプと言われています．
ソフトウェアはまさにデジタルであり，プログラミング言語は完全に論理的な言語です．よって，ソフトウェア開発は左脳的（論理的）作業であると思われがちです．しかし，顧客からの漠然とした要求を理解しそれを具体化し実際のモノに変える設計という作業は，直感や図で考える作業であり，アナログ的部分が多いのです．さらに，顧客とのコミュニケーションには右脳的な感覚が必要なのです．
●ソフトウェア業界の位置
今現在思い当たる大まかな業種と，ソフトウェア業界の位置関係を図1に表してみました．横軸はサービス業に近い業種と製造業に近い業種に分け，そして縦軸に生産数（大量か少量か）を分け，大きく4つの種類に分割して表してみました．断っておきたいことは，厳密な図ではなく，製造業であってもサービス業的な作業も含んでいますし，その逆も言えます．ここでは，おもな作業はどちらなのかを考えています．
筆者のような，職人気質なプログラマにしてみれば，「ソフトウェア業界はサービス業である」と言われてもピンと来ません．むしろ「製造業だろ!?」と反論したくなります．もともとコンピュータは電子製品であり製造業なので，その中で動くソフトウェアも製造業であると思いがちです．
しかし，よく考えてみると，建築設計やコンサルト業務に近い業種であることがわかります．そして，ソフトウェアの生産数も決して多いほうではなく，むしろ受注生産や少量生産が多く，同じモノは2度と作らない傾向があります（注2）．
一般に「方法論」の話になると，製造業的な大量生産の定型化やマニュアル化の話になる傾向があります．ソフトウェア開発の方法論も，どちらかといえば製造業的なアプローチを行い生産性を上げようとする試みが多いと思われます．
図で言えば，右上に進もうとしているわけです．
もしくは，右下にいると思い込み，上に行こうとしているとも考えられます．しかし，これでは現在の位置を考えずに闇雲に生産効率を延ばそうと気持ちだけが空回りしているようにも見えます．やはりここは，「ソフトウェア開発業はサービス業である」という認識からスタートし，生産効率を上げる，すなわちサービスの価値を高める努力をすべきではないでしょうか．
注2）複製が可能なので，同じモノを作る意味がないとも言えます．
●サービス業の視点で見るアジャイル
そういった意味から見ると，今回のテーマである「アジャイル」は，サービス業としてのスタンスの強化につながる考え方です．ある種の「方法論」は手順のマニュアル化であり，作業の定型化であると言えなくもありません．しかし，アジャイルという方法論は少し違った側面を持っています．それは，少なくとも作業の定型化に関するマニュアルではないというところです．
生産効率を高めるために定型化しマニュアル化しようという，右上への方向性ではなく，サービス業としての価値を高めるための左側での価値を高めようという方向性だと思うのです．
●サービス業の価値
「ザ・ゴール」シリーズの第3弾である『チェンジ・ザ・ルール！―なぜ，出せるはずの利益が出ないのか』（Eliyahu M.Goldratt著／三本木亮訳／ダイヤモンド社／ISBN：4478420440）という本の中に，ソフトウェア開発の価値とは何か？という問いのヒントになる言葉が書かれています．クレイグ氏の『コスト削減だけでなく，利益にどう影響を及ぼすのか，そのあたりをよく調べてみてくれないか』という発言です．
サービス業の最終的な目標は顧客の抱えている問題を解決すること，そして顧客の望む価値を提供することです．ソフトウェア開発の顧客はおもに企業であり，その顧客の望む価値は「顧客の利益」であるということなのです．顧客に利益をもたらすことができるかどうかが，開発するソフトウェアの価値になるということなのです．すべてのソフトウェアにあてはまることとは思いませんが，多くのソフトウェア製品にあてはまることです．
また，ソフトウェア開発で陥るデスマーチの最大の原因は，「顧客の要求が把握できていない」（注3）ことであり，そのために開発すべき項目の優先順位が付けられず，闇雲に走り回ることになってしまっています．これは開発者側のみの話ではなく，顧客の側も把握できていないこともあるので，漠然とした「こうなったらいいなぁ」という顧客の要求を「現状はこうなので，こうすることで利益につながります」と明確な要求に変えていくことがプログラマの仕事ではないでしょうか．
注3）顧客が何を必要としていて，何に価値を感じているのかが把握できていない．
●そもそもプログラマとは
そもそも，プログラマの仕事とは，漠然とした要求をコードという明確なモノとして実現する仕事なのですから．「それはマネージャの仕事だ」とか「営業が勝手に決めたことだろ」という発言は責任転嫁，もしくは職業放棄となるではないでしょうか．
マネージャや営業とのコミュニケーションさえできないプログラマが，果たして顧客の要求する価値を提供できるのでしょうか．
プログラマという仕事は，コードさえ書ければコミュニケーション能力は重要ではないと誤解している人もいるかもしれません．とくに成果主義へと傾いている昨今，正しいコードさえ書ければ仕事として成り立つと思われています．しかし，大事な点が1つ抜けています．それは「正しいコード」とは顧客の持つ価値観に沿っているかどうかであって，コードを書くプログラマの価値観に沿っているかではないという点です．顧客の価値観（何を望んでいるのか？）を，コミュニケーションなしに知ることはできません．よって，コミュニケーション能力のないプログラマの価値はないということになります．
また，顧客の要求する機能を実現するという仕事は，問題を分析して解決する仕事でもあります．一般に，1人で悩むよりも複数人で考えたほうが，偏りのない良いアイデアが出ます．ここでもコミュニケーション能力が重要になるということです．
『チェンジ・ザ・ルール！』はTOC（制約理論）の小説ですが，ソフトウェア業界の話が書かれています．具体的な手法を書いた本ではありませんが，プログラマの皆さんにも，管理者の皆さんにもお勧めできる1冊です．
|
|
|
●●アジャイルとは |
|
|
●アジャイルの特徴
アジャイル（Agile）という言葉は，もともとは経営手法の話から出てきた言葉のようです．ネット書店などで「アジル」という言葉を検索すると，いくつか経営関係の書籍が見つかります．
アジャイルという言葉を日本語にすると，「機動的」「俊敏な」「臨機応変」となるでしょう．これはXP（eXtreme
Programming）などの方法論の目指すところと同じに見えます．XPは「良いと思われることはとことんやる」という姿勢なので，その「良いと思われること」の中に「機動的であること」が入っているため同じに見えるのだと思います．
アジャイルの特徴は，「適応」もしくは「対応」です．簡単に書くなら，やはり「変化を受け入れろ」ということでしょう．アジャイルでは，XPのように明確な手法（プラクティス）を提示したりはしていません．より優れたソフトウェア開発方法を見つけようという姿勢を示しているわけです．変化を受け入れる姿勢を重視し，重量級（ヘビーウェイト）であるよりも軽量級（ライトウェイト）であることも重視しているようです．
そして，一番の特徴は，なんといってもアジャイル自身がアジャイルであろうとする姿勢です．アジャイルという方法論そのものも変化を受け入れる姿勢を取り，軽量級であろうとしているところです．
●予測と対応
ソフトウェア開発に限らずあらゆるプロジェクトで言えることですが，ある程度の予測と臨機応変な対応が必要です．逆に言えば，予測のまったくない作業や対応のまったくない作業はありえず，どちらかのみの作業もありえません．顧客の要求はつねに変化するものですし，設計や実装もやってみなければわからないということです．しかし，まったく予測せずに作業を進めることは困難です．予測どおりにならないことも多くあります．そこで，予測と対応のバランスが重要になってきます．
問題なのは，完全な予測はできないのに，予測できるものとして作業を進めることです．それは，完全な要求仕様など存在しないのに，存在するとして作業を進めることと同じだからです．必ず予測できなかった何かが起こり，その都度対応が必要になります．そのときになってからあわててその場しのぎの対応をするのではなく，対応は必要であるというスタンスが大切なのです．
●顧客
対応を受け入れるということについては，開発側だけではなく顧客側の意識も変える必要があります．現在多くの顧客は，費用と納期と仕様書を提示しさえすれば望みどおりのソフトウェアが完成すると思っています．実際にはそれは幻想であり，望みどおりのソフトウェアは完成しないのです．顧客から多くの情報を受け取らない限り，価値を提供することは不可能なのです．顧客にも予測のみの考え方から，対応型の考えを受け入れてもらう必要があります．
簡単に書いてしまいましたが，現実の顧客に対応を重視する考え方を受け入れてもらうのは簡単なことではありません．今までの習慣やルール，考え方を変えなければなりませんし，それはちょっとした努力で変えられるものではありません．しかし，この考え方を受け入れてもらえれば，ソフトウェア開発はよりスムーズに進みます．その結果，顧客は望む価値を手に入るのですから，顧客にとっても望ましいことなのです．
|
|
|
●●『アジャイルソフトウェア開発』 |
|
|
●アジャイルは軽量級
『アジャイルソフトウェア開発』（Alistair Cockburn著／テクノロジックアート訳／長瀬嘉秀，今野睦監訳／ピアソン・エデュケーション／ISBN：4894715791）という，今回のテーマそのものの本があります．
この本の中に「40人のチームは6人のチームほどアジャイルではない」という言葉があります．ただ，40人のチームであってもアジャイルであろうとすることはできる，と書いています．また「開発速度はアイデアの伝達に要する時間とエネルギーコストに関係する」とも書いています．さらに，軽量級と，重量級という言葉も頻繁に出てきます．アジャイルでは「コミュニケーション」「コミュニティ」「頻繁な納品による勝利」「フィードバック」を重視するそうです．
●アジャイルソフトウェア開発宣言
『アジャイルソフトウェア開発』の中で一番重要だと思う部分は，付録Aの「アジャイルソフトウェア開発宣言」です．ここではすべてを紹介することはできませんが，冒頭の4つの宣言だけでも紹介したいと思います．
・プロセスやツールよりも，個人と相互作用
・包括的なドキュメントよりも，動作するソフトウェア
・契約交渉よりも，ユーザとの協調
・計画に従うよりも，変化に対応
ソフトウェア開発において，右側の項目に価値を見出しているそうです．XPの提唱者であるKentBeckを筆頭に，この本の著者であるAlistair
Cockburn氏を含む17人がこの宣言にサインしているところも注目すべきででしょう．
筆者は，この4つの宣言に感銘するところがあります．
・決められた手順や道具よりも，個人の能力やチームとしての能力を重視しているところ
・曖昧な表記が多くなりがちなドキュメントよりも，正しく動作するコードを重視しているところ
・要求定義というドキュメントが必ずしもユーザの望む価値を表していないところ
・未来は予測できないというところ
といったことを筆者も重要に思うからです．
●インクリメンタルとイテレーション
「イテレーション」や「インクリメンタル」とは，過去に何度も議論されてきた「プロトタイプ」や「スパイラル」と何が違うのだろうかと思ってしまうのですが，ソフトウェア開発においては誰もが同じようなことを感じているということなのでしょう．
今までの方法論では，ユーザや顧客という言葉が含まれるケースが少なかったのですが，イテレーションにはユーザや顧客を含んだフィードバックであることが明言されていることが大きな違いなのだと思います．
また，インクリメンタルとは，イテレーションより大きなループであり，開発方法そのものを改善することを示しているようです．
「わらしべ長者」という昔話があります．ある貧乏な男が，観音様のお告げのとおり手にしたモノを大事にしていると，わらしべがみかんに，みかんが布に，布が馬に，馬が屋敷になり，最後に男は長者になります（注4）．
この話のミソは，少々強引かもしれませんが，イテレーションだと思います．あるモノを提示しその結果からまた次のモノを提示する，これを繰り返すことで，最終目標に到達するということです．最初からいきなり長者を狙うのではなく，わらしべから徐々にステップアップしていくところだと思います．「与えなければ得られない」といいますか「ゼロは何倍してもゼロである」ということなのです．
最初は1でもいいわけです．その1を1.2倍程度のフィードバックで繰り返せば，たった38回で1020を超えることができるのです．
イテレーションとは，顧客にわらしべを提案し，みかんと交換してもらう方法です．そして，わらしべ長者から何かを学んだ人が再び長者になることを，インクリメンタルと言うのでしょう．
注4）簡単な話ですが，資産運用の基本を語っていると思います．
●情報の伝達
アジャイルでは，情報の伝達速度を重視しています．それは，ソフトウェア開発の開発速度は情報の伝達速度に比例しているという考え方から来ています．つまり，コミュニケーションを維持するためのコストよりも，それを失うことによるダメージが大きいと考えているわけです．
ある疑問や問題を解決するには，多くの場合，情報が必要です．その情報までの時間とエネルギーがコストになります．遅延や機会損失が起こると，疑問や問題が先送りされます．先送りされることで問題が正しく伝わらなくなったり，問題そのものが存在したことさえ忘れてしまう場合もあります．作業をしているその場であれば，数秒で解決できた問題も，数時間後，数日後になってしまうと，どんな問題だったのか，どこで起きた問題だったのか，時間とともに情報が希薄になり，思い出したときにはほかとの関係が増えていて問題が大きくなっていたりします．
これがもし，問題を解決するための情報を持った人とペアプログラミングしていれば，数秒で解決したでしょう．同じ部屋にいれば数十秒から数分以内に解決したでしょう．これが隣の部屋であったり，異なる階であったり，異なるビルであったり，異なる町であった場合は，それだけ遅延することになります．その累積が開発全体で大きなダメージになることを，忘れてはいけません．
●全体の状況
個々の問題のほかにも，知りたい情報があります．
それは全体の状況です．自分は今どこにいて何をしているのか？そしてどの方向に進むべきなのか？そういったマクロな視点からの情報がつねに必要なのです．こうした共有すべき情報を，ネットワークで管理したファイルに書き込んだり，メールに書いて全員に送ったりしますが，もっと簡単でかつ効率的な方法があります．それは「付箋紙に書いて壁に貼る」という方法です．なんともローテクな方法ですが，全体を把握するのも，更新するのも，この方法が効率的です．費用もたいしてかかりません．付箋紙と壁があれば良いわけですから．
進捗状況や優先度を上下左右の方向に割り当て，作業内容と作業者の名前を書いた付箋紙を張るわけです．名前を書かずに付箋紙の色で区別することもできます．更新はその日の進捗によって貼る位置を変えるだけですから，数秒もかかりません．また，情報を受け取るために，わざわざファイルを開いたり印刷する必要もありません．壁を見るだけです．
●コミュニケーションツールあれこれ
現在，使えるであろうコミュニケーションのためのツールの位置関係を図2に示します．縦軸にツールにより情報の流れる速さ，横軸にツールが運ぶ情報の量を示します．これらの中からより早く情報量の多いコミュニケーションツールを選択できる環境を作ることが，最終的に開発速度の向上につながります．
|
|
|
●●アジャイルの7つの原則 |
|
|
『アジャイルソフトウェア開発』では，ソフトウェア開発の方法論について7つの原則を挙げています．
① インタラクティブな直接対話によるコミュニケーションは，情報交換の最も安価で高速なチャネルである
② 方法論の余分な重量にはコストがかかる
③ 大きなチームは重量級の方法論を必要とする
④ 大きな儀式は重要度の高いプロジェクトに適している
⑤ フィードバックとコミュニケーションが増すと，中間納品物の必要性が減る
⑥ 規律，スキル，暗黙知は，プロセス，形式化，文書化と対峙する
⑦ 効率はボトルネック以外のアクティビティで消費できる（注5）
これらの原則に対する，筆者の補足意見も挙げておきます．
①⑤ とくに補足はありません．そのとおりだと思います
② 決めごとが多くなりそれに伴って手順（儀式）が多くなると，それだけ多くのコストがかかるということでしょう
③ 原則②の逆といいますか，人数が多くなるとその人数のコミュニケーションの方法として，多くの手順が必要になり，方法論も重量級にならざるを得ないということでしょう
④ この原則は筆者には理解しがたいのですが，重要度の高くなるとそれだけ大きな儀式が必要になるということなのでしょうか？それとも大きな儀式はそれだけの多くのコストをかけられるプロジェクトでないとできないということなのでしょうか？どちらにしろ儀式を少なくする方向で考えるべきだと思います
⑥ 「プロセスは規律ではない」「スキルと形式化を混同するな」「暗黙知と文書化を混同するな」これらはお互いに逆方向へ引き合うとのことです．
軽量級は「規律，スキル，暗黙知」の方向へ，重量級は「プロセス，形式化，文書化」の方向へ引くということだと思います
⑦ これはTOC（制約理論）のことだと思います．
注5） ボトルネック以外のところで非効率なことをしても，全体に影響はないということです．
|
|
|
●●アジャイルの6つの結果 |
|
|
7つの原則に続き，6つの結果も挙げておきます．
ソフトウェア開発の真理を，かなり言い当てているのではないでしょうか．
① プロジェクトへの人員追加はコストがかかる
② チームのサイズは飛躍的に大きくなる
③ チームは改善すべきであって，大きくすべきではない
④ プロジェクトが異なれば，必要とされる方法論も異なる
⑤ 行き詰まるまで，軽量級の方法論のほうが良い
⑥ 方法論は状況に合わせて拡張可能であるべきだ
細かく補足したいところではあるのですが，詳細については各自『アジャイルソフトウェア開発』の本を読んでください．
|
|
|
●●アジャイルと改善 |
|
|
アジャイル開発はインクリメンタルな方法論であろうとしているわけです．そのためソフトウェアを開発し納品したあとに，
① 「何を学習したのか」
② 「何ををより改善できるか」
といったことについて話し合い，次の開発に活かすのだそうです．
|
|
|
●●最後に |
|
|
最後に簡潔にまとめると，アジャイルとは「大きくて重くて儀式的なモノの反対側を目指すモノ」や「巨大な恐竜の時代に現れた小さな哺乳類のイメージ」です．
早いもので，あと2回で連載開始から1年になるのですね．次回は「V字モデル」についてオールフィクションで書いてみようと思います．お楽しみに．
|
|
|
コラム●進化とは |
|
|
少し話が脱線しますが，生物は変化する環境に対してつねに対応してきたわけです．対応すべき情報を遺伝子に残し，次の世代に伝えてきたとも言えるわけです（注A）．
現在生きているすべての生物は，地球という環境に対応し続け，生き残ったのです．反対に，環境の変化を無視して対応をやめた生物には絶滅の道が待っています．
注A）実際には，残したのではなく，環境に淘汰されて残ったという表現が正しいでしょう．
|
|
|
コラム●価値の実現 |
|
|
筆者は以前から，世の中には次のような前提条件があるのではないかと思っていました．その前提条件とは，
・あらゆるものはつねに変化する
・あらゆる情報を手に入れることはできない
・よって，つねに限定的な判断しかできない
このことから，完璧な製品はありえないとともに，完璧なソフトウェア製品もありえないと言えそうです．しかし，情報を収集する能力と，情報を伝達する速度と量と質を高め，変化をフィードバックし，繰り返す能力を高めれば，より完璧に近づくことは可能です．そして，その近づく努力こそが「価値」の実現につながるのではないでしょうか．
|
|
|
コラム●宮本武蔵 |
|
|
『アジャイルソフトウェア開発』の本の中の付録Bに，宮本武蔵の『五輪書』のことが書かれています．筆者はこの数ページの文章を読んで驚きました．まさにソフトウェア開発のキモについて述べていると思ったからです．そして，日本人である我々よりも先にCockburn氏の目にとまり，逆輸入という形で知ることになったことが悔やまれます．
Cockburn氏は武蔵の戦い方の特徴を3つ挙げています．
・武器や流派にこだわるな
・実践し定期的に観察せよ
・勝て
このことは筆者がソフトウェア開発時にいつも思っていたことそのものだったのです．筆者は今後，「武蔵流プログラマ」と名乗ることにします（半分本気です）．
|
|
|
コラム●マラソン |
|
|
ソフトウェア開発は「短距離走ではなく長距離走だ」とよく言われます．筆者もこの考えに同意します．
中でも，全体の距離がわからずに全力で走って，途中で息切れをしてしまい，最後まで走りきれない，もしくは完走までのタイムが遅くなる（生産性が悪くなる）ところがそっくりです．まずは，どこまで行けばゴールなのか？ゴールまでの距離はどのくらいなのか？どの道を通ればいいのか？を明確にする必要があるでしょう．
|
|
アジャイル