はじめに
この記事はふりかえりアドベントカレンダーの13日目の記事です
Developers Boostが終わって、「アウトプットしなきゃなぁ」と思いながらきっかけを作れていませんでした
ふとした拍子に懇親会の終わりに名札の写真をとらせてもらった黄色の人を見てみると、今回のふりかえりアドベントカレンダーがもう少しで埋まるとのツイートがあった
「この忙しい年の瀬に志高い人がそんなにいるのか」と思いながら見てみると、私の誕生日だけスッポリ空いていた(実はもう1日空いてた)
しっかりふりかえることができるかとても不安だったけれど、ここまでお膳立てされて始められないなら一生始めないだろうということで、アドベントカレンダーに参加して、1年のふりかえりをアウトプットすることにしました
自己紹介
Developers Boost 2019に参加し、アウトプットを始めました
2019年02月に転職し、医療機関向けソフトウェア開発を行う中小企業に勤務しているエンジニア1年生です
製品や社内向けツールについて、仕様検討、実装、テスト設計、テスト、トラブル解析といった工程を主に行っています
工程が分化されていない、トラックナンバーが少ない、社内システムの一部が化石化しているなど様々カイゼンをしたいことはありますが、それはまた別の機会にアウトプットすることにします
月毎のふりかえり
月毎のふりかえりを、「やったこと、わかったこと、つぎやることor心がけること」の形式で行います
1月
やったこと
- 新卒入社した非鉄金属系材料メーカーを退社
- 引越作業やそれに伴う事務手続き
わかったこと
- 会社関連
- 会社が辞めさせたがる時はいともたやすく辞めさせるが、社員が辞めたがる時は易易とは辞めさせてくれないこと
- 粉骨砕身して働いても、身が粉になってしまったら元も子もないこと
- 引越関連
- 収納ケースを定位置としてものを管理する習慣をつけておくこと(荷造りが楽)
- 転出届を出す前に、住民票を発行しておくこと(物件契約時に必要な可能性アリ)
- 転入届を出すと同時に、マイナンバー系(通知カード含む)の住所変更を行い、住民票を発行しておくこと(免許更新等各種手続きに必要)
2月
晴れて今の会社へ入社
入社当初の育成方針は「未経験での採用だし、半年とか一年ぐらいは自学の為に費やしてもらってそれから方向性を考えよう」だったらしい
やったこと
- 1日目 : 初めての満員電車に乗ってみた
- 2日目 : 「自学でレベル上げしてくれ」と裸一貫で放り出されてみた
- C#やWPFについて調べてみた
- オブジェクト指向について調べてみた
- 20日目 : 業界知識(各種規格)について調べて、理解を試すために規格の要求事項を満たすストレージ&ビューアソフトを作ってみた(Windows Forms)
- 規格通りのファイルを受けとり、規格に従った階層構造で格納し、それら内容を閲覧する
- 最低限の要件をすべて満たすのみで、例外処理とかはまだできていない
- 思考や検討の能力に優れた長く勤めている外注の大先輩が面倒を見てくれることになった
- 計算量とアルゴリズム、数学的思考、課題整理の手法など、様々なトピックについてディスカッションの形式で学んだ
- 学習レポートという名目で様々なログを残し始めた
結果/わかったこと
- 椅子が埋まっていたら「混んでるなぁ」という地元(北関東)の価値観が崩壊した
- 大学時代の仙台の市バスもなかなか酷かったが、それ以上というのはとても驚いた
- 帰路の乗換駅が始発駅となる通勤経路を設定した1ヶ月前の自分を褒めた
- WPF-C#でシングルスレッドかつ同期処理であれば多少どうにかできるようになった
- ただしまだコードの可読性は低く、例外処理も不十分
- 見返すと、操作性も悪いし表示も不親切、ユーザーアンフレンドリーの塊
- しかし、よく「Visual Studio？映像編集ソフトじゃないの？」というところから20日で最低限のアウトプットができたものだとも驚く
- オブジェクト指向あまりよくわからないことがわかった
- カプセル化や継承、ポリモーフィズムといった理念により、凝縮性が高く結合度が低いものにするといった概念的理解は得られた
- そういったものが変更容易性やメンテナンスのしやすさにつながることもなんとなく理解した
- しかしどう実践するのかあまりわからない、ということを認識した
- とにかく何を調べても教科書の文言丸写しみたいなものや脈絡もなく関連の見えない例え話が多くてわかりにくい、オブジェクト指向の概念を調べてるのに「この言語はいいぞ！」とか主張しだすといった状況で大変苦痛だった
- 人によって相性もあるのかもしれないが、自身で考えて解決策などを出させてドライアンドエラーを繰り返させるといった指導は、最終的な理解度が高くなるように思う
- ただし、時間や精神力といった要求リソースの多さや個々人との相性があるため、一概に最善といえるものではない
- 行動のログを残すことで理解を深めることができた
- 「やったこと」しか存在しないものの、実はアウトプットが入社直後から行われていた
- この記録がなかったら、1年をふりかえるのは困難を極めていたと思う
3月
予想より早く実際の開発、製品の開発へ
やったこと
- 社内ツールの開発(WPF-C#)
- WPFのメインコンセプトのViewとModelの分離を支える、バインディングとコマンドを実際に使うことができた
- 小さめの製品(カスタマイズの更新)の開発(IronPython)
- 不完全なものを出したくないと真剣に要件定義をして、要求仕様内の矛盾を多数見つけた
- 要求仕様の確認に時間がかかった結果、最終的には要件定義中にお流れになってしまった
結果/わかったこと
-
誰も中身を正確に知らない社内システムが使われており、不便を感じている人が多い
- メスを入れたいがリソースが足りないようだ
-
変更に強い設計について考えることの必要性
- 設計の段階で計画しないと変更に強くするのは難しい
- 変更に強い設計をするには、どんな変更が将来予想されるのか検討する必要がある
-
要望(要求仕様)が複雑なものや手続き的な記述になっているものは危険
- 顧客の「実現したいこと(要望)」がそのまま記述されていれば、開発が「それを知ることができる
- しかし、要求仕様の段階で内部に矛盾があったり、手続き的に要求仕様が書かれていると、そこから開発が「推測した実現したいこと」と顧客の「本当に実現したかったこと」の間に齟齬が生じうる
- 人員の問題もあって、営業と開発が大きく分離していることが原因の一端と思うが、またの機会に分析する
4月
小さめの製品(カスタマイズ)の実装を行うように
やったこと
- 既存のコードを読んで、どのような処理構造になっているのか知識を得た
- 変更に弱い部分を見つけ、汎用化できるように改造してみた
- レビューの結果は、「コンセプトや処理構造はよいが、設定方法が煩雑」
- 社内ツールの開発(WPF-C#)
- 異常状態について検討し、例外処理を追加した
- 自社製品の種類や特徴について知識を得た
- 国際医用画像総合展の出展を手伝いつつレクチャーを受けた
結果/わかったこと
- 既に存在するコードが必ずしも適切とは限らない
- 先輩が書いたコードであっても、先輩が新人の頃書いたコードだったり技術の更新があったりなどで必ずしも適切性が担保されているわけではない
- 設定に許される複雑性について考えるようになった
- わかりやすさを維持しつつ設定可能な範囲を広げる方法について考るようになった
-
トラックナンバーが小さい製品が多いことを知った
- 開発メンバーに対して製品が多い
- トラックナンバー1の製品が4つ5つ見受けられる
- しかもドキュメントが少ない製品も多い
- 今後カイゼンしたい内容の1つ
5月
小さめの製品がメインだが開発が本格的に割り振られるように
やったこと
- 要件定義をはじめて自分で行った
- はじめてのフィードバックは「それは要件ではなく処理内容」
- どういった設計・プロセスで解決するのがよいか考えた結果、処理内容を羅列してしまったため
- ローカル環境でファイルのバージョンの取り違えを起こした
- コーディングするフォルダと製品に組み込み動作確認をするフォルダが別れており、ファイルが2重に存在する状況だった
- 製品の内部に配置するファイルを編集するのではバージョン管理の都合が悪かった
- そこで、製品内部のフォルダをシンボリックリンクに置き換えて一元化した
わかったこと
- 要件定義では、入力と出力に焦点を当て、正常や準正常といった状態を考慮して適度な抽象化を行うことが重要
- これを心がけるようにしたら、要件定義のレビューでつまずくことが減った
- 取り違えうる状況ならどうしてもミスは起こるので、そもそも発生しようがない仕組みにするのが重要(フールプルーフ)
- シンボリックリンク便利
6月
ドキュメントが殆どないプログラムのトラブル解析をすることに
やったこと
- ドキュメントが殆どないプログラム(C++)のトラブル解析
- トラブルを再現させてみた
- 再現性100%のトラブルと全く同じ入力なのに60%のトラブルがあった
- ソースコードを読んで解析してみた
- C++初見なのこともあり、「*に&マーク？なんか文字列をインクリメントしてる…」など大混乱
- トラブルの内容からコードの領域に当たりをつけて詳しく見た結果、変数の初期化漏れによる未定義動作だと判明
- トラブルを再現させてみた
わかったこと
- 必ずドキュメントを残すことが重要
- 見ればわかるコードを書くのも大事だが、そこからわかるのは「何をしたいのか、何をしているのか」
- 「何を目的にこのコードを書いたのか」を把握するにはやはりドキュメントが必要だと思った
- 初期化などの基本の踏襲・確認は重要
- コンパイルエラーなどになって発覚すればまだいい
- 万が一すり抜けると再現性が低い不具合となって遠い将来に災厄となって降りかかる
7月
はじめてのレースコンディション
やったこと
- はじめての設置施設への出張
- 社内でいくら接続テストや負荷テストをしても、現地でトラブルは起こりうることを学んだ
- ネットワーク関係、しかも他社管理のものとの接続はとても大変
- はじめてのレースコンディション
- 外部のプログラムとやりとりする製品をはじめてつくることに
- 今回は比較的簡単な方といわれる「ファイルの取り合い」
- アトミック操作について調べ、「リネームで取り合い」することにした
- 「リネームの成否」で判断しているのに、「ファイルの存在確認」をするなど最初は無駄だらけだった
- 今回は安全性の要求がそこまで高くないこともあって上手く実装できた
わかったこと
- レースコンディションは奥が深い
- アトミックなもの操作があっても、その操作をする外側の相性など様々検討すべきことはある
- レースコンディションの検討は、比較的得意(or好き)なようで、結構しっかり討論に参加できたし楽しかった
- 複雑な検討をするときは、可視化したりモデル化するとよい
- 図に起こしたり、実際のものを複数人で取り合いながら考えると考えやすいなと思った
8月
複雑なテストを任されるように
また、このあたりから目新しいタスクが減ってアウトプットが減ってきた
やったこと
- 複雑な仕様のプログラムをテストするようになった
- 仕様の把握が大変なので、テスト設計が適切か確認するのが大変だった
- 入力状態のパターンを整理して、テスト設計の適切性を考えた
- また、テストデータの情報を記録することでテストの正確性のレビューに役立てるようにした
わかったこと
- 複雑なテストにおいては、テストデータが適切であるかもレビューが必要
- テスト設計のレビューにおいて、テスト手順が適切かばかりが注目されがちだった
- しかし、テスト設計が適切でも、テストデータがその設計に沿っていない場合があるので、テストデータもレビュー対象にすべきだろう
9月
やったこと
- 医用画像業界一斉の接続テストに参加(ほぼ見学)した
わかったこと
- 他社との接続テストはとても大変
- システムの仕様が異なるという純粋な難しさ
- それに加えて、規格に準拠している範囲が限定されているシステムや、(厳密には)規格違反の通信を投げてくるシステムも稀にある
- 「対応範囲を明言すれば必ずしも全範囲カバーしなくともよい」という規格の宣言によって接続テストの難しさが助長されているようだ
10月
やったこと
- 6月にトラブルを解析した、ドキュメントが殆どないプログラム(C++)の修正仕様を検討するための事前調査
わかったこと
- ポインタってすげー！
- 制御をしっかり考える必要があるが、大変柔軟な(良くも悪くもなんでもできる)コードが書ける
- 制御に失敗すると未定義動作が出やすいと思うので、ひとまず無闇矢鱈に使うものではないと考えておく
- C++標準ライブラリとVisual C++って違うんだ
- C++標準ライブラリは標準的な関数やシステムが入っている
- Visual C++は、標準ライブラリに「こんなのあったら便利よね～」と関数とかを追加されているライブラリ
- Visual C++にあって標準ライブラリにない関数には、関数名の頭に「_」が必ずついているように思えるが、何か規則性があるのだろうか？
11月
やったこと
- 製品カスタマイズの内部的な汎用化を試みた
- 設定値を引数に使いたいという汎用化だったので、引数に辞書を投げ込む形式にした
- 辞書なら、キーで設定項目名を示せば、設定値がどんな意味を持つのか直感的に理解しやすいと考えての設計
- 4月に受けた「コンセプトや処理構造はよいが、設定方法が煩雑」というレビューを一応克服できた
- 要望(要求仕様)が複雑かつ不明瞭な製品カスタマイズの要件定義を行った
- レースコンディションが考えられたので、図に起こして整理し殆どのパターンを自力で洗い出せた
-
Developers Boost 2019に参加した
- 懇親会の場で黄色の人と話す機会があったのが大きい
わかったこと
- 「見てわかる」ことは、ユーザーやサポートの操作を考える上では重要
- 設定の形式を辞書にすれば、パラメータの指す意味が混同されにくくなる
12月
やったこと
-【イベント】Developers Boost 2019 に参加してきた【ふりかえり】
- マイクロソフト社のイベント[MR 徹底解説] HoloLens 2 x MR Azure Services で実現する世界に参加
- ふりかえりは別の記事で
- この1年のふりかえり
わかったこと
- アウトプットは結構大変
- 自分用のメモのようなログと違い、他人が読むことので端折ることができない
- 階層構造とかに頭がいって本文が進まない
- Mixed RealityやVirtual Reality関連は何かのきっかけで一気に普及する気がする
- Minecraft Earthも高度な技術が使われていて、よくよく考えるととても興味深い
- だんだん廉価化するなどして一般化が進むというよりは、何らかの革新的なサービス一つで爆発的に普及しそうなイメージがある
1年全体のふりかえり
やったこと
- 「半年で戦力になる」という期待を達成した
- 実際に作ってみて/やってみて学習するスタイルと内容が上手くマッチした
- 「半年で戦力になる」という目標が達成できなかった
- 「製品本体にも携わるようなレベル」を目指していたので個人的にはまだ目標の道半ば
- 高望みが過ぎたかもしれないが、志が低いよりはよいだろう
- ふりかえりをはじめた
- この1年のふりかえりなど
- Developers Boost 2019で黄色の人を知ることができたのが大きなきっかけ
わかったこと
- 言語への理解度が足りない
- 大きな範囲での設計や不具合に対するディスカッション等で、どうしてもわからない話題が多い
- 都度質問してはいるが、言語の体系的知識があればわかるような内容が多かった
- 刺激を得るには外部のイベントに参加するのがよい
- 社内や私生活だけではどうしても習慣化された刺激が多い
- 何かのきっかけをつくるにも、自身の駆動力のみで動き始めなければいけないので大変
- 受ける影響に良し悪しあれど、しばらく採用しておいて、しばらく実践してからその良し悪しを考えればいいかなと考えています
- ふりかえりは記憶の整理や定着に有用だが大変
- 経験を思い出して再出力するというプロセスでかなり記憶が整理される
- しかし思っていたよりもとても時間がかかる
つぎやること
- MSCD : App Builderの取得
- マイクロソフトの認定プログラムで、複数の試験から構成される
- 体系的知識の習得を目標とする
- まずはProgrammming in C#の取得を目指す
- イベントの探し方を見つける
- 今はマイクロソフト社の法人受けイベント案内ぐらいでしか探せていない
- どこかイベントに関する情報源を見つけて整理したい
- 継続的な自身のふりかえりやアウトプット
- TwitterやQiitaを活用して継続的にふりかえりやアウトプットを行っていく
- チームや会社のふりかえり(状況整理?)
- 一部の人(マネージャー)のタスクが過剰になっている
- 複数の部署の担当から有効性が疑問視されている化石(社内システム)がある
- こういった課題が、どんな背景はあり、どんな状況にあるのかを整理していきたい
おわりに
エンジニア1年目をふりかえると、ひたすら目の前に迫る壁を乗り越えていただけではあるものの、そこそこ成長できたように思います
しかし、今後は与えられるタスクから目新しさが減っていくはずで、自発的に新しいことを見つけて吸収していく必要がありそうです
様々なイベントに参加して新たな刺激を受け、新たな刺激をふりかえって新たな目標とし、新たな目標へ向かって努力し、その過程でまた新たなイベントを見出す
そんな成長のサイクルを生み出せるようにアンテナを張って、今後の成長を促進したいと思います
きっと、参加したイベントたちのふりかえりを終える頃には、そんなエンジニア2年目が始まっていることでしょう
ふりかえりとアウトプットのきっかけを下さった、黄色の人やふりかえりアドベントカレンダーの参加者の方々に心からの感謝を
アドベントカレンダーの次のバトンは、渡部 壮彦さんへとお渡しします
執筆中に気づいた
黄色の人が「弟子になりたい人がいたら…」とツイートされてたが、ぜひとも弟子になりたいと思った
こんなにも「ふりかえり」を広範囲かつ体系的に整理していて、なおかつ、わかりやすく解説してくれるような人を他に知らないからだ(知らないだけでいるのかもしれないが)
まずは個人のふりかえりについて、そして機会を作れればチームのふりかえりについてアウトプットしていき、ゆくゆくはふりかえりについて意見を交わせるまでになりたいと思う