唐突ですが、僕はこの言葉にすごく勇気づけられました。
「優秀なソフトウェア・エンジニアである」ということは、それほどまでに貴重な存在だ、ということを強く意識した上で、自分を鍛え続け、良い物を作る・ユーザーに価値を提供する・会社の価値を高めることを一生懸命にしていれば、必ず道は開ける。
Life is beautiful: テクノロジー・ベンチャーにはなぜソフトウェア・エンジニアが不可欠なのか？
何を持って優秀とするか、は別にして、
「優秀なソフトウェアエンジニア」を目指す決意を新たにしました。
僕はプログラミングが好きなようですが、
別段プログラミングだけが好きなわけではありません。
社会人2年目には、先輩に勧められたドラッカーに大ハマリして、
マネジメントについても、本を読んだりチームに試したりして、
今の自分の考えはあります。
3冊の書籍の執筆を通じて、文章の書き方もけっこう突き詰めて考えました。
システム開発の設計書はどうあるべきか、も自分の考えを述べて、プロジェクトに適用したりしています。
何が言いたいかというと、別にプログラミングだけやってるわけじゃなくて、
「今やっているプロジェクト」には、
どういうこと(マネジメント、設計書、言語/フレームワーク選択など)が適切か、
というのは、自分なりに考えているつもりなんです。
もちろん、自分がいつも正しい、なんて思っていません。
けれど、本当にSI業界には、
「なぜそうしたのか？」という理由もなしに決定した事柄が、
あまりに多すぎると考えているんです。
というよりも、決定事項のすべてが、
そうではないか。
惰性による判断、無思考が横行しすぎている、
と肌で感じます。
個人的には、僕はこれがSI業界から人材が流出している原因と考えています。
「このやり方はどう考えてもおかしいだろ」と感じるやり方を強制させられ、
それを長時間やらされれば、そりゃネット業界に人材が流動します。
優秀な人であればあるほど、「今回はこっちの方がいいのではないか」と考え、
時にはそのアイデアを提案することもあるでしょう。
なのに、そこで議論も論理的な反論もなく、
「前からそうだったから」という惰性的な判断が優先されれば、
もう心を閉ざすしかありません。
どんなやり方をしても、失敗することはあります。
けれど、懸命に考えて失敗するのと、惰性的な判断で失敗するのとでは、
まったく意味が異なります。
惰性的な判断にすれば、責任の所在が曖昧になる、
というメリットはあるでしょうけどね！
より優秀な人ほど、さまざまなことをインプットしているし、
それを基に考え、判断しています。
しかし、そうした人ほど損をするのが、
SI業界なのだ、と言いたいのです。
(あくまで僕が見てきたSI業界にはなりますが…)
何もインプットせず、何も考えず、何も判断せず、
ただ前から決まっていることに黙々と従って
作業する人に合わせるプロジェクトに
何の魅力があると言うのでしょう。
今回のプロジェクトにおいて、
どうしてそのプログラミング言語なのか？他の言語ではいけないのか？
どうしてそのフレームワークなのか？他のフレームワークではいけないのか？
どうして設計書がExcelファイルなのか？他のファイル形式ではいけないのか？
どうして仕様はそういう内容を記述しているのか？もっと他に記述するべきことはないのか？
どうしてテスト仕様書のテストケースはそういう内容なのか？もっと他の記述形式はないのか？
判断は、無数にあるわけです。
とても誰か1人が決めれるものではないし、
判断せずに、惰性で進めるのがある種一番楽でしょう。
けれど、楽をしてプロジェクトが成功するなんて、思うな！
と言いたいわけです。
そんな甘い話はありません。
どれもこれも議論していたら、時間は足りないでしょう。
でもやり方はあります。
誰かに任せてみたり、非公式な集まりで話してみたり、ささっと作ったプロトタイプを見せてまわったり。
決まってしまってから、変えることは難しいものです。
でも、決まる前ならいくらでもよくしていくことができます。
たとえば、納品先が、設計書はExcelファイルで、なんて言わない限り、
設計書にExcelを選択することなんて、
プロジェクトメンバーの誰も喜んでいないでしょう。
あんな書きづらい、変えづらいものはありません。
メリットの100倍はデメリットが上回っています。
なのになぜ選ぶのでしょう。その論理的な理由は？
みなExcelから変えたくてしょうがない。
けれどプロジェクトにおける惰性の判断を覆せずにいる。
もし、今までこの疑問を抱かなかった人は、
自分自身が、惰性の判断に陥ってしまっているわけです。
さらに、そのExcelの設計書に記述してある仕様は、
本当に必要十分な文章になっているのか？
ただ、何でもいいからそれらしい文章を書けば、
それが設計になんてなるわけないんです。
役に立たない文章だけがある設計書は、
いらないドキュメントでしかない、
ということです。
どんなことを書けば、
実装や保守運用に役立つのか、
逆にどんなことは書かなくていいのか、
考えるべき点は多くあります。
ほんと、夜中のテンションでここまできましたが、
僕は、あまりにも悔しくてこれを書きました。
変えたいんです。
誠実でいたい。
システムは、高いものです。
だから、いいものにしたい。
Excelだから設計書の作成に時間がかかって、
それが人件費となって、
価格に反映されているなんて、
まともな神経じゃ耐えられないでしょう。
全力を尽くして、でもこの程度しかできなかった、
にしたいんです。
自分の仕事に誇りを持ちたい。
プロフェッショナルとして、仕事をしたい。
そして、ソフトウェアエンジニアでありたい。
僕は、そう考えています。
(追記)
僕は、仕様書がExcelじゃダメだ！
ってことを言いたいのではないんです。
あくまで例としてExcel設計書を挙げました。
「そのプロジェクト」でExcelが適しているという判断があれば、
それでいいんです。
(ものすごく作り込んで、使いやすいExcelフォーマットがあったりとか)
そうではなくて、
前からそうだったから、という理由で選んでいないか？(惰性による判断)
という内容が主旨です。
よりよい方法がないか、比較検討することが大切だ、と。
