プロ意識
プロになる前に注意したいこと
プロにならないのは簡単だ。自分の仕事に責任を持たなければいい。すべて上司にお任せだ。 ミスをしたら上司が後始末をしてくれる。だた、プロは自分で後始末をする。
機能に危害を加えてはいけない
ソフトウェアをリリースするときには、QAに問題を見つけてもらってはいけない。 不具合がありそうなコードをわざとQAに渡すようでは、プロの風土にも置けない。 では、不具合がありそうなコードとは何だろうか？詳細がわからないコードだ！
コードが動いていることをどうやって把握するのだろうか？簡単だ。テストすればいい。
何度もテストするのだ。手を変え、品を変え、あらゆる方法でテストするのだ。
テストには時間がかかりすぎると思っているかもしれない。スケジュールや納期は守らないければいけない。
テストだけやってたらコードが書けないじゃないか。いい指摘だ！
だからこそ、テストを自動化するんだ。すぐに実行できるユニットテストを何度も実行するんだ。
本物のプロは、構造を犠牲にして機能を届けるのはバカのやることだと思っている。 コードの柔軟性はその構造にかかっている。構造が不安定ならば未来も不安定になる。 ソフトウェアは適切なコストで変更できなければいけない。
労働倫理
1週間は168時間だ。雇用主に40時間、君のキャリアに20時間を使える。 残りは108時間。睡眠に56時間を使うとして、残りの52時間は自由に使える。
自分の専門を知る
ソフトウェアのプロが備えるべき最低限のこと
- デザインパターン GOF の 24 のパターンについて説明できる。 POSA のパターンを実際に使える知識がある。
- 設計原則 SOLID 原則を知っている。コンポーネントの原則を熟知している。
- 方法論 XP・スクラム・リーン・カンバン・ウォーターフォール・構造化分析・構造化設計を理解している。
- 規律 TDD・ オブジェクト思考・設計構造化プログラミング・継続的インテグレーション・ペアプログラミングを実践している
- 成果物 UML・DFD・構造チャート・ペトリネット・状態遷移図・状態遷移表・フローチャート・ディシジョンテーブルの使い方を知っている。
ドメインを知る
プログラミングの対象ドメインを理化する責任がある。会計システムを作っているのなら、会計の知識が必要。
ドメインの専門家になる必要はないが、仕事に必要な知識というものがある。
新しいドメインのプロジェクトが始まるときには、関連書籍を1～2冊読んでみよう。
専門家と一緒に時間を過ごして、彼らの原則や価値を理解しよう。
ビジネスを理解せずに仕様からただコードを書くのはプロとして最低だ。
仕様の間違いを発見・指摘できるように、ドメインを理解しなければいけない。
「ノー」と言う
奴隷は「ノー」と言うことを許されていない。労働者は「ノー」と言うことをためらうだろう。 だが、プロは「ノー」と言うことを期待されている。
反対者の役割
「なぜ」よりも「事実」のほうが重要。
だが、「なぜ」を説明することで相手の理解が深まり、事実を受け入れてくれることもある。
相手には技術的な知識があり、理解しようとしてくれるならば、理由を説明するのもいいだろう。
だが、理由を説明しても相手が納得しないこともある。
それどころか、あなたが全て悪いと決めつけていまうこともある。
詳細を説明しすぎると、マイクロマネジメントを招いてしまう。
試しにやってみる
「試しにやってみる」にはさまざまな意味がある。問題にしているのは、「余分な仕事をする」ことだ。
期日に間に合わせるために何かできたのであれば、それまで仕事をしていなかったことになる。
つまり、力を温存していたわけだ。
もし力を温存していないのんら、もし新しい計画がないのであれば、もし振る舞いを変えないのであれば、もし最初の見積もりに自信があるのであれば、
試しにやってみると約束するのは不誠実である。ウソをついているのと同じだ。おそらくは、自分のメンツを保ち、対立を避けるためにやっているのだろう。
「イエス」と言う代償
できることなら「イエス」と言いたい。健全なチームはみんなで「イエス」と言うことを目指している。
うまくいっているチームのマネージャーや開発者は、お互いに合意するまで実行計画の内容について交渉する。
しかし、これまで見てきたように、正しい「イエス」を言うには、「ノー」も恐れずに言わなければいけない。
コードの実現不可能性
プロはヒーローになることがある。しかし、それはヒーローになろうとしたからではない。
プロは、納期・予算どおりに仕事を成し遂げたときにヒーローになる。
ヒーローになりたい気持ちや「問題を解決」したいと思う気持ちはとても大きい、
我々が意識しておかなければいけないのは、プロの規律を失ってまで「イエス」と言うのは、問題を解決する方法ではないということだ。
規律を失うということは、逆に問題を作り出すことだ。
約束の言葉
本物の約束を見つけるには、「私が・・・までに・・・をやります」という表現を探すことだ。
ここで重要なのは、「自分で」約束の内容と期日を名言していることだ。
自分以外の誰かの話はしていない。自分がこれからやる行動について話しているのだ。
やる「可能性がある」とか「たぶんやるだろう」ではなく、やり遂げることだ。
自分でやると言った以上、結果は、やるか、やらないかだ。
やらなければ、みんなの笑い者になる。自分でもそのことを申し訳なく思うようになる。
やってないと誰かに言うのが気まずくなる。
プロは頼まれたことすべてに「イエス」と言う必要はない。しかし、「イエス」と言えるような創造的な方法を懸命に探さなければいけない。 プロが「イエス」と言うときには、確実に約束したとわかるような約束の言葉を使っている。
コーディング
コーディングというのは、知的でやりがいはあるが、とても疲れる活動だ。他の仕事では必要とされないようなレベルの集中力が必要になる。 競合する要因を同時に扱わなければいけないからだ。
- 君のコードは、正しく動かなければいけない。そのためには、解決する問題と解決方法を理解しなければいけない。解決策を忠実に反映したコードを書かなければならない。 言語・プラットフォーム・アーキテクチャの一貫性を確保しながら、状況のシステムの欠点と解決策の詳細をうまく管理しなければいけない。
- 君のコードは、君に代わって顧客の問題を解決しなければいけない。顧客の要求では、問題が解決されないことがよくある。君が調査して、顧客と交渉して、本当のニーズに合わせなければいけない。
- 君のコードは、既存のシステムに適合しなければいけない。システムの硬直化・脆弱性・不透明性を増やすものであってはいけない。依存性をうまく管理しなければいけない。 つまり、コードはSOLID原則に基づいていなければいけない。
- 君のコードは、他のプログラマが読みやすいものでなければいけない。コメントをうまく書くという話ではない。君の意図がわかるようにコードを書くということだ。実際にうまくやるのは難しい。 プログラマが習得しなければいけないもののなかで、これが最も難しいことかもしれない。
集中が出来なければコードを間違え、バグを潜り込ませてしまう。構造を間違え不透明で複雑なものになってしまう。
コードにやり直しや手戻りが発生するということだ。集中力が欠けたまま仕事をすると無駄が発生する。
疲労時や注意散漫のときには、コードを書いてはいけない。やり直しになるだけだ。注意散漫の原因を排除する方法を探して、心を落ち着かせよう。
バックグランドの心配事が消えないときは、コードを無理やり書くように奮い立たせるのではなく、心配事を作り出している事柄に1時間ほど取り組んでみる。 心配事を減らすことで、バックグランドプロセスを静めることはできる。
去り際を知る
問題が解決するまで家に帰れないのだろうか？もちろん、帰っていい。むしろ帰るべきだ！
創造性や知性は、はかない。疲れたらどこかへ消えてしまう。
夜中に働かない脳を酷使して何時間もかけて問題を解決しようとしても、ただ疲れるだけだ。車やシャワーなどの問題解決の機会も減ってしまう。
疲れてどうしようもなくなったら、しばらく離れてみるといい。創造的な潜在意識で問題を解決してみるのだ。
リソースを節約するように気をつければ、より短い時間で、より少ない労力で、より多くのことができるようになる。
遅れ
遅れを管理する秘訣は、早期発見と透明性。
最悪なのは、ずっと間に合うと言い続け、最後になってみんなの期待を裏切ることだ。
定期的に進捗を管理して、事実に基づいた3つの期日（最早終了日・通常の終了日・最遅終了日）を求めよう。
3つの期日はできるだけ正直に求めよう。見積もりに願望を含めてはいけない！
チームとステークホルダーに3つの値を見せよう。そして、毎日更新するのだ。