Vapor Trail

明るく楽しく元気よく

去年の反省と目標

2018年を振り返る

1月 就職活動
2月 プログラマーとして働き始める。
3月 ぼちぼち働く
4月 ぼちぼち働く
5月 ぼちぼち働く
6月 ぼちぼち働く
7月 ぼちぼち働く
8月 雲行きが怪しくなり始める。残業が多くなる。
9月 炎上
10月 炎上
11月 炎上
12月 一段落

前半

去年の2月に就職が決まってプログラマーとして働き始めたので、転職したという点で大きな変化があった1年だなと思う。 職業訓練校ではJSPJavaサーブレットでショッピングサイトみたいなものを作ったが、pomとかDAOとかなんだかよくわからず、インターン先でたまたま使うことになったPHPがわかりやすくて、PHPを扱う今の会社に就職した。

プログラマーに向いていないと言って挫折した人もまわりにいたし、実習内容はインターン先によるのでPHPと出会わなかったら自分も挫折していたかもしれない。そういう点でPHPには愛着を持っている。

働き始めたものの、せいぜいPHPでお問い合わせフォームを作りました程度のレベルだったので最初は何もわからず作業のスピードものろのろであった。

PHPの基礎もよくわからないまま、FuelPHPというフレームワークを使うことになったが、まずドキュメントの読み方がわからなかった。

大概のことはドキュメントにちゃんと書いてあるのだが、どう書けばいいのかわからないのでググってソースをコピペして、引数とか値を変えながら実際にどう動くのか体験しつつ、自分の作りたいものを実装していくという有様であった。

連想配列をforeachで回して値を取り出したり、入れたりするのを理解するまでには、ずいぶん手こずったし、「Undefined Index」のエラーの画面をじっと見てよく途方に暮れていた。

そんなこんなでも、約1年も経てば作りたいものを実装することはできるようになったとは思う。

後半

それでいて、はじめてのプロジェクトではじめての炎上を経験した。

やたらと仕様が変更するため「最初から言ってくれよ・・・」と思うことが多くて、毎日なんでこんなことになっているんだろうといつも考えていた。

要件定義をキチンとしてないからこんなことになっているんじゃないのか?、どういうものを作るのか明確になっていないからこんなことになっているのだと考えた。

また仕様書をキチンと作ってないから、こんなことになっているんじゃないのか?、仕様についてクライアントと合意した上で、作ってたらこんなことにはなってないはずだとも考えた。

そういった経緯があって、自分が直面している問題はだいたい他の人も経験しているはずなので、先人たちはどうしたのか知りたくて、これがきっかけでソフトウェア開発についての本をいろいろ読みはじめた。

『Joel on Software』 仕様書とはどんなものか? - Vapor Trail

『オブジェクト指向のこころ』 - Vapor Trail

 

どれだけ頑張ったとしても、どれだけうまく分析したとしても、ユーザからすべての要件を引き出すことなんてできっこありません。

明日のことなんて誰にも判らず、万物は流転していくのです。これは絶対不変の真理なのです。

私の30年にわたるソフトウェア開発経験で、要求について学んだ大事なことといえば、要求は常に変化するということです。

要求が変化する理由は簡単です。

  • 開発者とディスカッションを行うたびにユーザがソフトウェアの新たな可能性に気付き、自らのニーズを変更する。
  • ソフトウェア開発の進展に伴い、問題領域に対する理解が深まり、開発者側の考え方が変わってくる。 

オブジェクト指向のこころ』

 

顧客が喜ぶものをつくる際に、まだ判明していないことやわからないこと、つまり不確実性を無視してはいけないのです。

不確実性を解消するには、...まず探索や行動をするしかありませんその実践で経験からの学びをフィードバックして、知識に変えることでしか解消できないのです。

計画変更を後ろ向きなスタンスとして捉えることは終わりにしてください。短いスパンで繰り返し、足りないタスクは計画に追加し、誤った見積は修正していくのです。

カイゼン・ジャーニー』

 

日本IBMがプロジェクト終盤、スイスのテメノス製パッケージ「TCB」を採用する代替案を提示した際、「CorebankをJava化したもののパフォーマンスが悪いことが判明した」「Corebankについて日本の銀行の諸制度に合致させることが難しかったのは事実」などと述べていた。

日本IBM全面敗訴の深層 「議事録」が決め手に | 日経 xTECH(クロステック)

 

どうやら仕様変更が多いとか、仕様書が不完全なものであるとか、プロジェクト終盤になってパフォーマンスが出ないとか、手戻りやちゃぶ台返しは、そんなに珍しいことではないとわかった。

またこの経験からソフトウェア開発とはこういったものとして受け入れた上で、「自分にできることは仕様変更・追加を容易にできるようなコードを書くことしかないのだ」という結論に至った。

炎上中はどうしてこんなことになるのかと現状への不満がかなり溜まっていたが、「隣の芝生は青くないのだな」と一旦受け入れるとふっきれて楽になったように思う。

 考え方を切り替えることはできたが、時間がない中で仕様変更や機能の追加を既存のコードに付け加えていく形で実装していったので、段々とコードの見通しが悪くなっていったのがこのときの悩みであった。

なので変更を容易にする・コードをシンプルに保つための方法として、リファクタリングやテスト、オブジェクト指向、設計、アジャイル型開発への興味・関心が増えた。そして結局、銀の弾丸などないとわかった・・・。意外とみんな泥臭いことやっているんだろうなぁと考えている。

 いろいろ思うことはあったが、常に学び続ける仕事に就きたいと考えていたので、この業界で働いたことに後悔はない。

 

2019年の目標

1. 設計を学ぶ
一朝一夕で身につくものではないのでコツコツがんばる。(あいまいだなぁ・・・)


2. 他の人に負けないスキルを身に着けたい
自分の中でこれだけは他の人には負けないというものを作りたい。


3. 手を動かす
あまり学習の仕方がよく分かってなかったせいもあって、去年は本だけ読んでわかった気になっていた気がするので、黙って手を動かす(コードを書く)ようにする。