本を読むのも仕事のうち、ではなくて本を読まなきゃ仕事にならない
ソフトウェア開発において、技術書を読むということは、やった方がいいことというレベルではなくて、必須の業務である。
仕事とはアウトプットを出す事である。しかし、そのために必要なインプットも当然仕事のうちである。ソフトウェア開発においては、読書という行為は、事前にやっておくとか、業務時間外にやるというのがなぜか前提になっていることが多い。
ただ、業務時間外に本を読むような人は、自己学習スキルのある人で、ほったらかしにしてもスキルがどんどんついていくのである。「男子三日会わざれば刮目して見よ」を地で行く人たちである。
上記のように本を読む人たちばかりなら何も懸念しなくてよいのだ。逆に言えば、そんな人たちはあまりいないということだ。「そんなプログラマはだめだ」という意見はよく聞くが、現に働いているのだからどうにかしないといけない。
現実解としては、仕事として強制的に業務時間内に本を読ませて、今回のプロジェクトで最低限必要な知識を頭の中に入れてもらう。チームで開発して、一人一人が個別に開発するよりもメリットを出そうとすれば、前提となる知識をあわせざるを得ない。
本を読むというと、勉強というイメージを持つ人もいるが、技術書はカタログなので、とりあえず全体に目を通して、どこに何が書いてあったかだけ覚えておいて、細部は必要になったらもう一度開くというのがいいのかなと思う。
本は高いからWEBでという人も最近は多いが、WEBだけで取れる情報には限界があるし、情報の取得に時間がかかると感じている。とりあえずWEBで検索して、もっと詳細な情報が欲しいと思ったら、情報が載っている本を探して購入している。
といっても、何冊も買っていると、趣味が技術書を読むこと、というような人以外は足が出る。立ち読みではなくて本は手元においておきたい。ぜひ会社が本を支給すべきである。プロジェクトに必要な本をマネージャか優秀なプログラマが選定して、全員に買い揃えて頂きたい。外部に講習に行かせるよりはかなり安上がりだろう。
気をつけないといけないのは、個別に「読んどけ」というだけでは読まない、もしくは読んでも何も身に付いていないということだ。チームで同時に読む、もしくは読んだはずのところを質問したりして、本を読むのは仕事であるという認識をじわりじわりと浸透させていこう。
そうすれば、いつのまにか本を読む習慣がついて、強制しなくても勝手に成長していくプログラマがまた１人増えていくかもしれない。と淡い期待をしてみる。
仕事とはアウトプットを出す事である。しかし、そのために必要なインプットも当然仕事のうちである。ソフトウェア開発においては、読書という行為は、事前にやっておくとか、業務時間外にやるというのがなぜか前提になっていることが多い。
ただ、業務時間外に本を読むような人は、自己学習スキルのある人で、ほったらかしにしてもスキルがどんどんついていくのである。「男子三日会わざれば刮目して見よ」を地で行く人たちである。
上記のように本を読む人たちばかりなら何も懸念しなくてよいのだ。逆に言えば、そんな人たちはあまりいないということだ。「そんなプログラマはだめだ」という意見はよく聞くが、現に働いているのだからどうにかしないといけない。
現実解としては、仕事として強制的に業務時間内に本を読ませて、今回のプロジェクトで最低限必要な知識を頭の中に入れてもらう。チームで開発して、一人一人が個別に開発するよりもメリットを出そうとすれば、前提となる知識をあわせざるを得ない。
本を読むというと、勉強というイメージを持つ人もいるが、技術書はカタログなので、とりあえず全体に目を通して、どこに何が書いてあったかだけ覚えておいて、細部は必要になったらもう一度開くというのがいいのかなと思う。
本は高いからWEBでという人も最近は多いが、WEBだけで取れる情報には限界があるし、情報の取得に時間がかかると感じている。とりあえずWEBで検索して、もっと詳細な情報が欲しいと思ったら、情報が載っている本を探して購入している。
といっても、何冊も買っていると、趣味が技術書を読むこと、というような人以外は足が出る。立ち読みではなくて本は手元においておきたい。ぜひ会社が本を支給すべきである。プロジェクトに必要な本をマネージャか優秀なプログラマが選定して、全員に買い揃えて頂きたい。外部に講習に行かせるよりはかなり安上がりだろう。
気をつけないといけないのは、個別に「読んどけ」というだけでは読まない、もしくは読んでも何も身に付いていないということだ。チームで同時に読む、もしくは読んだはずのところを質問したりして、本を読むのは仕事であるという認識をじわりじわりと浸透させていこう。
そうすれば、いつのまにか本を読む習慣がついて、強制しなくても勝手に成長していくプログラマがまた１人増えていくかもしれない。と淡い期待をしてみる。
プログラマしかいない開発チームは、ドラクエでいうと戦士ばかりのパーティってことだ
小規模なソフトウェア開発プロジェクトだと、集められるスタッフは、プログラマばっかりということがある。プログラムを作るのだから、プログラマが必要なのはその通りだが、それ以外の工程もいっぱいあるのだ。
プログラマばかりで開発するということは、プログラムは当然プログラマが書いて、HTMLもプログラマが書いて、SQLもプログラマが書いて、サーバ環境もプログラマが設定して、テストもプログラマがやって、ドキュメントもプログラマが書くということだ。
だいたい、そういう場合はどこかでうまくいかなくなるか、稀になんでもこなしてしまうスタッフが１人いるために、なんとなくうまくいってしまうことがある。
前者の失敗した場合は、専門家が必要だよねということになりやすい。後者のなんとなく成功した場合は、成功体験があるだけに性質が悪い。次回も同じようなやり方をして、うまくいかなかった場合は、スキルのあるスタッフがいないから失敗した、と責任転嫁しがちである。
俗人的だとか天才的なスタッフがいないと成功しないとか、そういうことをいう前に、もう少しプロジェクトの人員構成を考えた方がよい。
プロジェクトを通して必要な人員は最小限でよく、後は必要な時に必要な職業の人を活用すべきである。すでにフレームワークがあるなら、プログラマは専属で必要なく、本当に必要なのは定義ファイル等をメンテナンスして、サービスが正常に動くかどうかを確認する定義ファイル管理者かもしれない。
ただ、現実には必要な人を必要な時に活用するのは難しい。酒場に行けばいつでもスタッフを変更できるゲームとは違う。スキルのある人は抱えつづけていないと、すぐに他社に取られてしまう。どうやってスキルのある人とコネクションを張りつづけるか、というのも会社の資産の１つとなるだろう。
また、プロジェクトに必要なスキルをもう少ししっかり見極めて細分化して求めないと、雇う側と雇われる側のミスマッチが広がるばかりである。どういうスキルは即戦力で必要なのか、どういうスキルは社内で育てるのか。その戦略もないまま、スタッフに丸投げでは会社に何も残らない。
何でも出来る人は確かにコストパフォーマンスがいいが、そういうすごい人がいなくても、なんとかプロジェクトが回るようにしないといけない。必要なスキルを集めて、プロジェクトを成功に導く。これはスポーツや映画でいうところの監督にあたる人なのだろうか。
監督不在、これが今のソフトウェア業界の現実かもしれない。まずは現場監督である。それはプログラマの上位スキルではなく、まったく別のスキルであるということを理解して、さっさと新人のころから教育する方がよい。
大卒から働かせて、5,6年IT業界に残った人を監督にするというキャリアパスでは、いつまでたっても人材不足が解消されない。スキル標準もいいが、そのスキルを身につけた人を活かす人材がいないと意味がないと思うのだが。
プログラマばかりで開発するということは、プログラムは当然プログラマが書いて、HTMLもプログラマが書いて、SQLもプログラマが書いて、サーバ環境もプログラマが設定して、テストもプログラマがやって、ドキュメントもプログラマが書くということだ。
だいたい、そういう場合はどこかでうまくいかなくなるか、稀になんでもこなしてしまうスタッフが１人いるために、なんとなくうまくいってしまうことがある。
前者の失敗した場合は、専門家が必要だよねということになりやすい。後者のなんとなく成功した場合は、成功体験があるだけに性質が悪い。次回も同じようなやり方をして、うまくいかなかった場合は、スキルのあるスタッフがいないから失敗した、と責任転嫁しがちである。
俗人的だとか天才的なスタッフがいないと成功しないとか、そういうことをいう前に、もう少しプロジェクトの人員構成を考えた方がよい。
プロジェクトを通して必要な人員は最小限でよく、後は必要な時に必要な職業の人を活用すべきである。すでにフレームワークがあるなら、プログラマは専属で必要なく、本当に必要なのは定義ファイル等をメンテナンスして、サービスが正常に動くかどうかを確認する定義ファイル管理者かもしれない。
ただ、現実には必要な人を必要な時に活用するのは難しい。酒場に行けばいつでもスタッフを変更できるゲームとは違う。スキルのある人は抱えつづけていないと、すぐに他社に取られてしまう。どうやってスキルのある人とコネクションを張りつづけるか、というのも会社の資産の１つとなるだろう。
また、プロジェクトに必要なスキルをもう少ししっかり見極めて細分化して求めないと、雇う側と雇われる側のミスマッチが広がるばかりである。どういうスキルは即戦力で必要なのか、どういうスキルは社内で育てるのか。その戦略もないまま、スタッフに丸投げでは会社に何も残らない。
何でも出来る人は確かにコストパフォーマンスがいいが、そういうすごい人がいなくても、なんとかプロジェクトが回るようにしないといけない。必要なスキルを集めて、プロジェクトを成功に導く。これはスポーツや映画でいうところの監督にあたる人なのだろうか。
監督不在、これが今のソフトウェア業界の現実かもしれない。まずは現場監督である。それはプログラマの上位スキルではなく、まったく別のスキルであるということを理解して、さっさと新人のころから教育する方がよい。
大卒から働かせて、5,6年IT業界に残った人を監督にするというキャリアパスでは、いつまでたっても人材不足が解消されない。スキル標準もいいが、そのスキルを身につけた人を活かす人材がいないと意味がないと思うのだが。
仕様を増やすばかりのえらい人は火種を抱えていることに気づいていない
Software Desine 2005/3 「Pacific Connection Firefoxの教訓」より
---
「僕たちは基本的に、やんわりと断ることにしていた。『オーケー、君のインプットは尊重したいと思うけれど、製品については今日中にトップの5人が結論を出すから』というわけだ。旧来のモデルでは、アイデアと技術的なノウハウがある人なら誰でも、抵抗を受けずに実装できた。けれども、それではソフトウェアは膨らんでいき、上級ユーザでも理解できないような込み入ったインターフェースになってしまう。
他のオープンソース開発チームに僕が示せるベストなアドバイスは－というのも、他の多くのプロジェクトを同じ問題に苛まれているからだけれど－、決定は厳しく下すべしということだ。方針を変更すれば、コミュニティからは最初は反発も出るだろう。けれども、すぐに厚い皮膜ができるし、製品もより良いものになる。」
---
もう１つ、梅田望夫・英語で読むITトレンド Macromediaはいかにしてインターネットに対応したかより
---
詰め込むべき機能のアイデアに対して、テクノロジストのJon Gayがただひちすら「ノー」と言い続けたことがカギだったという話。共感される方も多いのではないかと思う。
---
ソフトウェアというものは、放置していると必ず機能が増えていく。プログラムの中に入れておいても問題ないのに、メンテナンスが楽だからという理由で、データをデータベースから読み込んだり、固定サイズでいいのに、可変長に対応したりする。
また、サービス精神旺盛なプログラマは、より便利になるからという理由で、機能を追加したりすることもあるかもしれない。顧客が便利になるのはいいことである、ということに疑う余地はないが、自分のリソースを注ぎ込んでまでやるべきかどうかのトレードオフについては考慮していない。
責任者は本来であれば、どれだけプログラマのモチベーションが高くても、機能を実装する優先順位を決めて、とにかくソフトウェアをシンプルに保つべきである。責任者自らが率先して機能を追加しようとするのはもっての外だ。
これは、アジャイル開発でいうところのYAGNI（You Aren't Gonna Need It!）なのだが、プログラムレベルの細かい話と思われているのか、あまり重要視されていないような気がする。
ソフトウェアをシンプルに保てるかどうか、というのはそのまま品質に直結する。仕様を決めるのが責任者の仕事なら、仕様を減らすのも責任者の仕事である。どうやったら機能を減らしつつ、アプリケーションの価値を保てるか、ということに力を注がなければならない。
シンプルに保つことに頭を使わずに、便利だから追加する、顧客に言われたから追加する、後で必要になるかもしれないから追加する（最悪！）という責任者の下では、ソフトウェアはいつまでたっても完成しないしバグだらけになるだろう。
この問題は作業しているプログラマでは解決できない問題である。そこに仕様があるから作る、となってしまう。逆に仕様を削る責任者の方が、自分のやりたいことをさせてくれない嫌な上司となってしまうかもしれない。
プログラマに好き勝手にさせる丸投げ責任者では、ソフトウェアは完成に向かっているようで破綻に向かっていてもわからない。かといって、がちがちに仕様を固めて厳格に守らせるような責任者でも駄目である。
大まかに仕様を守りつつ、途中でも必要なところは追加し、必要ないところは切り落としていく、というプロジェクトをドライブする能力が責任者には必要なのである。
なぜ完成まで至らずに終わるプロジェクトが多いのか、貴重な時間を何に費やしているのか、本当に大事なものはなんなのか、もう少し真剣に考えてもいいかもしれない。
---
「僕たちは基本的に、やんわりと断ることにしていた。『オーケー、君のインプットは尊重したいと思うけれど、製品については今日中にトップの5人が結論を出すから』というわけだ。旧来のモデルでは、アイデアと技術的なノウハウがある人なら誰でも、抵抗を受けずに実装できた。けれども、それではソフトウェアは膨らんでいき、上級ユーザでも理解できないような込み入ったインターフェースになってしまう。
他のオープンソース開発チームに僕が示せるベストなアドバイスは－というのも、他の多くのプロジェクトを同じ問題に苛まれているからだけれど－、決定は厳しく下すべしということだ。方針を変更すれば、コミュニティからは最初は反発も出るだろう。けれども、すぐに厚い皮膜ができるし、製品もより良いものになる。」
---
もう１つ、梅田望夫・英語で読むITトレンド Macromediaはいかにしてインターネットに対応したかより
---
詰め込むべき機能のアイデアに対して、テクノロジストのJon Gayがただひちすら「ノー」と言い続けたことがカギだったという話。共感される方も多いのではないかと思う。
---
ソフトウェアというものは、放置していると必ず機能が増えていく。プログラムの中に入れておいても問題ないのに、メンテナンスが楽だからという理由で、データをデータベースから読み込んだり、固定サイズでいいのに、可変長に対応したりする。
また、サービス精神旺盛なプログラマは、より便利になるからという理由で、機能を追加したりすることもあるかもしれない。顧客が便利になるのはいいことである、ということに疑う余地はないが、自分のリソースを注ぎ込んでまでやるべきかどうかのトレードオフについては考慮していない。
責任者は本来であれば、どれだけプログラマのモチベーションが高くても、機能を実装する優先順位を決めて、とにかくソフトウェアをシンプルに保つべきである。責任者自らが率先して機能を追加しようとするのはもっての外だ。
これは、アジャイル開発でいうところのYAGNI（You Aren't Gonna Need It!）なのだが、プログラムレベルの細かい話と思われているのか、あまり重要視されていないような気がする。
ソフトウェアをシンプルに保てるかどうか、というのはそのまま品質に直結する。仕様を決めるのが責任者の仕事なら、仕様を減らすのも責任者の仕事である。どうやったら機能を減らしつつ、アプリケーションの価値を保てるか、ということに力を注がなければならない。
シンプルに保つことに頭を使わずに、便利だから追加する、顧客に言われたから追加する、後で必要になるかもしれないから追加する（最悪！）という責任者の下では、ソフトウェアはいつまでたっても完成しないしバグだらけになるだろう。
この問題は作業しているプログラマでは解決できない問題である。そこに仕様があるから作る、となってしまう。逆に仕様を削る責任者の方が、自分のやりたいことをさせてくれない嫌な上司となってしまうかもしれない。
プログラマに好き勝手にさせる丸投げ責任者では、ソフトウェアは完成に向かっているようで破綻に向かっていてもわからない。かといって、がちがちに仕様を固めて厳格に守らせるような責任者でも駄目である。
大まかに仕様を守りつつ、途中でも必要なところは追加し、必要ないところは切り落としていく、というプロジェクトをドライブする能力が責任者には必要なのである。
なぜ完成まで至らずに終わるプロジェクトが多いのか、貴重な時間を何に費やしているのか、本当に大事なものはなんなのか、もう少し真剣に考えてもいいかもしれない。
理屈で選べない選択肢を自分の責任で決める覚悟がないと仕事にならない
ソフトウェア開発で難しいのが、序盤から中盤にかけての、「無数に選択肢がある中でどれを選ぶか」の判断である。
何が難しいのかというと、ある程度取捨選択した後、残りいくつかの方法は、どれを選んでも大差ないということがある。その場合に、後で「なぜこの方法を選んだのか、理由を述べよ」と言われたときに、説明できないため選択を躊躇してしまうのだ。
いわゆる「先延ばし」である。これが１つであれば、まだがんばっていろいろ説明材料を探そうという話になるのだが、ソフトウェア開発は、このような「複数のうちどれを選んでもいいけど、決めないと次に進めない」ことが多数あるので、決められない人は誰かに決めて欲しいと思ってしまう。
仕様がなかなか決まらないのは、以前にも書いたかもしれないが、ほとんどが「どっちでもいいと思うんだけど、決めると責任を取らないといけないので言わない」というチキンレース状態に陥るからである。
この場合、顧客や開発側の責任者は「どっちがいいかわからない（わからないからどっちでもいいと言われても決められない）」状態であり、知識のあるプログラマなら「どっちでもいいけどどっちかに決めて欲しい（後で文句言われたら困る）」という心理状態である。
顧客は解らないから、開発側で決めて欲しい、というかもしれない。開発側の責任者は、その場では判断できないので持ち帰らせて欲しいとなる。その場では解らないとはとても言えないからだ。
万事この調子では、仕様スケジュールは遅延する一方である。どうすれば理想的な解決策ができるだろうか。
これは、もうプログラマが腹を括るしかないと思う。責任を取りたくないというのは、ある意味仕事の放棄だからだ。勝手に決めてもたぶん全体に影響がないと思われるところについては、どんどん勝手に決めるべきだろう。
その時に、とりえる選択肢が無数にあったって構わないのである。細かいものはいちいちレポート書くほどのこともない。後で、決めた理由を尋ねられたら「私の判断で決めました」と言えばいいのである。判断が気に入らないのなら、そこで初めて、じゃぁあなたが決めてくれという話である。
本などで知識を得て博学になると、逆に理屈では選択できない項目について、判断できなくなってしまうことがある。理屈で判断できるのであれば、それは最適解があるわけなので、覚悟はいらない。
理屈抜きで何かを選ぶ時に必要な感覚は、「俺の好み」とか、「こちらの方が美しい」とかそういう感覚である。あるいは「適当」「サイコロで決めた」でもいいのである。自分で選択して自分で責任を取ればいいのだ。
責任を取るというのは、「選択したのは私です」と宣言することぐらいである。選択を他人のせいにしないのが責任の取り方である。
それ以外は、結局やることは同じで、直すものは直さないといけないし、トラブったら徹夜で対応しないといけないのは変わらない。他人が選択して失敗するくらいなら、自分で選んでしまった方がいいと思うのだが。
責任を自分でとるようになると、言われた事だけをやる人から昇格して、自分で動く人になれる。レベルアップである。スキルアップだけではいつまで経っても昇格できない。スキルを磨くのも大事だが、レベルもあげていこう。
何が難しいのかというと、ある程度取捨選択した後、残りいくつかの方法は、どれを選んでも大差ないということがある。その場合に、後で「なぜこの方法を選んだのか、理由を述べよ」と言われたときに、説明できないため選択を躊躇してしまうのだ。
いわゆる「先延ばし」である。これが１つであれば、まだがんばっていろいろ説明材料を探そうという話になるのだが、ソフトウェア開発は、このような「複数のうちどれを選んでもいいけど、決めないと次に進めない」ことが多数あるので、決められない人は誰かに決めて欲しいと思ってしまう。
仕様がなかなか決まらないのは、以前にも書いたかもしれないが、ほとんどが「どっちでもいいと思うんだけど、決めると責任を取らないといけないので言わない」というチキンレース状態に陥るからである。
この場合、顧客や開発側の責任者は「どっちがいいかわからない（わからないからどっちでもいいと言われても決められない）」状態であり、知識のあるプログラマなら「どっちでもいいけどどっちかに決めて欲しい（後で文句言われたら困る）」という心理状態である。
顧客は解らないから、開発側で決めて欲しい、というかもしれない。開発側の責任者は、その場では判断できないので持ち帰らせて欲しいとなる。その場では解らないとはとても言えないからだ。
万事この調子では、仕様スケジュールは遅延する一方である。どうすれば理想的な解決策ができるだろうか。
これは、もうプログラマが腹を括るしかないと思う。責任を取りたくないというのは、ある意味仕事の放棄だからだ。勝手に決めてもたぶん全体に影響がないと思われるところについては、どんどん勝手に決めるべきだろう。
その時に、とりえる選択肢が無数にあったって構わないのである。細かいものはいちいちレポート書くほどのこともない。後で、決めた理由を尋ねられたら「私の判断で決めました」と言えばいいのである。判断が気に入らないのなら、そこで初めて、じゃぁあなたが決めてくれという話である。
本などで知識を得て博学になると、逆に理屈では選択できない項目について、判断できなくなってしまうことがある。理屈で判断できるのであれば、それは最適解があるわけなので、覚悟はいらない。
理屈抜きで何かを選ぶ時に必要な感覚は、「俺の好み」とか、「こちらの方が美しい」とかそういう感覚である。あるいは「適当」「サイコロで決めた」でもいいのである。自分で選択して自分で責任を取ればいいのだ。
責任を取るというのは、「選択したのは私です」と宣言することぐらいである。選択を他人のせいにしないのが責任の取り方である。
それ以外は、結局やることは同じで、直すものは直さないといけないし、トラブったら徹夜で対応しないといけないのは変わらない。他人が選択して失敗するくらいなら、自分で選んでしまった方がいいと思うのだが。
責任を自分でとるようになると、言われた事だけをやる人から昇格して、自分で動く人になれる。レベルアップである。スキルアップだけではいつまで経っても昇格できない。スキルを磨くのも大事だが、レベルもあげていこう。
プログラマとしてのレベルをあげるには
社会人になってからプログラマになった人は、１人で最初から最後まで作るということを経験したことがない人がいるかもしれない。
設計書がすでにあって、その一部分を任せられるところからステップアップして、だんだん設計の一部を任されていったりして、そのままプログラマを卒業してしまうのかもしれない。
プログラマとして何年経験があったとしても、一部分だけを任されているだけではスキルがなかなか身につかない。というのは、ソフトウェアをどう設計して、どう分割して実装するかというのが一番の肝の部分だからである。
ずっと一部分だけを請け負っていて、ある日突然、君は経験○年だからそろそろ全体を仕切ってくれたまえ、と言われてもたぶん手も足も出ないのでは無いかと思う。破綻するプロジェクトというのは、経験○年だからこの人に任せれば大丈夫と、経験年数だけで判断したケースが多いように思う。というか実際良く見かける。
ではどうすればいいのか。経験の積ませ方としては、一部分を任せるのではなくて、小さいソフトウェアを１から最後まで面倒を見させるということではないかと思う。サンプルとして使うものではなくて、実際に現場で運用ツールとして使うものであったり、開発時に必要なツールであったり、ちゃんと開発者にフィードバックがあるものが理想である。
実際、どれだけ小さいソフトウェアでも、自分で考えて作った後、皆からあちこち仕様変更を言われることで、どのように作っておくのがよかったのか、という自己学習ができるのである。
また、仕様変更する度に「それは３日かかります」とか「それは最初から作り直しになります」とか言う開発者に対しては、仕様変更に強いプログラミングというのはどういうものかというのを教える場にもなる。
最初からいっしょにペアプログラミングでリファクタリングをするのもいいと思うが、一度自分で考えてプログラミングしてみて、現場で求められるものとのギャップというのを直に経験しないとなかなか頭に染み付かないのではないかと思う。
自分はこう思うと思ってソフトウェアを作っても、ことごとく仕様が変更されるだろう。自分の思いに反して仕様が変更された部分というのが、ある意味次にソフトウェアを作る際のノウハウになるわけである。このノウハウは一部分だけ作っていてもなかなかたまらない。全体を構築して、破壊されて、を繰り返す中にのみ存在するものである。
そういう意味で、ソフトウェア全体を構築した経験がない人がSEという名のもとに設計作業に勤しむというのは、何かが矛盾しているんではないかという気がしている。できるという人もいるのだが、最終的にプログラマに任せちゃってますよね、と思ったりするのですけれども。
設計書がすでにあって、その一部分を任せられるところからステップアップして、だんだん設計の一部を任されていったりして、そのままプログラマを卒業してしまうのかもしれない。
プログラマとして何年経験があったとしても、一部分だけを任されているだけではスキルがなかなか身につかない。というのは、ソフトウェアをどう設計して、どう分割して実装するかというのが一番の肝の部分だからである。
ずっと一部分だけを請け負っていて、ある日突然、君は経験○年だからそろそろ全体を仕切ってくれたまえ、と言われてもたぶん手も足も出ないのでは無いかと思う。破綻するプロジェクトというのは、経験○年だからこの人に任せれば大丈夫と、経験年数だけで判断したケースが多いように思う。というか実際良く見かける。
ではどうすればいいのか。経験の積ませ方としては、一部分を任せるのではなくて、小さいソフトウェアを１から最後まで面倒を見させるということではないかと思う。サンプルとして使うものではなくて、実際に現場で運用ツールとして使うものであったり、開発時に必要なツールであったり、ちゃんと開発者にフィードバックがあるものが理想である。
実際、どれだけ小さいソフトウェアでも、自分で考えて作った後、皆からあちこち仕様変更を言われることで、どのように作っておくのがよかったのか、という自己学習ができるのである。
また、仕様変更する度に「それは３日かかります」とか「それは最初から作り直しになります」とか言う開発者に対しては、仕様変更に強いプログラミングというのはどういうものかというのを教える場にもなる。
最初からいっしょにペアプログラミングでリファクタリングをするのもいいと思うが、一度自分で考えてプログラミングしてみて、現場で求められるものとのギャップというのを直に経験しないとなかなか頭に染み付かないのではないかと思う。
自分はこう思うと思ってソフトウェアを作っても、ことごとく仕様が変更されるだろう。自分の思いに反して仕様が変更された部分というのが、ある意味次にソフトウェアを作る際のノウハウになるわけである。このノウハウは一部分だけ作っていてもなかなかたまらない。全体を構築して、破壊されて、を繰り返す中にのみ存在するものである。
そういう意味で、ソフトウェア全体を構築した経験がない人がSEという名のもとに設計作業に勤しむというのは、何かが矛盾しているんではないかという気がしている。できるという人もいるのだが、最終的にプログラマに任せちゃってますよね、と思ったりするのですけれども。
正論だけではすまないから交渉力が求められる
どんなソフトウェアでも、「あと、これがあれば完璧なのになぁ」と思う事は多いと思う。「なんでこんな簡単な機能がないんだろう」とか「これが出来ればすごく楽なのに」と考えるのは日常茶飯事である。
落ち着いて考えると、そのソフトウェアをあなたは利用しているのである。利用している上で、よりよい機能を欲しがっている。もし直接開発している人に連絡が取れるのであれば、それを伝えるだろう。
それは利用者から開発者へのフィードバックであり、開発者がそれはいい提案であると思えば、次のリリースでその機能は実装される。開発者側に実装する機能の選択権があればの話だが。
問題は、受託開発の場合、出来上がる前のソフトウェアでも、顧客は上の話と同じ思考パターンで開発者に要求を出してくるということだ。当然、仕様書には書いていないことについてもである。
開発者側には、ここで交渉力が問われるのである。仕様書に書いてないからやりません、契約範囲外です、とずばっと言いたいところなのだが、その機能がないと確かに不便なので使いにいくというのも事実、ということが往々にしてあるからだ。
わかっているだけに開発側も作りたいが、納期が伸びる、予算が増える。顧客と交渉しても納期が伸びたり、予算が増えたりするかしないかは交渉次第だ。ここでよくあるのは次の仕事に金額を上乗せするから、今回はこのまま機能だけ追加してくれというパターンだ。
また、次の仕事も予定が詰まっているので、仕様書にないからやらないといっても今回の開発分のお金はもらえるだろうが、顧客の心情を悪くすると次回はないかもしれない。あの会社はちょっとした顧客の頼みを聞いてくれない冷たい会社だと、ネガティブな口コミ情報が流れるかもしれない。
最初にちゃんと要求分析しないからダメだ、とかよく言われるのだけれども、やはり顧客は実物に触るまで感覚的に理解できないため、あらかた出来上がってからいろいろ要求が出るのは当然なのだと思う。
要はその時に、どう顧客を納得させて次に繋げるか、という大人の対応が交渉力であり、交渉力に劣ると、どれだけ素晴らしい技術力があっても顧客に不満が残る。
最後は交渉力でカバーすると言うと、技術屋的にはすごい嫌悪感を持つ人がいるが、他人に納得してもらってなんぼである。ダメなソフトウェアを騙して買ってもらうということではなくて、一生懸命作ったいいソフトウェアを納得して使ってもらうために必要なのである。
何も説明しなくても解る人には解るとか言ってたら、より粗悪なソフトウェアに交渉力だけで負けてしまう事もあるのだ。だからプログラマは交渉力を磨いて、いいものが駆逐されないように頑張らないといけない。
喋りだけが達者で中身が何も無い人よりも、喋りも中身もある人の方がいいに決まっている。喋りが達者じゃなくても中身があればいいと思っているプログラマは、少し方針を転換して、喋り（漫才ネタではなくてここでは交渉力）のスキルがあればより自分も相手も幸せに出来るかもと思って頂ければ幸いである。
落ち着いて考えると、そのソフトウェアをあなたは利用しているのである。利用している上で、よりよい機能を欲しがっている。もし直接開発している人に連絡が取れるのであれば、それを伝えるだろう。
それは利用者から開発者へのフィードバックであり、開発者がそれはいい提案であると思えば、次のリリースでその機能は実装される。開発者側に実装する機能の選択権があればの話だが。
問題は、受託開発の場合、出来上がる前のソフトウェアでも、顧客は上の話と同じ思考パターンで開発者に要求を出してくるということだ。当然、仕様書には書いていないことについてもである。
開発者側には、ここで交渉力が問われるのである。仕様書に書いてないからやりません、契約範囲外です、とずばっと言いたいところなのだが、その機能がないと確かに不便なので使いにいくというのも事実、ということが往々にしてあるからだ。
わかっているだけに開発側も作りたいが、納期が伸びる、予算が増える。顧客と交渉しても納期が伸びたり、予算が増えたりするかしないかは交渉次第だ。ここでよくあるのは次の仕事に金額を上乗せするから、今回はこのまま機能だけ追加してくれというパターンだ。
また、次の仕事も予定が詰まっているので、仕様書にないからやらないといっても今回の開発分のお金はもらえるだろうが、顧客の心情を悪くすると次回はないかもしれない。あの会社はちょっとした顧客の頼みを聞いてくれない冷たい会社だと、ネガティブな口コミ情報が流れるかもしれない。
最初にちゃんと要求分析しないからダメだ、とかよく言われるのだけれども、やはり顧客は実物に触るまで感覚的に理解できないため、あらかた出来上がってからいろいろ要求が出るのは当然なのだと思う。
要はその時に、どう顧客を納得させて次に繋げるか、という大人の対応が交渉力であり、交渉力に劣ると、どれだけ素晴らしい技術力があっても顧客に不満が残る。
最後は交渉力でカバーすると言うと、技術屋的にはすごい嫌悪感を持つ人がいるが、他人に納得してもらってなんぼである。ダメなソフトウェアを騙して買ってもらうということではなくて、一生懸命作ったいいソフトウェアを納得して使ってもらうために必要なのである。
何も説明しなくても解る人には解るとか言ってたら、より粗悪なソフトウェアに交渉力だけで負けてしまう事もあるのだ。だからプログラマは交渉力を磨いて、いいものが駆逐されないように頑張らないといけない。
喋りだけが達者で中身が何も無い人よりも、喋りも中身もある人の方がいいに決まっている。喋りが達者じゃなくても中身があればいいと思っているプログラマは、少し方針を転換して、喋り（漫才ネタではなくてここでは交渉力）のスキルがあればより自分も相手も幸せに出来るかもと思って頂ければ幸いである。
「そんなバグたいしたことないですよ」と思っていても口に出してはいけない
プログラマに限った事ではなく、えてして技術に長けた人は、物事の重大さというのを、技術的に難しいか否かで判断する傾向がある。
そして、納品後に不具合が出た場合、簡単に直せそうだと思うと、「そんなバグはたいしたことはない」という発言に繋がる。顧客から見ると、簡単に直せるか、難しいかは関係なく、不具合は不具合なのである。
顧客の価値基準は、うまく動いているかどうかであり、次のページに進めなかったり、入力した値が保存されてなかったり、どこか１つでもおかしければ、それは不良品という認識になる。
こんな簡単なバグで不良品とか言われるのはおかしい、一生懸命作ったのに、と思うプログラマはもう少し考えた方がいい。簡単かどうかは外からは見てわからないので、作った人がいないと、一生動かないシステムになる可能性だってあるのだ。
とにかく、どんなに理論的に設計が優れていても、エレガントな実装でも、動かなければプログラマの成果は０である。何年、何ヶ月かけても０。コンサルタントは何かをしゃべって何かを渡せばお金をもらえるが、プログラマはとにかく動かないと成果０である。１００万行書こうが０だ。
よって、不具合については真摯に受け止めて直すことを心がけよう。難易度でモチベーションを調整したりしてはいけない。手離れのいいソフトウェア開発が出来れば、身も心もすっきりするに違いない。
そして、納品後に不具合が出た場合、簡単に直せそうだと思うと、「そんなバグはたいしたことはない」という発言に繋がる。顧客から見ると、簡単に直せるか、難しいかは関係なく、不具合は不具合なのである。
顧客の価値基準は、うまく動いているかどうかであり、次のページに進めなかったり、入力した値が保存されてなかったり、どこか１つでもおかしければ、それは不良品という認識になる。
こんな簡単なバグで不良品とか言われるのはおかしい、一生懸命作ったのに、と思うプログラマはもう少し考えた方がいい。簡単かどうかは外からは見てわからないので、作った人がいないと、一生動かないシステムになる可能性だってあるのだ。
とにかく、どんなに理論的に設計が優れていても、エレガントな実装でも、動かなければプログラマの成果は０である。何年、何ヶ月かけても０。コンサルタントは何かをしゃべって何かを渡せばお金をもらえるが、プログラマはとにかく動かないと成果０である。１００万行書こうが０だ。
よって、不具合については真摯に受け止めて直すことを心がけよう。難易度でモチベーションを調整したりしてはいけない。手離れのいいソフトウェア開発が出来れば、身も心もすっきりするに違いない。
火事場開発モデルとアジャイル開発モデル
＠IT 開発現場の天国と地獄 第3回 ベテランならホントに安心なのか？
via オレンジニュース
---
顧客は運送会社であったために、長距離ドライバー向けの宿泊施設を持っていました。そこがその日からプロジェクトルームになりました。事実上、要件定義と、設計と、詳細設計、実装を同時にしているような状態でした。最大の効率で構築が行えたのは、本来プロジェクトチームが分担すべき各ロールを2人の人間に集約し、その人間が月間400時間を超える労働時間で対応したからでした。この対応方法に学ぶべきものは何もありませんが、効率が非常に良かったのは事実です。
---
火事場開発モデルとは、すでに納期から遅れている、または納期が遅れそう、という時に、ソフトウェア開発受託側の会社が危機的状況を打開するため、また顧客への言い訳として、エース級の戦力をなりふり構わず投入するというモデルである。
火事場開発モデルとアジャイル開発モデルはよく似ている。しかし、アジャイル開発の根幹の考え方の１つとして、個人を大切にするということがなかっただろうか。火事場開発モデルは、会社に利があれども、個人にはなんの利もないことに気付かなければならない。火事場開発とアジャイル開発は別物である。
プロジェクトが火事にならないようにどうすればいいか、ということを考える人がいるプロジェクトは基本的に火事にならないので、火事になるプロジェクトはほとんどが人材不足、力不足なのである。問題は人材不足なのにプロジェクトを引き受けてしまう会社であり、責任は会社が負うべきなのだ。
一番いいのは、火事場に近づかないことなのだが、世の中のしがらみがそうはさせてくれないことがよくある。そうでなくても、プログラマ側も軽く考えている節があるし、少しばかりのボーナスに釣られてしまうこともあるだろう。
そんなプログラマのための火事場開発モデルでのポイントは、次の２点である。
１．権限を得る－火事場では、発言権を得ないと、本当に身も心もボロボロにされてしまう。社内の別プロジェクトだろうが、社外のプロジェクトだろうが、参加する以上はある程度コントロールできる権限を手に入れなければならない。自分の意見が通らない火事場では、逃げなければ燃えてしまう。
２．納期の仕切り直し－無理なものは無理なので、出来るだけ早く、一秒でも早く、寝ずにやってくれ、と言われても納期は仕切り直しである。仕様は決まっているはずなので、見積もりはそれなりに精度が高いものが出来るだろう。納期の仕切り直しを許さない顧客とか上司とかがいる場合は、いちおう目安としてとでも言って説得を試みよう。それでも無理なら逃げるしかない。
あとは、火事場に入る前に、夜食の提供とか、寝る場所の提供とか、わがままをできるだけ言っておく。言うのはただだ。火事場は入るまでは飴ばっかりで、入った後は鞭ばっかりと覚悟しておいたほうがよい。
それでも一度は火事場を経験してみるのも面白いかもしれないが、諸刃の剣なので、あまりお勧めできない。
リエンジニアリング革命
著者： マイケル ハマー, ジェイムズ チャンピー, Michael Hammer, James Champy, 野中 郁次郎
タイトル： リエンジニアリング革命―企業を根本から変える業務革新
---
我々は、よく次のようなシナリオに直面する。シニア・マネジャーが、問題のあるプロセスを画期的に改善するためにリエンジニアリング・チームを任命する。しばらくしてそのチームは答えを出し、画期的なコンセプトについて説明し、どのようにしてサイクル・タイムの９０パーセント、コストの９５パーセント、欠陥品の９９パーセントを取り除くかを示す。それを聞きこのマネジャーは喜びながらも困惑する。チームは続けて、再設計されたプロセスがなぜ、新しい職務賃金システム、多数の部門の集合、マネジメントに関する権限の再定義、労働関係の新しいスタイルを必要とするのかを説明する。シニア・マネジャーは再び困惑する。しかし今度は喜んでいるのではなく、「君たちにコストと欠陥品の削減を頼んだだけで、会社のことについて意見を求めたのではない」と言う。このチームは通常、解散し、その画期的なコンセプトは二度と聞かれなくなる。しかし、会社について意見を述べることこそが、まさにリエンジニアリングなのである。
---
ソフトウェア開発において、部分的なプロセス改善によって、ソフトウェアの納期の短縮や、作業の省力化を図ろうとするが、ほとんどの場合上手くいかない。上手くいかない理由はいろいろあって、いろいろ改善した部分については少し効果が出るのだが、劇的な効果はないし、がんばらなくなるとすぐに元に戻ってしまう。
がんばっても給料増えないし、残業はするけど早く終わったからといって早く帰れるわけではないし、何時に帰っても朝は定時出社だし、スタッフ辞めても代わりの人材がなかなか入ってこないし、という組織に絡む話が、どうしてもソフトウェア開発とセットでついてくるからである。
本質的な問題として、まさに引用のように会社の雇用や賃金体系や就業規則や経営陣の考え方は、ボトムアップではなかなか変えづらいのである。これをどうやったら話を聞いてもらうようにするか、と組織の下部スタッフが云々唸っても変わるものでは無い。
なぜか、結局行き着くところは会社の売上と利益をどうするのかという、経営論になるからである。ただそのためには経営者を論破する必要がある。技術論だけでは、売上の担保にならない。
今会社が存続している時点で、なんらかの利益獲得ルールに則って会社は動いているのだ。あなたの意見がその利益獲得ルールを無視した理想論を述べても、会社にとっては動きのとりようがない。どうやって利益をあげているのか、自社の仕組みをよく観察してみたほうがよい。
自社の強みがソフトウェアの品質にあるのであれば、よりソフトウェアの品質を保つ方向で提案すればすぐに認められるだろう。逆に短納期を売りにしている会社で、「品質が1．5倍になるからペアプログラミングですよ！」と言っても、当然話を聞いてくれない。
もっとも、上記のようなわかりやすい例はほとんどない。顧客ありきの受託開発会社の場合は、顧客担当者によって優先順位がころころ変わることもよくある。この場合、顧客情報を持つ営業が偉いはずなので、営業の発言力が増す。
何が言いたかったかというと、自社のソフトウェア開発体制がまずいと思うのであれば、今自社はどうやって仕事を取ってきて、どうやって売上をあげているのか、ということを再確認して、それから提案内容を考えるのである。己を知り敵を知れば～、というのはいつの時代も当てはまる。
タイトル： リエンジニアリング革命―企業を根本から変える業務革新
---
我々は、よく次のようなシナリオに直面する。シニア・マネジャーが、問題のあるプロセスを画期的に改善するためにリエンジニアリング・チームを任命する。しばらくしてそのチームは答えを出し、画期的なコンセプトについて説明し、どのようにしてサイクル・タイムの９０パーセント、コストの９５パーセント、欠陥品の９９パーセントを取り除くかを示す。それを聞きこのマネジャーは喜びながらも困惑する。チームは続けて、再設計されたプロセスがなぜ、新しい職務賃金システム、多数の部門の集合、マネジメントに関する権限の再定義、労働関係の新しいスタイルを必要とするのかを説明する。シニア・マネジャーは再び困惑する。しかし今度は喜んでいるのではなく、「君たちにコストと欠陥品の削減を頼んだだけで、会社のことについて意見を求めたのではない」と言う。このチームは通常、解散し、その画期的なコンセプトは二度と聞かれなくなる。しかし、会社について意見を述べることこそが、まさにリエンジニアリングなのである。
---
ソフトウェア開発において、部分的なプロセス改善によって、ソフトウェアの納期の短縮や、作業の省力化を図ろうとするが、ほとんどの場合上手くいかない。上手くいかない理由はいろいろあって、いろいろ改善した部分については少し効果が出るのだが、劇的な効果はないし、がんばらなくなるとすぐに元に戻ってしまう。
がんばっても給料増えないし、残業はするけど早く終わったからといって早く帰れるわけではないし、何時に帰っても朝は定時出社だし、スタッフ辞めても代わりの人材がなかなか入ってこないし、という組織に絡む話が、どうしてもソフトウェア開発とセットでついてくるからである。
本質的な問題として、まさに引用のように会社の雇用や賃金体系や就業規則や経営陣の考え方は、ボトムアップではなかなか変えづらいのである。これをどうやったら話を聞いてもらうようにするか、と組織の下部スタッフが云々唸っても変わるものでは無い。
なぜか、結局行き着くところは会社の売上と利益をどうするのかという、経営論になるからである。ただそのためには経営者を論破する必要がある。技術論だけでは、売上の担保にならない。
今会社が存続している時点で、なんらかの利益獲得ルールに則って会社は動いているのだ。あなたの意見がその利益獲得ルールを無視した理想論を述べても、会社にとっては動きのとりようがない。どうやって利益をあげているのか、自社の仕組みをよく観察してみたほうがよい。
自社の強みがソフトウェアの品質にあるのであれば、よりソフトウェアの品質を保つ方向で提案すればすぐに認められるだろう。逆に短納期を売りにしている会社で、「品質が1．5倍になるからペアプログラミングですよ！」と言っても、当然話を聞いてくれない。
もっとも、上記のようなわかりやすい例はほとんどない。顧客ありきの受託開発会社の場合は、顧客担当者によって優先順位がころころ変わることもよくある。この場合、顧客情報を持つ営業が偉いはずなので、営業の発言力が増す。
何が言いたかったかというと、自社のソフトウェア開発体制がまずいと思うのであれば、今自社はどうやって仕事を取ってきて、どうやって売上をあげているのか、ということを再確認して、それから提案内容を考えるのである。己を知り敵を知れば～、というのはいつの時代も当てはまる。
チームで開発するならパソコンの前にいる時間を減らすしかない
普通の会社ならプログラマ１人に１台のパソコンが与えられる。２台以上与えられるところもあるかもしれないが、与えられないということはないだろう。自腹で購入させるところがあるかもしれないが、机の上にパソコンが最低１台あるというのが普通である。
さて、自分の机をパソコンが占領している状態だと、どうしてもパソコンを使って何かするという状況に追い込まれる。で、パソコンを使っていると仕事をしているように見えるため、どれほど非効率なことでも許されるという変なことが起こる。
パソコンに奪われている無駄な時間を、もう少しコミュニケーションに割く事で、パソコンでの作業の絶対量を減らせるのではないかと思うわけだ。パソコンのある状態が主で、パソコンのない状態が従という考え方だと、コミュニケーションが終わればすぐパソコンに戻るということになる。
考え方を逆にして、パソコンのない状態を主、パソコンのある状態を従とすると、作業をし終えたら、パソコンのない状態＝コミュニケーションを取れる状態となる。
チーム内で話が出来る状態を主とすることで、作業の絶対時間が減るかもしれないが、チーム内の情報伝達は進むので、無駄作業が減って作業しなければいけない絶対量が減るのではないかと思う。そもそも頭脳労働なので、考える時間と考えた事を皆に伝える時間をきちんと取らないと、後戻りが増えるだけなのである。
優秀な人達の開発方法論を読むと、皆が自律して動いているので、朝５分のミーティングと後は個別の話し合いで済むかもしれないが、チーム内に新人も含めてばらばらのスキルの人たちがいるような状態だと、うまくいかない。後戻りが発生しそうな作業を繰り返す人が出てくるからだ。
何かを任せたい、一人で作業した方がはかどるということはよくわかるが、結局後で直すのであれば意味がない。スキルに差があるなら俺の後ろで３日ぐらい見とけ、でもいいかもしれない。ペアプログラミングっぽいが、ドライバーがずーっと開発して、パートナーは見てるだけというような感じである。
１人で勉強できるような人なら、すでにスキルがあるはずだ。今の時点でスキルが身に付いていないのなら、ほったらかしても何も身に付かない。OJTをするなら、パソコンを与えずに誰かの隣につける方がよっぽど教育になる。出来たソースを追いかけさせるよりも、リアルタイムで作っているものを見せたほうがいい。
パソコンに時間を搾取されているようでは、デスマーチ以前の問題だろう。脳みその使い方をもう少し考えないといけない。
さて、自分の机をパソコンが占領している状態だと、どうしてもパソコンを使って何かするという状況に追い込まれる。で、パソコンを使っていると仕事をしているように見えるため、どれほど非効率なことでも許されるという変なことが起こる。
パソコンに奪われている無駄な時間を、もう少しコミュニケーションに割く事で、パソコンでの作業の絶対量を減らせるのではないかと思うわけだ。パソコンのある状態が主で、パソコンのない状態が従という考え方だと、コミュニケーションが終わればすぐパソコンに戻るということになる。
考え方を逆にして、パソコンのない状態を主、パソコンのある状態を従とすると、作業をし終えたら、パソコンのない状態＝コミュニケーションを取れる状態となる。
チーム内で話が出来る状態を主とすることで、作業の絶対時間が減るかもしれないが、チーム内の情報伝達は進むので、無駄作業が減って作業しなければいけない絶対量が減るのではないかと思う。そもそも頭脳労働なので、考える時間と考えた事を皆に伝える時間をきちんと取らないと、後戻りが増えるだけなのである。
優秀な人達の開発方法論を読むと、皆が自律して動いているので、朝５分のミーティングと後は個別の話し合いで済むかもしれないが、チーム内に新人も含めてばらばらのスキルの人たちがいるような状態だと、うまくいかない。後戻りが発生しそうな作業を繰り返す人が出てくるからだ。
何かを任せたい、一人で作業した方がはかどるということはよくわかるが、結局後で直すのであれば意味がない。スキルに差があるなら俺の後ろで３日ぐらい見とけ、でもいいかもしれない。ペアプログラミングっぽいが、ドライバーがずーっと開発して、パートナーは見てるだけというような感じである。
１人で勉強できるような人なら、すでにスキルがあるはずだ。今の時点でスキルが身に付いていないのなら、ほったらかしても何も身に付かない。OJTをするなら、パソコンを与えずに誰かの隣につける方がよっぽど教育になる。出来たソースを追いかけさせるよりも、リアルタイムで作っているものを見せたほうがいい。
パソコンに時間を搾取されているようでは、デスマーチ以前の問題だろう。脳みその使い方をもう少し考えないといけない。