社員の活動紹介

メディカルネットワークグループ

[画像]

こんにちは! ご機嫌麗しゅう! またまたigoです。コラム3本目は本年私が担当した新人研修からのネタです。

数年前、富士フイルムソフトウエアの新人研修の大部分は社員が講師をしていました。私も結構な注力度(大体3週間分ぐらいでしょうか)で講師を担当しており、コマ数が講師中でも一番多いことからカリキュラム設計にもがっつり携わりました。

セルフマネジメント、チーム運営、要望の聞き出し、モデリング、オブジェクト指向設計(Open-ClosedとGRASP)、リファクタ…と、もう、盛りだくさん。流石にあまりに講師側が大変なので、その後社内講師の割合を大きく下げた経緯があります。

そんな中でも1コマ(半日)だけたくましく残っている私の担当からのご紹介です。大きく3つの観点で講座構成しています。ところで3部作って、なんだかかっこいいですよね。だって、トリロジーですよ!ダンテですよ! ボーマルシェにスターウォーズですよ!

講座のお題の中心は仮説演繹です。実験系の大学院で科学哲学の教養科目としてたまに題材にされる、Strong Inference(※1)というScienceの古い論文をまず、読んでもらいます。
(※1) John R. Platt (1964). "Strong inference". Science. 146 (3642): 347–53.

観察された事柄に対して

 1.二者択一の対立仮説を設計する
 2.1の2つの仮説について、得られた結果により片方の仮説を棄却するような実験を設計する
 3.クリアな結果が出るまで2の実験をする
 1’.残された仮説について更にサブな仮説や連想される仮説を作成し、1に戻る

を繰り返す、という方法論です。

この繰り返しにより関心事が常に半分ずつそぎ落とせることになり、結論にたどり着くのが早い、という仕組みです。

勿論、現実はこんな簡単には行かないものですが、要求分析や不具合解析、設計書が残っていない実装の意図を理解したいときなど、予想を立てて立ち向かわなければいけないようなソフトウェア開発の様々な場面で活躍します。その強力さを実感してもらおう、というわけです。

この論文を一時間程度でざっと読んでもらい、要旨をざっくり把握してもらったうえで幾つかのお題に対して仮説立て、実験設計あたりをやってもらいます。

アイデア出しのお題は「京都鴨川のカップルがどうしても等間隔に並んでしまうという性質があると仮定して、それを確認する実験を設計せよ(※2)」「カクレクマノミがハタゴイソギンチャクに刺されない理由を解明せよ」「走る新幹線をスマホで撮影すると窓が斜めになる理由、仮説立案せよ(※3)」あたりです。
(※2) 模範解答としては「カップルの間に座る」としています。この後、両脇のカップルが距離を保とうと移動し、それがまた隣のカップルの移動に繋がり…と順に移動していく現象を観察できた、としています。京都の学生自由研究コンクールで入賞したネタが秀逸だと、私の学生時代の助教の先生がその昔教えてくれたのですが、実はWeb上からはその元ネタは見当たらず…あくまで実験設計の練習と割り切って引用元の不明瞭さには目をつぶり、お題にしています。
(※3) ローリングシャッター歪みと言われるやつですね。ウチの当時5歳の息子がNHK教育「考えるカラス」をかぶり付いて見ていた時にあぁ、このネタ使えるな、と。

答えは一つではないし、複数考えた答えの中からどれが対立仮説や検証実験としてより良いか?という美学な世界で悩むという点で、みんなで議論を楽しんでもらおうといった魂胆も籠めてあります。

上記お題の2つ目、「カクレクマノミがハタゴイソギンチャクに刺されない理由を解明せよ」において観点その2、引き算の考え方を体験します。

[画像]

愛媛県立長浜高校水族館部(水族館部があるってさ!羨ましい!)の2014年の研究報告(※4)よりのお題です。
(※4) サイエンスメンターニュース Vol.1, No.6, July,2015, 日本科学協会

この報告の海水の組成に着目した実験設計を題材として取り上げています。

「イソギンチャクはなぜクマノミを刺さないのか?」というお題に対し、「海水に対しては反応していない(海中で刺しっぱなしになっていないですからね)」「物理刺激に対しても反応していない(岩にあたっても刺さないですからね)」といった観察結果を前提として「イソギンチャクが刺す条件を見つけるための実験を考えよう」のアイデア出しをします。

大抵は数分もせず発想に行き詰まるため、開始直後にヒントとして海水組成を新人の皆さんに提示した上で「海水に対して反応しない(=イソギンチャクが海水と判断している)」条件を見つけるための実験を考えてもらいます。

出典:化学と生物 1984年 22 巻 7 号 439-445

この組成表を提示された場合、イソギンチャクにとっての海水を作るのに最低限必要なイオンの組み合わせを導出するために総当たりの実験を始めようとすると10種類のイオンの中から複数種類を選び出す事になります。

∑10Cn(n=1…10)の1022通りとなり、実験の数としては現実的ではありません。そこで引き算の実験を思いつくか?が分かれ目となります。

要は上記組成から一つ抜いた溶液を一つずつ作ってイソギンチャクがさすかどうかを確認し、刺したらイソギンチャクが海水とみなすのに必要な条件じゃん!というわけです(そのイオンは必ずしも1種類とは限らないことに注意)。

上記イオンの数分、10通りの実験のみで済むわけですね。実際にはマグネシウムイオンの有無のみがイソギンチャクの刺胞射出を制御していたことを長浜高校の皆さんは突き止めています。

他にも例えばあの、iPS細胞における24個の遺伝子の中から4つへの絞り込み過程でも同じロジックが鮮やかに決まっています(※5)。
※5 「iPS細胞(人工多能性幹細胞)と山中さん」特技懇 2019年 5月 293号 「そんなに考えないで、1個ずつ除いていった らええんやないですか」の一言が強烈。

これも仮説演繹と同じく使える場面が多々ある発想法で、例えばPCを色々といじったら起動しなくなったなんて時の原因の推定や、要素検討時の試行錯誤において上手くいかない原因候補を挙げる時等、様々な場面で試してみる価値のある発想法です。

観点その3は…と、思いましたがちょっと長くなってしまいましたね。観点その3はまた、後ほど、としましょう。
なんだかTV番組の「答えは後ほど!」的なアレになっちゃいましたね。ごめんなさい!それではまたお会いしましょう!

[画像]

ご機嫌麗しゅう!またigoです。私の住む南足柄では拡大造林政策の恩恵(?)にあずかり、毎日なんだか目が痒いような鼻がムズムズするような、そんな季節となりました。

戦後の我々の祖父や曾祖父世代の旺盛な住宅需要の結果の木材不足、それによる国民の不満を受けて林野行政の急拡大、それでも足らずに海外に頼り木材輸入緩和、結果、杉が育ち切る前に海外のぶっとい、いい木材が低価格で入手できるようになる、そこで競争力確保のための国内材安売りによる価格崩壊、で、林業が支えきれずに最低限の森林整備でしのぐ、結果杉は伐採されずに元気に花粉をふりまく、という何かが吹いたら桶屋が儲けたような、そんな流れですね。

こういう経緯をよくよく腹落ちすると一概に行政や政治家に不満をぶつけても仕方ない(そもそも国民の願いだったわけですから)、じゃぁどうにかできないかなぁ、とひとまず家の掃き・拭き掃除(※1)で身の回りの花粉退治を始めるわけです。
(※1) 花粉は水で壊れるため、空拭きのほうがよさそうです。破片にもリガンドがありますからね。

さて、そんな小春日和の穏やかな日は4月のIPA高度試験対策を効率的に進めたいぃ~(※2)。
(※2) 車の運転をしながら母が良く口ずさんでいたものです。

弊社富士フイルムソフトウエアではシステムアーキテクト(SA)、ITストラテジスト(ST)といった高度試験合格の暁には20万円の資格補助金を美味しく頂けます。入社してすぐ試験に合格すれば転職にまつわる収入の不安も幾分解消されるかも。

ところが、我々IT技術者にとってPCも使わずに計3,000字の長い文章を短時間で記述する午後II試験の鉛筆筋トレは苦痛でしかないようです。理系出身な皆さまが多いこともあり、作文に苦手意識を持っている方も多いですよね。

だからこそ事前に文章の構成をパタン化し、当日はただただ文字を書くだけと作業簡易化したいものです。早速過去問を眺めてみましょう。

出典:令和3年度 春期 システムアーキテクト試験 午後II 問2

記述量が最も多い設問イは1,600字までの作文です。義務教育の過程で「起承転結」「序破急」「序論本論結論」なんて形で文章の構造化について習ってきたわけで、IPA試験対策の参考書でもこれらを鉄則としていますよね。が、一番細切れな起承転結で設計するにしても一部当たり1,600/4=400字のネタが必要なわけです。原稿用紙1枚分、丸々を1ネタで記述することになるわけです。これはキビシイ!ヒジョーにキビシイです。

ちなみにこの文章は、ここまで1,000字程度。ネタは花粉→春試験→春試験の作文と大きく3ネタで文章を構成しています。1,000/3=300字強。徒然書くにしても、また、読むにしても1ネタ300字程度が無理ない文量であること、示唆されますよね。

さて、1,600字の作文、どうしましょう?ここで世の中一般の作戦を拝借します。○○には3つある、通称「ポイント3つ」パタンです。設問イは設問アを受けてどう分析したか?その結果どう設計したか?を問うています。従って、設問アの時点でポイント3つパタンを適用しておきます。「機能追加が必要になった背景は3つあった。」と実は3つ、まだ思い浮かんでいなくても書いちゃうわけです。

そして、例えば

  1. 20年に及ぶメインテナンス開発の結果、似て非なる機能が追加され、ユーザの混乱と誤操作を引き起こしていた。そのため、機能の整理統合が必要だった。
  2. 合わせてユーザの利用環境の変化によりスマートデバイス等PC以外でのアプリケーション利用が切望されていた。
  3. 定年後再雇用制度の浸透により画面の文字の大きさに対しての不満が増加してきた。一方、ユーザには若年者も一定数おり、同一端末における表示の棲み分け要望がでてきた。

的に心の引き出しにしまっておいた今の世の中でよくありがちな問題点、要望をそれっぽく列挙しておきます。上記箇条書き3つで計200字程度です。

設問アの800字に対して対象の業務、システムの概要をコンセプトレベルの説明で200字ずつさらに記述すると600~700字程度、これで回答アの完成。

そして回答イへ。【機能統廃合について】【マルチデバイス対応について】【UI改善について】と3つに分けて「アクター毎のユースケースを想定し、それぞれのワークフロー単位で機能化していたため、一つの機能に対してアクター毎に似た実装が複数なされる設計となっていた」「ハードウエアとその制御アプリケーションの境界があいまいな状態で機能縦割りの構造だった。そのため、Viewとロジック実装が密結合しており、PCネイティブな環境で動作させるしかなかった」「ユーザ管理機能はログイン認証のみ。実質アドミニストレータ1アカウントでの運用となっていた。実質的なアカウント管理機能そのものが存在していないため、そのままではユーザ毎のカスタマイズを実現できなかった」とこれまたありがちな分析を大体5文程度で続けるわけです。

で、その構造のまま回答ウへ。「機能とアクターで2次元の表を作成し、アクターの属性を事前条件へと設計しなおすことで1機能複数アクター構造として機能統合、この機能設計に追従するため、コマンドパタンで事前条件判定によるコマンドリスト作成+コマンドリストの連続実行フレームワークの設計とし、機能追加時はコマンドリストを新規に作るのみでコマンドクラスの再利用を促進、機能追加設計を容易にした」「View部分を大きめの1レイヤとしてハードウエア制御から独立させた後、ViewレイヤにV・VMをWeb系のフロントエンドフレームワークを利用して導入、ブラウザ動作とすることでマルチクライアントに対応」「ロールと権限でざっくりと再設計、ロールに対しての要望は特に存在していなかったため、若年・ベテランといった年齢区分を疑似的なロール分類として採用」と続けます。

図にするとこんな感じです。

図 作文構造化

一箱200字~300字程度で記述するとさほど困ることなく収まりがよさそうです。

この流れを過去問3問分ほど練習したら後は「心の引き出しにしまっておいた今の世の中でよくありがちな問題点、要望」を10個ほど在庫しておきましょう。試験ではそこから3つ取り出すだけ。IPAの高度試験の作文はSA:設計作戦、PM:コミュニケーションや助け合い、ST:先読みと対策、及び効果的な実施時期といった各区分特有のロールプレイを要求されます。自分のかかわっているシステムのユーザ視点での不満、改善要望をいくつか挙げ、それぞれの立場で一段抽象するだけで対処ができます。妄想を膨らませ、引き出しにため込みましょう!

どうです?上手くいきそうでしょう?

さて、それでは練習問題です。

お題:あなたは新々型インフルエンザの猛威に備え、ワクチン予約システムを超短納期で整える事となりました。「ST:先読みと対策、及び効果的な実施時期」な立場で設問ア~ウの要領で作文してみてください。

そんな立場、経験したことないよぉ…という方は身近な企画担当上司や時事ネタなニュースを想定してその立場になって想定してみるといいですよ!

「注射は本人にするものであり、同一人物による複数の予約があってもどれか一つの枠で実施されるもの。予約システムはあくまで順番待ち行列をシステム化する責務に徹することとし、納期・コストを勘案して初版ではシステムによる自治体個人情報との突合せチェック機能の構築はあきらめる。注射実績は自治体による集計に任せることとし、予約システムでの同一人物重複予約は一切不問とする。一方、システムへの不具合指摘が広がることを想定し、ステイクホルダとの合意形成を優先、マスコミ発表用の文案を事前作成するため、コンサルタントを入れる。」といった通例では採ることのできないストラテジックな、ステキな妄想(※3)を楽しく書けるかも。
(※3) 本当にそんな作戦を取っていたかは定かではありません。あくまで私の妄想です。

富士フイルムソフトウエアは通年で社員募集をしています。資格助成も充実しており、検討の価値ありかと。是非是非よろしゅうお願いします!

[画像]

こんにちは、igoです。富士フイルムソフトウエアにおいてメディカル2部門(メディカルネットワークグループ、メディカル機器グループ)の技術責任者を担当しています。今日は我々の部門で行っているモデリング訓練の紹介をしようかと。

ご自身の本棚にある最も分厚い本を選んでみてください。ご家族に「この本どんな本?」と聞かれたとき、納得を得られる説明ができますか? 冒頭からの章立順にそれっぽく筋を説明して、理解を得られるでしょうか?例えば、桃太郎。最も短く説明するとすると「おじいさんは山へしばかりに行きました。おばあさんは川へ洗濯に行きました。桃太郎は鬼が島へ鬼退治に行きました。」とでもやってみますかね。

物事を端的に要約すること、それが抽象化です。抽象化を行うと一般的に物事があいまいになってしまうため、ソフトウエア開発では決められた表現で標準的な図にします(我々、富士フイルムソフトウエアではUMLが使われます)。これをモデリングといいます。数百万行あるソフトウエアを深く理解して継続開発するために必須な能力が抽象化能力であり、抽象化された設計内容を正確に伝えるために大切な技術がモデリング能力です。抽象化能力とモデリング能力、この2つを最大限に利用して適切な設計を行うことで、開発効率は大幅に向上するわけです。そして、これが失敗すると後々の足かせになり、不具合や開発効率悪化として現れるのです。この2つの技能向上こそがソフトウエア設計者の能力の源泉、そう考えて私たちは若手中心にモデリング訓練を継続実施しています。

[画像]カレーライスの作り方は調理作業の繰り返しでしかない。レシピにはその作業と順番が定義されるため、レシピの質こそが大切である。

図1 「カレーライスの作り方」のモデリング

[画像]一連の画像処理は個別の処理の繰り返しでしかない。処理順を変えることで、画質向上を行うことがよくあるので、画像処理順の管理こそがキモ。

図2 「画像処理」のモデリング

さて、実際のモデリング訓練では身近なものを題材とします。図1は「カレーライスの作り方」のモデリング(クラス図)。図2は「画像処理」です。どうです、そっくりでしょう? 実際の開発では、せいぜい年に5機能程度しか設計できません。一方、週に一度のモデリング訓練では年に40回以上の設計訓練を行えるわけです。設計行為を疑似体験し、知識→スキルへと昇華させる。これがソフトウエア技術者のための技量鍛錬になるんですね。まず、実際のカレーライスの作り方を頭の中で検証したり、オブジェクト図で表現したりしながら、「カレーライスの作り方は所詮、一口大に切られた食材をその前工程までに作られた調理済み食材があるに鍋に繰り返し投入することでしかない。」といった抽象化(=コンセプトの導出)を行います。その後、そのコンセプトを図で表すとね、とクラス図で表現するわけです。これを15分ほどで一斉に実施し、ホワイトボードにそれぞれ書き出して議論します。着眼点の違いや他人への伝わりやすさの議論は楽しいものです。

私たち富士フイルムソフトウエアで扱う製品の寿命は非常に長く、モノによっては20年以上もメインテナンスしている製品もあります。大先輩が作った製品を上手に理解し、壊さないように機能追加する。あるいは、20年後の後輩が機能追加しやすいように適切にフレームワーク化し、コンセプトを設計に残す。そんなやりがいある仕事を上手に進めるための鍛錬、一緒にやってみませんか?