|
武蔵流プログラマ
山崎敏 YAMAZAKI Satoshi
vol.13【最終回】 |
|
|
●●あなたはラッキー |
|
|
今，この記事を読めているあなたは非常にラッキーです．とても運がいいと思います．ここで，そんなに運を使ってしまっては，あなたの今後の運が心配になってしまうほどです（注1）．
まったく根拠なくそう言っているわけではなくて，なんと，この「コードデザイン最前線」の連載が今回で終了するからなのです．次回はありません．次号を買ってもこの連載は読めないのです．
さらに，筆者にとって（読者にとっても？）悲しいニュースなのですが，「この連載を本にしよう」という話がなんと正式に「ボツ」になってしまい，ほかの場所でこの記事を読むことができなくなってしまいました．こんなことではあまりにももったいないので，過去の記事に関しては編集担当の方の了解を得て，筆者が身銭を切り，個人のWebページに掲載しています（注2）．
しかし，やはり記事は雑誌や本という紙の形で読みたいものです．筆者はそう思います．残念ながら現在その道はなくなりました（注3）．なので，とても貴重な最終回になりました．じっくり味わって読んでください．
注1） 大げさです．
注2） http://www.01-tec.com/です．
注3） もしかしたら，自費出版をするかもしれません．自費出版に詳しい方がいらしたら，アドバイスをいただけませんか？
|
|
|
●●直球勝負 |
|
|
さて，最終回である今回は「システム開発にたずさわる人は開発者も発注者も，もっとスマートに仕事が進み，皆さんの家庭もこの日本の社会も円満になってほしい」というちょっぴりおおげさなテーマで書きたいと思います．とくに，デスマーチで困っている人に打開へのヒントになればという想いです．
残業ゼロで，納期を守り，バグもない最高の品質で，なおかつ顧客に「たいへん助かってるよ」と感謝され，高い対価を払ってもらえる…そんなシステム開発ができてこそ本物だと思うのです．
そんなわけで，この回ですべての力を出し切るためにも，変化球なしの直球勝負で筆を進めたいと思います．
|
|
|
●●チェックリスト |
|
|
システム開発について，次のリストを読んで，自分もしくは自分のチームがあてはまると思う項目の数を数えてみてください．
・技術力もスキルもあるから大丈夫．
・人はたくさんいるから大丈夫．
・みんな徹夜してでもモノを完成させる根性と体力があるので大丈夫．
・最新式の開発ツールを買い揃え全員が使いこなしているので大丈夫．
・最新の開発方法論であるXPを実践しているので大丈夫．
・過去に失敗はないし失敗するような危ない橋は渡らないから大丈夫．
・毎週定期的に会議を開いてじっくり議論しているから大丈夫．
・高い費用をかけてISOを取得したし，開発時のマニュアルも完璧に揃っているから大丈夫．
・開発手順をきちんと決めて，その手順から逸脱しないようにしっかり見張っているので大丈夫．
・親会社が大手だから大きな仕事は次々と来るし，親会社の言うことを素直（すなお）に聞いていれば大丈夫．
・精一杯やってるよ．悪いのは世の中だろ．不況なんだからしょうがないよ．景気が良くなればうちも良くなるから大丈夫．
筆者は基本的に，これらの項目すべてに否定的です．こういった安心感は危険だと思います．
|
|
|
●●発注者の禁じ手 |
|
|
システム開発者に対する意見ばかりでは不公平なので，ここで逆の立場でもある，システム発注者から意見しようと思います．
●●ダメなチームを見分けろ！
やはり開発チームには，優良チームと欠陥チームが存在します．そのチームをいち早く見分けることが大切です．「優良チームでお願いします」と口頭で伝えても「はい，わかりました」と優良チームが揃うわけではありません．それは自分の目で判断するしかない，ということをまず心掛けてください．
●●おまかせはダメ！
●システムの具体的なイメージを絞り込む
システムの具体的なイメージの絞り込みが必要です．
まず，どのようなシステムが欲しいのか，できるだけ具体的なイメージをしっかりと持つことです．そして，限りなくシンプルな道を目指すべきです．「80対20の法則」の言うように，効率良く開発を行えば2割の力で8割の成果があげられます．予算は5分の1になり，パフォーマンス（性能）はコスト（費用）の4倍になるわけです．とにかくコアな機能のみに絞り込むことです．「これがなければシステムの意味がない」と言えるところまで絞り込むことが大切です．
この絞り込みには，とくに現場の作業者の意見を聞くことが大事です．現場を知らない人が「〜だろう」で判断すると，多くの場合，的（まと）を外します．それこそ経費の無駄使いになります．
●大規模で多機能なほどバグが増える
システム開発は大規模で多機能なほど，複雑になり，工数がかかり，コストは高くなる傾向があります．そしてさらに，バグが入りやすくなります．「単純なモノほど壊れにくい」という原則を忘れてはいけません．PCは電気がないと動きませんが，紙と鉛筆なら電気がなくても書くことができるのです（注4）．
注4）電子メールはやめて，手紙を書けと言っているわけではありません．念のため．
●開発途中で機能を追加しない
同じコストなら…とついあれこれ機能を追加したくなってしまいがちですが，開発途中での機能追加や変更はシステムのバグを誘発しますし，納期にも影響します．なにより開発者のモチベーションを下げますので，禁じ手であると判断していいでしょう．その代わり，メインの機能については徹底してフォローすべきと思います．
●システム化は必要か
また，そもそも本当にシステム化することで価値が上がるのか，よく考えてみることが大切だと思います．
●●大所帯はダメ！
この連載で何度も書いているのですが，システム開発に大人数は必要ありません．逆に，人数を安易に増やす傾向のある開発チームは疑うべきだと思います．システムの開発規模を小さく抑えるのは，とくにコミュニケーションのロスを少なくすることが目的です．このコミュニケーションのロスは大所帯になるほど深刻になります．小規模なチームにすることで，柔軟な対応が可能になるわけです．
●●短納期もダメ！
開発期間はできる限り長くしましょう．1日でも早く完成させようと納期を狭めると，バグを誘発することになります．
しかし，放置してはいけません．フォローを欠かしてはいけないのです．それこそXPの「オンサイトカスタマー」の精神が必要です．開発者に密着する形でつねに現状を把握し，問題をフィードバックし，対応を実施できる体制を整えるべきです．とくに，ユニットテストの実施やプロトタイプの開発など，早期に「動くモノ」が確認できる体制にするべきです．
このオンサイトカスタマーが実施できれば，システムは順調に完成するでしょう．そのくらい重要なポイントだと思います．コミュニケーションのロスを少なくし，フィードバックを高速にする．この点が重要なのです．発注側と開発側の双方の意見を通りやすくしておくべきです．
とくにシステムのどの部分に価値があるのかは発注側にしかわからないはずですから，その点を正確に伝えるためにも，その価値を熟知した人間を「オンサイトカスタマー」として投入すべきと思います．
●●テストの後回しはダメ！
品質はテスト件数に比例します．重要なので繰り返します．システムの品質は開発時のテスト件数に比例するのです．
よって，発注側はどのくらいテストが行われているのかをしっかり把握することが大切です．オンサイトカスタマーが実施できれば，その都度，テスト項目やテストの進捗がチェックできますから，より理想的と言えるでしょう．
ウォーターフォールモデルを採用してテストを後回しにする開発チームは，システムの品質が心配です．とくに納期直前までバタバタとテストを行っているチームがあったのなら，筆者はそのチームの品質は「悪い」と断言できます．
もし可能ならば，テスト自体もプログラム化するようにすべきだと思います．筆者は，テストを自動化するメリットはかなり高いと思っています．
テストをプログラム化して自動化することで，何度もテストを繰り返すことが容易になります．手動によるテストでは，一度やるだけでもたいへんな作業ですし，間違いやすいです．なによりバグが漏れる可能性がとても高いと思うのです．
テストがプログラムによって自動化できていれば，1つのバグを取ったためにほかのバグを作りこんでしまうという「デグレード」を楽に回避できます．このことでシステムの品質は格段に上がります．
システム開発の納品物件にテストプログラムを含めるのもいいかもしれません．その後，完成したシステムを改良することになっても，テストプログラムをうまく使えばシステムの品質が落ちるのを抑えることができます．
筆者は，テストプログラムにはコストをかけるだけの価値が十分あると思っています．
●●経験者なしはダメ！
筆者は趣味として，スキューバダイビングを楽しんでいます．石垣島や西表島の海はそれはもう，とてもキレイです．毎日でも潜りたいくらいです．
ライセンスも持っていますし，それなりの知識も経験もあるので，すぐにでも海に潜りたくてしょうがないのですが，勝手に潜ったりすることはしません．やはり，知らない海は危険です．おそらく，ほとんどの人が知らない海にいきなり潜るようなことはしないでしょう．かならずガイドと一緒に潜ります．
ダイビングでなくても，知らない山を登るときにも，やはり現地のガイドを頼むと思います．現地のガイドはその地理に詳しいし，何度も登った経験があるわけです．知識だけではなく体験が豊富なのです．こんな天候は危険であるとか，この場所は注意すべきだとか，これ以上行ったら危険であるとか，このペースでは登れないとか，いろいろな経験と判断材料を持っているわけです．
はじめて登る人にはそれがないわけですから，いきなり失敗を体験しろと言っているようなものです．山で失敗しても，生き延びる確率はまだ高いかもしれませんが，海の中で失敗したら，それはもう生き延びる確率はとても低かったりします．
「天は我々を見放した！」というセリフで有名な『八甲田山』（'77／日）という日本の映画がありますが，まさにそのイメージがピッタリはまります．
そのくらい経験者の体験というのは大切だと思うのです．
システム開発においても，デスマーチを体験し，その回避策を体得したした人をガイドに雇い入れることが安全への第一歩と言えます．システムの品質やコストを考えるなら必ずそうすべきです．
進むべきか戻るべきか，どこを注意すべきか，何をチェックすべきか，何を避けなければならないのか，危機に落ちたら何をしなければならないのか，など貴重な経験を体感しているからです．
とくにシステム発注側の人はシステムに関して詳しい人ばかりではないので，まずはここから強化すべきです．
●●技に頼るな！
技（テクノロジや方法論）とは将棋でいう手駒のことであり，それがあればかならず勝負に勝てるというわけではありません．それがあると勝負が楽になるというモノです．技や知識に頼る傾向のある開発チームは，少し警戒すべきです．
「ハンマーを持つ人には，すべてが釘に見える」
という言葉があります．1つの技を持つ人は，すべての問題がその技で解決できると思いこんでしまうということです．システム開発にあてはめてみると，「オブジェクト指向を得意とする人には，すべてがオブジェクトに見える」とか「構造化設計を得意とする人には，すべてが構造体に見える」といったところでしょう．
いろいろな技を知ったうえで，ベストな選択ができるチームが理想です．「適材適所」です．
|
|
|
●●●開発側の禁じ手 |
|
|
次に，開発者の禁じ手を見てみましょう．
●●コストを下げるな！
現在，日本の（世界も）経済は悲惨な状況ですが，この状況を回避できるかもしれない提案があります．筆者は政治や経済の勉強をまともにしたことがないので的を外しているかもしれませんが，聞くだけでも聞いてみてください．
●コストとパフォーマンスの関係
本誌2002年7月号の連載に，コストとパフォーマンスの関係を表す図を描いたのですが覚えていますか（図1）．
この図ですが，横軸がモノを生産／開発するためのコストで，縦軸がそのできあがったモノの価値であるパフォーマンスを示しています．単純に，「仕入値」と「売値」で考えていただいてもいいと思います．
●利益が出る条件
図の中の点線は損益の分岐線で，右下の領域ではコスト（仕入値）がパフォーマンス（売値）を上回るので損が出ます．利益が出るところは点Aから点Cの間になります．それ以外の点では損をしてしまうわけです．損をしないように点線の左上になるように皆さんがんばっているわけです．
●現状
そして現在，皆さんはコストを下げて少しでも多く，少しでも安く売ろうと左下の方向へ進むべく，血のにじむ努力しているわけです．しかし，もうすでに点Aより下はありません．崖っぷちです．これ以上進めないところに来てしまっているわけです．
●望ましい状況
しかし，図をよく見て考えてみてください．商売として一番おいしいのは点Bです．本来，点Bへ向かうべきなのです．
もし現在，点Cにいるのであれば右下のコストを下げる方向に進むべきですが，今皆さんは点Aにいるわけですから，これ以上コストを下げてはいけないということです．むしろコストを上げる方向，パフォーマンス（価値）を高める方向へ進むべきなのです．
モノが少ない時代であれば，点Cのモノでも売れていたと思います．しかし，多くの会社が同じようなモノを生産し，価格競争が始まったことで，我々は点Cから点Bを一気に通り越して点Aまで来てしまったわけです．
ここで本来の価値とは何だったのか，価値を最大に高めるにはどうしたらいいのか，冷静に考え直して，進むべき道を改めるときだと思うのです．
●●人を増やすな！
複雑度の話題もありました．図2を見てください．
人の数が増えると，その人を結ぶ線の数が増えます．しかも，人は1，2，3，4…と一定の増え方なのに，線の数は0，1，3，6…のように指数的に増えていきます．たとえば人が10人だと線は45本になり，人が100人だと…計算できません．えーと4950のようですが，合っていますか？なんと人の数の50倍にまでなっています．これが複雑さの爆発です．この爆発に注意する必要があります．
システム開発では，開発者が増えることでコミュニケーションロスの問題が爆発します．人が増えないように，問題を上手に分割する必要があります．
また，コードが増えればコード間の複雑さが爆発します．バグが入りやすいコードになってしまうということです．データ指向の話でも触れましたが，こちらも上手に分割し，カプセル化することで複雑さの爆発を防ぐことができます．
●●技に頼るな！
同じ項目をすでに発注側で書いたので，ここでは若干補足する程度にします．
●技より道
本誌2003年1月号の「データ指向」の回では，おもにコードの話を書きましたが，ここでも「マクロな視点が大切」ということを主張しました．
具体的な「技（テクノロジ）」よりも，大きな流れである「道（スタイル）」を大切にするべきと言いたかったのです．そして，その道は限りなくシンプルな道を目指すべきです．
●マクロな視点を
マクロな視点を持つことで，ときにはパラダイムシフトが起こります．今まで前提としてきた常識が，ある日突然に常識ではなくなるのです．たとえば，その昔，地球は平らだと思われていました．ミクロな視点であれば平らであるという前提で問題はありません．しかし，そういった前提では，月はもちろん新大陸に行くこともできないのです．
やはり一歩でも先に進もうと思うのであれば，つねにマクロな視点を心掛けるべきです．
会社という枠の中で見ていませんか？開発者という枠の中で考えていませんか？どうやって売り込もう…と考えていませんか？その視点で考えている限り永遠に問題は解決しないと思います．
前の車に追いつくためには前の車をめがけて走ればいいのですが，前の車を追い越すにはまず追い越し車線に移る必要があります．そういったマクロなイメージが大切なのです．
●●最適化をするな！
部分最適化をしてはいけません．全体最適化をするべきです．「80対20の法則」が言うように，20の部分がボトルネックになるのです．ボトルネック以外の場所を最適化しても意味がないのです．
むしろ，最適化をしたために，シンプルさが破壊され，保守がしにくくなります．そうなることを危惧しているのです．
昼休みに電灯を消したり，紙の裏を再利用するといった，部分最適化だけでは意味がないのです．
もちろん多少の効果はあるでしょうけど，一番大きなボトルネックを見つけ改善することが大切なのです．
●●仕様書に頼るな！
仕様書を完成させることが開発者の仕事ではないということです．我々開発者の仕事はシステムを完成させることです．仕様書を書くことがおもな目的ではありません．ほかに優先すべきことがあるのです．本質を見落としてはいけないのです．
もちろん，メンテナンス時には仕様書レベルの情報が必要になります．しかし，その情報はコードを書く前にすべて揃うものではないということを忘れてはいけないのです．
●●がんばるな！
努力したことを評価してもらいたいと思ってはダメです．がんばったからそれでいいんだと思ってもダメです．がんばることが目標になってもダメということです．
やはり目標とは「ある地点に到達すること」だと思います．どんなにがんばっても目標に到達できなければ意味がないわけですし，がんばらなくても目標に到達できればそれはそれでオッケーなわけです．手を抜け！とかサボれ！と言いたいわけではありません．がんばることで「がんばること」が正しいと錯覚してしまうこと，「がんばること」が目標になってしまうことを否定しているわけです．
●●継続せよ！
●V字モデル
この連載の中で一番反響の大きかった「V字モデル」ですが，考えてみると「考える→やってみる→失敗から学ぶ」というループの考え方（図3）は，結構たくさん存在していることに気が付きました．
「PLAN→DO→CHECK」という欧米の考え方から，「立法→行政→司法」という日本の政治の考え方まであります（注5）．
注5）日本の政治は，このループを縦割りにしてしまったことが問題かもしれません．これはあちらこちらで言われていることだと思いますが…．
●抜けてしまっているもの
皆さんは「考える→やってみる」までは理解して行動できているようですが，その次の「失敗から学ぶ」ことが抜けてしまうようです．失敗したら止めてしまうとか，失敗を恐れて危なくなる前に止めてしまうとか，インクリメンタルなループにならないケースが多いようです．
システム開発やプログラミングでも，設計して，コードの実装までは，皆さんきちんと行うのですが，そのあとのテストとなるとどうしてもおろそかになりがちです．納期が迫っているため時間がないというのが，おもな原因かもしれません．
筆者が思うのは，この点（テストをするかどうか）が，ポジティブなループに入るかネガティブなループに入るかの境目であるということです．
テストをしフィードバックすることができれば，それはポジティブなループになり，楽な方向に転がります．しかし，テストを軽視しフィードバックを怠ると，ネガティブなループに入り，苦しくなる方向に転がります．
まるで落下地点が1メートル違っただけで，太平洋に流れ着くか大西洋に流れ着くか決まってしまう水滴のようです．そうです．分水嶺です．この分水嶺を越えるべきなのです．
●●分割せよ！
●ありがちな分割の仕方
大きな問題は小さく分割して解決するのです．
しかし，多くの場合，この分割の仕方を間違えていると思います．どうしても機能ごとといいますか，縦に分割する癖があるようです．そうではなくて横に分割するべきなのです．何が縦で何が横なのかはっきりと明言しにくいのですが，図4を見てください．
V字モデルの「考える→やってみる→失敗から学ぶ」という概念のループが3層になっている状態を立体的に表しています．この立体の分割を考えるときに，縦に「考える」と「やってみる」と「失敗から学ぶ」の3つに分割してしまいやすいということなのです．「設計」して「コーディング」して「テスト」するとか．「設計」して「生産」して「販売」するとか．「立法」「行政」「司法」とか．
このように，ループを縦に分割すると，コミュニケーションのロスが多くなり問題が増えるのです．
●望ましい分割の仕方
そうではなく，ループを壊さないように，小さなループの単位に分割すべきであるといいたいのです．図3で言うと右側のイメージになります．このループを高速に回すことが大事なのです．
|
|
|
●●●三種の神器 |
|
|
最後に，筆者がシステム開発において大切だと思うモノを3つあげます．システム開発に関係のある方は，これらのことについてよく考えてみてください．その3つとは
・モチベーション
・コミュニケーション
・フィードバック
です．
|
|
|
●●モチベーション |
|
|
まずは「楽しみましょう」ということです．仕事が楽しくなければ仕事をする意味がないと思います．「現場」がキーになるでしょう．現場が楽しいことが大切です．
モチベーションを維持するには共感や感動が必要です．決して報酬や昇格ではありません．とくに管理者の人は気をつけるべきと思います（注6）．
以前，筆者はデスマーチの中でも仕事を少しでも楽しくやろうと心掛けていました．そのとき，上司から「笑いながら仕事をするな！」と怒られました．「なぜ？」と聞くと「誰も笑ってないだろ！真剣に仕事をしろ！」とのことです．そのとき，なぜこのチームがデスマーチになるのかがわかりました．そのチームでは「作業」をしているのです．黙々と何の感情を持たずに「機械の部品」になっているわけです．
人は誰も部品になることを望んではいないのです．まずは楽しいこと，そして行う仕事／作業が納得できることが大事なのです．難しい言葉を使うならミッション（あるべき姿）やビジョン（あろうとする姿）が必要ということです．そのミッションやビジョンが共感できなければ，現場のモチベーションは生まれません．そして達成感も感動も生まれないわけです．
クラーク博士の有名な
「Boys be ambtious ! （少年よ，大志を抱け）」
という言葉がピッタリとハマると思います．志（こころざし）です．これがないと仕事も人生も楽しめないと筆者は思っています．
注6）マズローの欲求段階説の5つのレベルの中に，報酬や昇格は含まれていません．筆者はこのマズロー説はかなり的を射た説だと思っています．
|
|
|
●●コミュニケーション |
|
|
大規模開発ではどうしても人数が多くなる傾向になり，コミュニケーションがおろそかになります．人数が多くなると指数的に情報のロスが発生するわけです．情報のロスはそのまま問題に発展します．
情報の伝達はとくに大事です．状況はつねに変化しています．情報が素早く正確に伝わることが大切なのです．どんなテクノロジよりも，ツールや方法論よりも，まずは身の回りの状況，そしてこれから進む方向を把握することが大事です．まずは足元を見ましょう．足元がふらついているのに，テクノロジや方法論を追い求めても，それは意味のないことなのです．
コミュニケーションが不足すると，顧客までの距離が遠くなります．顧客のメリットが見えていないと思います．顧客の顔が見えない仕事では社員のモチベーションももたないと思います．
|
|
|
●●フィードバック |
|
|
世界はつねに変化し続けています．変化を受け入れず，対応できなかった場合，恐竜のように滅んでいくことになります．
継続的な対応，臨機応変な態度が求められているわけです．ただし，基本理念（志）の部分は変えてはいけません．なんでもかんでも変えるべきではなく，コアな部分ではしっかりと根を張り，枝葉の部分は大胆かつ柔軟に変えていくということです．正解はありません．万能なツールも，万能な方法論もありません．
あえて繰り返すなら，万能なツールは1つあります．それは，あなたの頭脳です．筆者の頭脳でも天才の頭脳でもなく，あなたの頭脳です．あなたの頭脳はあなたのものです．自由にいくらでも使えます．誰にも邪魔されることはありません．好きなときに好きなだけ使えます．
「適材適所」という言葉もあります．どんなツールもどんな方法論も，その能力に適した場所，その能力を活かすことのできる機会があるということです．逆に言えば，合っていないところではその能力を十分に発揮できないということです．
マクロな視点からつねに考え続けること．流れを見張ることが大切なのです．「治水」という言葉があります．現在ではあまり聞かなくなりましたが，川が氾濫しないように土手を造ったり，生活用の水路を造ったりして，水の流れ全体を見守ること，整え続けることを意味する言葉です．筆者がこのフィードバックの項目で言いたいことは，システム開発において「治水をしましょう」ということなのです．
|
|
|
●●●人生を語る |
|
|
どうでしょう．システム開発には，技術力やテクニック，ツールや方法論，人や根性だけでは足りませんね．失敗はしたほうがいいし，会議が多ければいいわけでもない．ましてや，マニュアルや手順がすべてでもない．必要条件ではあっても十分条件ではないわけです．
周りではなく自分がどう考えて，どう行動するか．そこが大切だと筆者は思います．
●失敗をしろ！
失敗を恐れるな．筆者は，とくにこの点を強調したいと思います．誰でも最初は失敗します．失敗という言葉に負けてはいけない，恐れてはいけないと思うのです．
「七転び八起き」という言葉があります．逆に言えば，8回のうち7回は失敗するということです．
あきらめてはいけません．とにかくあきらめないことです．あきらめなければそれは失敗ではないのです．その失敗はかならず次の挑戦の役に立ちます．何も挑戦せずにあきらめてしまうことが「本当の失敗」なのです．
生まれたときから泳げる人はいません．自転車に乗ることだって，バットをボールに当てることだって，パンにバターを塗ることだって，みんな最初はできないのです．失敗を繰り返しながら覚えたのです．汗を流しながら，ときには涙を流しながら，一歩ずつ階段を昇ってきたわけです．挑戦しなかった人は大人になってもできないし，挑戦し続けた人だけができるようになるのです．誰もズルなんてしていません．お金を払えば買えるモノでもないのです．
●お金で買えない
人生そのものもお金では買えませんが，世の中にはお金で買えないモノがたくさんあります．健康，家族，愛情，親友，友人，信頼，尊敬，体験，感動，達成感，充実感，時間，機会，志，技，才能，センス，考え方，ひらめき，発想，自尊心…，まだまだ考えれば出てくると思いますが，お金で買えるモノより大切なモノが多いのです．そのことに気がついていない人も結構多いような気もします．
|
|
|
●●人生に必要なモノ |
|
|
今筆者が「人生にはこれが大切なのではないだろうか」と思うモノを，3つ挙げておきます．
・自制心：自分の頭で考えて判断すること．自分をコントロールし継続できる強い意志．これらを持続し，つねに考え，コントロールし続けることです．
・自立心：自分の足で立って歩くこと．誠実さと信念をもって行動すること．これらを持続し，あきらめずに歩き続けることです．人生に失敗はないのです．
・楽しむ：体感すること，幸せを感じるとることです．自分が楽しまなければ始まらないのです．そして，その楽しさを人に分けてあげられれば，その人の人生は幸せだと思うのです．
|
|
|
●●●本当の最後に |
|
|
この連載では，システム開発におけるさまざまな事柄について書いてきました．中でも常識から外れたことや理論的ではない感覚的なことも書いていたと思います．この業界では，「直感」とか「勘」や「センス」という考え方はどちらかと言えば排除される傾向にあります．しかし，筆者はあえてその部分を重視してきたつもりです．
そのことが正しいとか間違っているとかが言いたいのではなくて，常識と思われていることであっても本当にそれでいいのだろうかとか，無意識にやっていることが本当に顧客のためになっているのだろうか，といった「疑問の投げかけ」がしたかったわけです．つねに考え続ける姿勢が必要ではないかと言いたかったわけです．
「人間は考える葦である」と言われます．逆に言えば「考えない人間はただの葦である」ということにもなります．そして「思考は現実化する」とも言われます．今の世界がこれだけの社会として現実化しているのは，今日まであらゆる人が一生懸命考えた結果であるとも言えます．
考えることに終わりはないのです．最後の最後まで考えましょう．それが人生であり，そうすることが楽しいのですから．
|
|
おさらい【最終回】